In this blog post, I discuss an app modernization approach that we call “modernize-by-shifting.” In essence, we take an existing application and move it to “managed” container hosting environments like Azure Kubernetes Service or Azure Service Fabric Mesh. The primary goal of this app modernization strategy is to undertake minimal possible change to the existing application codebase. This approach to modernization is markedly different from a “lift-and-shift” approach where workloads are migrated to the cloud IaaS unchanged with little to no use of cloud native capabilities.

Step One of App Modernization by Shifting

As the first step of this approach, an existing application is broken into a set of container images that include everything needed to run a portion of the application: code, runtime, system tools, system libraries, and settings. Approaches to breaking up the application in smaller parts can vary based on original architecture. For example, if we begin with multi-tier application, each tier (e.g. presentation, application, business, data access) could map to a container image. While this approach will admittedly lead to coarser-grained images, compared to a puritanical microservices-based approach of light-weight images, it should be seen as the first step in modernizing the application.

Immediate, Tangible Benefits

Even as the first step in modernization, this approach can lead to tangible benefits. By moving to a “managed” cluster for hosting the containers, all the underlying Hardware, OS/Kernel and Cluster SRE (Site Reliability Engineering) become the responsibility of the cloud provider, like Azure.

As shown in the diagram below, once the application is running on a managed cluster, the application teams can completely offload the SRE work for lower layers to the cloud provider.

Source: Microsoft Ignite Orlando

Additionally, since the application is now captured as a set of immutable, self-contained images, the DevOps setup is greatly simplified for two reasons:

1. The exact same image gets deployed to the dev, test and production environments.
2. The need for automation scripts to deploy and configure the application on the target machine is greatly reduced.

Furthermore, with the advent of concepts like Helm Chart, you have a first-class notion of an application that fully describes all its aspect. Once the Helm Chart is defined for an application, it can easily be shared and deployed to any environment. Container orchestrators offer services like restart, logging, and monitoring that further lower the operational costs.

Finally, note that we focused on avoiding potentially expensive refactoring of the original application, as was often the case when moving to a pure play PaaS environment. This is why this particular app modernization approach can scale to a portfolio of applications that most large commercial or public sector enterprises have to deal with.

App Modernization Challenges

For all the advantages of this approach mentioned above, this blog post would not be complete without a mention of the challenges involved in this approach. A few of the challenges involved were:

1. 1. The steps in containerizing an application (often monolithic in nature) can be challenging. Specifically, you will need to discover the static and runtime dependencies of the application (a task often complicated by the lack of adequate documentation available for a legacy app). In many cases, runtime dependencies may be unsupported on the target host OS (that is hosting the container runtime). There may also be instances where the application has tight coupling to an underlying OS/Kernel. This is where projects like gVisor that offer a user-space Kernel for sandboxing such applications, comes in handy.
   2. The amount of work involved with the automation of the image creation. (Tools like Imaget2Docker can be a good place to start, but likely not enough.)
   3. The need for a robust understanding of containers, internals, and constraints (especially since Windows Containers are relatively new and evolving).
   4. For stateful portions of your application, you will need to understand container persistence mechanisms and match them against available IOPS. You will also need to think through the backup and restore procedures for your persisted data. This is where an understanding of native cloud services such as Azure Files or Azure Disks would come into play. Fortunately, there is a growing momentum behind specification like the Open Service Broker API that is designed to provide a standards-based approach for provisioning “native” cloud services, from Kubernetes tooling without a lock-in. Here is a reference to Azure team’s implementation of Open Service Broker spec.
   5. You will need to map any specific network isolation and other security requirements of your application to equivalent capabilities offered by the container orchestrator. For example, you could take advantage of network policies in Kubernetes using projects like Calico.
   6. In instances where a “managed” cluster orchestrator is not available (for example, Azure Kubernetes Service is not available in AzureGov regions) you will need to take on the additional responsibility of cluster SRE. This is where offerings like ACS (Azure Container Service) or Docker Enterprise may come in handy.
   7. The challenges involved in thoroughly testing the application anytime you rehost it cannot be overstated.

App Modernization Approaches in Action

To see many of these modernization steps in action, I encourage you to watch the two short videos that discuss the Cloud App Modernization approaches further. In the first video, I cover moving an application to Kubernetes on Azure. In the second part of the video, I look at modernizing an application by moving it to Service Fabric.

In addition to the two examples demonstrated in the video, please refer to case studies from companies like Met Life and Alaska Airlines who have followed somewhat similar app modernization approaches successfully.

Hope you find this useful. We’d love to hear your thoughts and encourage you to reach out to us to discuss your applications that need to be modernized. We are constantly working on ways to alleviate the aforementioned challenges in app modernization approaches and would love to collaborate with you to meet your goals. Thank you for reading!