Cloud Migration Strategies

Introduction

“I don’t need a hard disk in my computer if I can get to the server faster… carrying around these non-connected computers is Byzantine by comparison.”

said a certain Mr. Steve Jobs talking about the cloud.

Why are CTOs and CIOs all over the world excited about migrating to the cloud? Why is there so much rush and buzz about going to the cloud?

‘Why not?“

says me.

If something provides on-demand availability, elasticity, flexibility, reliability, better business continuity and security while being light on the wallet – why not?  But mere thinking about migrating to the cloud does not take us to the cloud. Migration to the cloud is hard. It can get messy! So there needs to be a strategy, a structure and method to this whole madness.

It is hard because there is no sure shot answer to which strategy is the best. There are 3 main variables to the equation- tweaking which could change the strategy you might want to use:-

1. Lead Time: How much lead time have you got?
2. Cost/Effort: What’s your budget?
3. Complexity: How complex is it going be?

This blog talks about high-level strategies that will help businesses to migrate to the cloud and how these strategies fit against the variables mentioned above.  

Let’s get into it.

6 R’s of migration

Migration Strategies

The phrase ‘6 R’s of Migration’ was first coined by Gartner back in 2011, and now it is being used a standard to talk about migration. Here are the most commonly used migration strategies generalized: –

• Rehosting

Also known as “lift and shift”. This means – migrate the applications, services, databases without any changes. In the large-scale, legacy migrations involving a portfolio of apps and services – organizations typically go for lift and shift as the first step since these can be get done with quickly and help meet business objectives at the same time.

It is worth to be noted that, the re-hosted applications might not be completely optimized from the get-go. It certainly requires enhancements after the migration to be fully cloud-native and cloud optimized. However, this strategy can be looked at as something that provides quick wins.

• Re-platforming

As part of this strategy, while the core architecture is still kept intact, certain cloud optimizations or tweaks are applied to the apps, services or databases.

An example could be migrating your existing My SQL relational databases to the Azure SQL Database Service or migrating your IIS based ASP.NET Web App to a fully-managed Platform As a Service offering. In both these examples, there is no change to the overall architecture – but there is a tangible change to the philosophy that helps unlock the benefits which the cloud has to offer.  This helps organizations’ engineering teams to focus on business value and not worry about infra.  

• Repurchasing

This strategy means fulfilling the business needs using Software as a Service (SaaS) model.  In an enterprise, it is typical to find a licensed, commercial off-the-shelf (COTS) product developed by an Independent Software Vendors (ISV) that solves a specific problem and integrate that within the enterprise.

E.g. using WordPress or Drupal for all the content management needs. Or using the customizable Workday as an HR module and migrate the entire application to the cloud is a classic move enterprise make.  

Most of the ISVs provide a “cloud version” of their platform in AWS or Azure Marketplace and which can be directly integrated into the existing cloud-hosted application/service. Using the SaaS model ensures that the application is always up to date with the latest features and supports “don’t invent your own wheel” strategy.

• Refactoring/ re-architecting

This strategy is all about re-imagining the application/services/database stack and introduce cloud-native features to enrich the application from scalability, security and stability point of view. Considering the investment it will take, it needs to be strongly backed by the business needs.

E.g. a certain organization has a monolithic platform that is experiencing the stability and scalability issues – as part of this strategy, this platform can be re-architected and migrated to let’s say Azure Kubernetes Services using microservices pattern that enhances the business and makes it future proof as well.

• Retire

Get rid of the applications, services or databases that are no longer needed by the business users. Many times, you would be surprised to see that as much as 10%-20% of an enterprise IT portfolio is no longer required or has outlived itself. Sometimes there might be multiple apps, services within an enterprise that are performing redundant operations.

This is an opportunity to consolidate and decommission these legacy applications which helps eliminate the operational costs and enable your IT teams to focus on business-critical applications.

• Retain

This strategy means “Do nothing for now”. This strategy can be used where there is no strong business justification or business benefits of migrating to the cloud. Sometimes, such apps, services require massive refactoring before it can be moved to the cloud.

This strategy does not eliminate the possibility of cloud migration, it just says currently there is no good enough justification to move to the cloud.

Some examples in which retain strategy is wise could be: –

1. There are compliance and regulatory requirements where data can be stored and cloud provider doesn’t support that
2. A certain enterprise has recently refreshed the licenses across data centres

So which strategy should I go for?

There is no definitive answer to that question. It kind of depends!

• Cost of Migration

Cost vs Complexity vs Time

As shown in the graph above the cost of migration and complexity are proportional to each other. Cost goes up if you start refactoring architecture, code – since complexity goes up along with it. But in the long term, you get all the good things that cloud offers. But if project timeline is a larger factor and business is looking for quick wins – re-hosting (using either IaaS or containerization) or investing into SaaS product would do.

Many organizations go with the hybrid approach. As a first phase, they migrate the apps using the Re-hosting (lift n’ shift) strategy. Obviously, it does not unlock all the benefits that cloud offers – but it takes them closer to the ultimate goal. As a second phase, or as multi-step process – enterprises start doing re-platforming or refactoring and start introducing more and more cloud-native features. This way they can control both complexity and cost factors over a period of time.

It is typically recommended to start with applications that can be re-hosted to help build confidence and achieve some “quick wins” while applying the learnings to future migrations as we build confidence.

Complexity and Opportunity

Complexity vs Opportunity

Let’s look at it from another angle. While we know that rearchitecting strategy is going to take more resources (time and cost) it does provide better opportunity to optimize.

Conclusion

To reiterate – going for a phased migration approach is probably the best choice. Focus and prioritize business functionality in the first phase, rather than attempting to do it all in one step. In the next phase(s), applications can be optimized for cost, performance, productivity etc.

If you could sunset and retire apps, nothing like it. If you have too much invested in the on-premise infrastructure and there is no strong reason to go to the cloud – retain.

Cost optimizing for cloud?

Introduction

We live in an era where every Tom, Dick, and Harry wants to go to the cloud. When you ask them “Why?”, they pin you to the wall and say “because I want to save some dollars for my organization!”.
Well, they have got the correct idea, but just mere thinking of “going to the cloud” does not save the cost isn’t it? Or for that matter, just going to the cloud might or might not save the cost as well.

You want to optimize for the cloud, you need to design for the cloud!

Optimizing for the cloud is a continuous process. There is no magic pill or lever that you can pull to start saving cost. In this blog post, we are going to discuss a process to optimize for the cloud and few tips that will help optimize the cloud bill.

What is cloud optimization, anyway?

This term could optimization could mean different things to different organizations – but here is my attempt to generalize it, simplify it.

Stay with me.

Cloud Optimization is about 2 or maybe 3 things really:-

• Being smart while procuring the cloud services, storage, and infra
• Being smart about mapping your workloads to the correct cloud capacity
• Monitoring the traffic, workloads and keep adjusting

Ok, tell me how do I do it? 

• Find unused resources and get rid of them

Identify the resources that were created accidentally and are not being used anymore. Find that “Test_Jan_2011” Azure SQL Database from your Azure subscription and kill it.

The best and probably the easiest way to optimize cloud costs is to audit regularly and identify the unused or dangling resources. How many times have you seen that a developer creates a “quick test” EC2 instance and forgets to delete or turn-off once done? Or for perf testing, your testing team scales up the App Service and forgets to bring it back to the original state. Far, too many times, isn’t it?

The idea is – organizations should have a continuous audit to find such unused pieces and delete them off, otherwise such resources will keep on eating into their wallet.

• Automate Rightsizing 

Rightsizing is a continuous process of doing the demand and supply mapping. It is a process of looking at the demand (workload) of a particular resource and identifying the perfect supply (E.g. CPU, Memory or Storage, etc.) that is a good fit. It is a process of finalizing the computing services and modifying them to the most efficient size.

Typically, service admins have a practice of over-provisioning when a new environment is created. To be fair, they do not have any or very little idea, what kind of muscle power would be required, so they over-provision to be on the safer side. Which is ok! What’s not ok though is – when they do not correct it or make adjustments over some time.

The idea of right-sizing is to look at the usage of a compute resource and scale it down if it is not needed. E.g. Service Admin created a VM with 16 cores and found after a month that hardly 4 cores are being used for the work, he/she is expected to scale that VM down to 4 cores and rightsize.

If you could automate this process of environment creation and standardize the resource capacity using IAC (Infrastructure-as-code) utilities like Terraform or Cloud Formation Templates etc. that would be the icing on the cake!

• Monitor and Merge 

It’s extremely important that you keep on monitoring all the infrastructure, compute, and data resources using your favorite tool of choice. Pick up your favorite heat map tool that shows which resource is being utilized when and how much. For establishing auto-scaling patterns, it’s important to know how much and when a particular resource is being used. Such continuous monitoring will help in identifying the patterns where you are spending way too much unknowingly.

E.g. during the night, since the traffic is only at 10%, databases can be scaled down to Small size and during the day-time when the traffic is at its peak – it needs to be scaled up to Large size.

The monitoring will help identify the egress and ingress (costs that are typically ignored, but when multiplied could be a dent in your pocket.)

E.g. what if we have an Azure Function or AWS Lambda that is polling the queue continuously? This means, even if there is nothing to process on the queue – there could be few processes that are doing long polling. Identifying such processes that would multiply the network costs – need to be identified and redesigned.

The strategy here is to monitor your infra in a continuous and consistent manner, identify the anomalies, identify the resources that are lying idle and consolidate/merge such resources. E.g. instead of having 3 Virtual Machines running at 20% CPU utilization – one virtual machine with 60% CPU utilization would be a cheaper alternative.

• Utilize the cloud vendor-specific features/discounts 

Organizations that are looking to hug the cloud for the long haul can improve upon the costs by investing in Reserved Instances. These are discounts offered based on reservation commitments and upfront down payments. If invested correctly, the savings through the right RI adoption can be up to 75%. But, it is extremely important that you have some visibility into the future demands and have done some analysis based on the past usage patterns to be able to purchase RIs.

Some cloud vendors also support what they call Spot Instances. Spot Instances are available for auction and, if the price is ok, can be bought cheaply for immediate use.

But opportunities to buy Spot Instances can come and go quickly. Spot instances are best suited for particular computing cases like batch jobs and jobs that can be terminated quickly. So hunting for Spot Instances and using them cheaply to get the job done should be an important part of all cloud cost optimization strategies.

• Auto Scaling

On-demand elasticity is the main virtue of cloud computing. Scaling up/out and down with just a simple command or slider from the web console is what most of the cloud vendors offer these days.

While scalability of the cloud is fine, what’s extremely important is to get the auto-scaling strategy right. When your infrastructure, cloud services, or storage scales up and down to cater to an increase or decrease in the demand/workload in an automated manner you get a very good cloud optimization story and a better overall throughput.

E.g. your background process increases or decreases no. of instances based on the jobs available on the queue. So if there are more no. of jobs to be processed automatically more no. of instances are spawned and removed once the no. of jobs on queue reduce.

Or looking at the CPU and Memory Utilization of your database you decide to increase or decrease the no. of eDTUs allocated.

Configure auto-scale, will ya?

• Resource Tagging Practice

Leveraging categorization and tagging practices easily sorts resources by the subject. Organizing the cloud expenses into types and categories, by means of a consistent tagging policy allows you to track and analyze the cloud costs better. Finding the real culprit becomes way easier. Most of the cloud providers use these tags to report on the monthly bill so these tags become super handy.

E.g. Tagging all development sources as “Dev” and all Test resources as “Test” helps identify – is expenditure more in Dev environment or Test? To further tag all storage resources as “Storage” and all services as “APIs” will further help in drilling down if the expenditure is more in Dev-APIs or Dev-Storage.

Tag it, while you are at it!

Conclusion

The cloud provides a lot of business benefits, with a pay-as-you-go model and without upfront capital expenditure, quick access to the resources, global scale, etc. This helps in focusing on your core business implementation but

it’s up to you how you plan and optimize the process of cost reduction while in the cloud.