Moving to the cloud?

Here’s A Quick Cloud Migration Checklist:

1. The right migration architect/partner

 

One of the foremost tasks before starting out with your cloud migration, is to find the right architect/partner – one who can perform a system-level planning and review all aspects of the migration. The partner can provide recommendations around the best approaches, data migration strategies, task prioritisation, and other critical aspects such as a fall-back plan, all specific to your environment.

 

2. Deriving your migration level

There are primarily two options of moving from your on-premise or co-located data centre to the cloud:

• A simple ‘lift-and-shift’ integration, or
• A deep cloud integration

Lift-and-shift: As simple as moving your application to the cloud and making little or no changes to your backend infrastructure supporting it. At best, you make certain modifications to the application itself, and move it straight to the cloud.

Deep Cloud integration: This involves re-factoring your application or workload to make the most of the resources and capabilities that are going to be used on the cloud. Let’s say, for instance, be able to use serverless computing on Amazon AWS Lambda, or, redesigning the application to be able to take advantage of unlimited storage & durability provided by Amazon S3.

 

3. The Cloud adoption approach: Single or Multi-cloud

Here’s a simple question to ask yourself before your start out on the migration: Do you want to choose a single cloud platform and optimise your application on it, or do you want to run it on multiple cloud providers?

The former is relatively simpler, with your developers having to deal with the stack of just one cloud provider. Why don’t we just choose this option, you ask? Well, too much dependency on one platform comes with its own downsides, viz. Vendor lock-ins and an equal (or more) amount of effort in case you decide to move to another cloud in the future. Needless to mention, the ability to negotiate commercials, SLAs & pricing better, when you set them up against competition!

Hang on just yet! A multi-cloud option could get complicated as quickly. Consider these:

• Would you want one application on one cloud platform while another runs on a different provider?
• Or would you rather get your application to run across multiple platforms?
• Or would you put in extra effort and funds, to build an application that is cloud agnostic?

Worry not, and just go back to our first point and find the right partner.

 

4. Establish Cloud metrics to track

 

It is always best practice to setup your cloud performance metrics (also known as Key Performance Indicators or KPIs) prior to cloud migration. They give you indicative, measurable parameters to see whether the cloud stack is performing as per your expectations or not. These may be similar, or quite different to your existing KPIs, specific to the workload and environment you are building. Let’s take a look a few examples:

For every category that is important for your business, derive the KPIs that provide visibility and help evaluate the impacts of migrating the cloud.

 

5. Create a comparison matrix

 

A process by which you can assess the performance of the application or workload pre and post cloud migration project. This is simple business management process where you set a baseline metric for every KPI and decide how long you will collect the data to form the baseline. Longer duration obviously takes longer, but allows for more accurate and effective outcomes. Another best practice is to collect data for all sorts of combinations, such as average, peak or critical timelines.

 

6. Finalise migration priorities and approach

 

A crucial step in the world of Cloud Computing, is to finalise the migration approach. Yes, we have mentioned that many times, but here, it is about availability and adopting loose coupling. Simply put, should you migrate your entire application at once, or move its various components, service by service?

Goes without saying, this will need your team to identify the various components of the application and their dependency on other components. Larger, complex applications can use automated application monitoring and dependency diagram tools available for Cloud Computing personnel, simplifying the process of making such critical decisions in the cloud adoption journey.

 

7. Perform ‘Refactoring’ (if applicable)

 

Refactoring, a word often used in the world of Cloud Migration, is nothing but about making changes to the application, in a way that its performance is optimised and effective, once moved to the cloud. Here are a few use cases for Refactoring:

• To ensure it works seamlessly in an environment that dynamically changes the backend infrastructure, in line with the traffic, using tools such as Amazon AWS Auto Scaling
• Better utilisation of resources for performance and cost-optimisation needs
• To move services component by component, thereby reducing potential errors while migrating to the cloud

 

8. Data migration plan

 

This has to be one of the trickiest steps in a cloud migration process. A lot will depend on how you decide to access the data, viz. whether the data continues to reside on your on-premise servers while the application moves to the cloud, or, move everything over.

What are our options, then?

• To start with, it is always recommended to create a bi-directional syncing system between the cloud and your on-prem databases, to facilitate fault tolerance. It is only after you have moved all your data to the cloud and see consistent performance, that you should remove your on-premise databases
• Allow for one-way syncing from your on-premise to cloud database, while the application or consumers continue to access the on-premise databases. Once stable, you can shift and connect to the cloud database
• Use widely available database migration services, such as those offered by Amazon AWS, Microsoft Azure, or Google Cloud, to name a few.

 

9. The final switch

Now that you’re ready to make the switch, how do you do it? Well, the usual answer always is, it depends on the architecture and complexity of your workload or application and how you store your data. Two highly common strategies are:

• One shot migration: Assess, evaluate and validate that your systems are working fine, then make the switch to the cloud infrastructure you created
• One bit at a time: Move individual workloads or components, move partial data, verify that it works, and slowly scale to move the entire application over to the cloud

 

10. Review

This is an ongoing, never-ending process. The cloud offers the kind of flexibility and agility that we could not hitherto comprehend. And there raises the need to constantly review your resources, for performance and cost optimisation, for securing your resources and for meeting demands when they peak, or even when they don’t. At CodeCulture Technologies, we are constantly applying our expertise in reviewing cloud best practices and systems for customers, optimising costs and helping them operate a lean yet effective IT stack.