Businesses of all sizes are embracing the cloud. It is an agile, cost-effective platform for running software applications and ensuring the health and stability of a business. During this migration, application and proprietary software have been the key driving force to move out of private data centers into Azure. There are several approaches for migrating applications to the cloud. You can either migrate them as it is. Or, you can choose to modernize the applications to be more efficient on Azure.
Compared to private enterprise clouds, Azure is far more feature-rich. Most enterprise clouds are just virtual machine platforms. A few support containerization. In contrast, Azure offers databases, API gateways, CI/CD pipelines, and a lot more as managed services.
These services can simplify the software architecture and reduce DevOps work. But, when migrating an application from a private data center to Azure, you have to update the application to use these services.
Depending on how you choose to update the application, there are three main approaches to migrating.
As we already mentioned, most enterprise clouds implement virtualization only. Most enterprise applications also run on virtual machines (VMs), while some applications are installed on bare-metal servers. The lift and shift is an easy way of migrating these applications to Azure. You create VMs in Azure and deploy the existing applications on these VMs.
Azure has a flexible networking mechanism. So, you can set up the connectivity between the VMs in the same way you had the network connectivity in your enterprise data center.
The lift and shift approach require little to no code changes in existing applications. So, the time and effort for migration are minimal.
Applications migrated with the lift and shift method would still be running on VMs on Azure. So, they will inherit all the disadvantages of VM-based applications. You will not be able to implement agile DevOps practices with them.
While VMs may have less operational overhead than the bare-metal servers, you still have to do security hardening, patch, software upgrades, etc.
Once you provision the VMs, you get billed irrespective of whether your application is consuming all resources assigned to the VMs. So, overall, you may be paying more for the infrastructure.
Azure offers several popular open-source databases such as PostgreSQL, MySQL, Apache Cassandra, etc., as managed database services. You can also deploy self-managed databases on Azure using VMs and block storage.
Azure takes care of all the database administration work in managed databases. Compared to self-managed databases, the Azure managed databases offer better scalability and resilience. So, you must always try to choose Azure-managed databases over self-managed databases.
Managed databases support the lift and shift approach quite well. They don’t need you to change the application code.
Moving a step further, you can migrate the existing applications by containerization. This method requires specific code-level changes.
An application intended to run on VMs or bare-metal servers tends to be monolithic. It will contain the complete application code bundled into a single package. You must rebuild and repackage such applications into container images.
Let’s consider an example. An e-commerce application has a search function and a shopping cart function. When a user searches for a product, the application gets the search request, executes the search, and sends the results. The application receives another request when the user adds a product from the search results to the shopping cart.
A typical application is a collection of functions that will manage these requests. When running on VMs, a single VM will be responsible for managing all these functions.
To containerize such an application, you must re-architect it according to micro-services. It involves considerable code changes. But, you would be able to reuse most of the business logic already implemented.
Azure has two options for running containerized applications.
Azure Kubernetes Service (AKS) offers Kubernetes as a managed service. You can provision a managed Kubernetes cluster and deploy your application on it. Since Azure manages the Kubernetes cluster, it will take care of most of the operational work involved in managing the cluster. AKS lets you create multiple Kubernetes clusters, so you have the flexibility of logically separating multiple applications if required.
If your application does not need a fully-fledged Kubernetes service, you can use Azure Container Instances (ACI) instead. ACI is a service that lets you quickly deploy containers without provisioning a Kubernetes cluster.
Containerization increases agility. You can implement agile development workflows such as CI/CD for containerized applications.
Containerization also makes an application more scalable. Unlike a private data center, you are not limited by infrastructure resources in Azure. You can dynamically scale up and scale down your application based on actual traffic load. A containerized application enables this kind of scaling since new containers can be spin up in a matter of seconds.
Rebuilding and re-architecting require more time and effort for migration.
Azure offers a tool – App Containerization – to help users containerize and migrate their existing ASP.NET and Java web apps. It can build the container images from your exiting application infrastructure and then deploy the application to AKS. The tool also takes care of the configuration files. It moves the static contents such as images, CSS files, etc. to a persisted storage location at deployment
Azure Functions is a serverless compute service from Azure. It lets you write an application as a collection of event-driven functions. As the name implies, serverless makes the underlying infrastructure transparent. Azure takes care of spinning up compute resources, increasing memory and storage, patching and updating the application runtime. You are only responsible to write and deploy the application code.
Serverless architecture completely removes the burden of managing infrastructure. It delivers the true agility of the cloud. In the serverless architecture, the resource consumption is minimal. You will only pay for the computing resources that are consumed for traffic handling. A serverless application sitting idle will not accumulate any computing cost.
You can scale a serverless application instantly without being bothered about spinning up VMs or deploying new pods and containers. Within seconds, a serverless application can scale from a few hundred users to handle requests from millions of users.
To migrate an existing application to serverless architecture, you must do a complete re-write. You will be able to reuse only a very little of the code from the old application. You will be using specific frameworks provided by Azure to write a serverless application for Azure. So, you will not be able to deploy it at a different cloud provider without re-writing again.
We have described three approaches to migrating applications to Azure. Each consecutive approach requires more effort but delivers more agility. But, the best approach will always depend on the context.
Here are some considerations for choosing the migration approach.
Each consecutive migration approach we described, demand more migration cost but, optimize on infrastructure cost. So, you could calculate a TCO (Total Cost of Ownership) comparison for your application for each of these approaches to find out which method has the optimum cost.
You may be interested in simplifying the IT operations when migrating to the cloud. Containerization and serverless architecture can help you with that. The serverless applications do not require any infrastructure management, so you would be relieved from all operations tasks.
Containerization and serverless approaches require more effort for migration. But they will deliver more agility. It could improve your flexibility for accommodating business logic updates, improve scalability and reduce time to market.
The serverless model delivers the best cost efficiency. But it may not be the best option for all applications.
The serverless architecture may introduce a slight latency. A serverless application is event-driven. So the application is idle or sleeping when there is no traffic. When a request comes, the application has to wake up from the sleep status. This could be problematic for applications with real-time performance.
You may prefer the lift and shift approach because it requires the least effort for migration. After migrating, you could modernize the application incrementally by implementing selected parts of the application in Azure Functions. The Azure API Gateway can implement the request routing between the legacy and the new application.
This method can incrementally modernize a VM-based application to a serverless application.
These are just a few steps and technologies that can be applied toward application modernization. We know that there is no escaping the demands of the digital transformation that the global economy demands. Sustainability and vertical growth begin with innovation, and in this case, application modernization is the path.
EN 
ES