Cloud Services

It is important to clarify what we aim to achieve.

In migrating to the cloud there are a number of approaches available.

You may simply wish to re-host your current environment (a 'Lift and Shift' approach). Or you may wish to re-platform along the way (for example, change your database infrastructure to be cloud-managed).

You may decide to opt for a completely different licensing model (or avoid licensing altogether).

Alternatively, you may wish to refactor all or part of your application's infrastructure in order to gain cloud-native benefits such as the realisation of elastic compute, decoupling and automatic scaling, or the introduction of machine learning or big data services which were previously unobtainable due to their high cost or complexity.

A thorough understanding of your goals is essential in determining which cloud provider and associated services to use.

It is during this phase that we begin to leverage our understanding by determining the components of and relationships between the elements of a cloud solution.

Whilst planning an architecture for the cloud, in addition to satisfying any core operational requirements, we must pay attention to security, reliability, performance and cost.

There is also a balance to be achieved between some of these factors, such as being prepared to incur higher cost in return for increasing the fault tolerance of the overall architecture.

For example, it may be determined that both primary and standby database instances are required in order to increase resilience and meet specific recovery time objectives.

This may further extend into operational considerations such as the provision of read-replica database instances for read-heavy applications to prevent contention (with write activity) at the primary database instance.

This phase is a natural extension of the architect phase whereby our architecture is realised and built.

This may often involve infrastructure as code technologies such as Azure Resource Manager or AWS CloudFormation to enable an easily repeatable build process together with being able to manage changes to the built environment.

Once built we are in a position to deploy data into the cloud environment which we have provisioned. In fact, we may sometimes deploy software or data configuration as part of the build process where it makes sense to do so.

In the case of database technology it is here that we may use replication and data migration tools to copy data from its on-premises origin to its cloud destination (for example using Azure or AWS Database Migration Service tooling).

For any data, depending on connectivity and data volumes, one might opt to bulk ship the data by means other than the network (for example using AWS snowball or Azure Databox).

Once you have tested the deployment to your satisfaction and are happily running in the cloud it doesn't end there.

The cloud is a fast changing environment, what was not possible one day may become possible the next.

A current trend is towards 'serverless' compute power so more serverless options and possibilities present themselves.

Whether this is right for you is another question, but in order to optimise both cost and performance efficiency it is sensible to keep an eye on developments to see if they may improve your systems over time.

You may have taken a 'Lift and Shift' approach when initially transitioning to the cloud and, having done so, are now more comfortable with operating in a cloud environment.

You may therefore wish to become more cloud optimised or even cloud-native by leveraging the full benefit of the cloud services available. Kronva is available to help you with this too.