4 Common Strategies for Azure Cloud Migration

Photo by Kenrick Mills

Introduction

When it comes time to transfer your application to a cloud platform, choosing the right cloud migration strategy is the key to success. The migration strategy you adopt determines your choice of cloud services and the steps needed to deploy an application to them. Off-the-shelf methodologies and frameworks, such as the Cloud Adoption Framework or Azure, are available to facilitate the migration strategy development process. The Cloud Adoption Framework describes all stages of preparing and implementing a migration to the cloud.

Here, we will take a deeper look at the four most used migration strategies: Rehost, Refactor, Rearchitect, and Rebuild. This will help you familiarize yourself with existing migration patterns and select the strategy that is most suitable for your application.

Rehost

Rehost, also known as “lift and shift”, refers to the direct transfer of virtual machine images from the local data center to the cloud. In this case, the type of application hosting changes and mainly cloud services from the “Infrastructure as a Service” (IaaS) group are used. During a Rehost, databases and file storage can be deployed on both virtual machines and managed databases and managed file storage services which are compatible with the IaaS.

This strategy is applicable when the migrated application includes a large number of legacy and obsolete code, special platform-dependent libraries or utilities. The strategy can also be used when there is a lack of resources for the migration process, e.g., constraints on human resources, time or the financial budget. The implementation of this strategy means that there is no need to make changes in the application code and deployment processes, thus resulting in high migration speed. Totally retraining or re-organizing your team is not required. Only administration, security, and cloud infrastructure operations change significantly. The development team can continue to operate in the same way as before, but the admin and operational teams will have to re-adjust to accommodate the use of cloud services. Problems with availability, reliability and performance of on-premise infrastructure can be mitigated by selecting the right IaaS services, setting up auto-scaling, having automatic backup and configuring full infrastructure monitoring.

There are two options for migrating virtual machines to Microsoft Azure: migrating to Azure VM IaaS (applicable to VMware and Hyper-V) or migrating to Azure VMware Solutions (applicable to VMware only).

Azure VMware Solutions is a dedicated, isolated, bare metal solution used to host entire data centers in the Azure cloud using VMware virtualization technology. In a typical case, migrating into the IaaS VM is more applicable. To facilitate this process, there is a specialized service called Azure Migrate, which works as follows:

• Set up prerequisites, prepare Azure subscription, and ensure that local and cloud environments have the needed permissions.
• Configure the Azure Migrate project, choose the necessary tools for assessment and migration.
• Download a virtual machine appliance and deploy it into the local environment as a virtual machine.
• Start discovering virtual machines and dependencies. Review the assessment and dependencies from Azure Migrate while scoping the target migration.
• Replicate virtual machines from the local environment into Azure storage.
• Test virtual machines using a test non-production virtual network.
• Migrate virtual machines into production using a production VNet.

The Azure Migrate service allows you to estimate VM sizes, and as a result, the cost of computing resources and storage deployed in the cloud. Also, service can suggest the right sizes of Azure VMs, based on the usage of your current resources. To optimize the cost for the current licenses, you can use Hybrid Benefits as well.
Rehost strategy has a number of shortcomings. After the migration, the application, together with its architecture and codebase, inherits all the possible problematic areas that might have been on the on-premises system. Hosting costs, as part of the total cost of running the system, can increase significantly, but if you plan and implement this strategy correctly, the total cost can be decreased substantially since you don’t have to invest in and manage on-premises IT infrastructure. For more details about the reasons behind increased cloud resource costs and how to reduce them, see this article.

Refactor

Refactor is a strategy where the migration of applications occurs with small changes in the code that allow you to deploy it to the Platform as a Service (PaaS) cloud group of services. PaaS services give developers less control over the operating system, which means that these services require that all dependencies necessary for the application’s operation are packaged in a deployable unit. Currently, the most used technology for this purpose is Docker, and the most widely used deployment environment for Docker containers is Kubernetes. Application refactoring consists of preparing the application for deployment as a Docker container and changing the deployment processes which includes implementation of DevOps methodology. Read more about how to use Kubernetes to deploy Enterprise applications in this article.

After dockerization, the application will receive all the benefits that containerization provides, namely:

• Fast software delivery cycles;
• Efficient use of hardware;
• Container isolation;
• Application portability;
• Fast startup process for Docker containers and readiness for auto-scaling;
• The same deployment process for microservices and for conventional layered architecture.

Another benefit of migrating an application to Docker and deploying it on the Kubernetes platform is platform independence. Docker and Kubernetes technologies are now the de facto industry standard supported by virtually all cloud providers.
Additionally, the managed PaaS services simplify and allow for fully automated administration and operational processes. To reach the full potential of managed services and containerization, it is necessary to implement DevOps processes in the team.
Compared to IaaS, PaaS services offer advantages in terms of greater availability, scalability, and reliability, which are built into the service and do not require complicated implementation.
In addition to migrating applications to PaaS managed services, data in relational databases can also be migrated to managed database services (e.g. Azure SQL, Azure SQL Database Managed Instances). The Azure Database Migration Service can be used for this purpose, which works as follows:

The first step of the Azure Database Migration Service is downloading and installing the migrated database server. The following services can be used as Azure Database Migration destinations: Azure SQL Managed Instance, Azure Database for SQL, Azure Database for MySQL, Azure Database for PostgreSQL, Azure CosmosDB and Azure VM SQL Server. The Data Migration Assistant prepares the necessary schema and data migration scripts, providing recommendations or warnings about possible incompatibilities between local and cloud database service.
The Refactoring strategy requires more time and effort than the Rehost strategy because it involves making changes to the code, formulating deployment processes, operations and adjusting operations and administrative routines for cloud resources.

Rearchitect

This strategy consists of breaking down the monolith code of the application services to be migrated into smaller pieces — microservices — which are deployed independently. Microservices can be implemented either on the Kubernetes platform or using Serverless services.

In some cases, the data access layer also should be rearchitected. To avoid dependency on a common monolithic database, highly loaded and high-performance microservices must have each of their own data sources. This means that data from general monolithic OLTP relational databases must be transferred to non-relation managed NoSQL databases, such as Azure CosmosDB.
In the case of complex systems, Rearchitech could be the most difficult and time-consuming migration strategy to implement, involving deep changes in code, processes of deployment, administration and cloud operation of the solution. Each microservice can be operated by one small DevOps team, responsible for both the whole microservice development lifecycle and supporting the cloud infrastructure. With this strategy, the migrated application can completely eliminate inherited performance and scalability issues. Each microservice is deployed and scaled independently, thus making very efficient use of cloud computing resources. Additionally, the code of each microservice takes up a small amount of space and is therefore easier to maintain, test, analyze, and refactor. The most appropriate framework and programming language for each microservice can be selected which, on the one hand, can significantly improve its performance but, on the other hand, may require additional development of a completely separate CI/CD pipeline.
To unlock the full potential of the microservices concept, the application code must correspond to the “12-factor app” approach. In order to minimize operating costs, you need to minimize the number of individual virtual machines in use that are not part of managed clusters such as the Azure Kubernetes Service, HDInsight or Azure Batch. For more information on optimizing the costs of cloud resources, see this article.

Rebuild

The Rebuild strategy involves recreating the system in the cloud from scratch, using only cloud services and cloud best practices. This strategy requires the most extensive implementation work but also gives you the possibility to use the maximum potential of the cloud provider’s services. You are able to take advantage of the most advanced and innovative technologies, approaches and processes when redesigning the system for the cloud.
Compared to Rearchitect, the cost of applying this strategy can be either higher or lower. It all depends on the complexity of the broken monolith and the degree to which the business logic allows implementation as part of microservices or cloud-native services.

How much do these strategies cost to put into action?

The differences in implementation costs for the four migration strategies are illustrated by the figure below.

The least expensive strategy to implement is Rehost, because it does not require any changes in the application code. The most expensive strategies are Rearchitect and Rebuild, as they require deep changes in both the code itself and in the development, support and operation processes related to the cloud infrastructure.
The differences in operational expenses for the four strategies are illustrated by the figure below.

The operational costs are the largest for the Rehost strategy and smallest for the Rearchitect and the Rebuild strategies. The main reason for this is that the two latter strategies take greater advantage of the cloud services and, therefore, require less administrative resources. The Rearchitect and Rebuild strategies also enable more efficient utilization of computing resources.
When adding the two cost components together you find the minimum total costs corresponding to the migration complexity of the Refactoring/Rearchitecting strategies. As our clients’ practice shows, migration to Kubernetes has the best “Migration cost / OpEx” ratio. That’s why, according to a study by Gartner, by 2022 more than 75% of global organizations will be running containerized applications in production, with most deployed in Kubernetes. Read more about how to use Kubernetes to create Enterprise solutions in this article.

Conclusion

In this article, we have covered the four most common strategies for migrating applications to the Azure cloud: Rehost, Refactor, Rearchitect and Rebuild. For each strategy, we have covered the conditions of applicability, the specifics of use, as well as factors that affect the cost of both the migration process itself and the subsequent operation of the system in the cloud. If you need help migrating your application to the cloud, please contact us for a free consultation.

Originally published at https://devops.fastdev.com