Cloud Photo

Azure Data Architect | DBA

Planning a Cloud Migration

,

This is the second in a series of articles discussing the pros and cons of various strategies for migrating to the cloud. In this article we explore five steps for a successful migration at a high level.

As an Azure Data Architect with nearly a decade of experience, I have seen countless clients with a desire to create a mirror image in the cloud of what is currently in the data center. Generally, this is referred to as a “Lift and Shift” strategy in which we lift the workloads out of the data center and shift them into the cloud. Of the five R’s, lift-and-shift is a rehosting strategy. While it sounds good in theory, there are other factors and strategies to consider.

First, what is a Lift-and-Shift strategy? Remember the big push to migrate physical machines to VMs? The P2V movement? A lift-and-shift approach is similar in that a workload such as a SQL Server can be migrated from an on-prem VM to a cloud VM. A VM on-prem is just a hosted CPU-Memory-Storage solution, right? If the solution is here or in the cloud, it’s all the same, no? Yes, but…

This is where things get spicy. Yes. You can migrate hundreds of servers from on-prem to cloud and configure secure networking, secure storage, and CICD processes. However, that is not the advantage of a cloud migration. If you have one problem on-prem, you will now have two problems in the cloud.

Lift and Shift Problem Number One
One common issue is network latency. On-prem, you have an isolated network in which application servers have direct routes to the database servers. Applications will need to be tuned to allow for latency. Clustered databases will need to account for latency as well.

Lift and Shift Problem Number Two
Your company has likely purchased a very beefy bare metal machine to host multiple VMs. If you need to spin up a small VM for testing, you can put in a request and have it added at little or no cost. In the cloud, everything costs. The CPUs, Memory, Storage and Networking all incur a cost that is usually more than a little.

Lift and Squish?
Lift and Squish is what I call it when you no longer want to lift a VM and shift it to a cloud VM. Some clients ask to migrate a SQL workload, for example, to Azure Synapse with minimal changes –  no changes to the SSIS packages, minimal changes to dimensional cubes and reports. While Synapse is comparable to an on-prem SQL data warehouse, there are several notable differences. For example, how the data is stored. Each table will need to be distributed among the Synapse nodes. Smaller tables can be replicated. Larger tables can be distributed based on a hash algorithm or based on a key column. Speaking of key columns, Synapse does not have the concept of primary and foreign keys. So, we can lift and shift that workload but there will be some squishing to make it fit and that means change. This hybrid of rehosting and refactoring rarely works out in the end.

The Right Way

Modernization and Migration
Modernization refers to four of the five R’s: Refactor, Rebuild, Revise and Replace. Modernization allows databases and applications to be modified and migrated in a way that takes advantage of the benefits of migrating to the cloud. Modernization requires a detailed discovery of your business and IT infrastructure. The following steps apply to both Lift-and-Shift as well as Modernization efforts.

Step 1: Analyze
Analyze your environment. Identify applications, databases, file storage, network partitions, firewalls, etc. Document how identities and security are managed. In addition to understanding the hardware and software involved, also document business and legal requirements. A cloud migration requires understanding PII (Personally Identifiable Information) as well as industry-specific regulations such as HIPAA. Even if the resource being migrated is container-based, understanding the impacts of a cloud migration will ensure success.

Step 2: Plan
Unless you are running on a small IT footprint with perhaps two database servers per environment and maybe three to five applications, your modernization efforts will not result in a big bang conversion. Rather, the modernization should occur in waves. The first wave is usually for those databases and applications that can simply be rehosted as is. The second wave might require refactoring the data or applications to fit in the new cloud architecture. Others might need to be completely rebuilt.
Based on the analysis of Step 1, plan which databases and applications can be easily rehosted, refactored, revised, rebuilt or replaced.  Planning the waves of deployment will help establish timeframes and thus align resources to ensure a successful deployment. This is also the time to plan for Wave Zero. Wave Zero is the very first step of creating subscriptions and security groups and defining a RACI chart of who will do what and who is allowed to perform which activities in the cloud. Wave Zero includes the fundamental building blocks required for Wave One.

Step 3: Design
While you can just start moving resources to the cloud, it will go much better if you design the “landing zones” for the resources. In Azure that includes identifying the subscriptions and resource groups, documenting a naming convention, etc. Now is a good time to design your Role Based Access Controls (RBAC) assignments to establish who is allowed to do what in Azure.
Other design considerations might include modernizing your entire stack to a microservices architecture or perhaps a hub-and-spoke model to decentralize and decouple dependencies.
The design for your cloud journey should also address deployment pipelines for databases and code as well as infrastructure. Many times we recommend an Infrastructure as Code (IaC) approach to make the entire environment easily repeatable. IaC eases the process or provisioning a second or third development environment and ensures an audited and consistent cloud deployment.

Step 4: Implement and Test
Whether you are modernizing or just doing a lift-and-shift rehost activity Steps 1 through 3 will determine how smoothly this step will go. Testing is also critical to ensuring that when you cutover a service from the on-prem data center to the cloud, your customers won’t notice.

Step 5: Repeat
Revisit your analysis, plans and designs. Ensure that they are still a good fit. Adjust where necessary and learn from mistakes and issues uncovered along the way.

Summary
Of the five R’s (Rehost, Refactor, Rebuild, Revise and Replace), rehosting can work in some situations. However, to take full advantage of the benefits of a cloud environment, additional R’s might be required.

Leave a Reply