DevOps Adoption Case Study: Developing a Tomcat Cloud Migration

Last week we shared with you the story of an enterprise media group’s IT modernization project in which it had determined an AWS cloud migration was the ideal path. While we previously shared the company’s overarching migration strategy (and the approach it took to develop that strategy), today we’ll dive into one specific set of applications, sharing how the Center of Excellence (COE) addressed the technical challenge of migrating over 100+ Java applications to AWS.

To start, the COE separated the applications into two groups. The first group consisted of external applications, apps that drive profit for the company; the second group consisted of internal non-revenue generating apps. Next, the COE developed two patterns — one for each category of application — to effectively manage the AWS cloud migration for these 100+ Java apps.

External App Migration

For this first set of applications, the COE established a pattern that their architecture will run Java/Tomcat in Docker containers on top of the Kubernetes platform. To do so, we developed a “Kubernetes pipeline” to deploy Kubernetes clusters as self-service on top of AWS. This Kubernetes cluster is setup for both security and operations best practices.

The COE solution allows applications that use session state as well as apps that don’t. The solution also allows apps with and without a need for shared storage (NFS). And, the COE created a generic method to securely inject application secrets from HashiCorp Vault into the applications with the help of a Tomcat-Vault plugin, and the HashiCorp Vault Kubernetes Auth plugin.

Furthermore, the COE developed Jenkins pipelines that are used to deploy Java/Tomcat applications via containers on Kubernetes. We use JFrog Aritfactory to store intermediate artifacts including WAR files and Docker container images. In the end, the developers have a very agile, self-service workflow for the company’s external applications.

With the self-service model in place, now when a team wants to replatform an app to Tomcat, Docker, and Kubernetes, they are able to start on their own — the teams are trained on the platform, and able to use the pipeline to start deploying services — or can schedule time with an architect to discuss what app changes will be needed. The goal is to make it easy for internal customers to use this approach to replatform the apps, giving them a framework of trust and agility that allows them to easily try out the process for any application.

Internal App Migration

A separate pattern was established by the COE for internal, non-revenue generating, applications. The goal is to replatform these applications with less work such that resources can focus on external apps instead. So, rather than using containers, the COE deploys these apps on Amazon EC2 instances. The architecture consists of a three-tier pattern: Load balancer, a database, and an EC2 auto-scaling group.

We monitor the internal and external app infrastructure using Splunk and Datadog. And, similar to the external apps, we developed four different flavors of the infrastructure (with and without session stickiness and shared storage). We also have a Jenkins pipeline for building, testing, and deploying code using AWS CodeDeploy; and we use JFrog Artifactory to store intermediate artifacts including WAR files. This provides a Java/Tomcat app factory that developers can use to create the infrastructure, and DevOps pipelines needed to securely deploy internal apps.

With a strategy of investing more resources to migrate applications that drive revenue, and fewer resources for internal applications, this organization is able to focus on optimizing its cloud ROI and resource utilization while taking advantage of important cloud features, like horizontal scalability where it’ll benefit the organization most. Through these two patterns, the COE is able to provide a self-service method for developers to simply start replatforming both their external and internal applications, getting the team quickly on the road to reaping the benefits of AWS-based DevOps.

This provided agility has an added benefit in that it encourages and facilitates tasks related to retiring technical debt. For this customer, there were some legacy internal apps using IBM Websphere. They were replatformed to use Apache Tomcat platform as a part of this replatforming. This was motivated by the fact that the team was provided a nice, repeatable test bed for testing their app changes easily, and also that the effort required to make them TomCat was less than the effort required to develop patterns just for WebSphere apps.

Interested in reading more about developing your cloud migration path? Subscribe to our series of short papers designed to walk readers through creating a custom approach to their own AWS cloud migration strategy, in support of strategic business change. Sign up for the full series here.