Automating Containerization at Scale with AWS App2Container

By Jayant Swamy, Lead – Intelligent Engineering Services at Accenture’s Advanced Technology Centers in India
By Rupa Ganesh, AWS Practice Lead at Accenture’s Advanced Technology Centers in India
By Arijit Maity, AWS Architect at Accenture’s Advanced Technology Centers in India
By Madhuri Susarla, Solutions Architect at AWS

Migrating legacy workloads to the cloud can be complex. In an ideal world, legacy applications are rearchitected to fully realize the benefits of cloud. However, this is neither practical nor feasible in every case.

Some customers have a business need to migrate their legacy systems to cloud very quickly, such as a data center contract expiry.

These customers may not have the luxury of time to rearchitect before migrating to the cloud. Or, the developers with the application knowledge may no longer be around to pull off a complex refactoring exercise. In the case of COTS software, there is an added limitation of unavailability of source code.

The Accenture AWS Business Group (AABG) has vast experience in migrating workloads to Amazon Web Services (AWS). Through years of working with diverse customers in this space, AABG notes that while the rehosting approach has allowed some customers to experience a quicker migration to cloud with initial CAPEX and OPEX savings, it does not provide the right optimization for operating in a cloud environment.

AABG sees containerization emerging as a pertinent solution, allowing customers to quickly migrate and modernize their legacy systems to the cloud with minimal code changes. Containers are also a popular choice for developing new applications that are based on microservices architecture.

Containerization can thus accomplish commonality between the old and new applications, and eliminate operational overheads of having to maintain different sets of tooling for their automation and CI/CD.

Inherent Challenges

While containerizing legacy systems enables these benefits, it also involves a series of tasks. This includes application assessments to gather data required for containerization, identification of dependencies, creating the Dockerfile, and setting up the build and deployment process for the applications.

These tasks tend to be time-consuming, error prone, and can slow down modernization efforts. Furthermore, this needs skills in container technology and considerable investments in terms of time and efforts.

AABG explored AWS App2Container (A2C) for containerizing customer workloads to AWS Cloud. In this post, we share our experience of how A2C can accelerate this journey by eliminating the manual tasks and simplifying the technical complexity involved in containerizing legacy systems.

We also discuss how this results in productivity gains and reduced engineering costs.

AWS App2Container

AWS App2Container (A2C) is a command-line tool for modernizing .NET and Java applications into containerized applications. With A2C, customers can easily get started with modernizing their existing applications to containers, and leverage a wide range of AWS services to store, manage, and run containerized applications.

A2C can containerize both Java and .NET legacy applications running on a virtual machine (VM) or physical server on-premises, in Amazon Elastic Compute Cloud (Amazon EC2) instances, or in any other cloud.

A2C analyzes the selected application, packages up its dependencies (for example, open network ports or third-party libraries in use), and generates the relevant container artifacts, such as the container image, task definitions, and YAML files for easy deployment to Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Kubernetes Service (Amazon EKS).

Figure 1 shows the sequence of steps in A2C, with the output of each being leveraged as the inputs to the subsequent steps in the sequence.

Figure 1 – Automation sequence in AWS App2Container.

Representative Use Case

AABG has piloted use of A2C across multiple customers. The sample scenario detailed in this section is a composite mix of these use cases to depict how A2C can help with migrating an entire portfolio of legacy applications to AWS in an accelerated manner.

The application landscape being migrated in this scenario is diverse:

• Heterogeneous technology stack: Most of the applications are Java-based and deployed across multiple application servers such as WebLogic and JBoss. A few applications in the legacy portfolio are .NET as well.
• Varying degrees of virtualization: Some application servers are directly installed on physical boxes, while a few have an on-premises virtualization implemented and run on virtual machines.
• Diverse operating systems: The Java applications are hosted on Linux, and .NET applications run on Windows.
• Varying runtimes and degrees of legacy: The applications are of different degrees of legacy, use different runtimes, and are a mix of different categories. Some are web applications while others are backend services.

Migrating to containers helps ensure a consistent strategy and target state across this heterogeneous stack, as shown in Figure 2.

Figure 2 – Migration approach using AWS App2Container.

Migrating the Heterogeneous Workloads Using A2C

In this section, we provide a detailed description of the steps for migrating the sample scenario described above.

Step 1: Running the Discovery

We installed A2C on the servers that ran these applications, which included a mix of physical boxes that directly hosted these applications, and VMs where virtualization had been implemented in some cases.

A2C automatically identified all candidate processes and listed them in a JSON format.

Step 2: Analysis Outcomes

For each application identified in the inventory, A2C’s analysis step generated detailed information and analysis output in a JSON format, which A2C leverages to containerize the application in subsequent steps.

The section below describes three important aspects of the generated analysis output:

• Issues and observations: A2C generated a text file (report.txt) with a list of any issues and observations found that may need remediating before containerization.
• Dependency identification: A2C not only analyzed and gathered details about the applications, but also identified dependencies via its “Co-operating process” feature. A snapshot of the analysis.json depicting this is shown below.

In the following screenshot, the application in question (with processId 3139) is shown as dependent on a second application that is assigned processId of 1376 in A2C analysis.

Figure 3 – Sample analysis.json with dependency information.

This analysis.json file also includes a section detailing the dependency found, such as the port used for connectivity, as well as other access parameters. A2C uses this information in subsequent steps to ensure these dependencies are factored into the generated containers.

Figure 4 – Sample analysis.json with details of the dependency.

• Application startup information: The deep scanning capabilities of A2C also identified the startup command and information for each legacy application. A2C uses this information in subsequent steps to launch these applications within containers.

Figure 5 – Sample analysis.json with application startup command.

Step 3: Image Generation

A2C leveraged all of the application and dependency information from the analysis step to generate the container image for the applications.

Three important value-adds of A2C in this phase:

• Creation of Dockerfile: A2C not only created the container image, but also generated the Dockerfile and made it available in an AWS CodeCommit repository that it created for the application.
  .
  If the application needs to be changed further later on, this Dockerfile may be integrated with CI/CD pipelines and directly reused to regenerate the Docker image for the changed code. This is a great value-add for use cases where the application is modernized further after it’s migrated to cloud.
  .
  A2C also automated integrating the generated Docker file with CI/CD for our use case, as we leveraged AWS-native DevOps tools like AWS CodePipeline, which is explained in more detail in Step 4.
  .
• Image tagging: The Docker file generated automatically applied image tagging and tagged the generated image as latest, thus handling versioning automatically.
  .
• Customization: A2C automatically made intelligent decisions while generating the Docker file and image, such as selection of the right base image. In case there is a need to make changes to these, such as using a different base image, the generated Dockerfile is available to be edited as needed.

Step 4: Automated Creation of the Entire Stack on AWS

A2C auto-generated AWS CloudFormation templates and leveraged them to create the entire underlying AWS stack, including virtual private clouds (VPCs), Subnets, and other components.

In addition, it generated the Amazon ECS task definition and registered the task to run on the created ECS cluster. It then used the Docker images created earlier to launch the applications into ECS as containers.

Our scenario used Amazon ECS, but A2C also auto-generated the Amazon EKS deployment manifests if EKS were to be used instead. In addition, it makes these generated manifests available for any edits needed. For instance, we used AWS Fargate for our use case as the ECS launch type. If we needed to use an Amazon EC2 launch type instead, we could accomplish this easily by simply editing these manifests.

A2C also created an AWS CodeCommit repository for each application, and auto-uploaded all generated CI/CD artifacts and manifests to this repository to allow these to be reused as needed if the application is changed in future.

In addition, it created an AWS CodeBuild project to automate the build for such future changes. Finally, it also created the CI/CD pipeline (AWS CodePipeline) for the application. For scenarios where a CI/CD tool other than AWS CodePipeline is used, the artifacts are available to be integrated as needed into any DevOps pipelines.

The diagram in Figure 6 shows how the entire AWS stack was auto-created by AWS App2Container.

Figure 6 – AWS stack auto-generated by AWS App2Container.

Productivity and Cost Savings

The automation enabled by A2C results in relatively shorter and accelerated migration cycles for customers, which in turn enables productivity and cost savings across multiple lines.

Reduced Effort

A2C cuts down the migration effort and time as it automates assessment and containerization, and also generates the artifacts needed to deploy the images to AWS. This results in quicker migration cycles to the cloud.

Without A2C, migrating the applications in our representative use case described earlier would have needed separate Java and .NET teams to analyze and understand the existing legacy. It would also need a team with skills in Docker and containerization to create the Docker images for the application, and a mix of people with knowledge of Amazon ECS or Amazon EKS to create several deployment manifests.

With A2C, all of these are automated, which results in cost savings from the reduced migration effort.

The table below highlights the automation enabled by A2C at each step of the migration, and compares it to the effort and skills that would have been needed had these been done manually.

Figure 7 – Accelerating containerization using A2C.

Reduced Complexity

There are several differences in containerizing Linux and Windows platforms. A2C takes care of these platform-specific steps as it auto-generates the Docker images. This allows developers to focus on application development without worrying about routine steps.

Cost of Tool

Use of A2C is free. AWS only charges for the actual usage of its compute resources and services used, such as Amazon EKS or Amazon ECS.

Summary

AWS App2Container (A2C) is an enabler for containerizing and migrating legacy applications to AWS quickly. Its value-add is specifically seen for use cases where the legacy system in question is large with heterogeneous applications, where A2C helps to bring a commonality to the migration approach, tools, and the target state architecture.

While containers have traditionally not been a recommended target state for monoliths, containerizing legacy applications as a cloud migration approach brings in added advantages over rehosting, such as commonalities in automation and abstraction of technical heterogeneity across those applications.

With A2C, customers can quickly containerize their legacy applications and migrate to AWS with minimal remediation and at scale. A2C also enhanced developer productivity due to automation and resulted in overall cost savings.

Once on AWS, customers may then choose to rearchitect any or all of these applications further at their own convenience and pace.

.

.

Accenture – AWS Partner Spotlight

Accenture is an AWS Premier Consulting Partner and MSP. A global professional services company that provides an end-to-end solution to migrate to and manage operations on AWS, Accenture’s staff of 440,000+ includes more than 8,000 trained and 6,000 AWS Certified professionals.

Contact Accenture | Practice Overview

*Already worked with Accenture? Rate this Partner

*To review an AWS Partner, you must be an AWS customer that has worked with them directly on a project.