Application Replatforming for the Cloud in Six Steps

According to 451 Research, 90% of companies are on the cloud. Odds are your company has workloads in the cloud, too. However, to achieve business objectives, a simple lift and shift to the cloud may not be enough. As a result, many organizations explore replatforming as a cloud migration alternative to more fully support corporate digital transformation goals. Yet, replatforming can seem like a black box if you haven’t been through the process before. Today, we’ll turn this mystery into a puzzle, walking you through the process of application replatforming for the public cloud.

A quick note: While our steps assume that you already have a cloud foundation in place, if you do not, you will want to build a scalable, secure and automated cloud foundation for your newly replatformed apps.

Step One: Assess
While you may have already lifted and shifted the application in question to the cloud, organizations can also start down the replatforming path with an application architecture diagram, or an on-premises application. Regardless of where you enter the path to replatforming from, the first step will be to review the architecture of the application, determining for each application tier what can be replaced with a cloud-native service.

The decision to replace a tier will depend on the business value the company will receive from the replacement service, balanced against the upfront cost to replace it. Primary considerations should include higher uptime, lower maintenance, and greater elasticity.

For example, can you replace your database tier with Amazon DynamoDB or another cloud-native database service? If so, what is the calculated benefit from decreased operating costs and greater database uptime and more reliable data backups? Perhaps the caching layer would benefit from a fast, geographically distributed service like Amazon CloudFront that can cache static and dynamic content and enhance your ability to handle spikes in web traffic.

What is replatforming?
Replatformed applications are moved to the cloud with a small amount of up-versioning — perhaps using a managed DB offering or the addition of automation-enabled autoscaling — to benefit from cloud infrastructure. This approach allows workloads to take advantage of base cloud functionality and cost optimization, without the level of resource commitment required for refactoring.

Step Two: Containerize
For tiers you can’t — or it doesn’t make sense to — replace with a cloud-native service, you should look to containerize.

Step Three: Modify the code
Once you’ve made the determination as to which tiers will gain from a cloud-native service or containerization, it’s time to roll up your sleeves. Begin making any code changes that may be needed to enable the app to use the chosen cloud-native service(s). In our experience, a Proof of Concept (or POC) is sometimes the most effective way to scale, proving through milestones the efficacy of a given approach. Or, just as importantly, highlighting where improvements could be made to increase success within the new cloud environment.

Step Four: Automate infrastructure
The next step is to automate the deployment of cloud-native services and VMs using Infrastructure as Code (IaC). IaC will help you automate infrastructure deployment with repeatability and consistency which will help you fulfill the expectation that your replatformed application is more secure and scalable, at a lower cost to the business.

Step Five: Automate code deployment
Automate your new services and the deployment of any application code custom to the application. Set up a continuous integration and continuous delivery (CI/CD) pipeline for it and you’ve successfully replatformed the application for the cloud. In this way, when developers have new updates for the application, they can be automatically made via the CI/CD pipeline.

Step Six: Full stack automation
While your application has been successfully replatformed for the cloud, we recommend a sixth step in which you create a full-stack automated deployment pipeline. In this way, you can automate the entire process using IaC tools like HashiCorp Terraform and automate the deployment of application code using a tool like Jenkins in AWS.

Now you have a replatformed application that takes advantage of the cloud’s scalability, automation, and security features, too. And, is also more amenable to quick changes. While not all apps are a fit for replatforming, we find that it is a good approach for applications that make a strategic contribution to the business and are not a fit for a full rewrite of the application. Given tight constraints for refactoring, enterprises opt to replatform anywhere between a quarter and a third of their portfolio, in our experience. For replatformed applications, the DevOps team can provide significant benefits such as autoscaling, self-healing, greater security and more, netting the business more value at less cost.

Replatforming in practice
We had the opportunity to work with an enterprise media group on its IT modernization project in which it had determined an AWS cloud migration was the ideal path. We began the project with a thorough assessment which flagged 400 applications for cloud replatforming. First we designed a platform for innovation, starting with an AWS landing zone.
Next, we separated the 400 apps into two groups, one consisting of external apps that drive profit for the company and the second consisting of internal, non-revenue generating apps. We developed two patterns (one for each group) to effectively manage the AWS cloud migration.

For the first set of applications, the pattern included an architecture that runs Java/Tomcat in Docker containers on top of a Kubernetes platform. (To do so, we developed a “Kubernetes pipeline” to deploy Kubernetes clusters as self-service on top of AWS.) And, we developed Jenkins pipelines to deploy Java/Tomcat applications via containers on Kubernetes. We used JFrog Artifactory to store intermediate artifacts including WAR files and Docker container images. We deployed internal apps on Amazon EC2 instances with a three-tier pattern consisting of a load balancer, a database, and an EC2 auto-scaling group. In the end, the developers have a very agile, self-service workflow for the company’s external applications.

*This was originally written by Flux7 Inc., which has become Flux7, an NTT DATA Services Company as of December 30, 2019