How to Migrate Legacy Applications Using AWS App2Container

By Vikranth MohanRao, Containerization Capability Lead – DXC Technology
By Elango Boopathy, Cloud Solution Architect – DXC Technology
By Dhiraj Thakur, Solution Architect – AWS

DXC Technology

Organizations typically use a large part of allocated IT budgets for maintaining and managing the technical debt of legacy applications in their portfolio.

To achieve cost benefits and mitigate some of these challenges, many organizations are quickly moving towards containerizing existing software applications that are developed on various platforms and technologies.

DXC Technology offers a suite of application services to migrate a customer’s application portfolio from a legacy infrastructure to the container management service in the most efficient manner. These services are bundled under DXC’s Applications Containerization as a Service (aCaaS) offering and enable organizations to leverage the seismic shift in application hosting with containerization.

The aCaaS framework supports a holistic portfolio assessment approach aimed at ensuring the right set of applications, which are validated using assessment discovery tools and templates coupled with workshops and focused sessions with application subject matter experts (SMEs).

In this post, we will discuss the risks and challenges encountered by application teams during migration of legacy applications using DXC’s containerization service offering. We’ll also explore how these were successfully mitigated using AWS App2Container.

DXC Technology is an AWS Premier Tier Services Partner and Managed Service Provider (MSP) that is helping organizations achieve excellence in the operation of their public cloud hosted workloads.

Containerization Assessment and Design

Following the high-level aCaaS assessment, containerization SMEs from DXC migration delivery teams inspect the application in detail and go through a design and assessment checklist to determine the best configuration for an application that’s been containerized. Examples include stateful and stateless security and network requirements.

Container delivery includes packaging the application itself as a Docker container and performing a standalone test to verify the containerization deliverables. Finally, DXC performs validation and hyper care support.

Figure 1 – DXC’s seven-step aCaaS factory approach to containerization.

Identifying feasibility of containerization and associated efforts plays a key role for the migration of an application portfolio into container platforms.

Several applications that have been upgraded frequently and are running on a recent operation system (OS) are easy to migrate since the base images are readily available. However, several other containers require a deep analysis and migration SMEs to follow best practices and design patterns.

These checklists and design considerations are applied as part of the DXC containerization and assessment aCaaS framework:

Containerization-focused questionnaire for application assessments.
Standard checklists for containerization feasibility based on application dependencies and characteristics.
Derive complexity of containerization using platform versions, application topology, design, and architecture.
Analysis of containers feasibility.

Figure 2 – DXC’s aCaaS assessment and discovery.

Factory-Based Containerization Approach

DXC’s proven factory-based approach for containerizing applications includes a set of standard process to enable a high degree of success in the execution of container migration.

This approach is backed by experience and involves a set of closely monitored software delivery processes to construct and deploy an application container image followed by validation and smoke testing.

Figure 3 – DXC’s aCaaS streamlined approach for bulk containerization.

Challenges with Manual Approach

DXC’s aCaaS framework defined a factory-based streamlined approach in bulk. When applied in practice for some customers, containerization was a time-consuming and error-prone activity due to the errors and defects that arise due to manual or custom script-based build processes, as well as the manual efforts involved in developing various Docker and other deployment and testing scripts.

In addition, the container migration team is augmented with application SME’s who, in many cases, have limited knowledge of deployment, release, and testing for container applications but have strong knowledge of the legacy application itself.

DXC and AWS: Automated Containerization Approach

One of the key areas of improvement identified early on in DXC’s factory-based containerization model was the ability to increase throughput. The framework could scale up containerization efforts significantly to meet timelines, which results in reduced effort and lower migration and transformation costs.

Layering the aCaaS approach with an automated tool to speed up containerization efforts and reduce manual errors was promising.

This is where the AWS Partner Network’s enablement team helped DXC to integrate the desired automation into the aCaaS framework and containerization approach. The rest of this post describes how AWS App2Container and aCaaS helped DXC improve operational efficiency, harmonize containerization processes, and increase agility of the factory-based DXC aCaaS framework.

AWS App2Container simplifies the containerization and modernization of existing Java and .NET applications in an automated fashion, and enables rapid deployment onto AWS. It also automates many of the manual tasks typically involved in containerizing an existing application.

Benefits of AWS App2Container with DXC aCaaS include legacy app containerization with minimal efforts; containerization at scale; best practices for containerization; and opinionated AWS deployment artifacts.

AWS App2Container

AWS App2Container analyzes your applications and automatically generates a container image that’s configured with the correct dependencies, network configurations, and deployment instructions for Amazon Elastic Container Service (Amazon ECS) or Amazon Elastic Kubernetes Service (Amazon EKS).

App2Container helps customers transform their applications running in virtual machines into containers and easily deploy them to Amazon ECS or EKS with minimal effort. By modernizing existing applications using containers, you can make them portable, increase development agility, standardize your CI/CD processes, and reduce operational costs.

Figure 4 – AWS App2Container approach to containerize in bulk.

The AWS App2Container CLI is used to generate container images for applications running on Windows and Linux servers that are compatible with the Open Containers Initiative (OCI). Users can install the CLI on application servers (virtual and physical machines) and use the commands to identify and containerize specific applications.

The CLI supports the following tasks:

Initialize: Set up a workspace for collating all relevant artefacts related to the containerization project.
Analyze: Scan through the server locations for an inventory of applications (candidates to containerize).
Containerize: Dockerize the selected applications using the extracted application artifacts.
Generate pipeline: Create pipeline and image repository using AWS CloudFormation templates.
Deploy pipeline: Deploy artefacts and pipeline; DXC can execute it to deploy containers on Amazon ECS or EKS.

Figure 5 – AWS App2Containter standard workflow to automate containerization.

As illustrated in the diagram above, a sequential step-wise approach is used in a workflow-based pattern to identify, analyze, containerize, generate deployment artefacts, and finally deploy the containerized application.

In subsequent sections of this post, we’ll explore in detail the prerequisites and go into detail on each workflow step to gain insights into the underlying scripts or commands involved.

Prerequisites for AWS App2Container

Linux Applications

Root privileges
UNIX utilities: tar
AWS CLI version 1.14 or later
AWS profile with AWS Identity and Access Management (IAM) policy associated
Docker (link to refer)
20 GB of free space

Windows Applications

Administrator access
AWS CLI version 1.14 or later
PowerShell version 5.1 or later
AWS Tools for PowerShell
Configured AWS profile for a user with IAM policy associated (refer to Appendix A)
Docker (link to refer)

Step 1: Initialize App2Container

The initialize command performs one-time initialization tasks for AWS App2Container. In this walkthrough, we’ll execute this command before executing any other commands that will prompt us for information required for setup of the tool.

We start by downloading the CLI binary archive available in the AWS App2Container User Guide. This is basically an interactive shell script that will install App2Container on the server. We can verify the installation by running the ‘app2container’ help command.

Figure 6 – AWS App2Container’s CLI tool used for containerization.

Step 2: Analyze Using App2Container

The analyze command scans through server locations for an inventory of applications (candidates to containerize). The selected application dependencies required for containerization are subsequently identified and an ‘analysis.json’ file is created for the application that’s specified in the ‘application-id’ parameter.

Most of DXC’s applications are hosted on customer site physical boxes or virtual machines. Alternatively, we can set up a worker machine with App2Container installed as a standalone setup. Setting up this machine is an optional step if we don’t want to install prerequisite tools on our application servers.

The deep scanning capabilities of App2Container identify the startup command and information for each legacy application. App2Container uses this information in subsequent steps to launch these applications within containers.

In this case, however, the inventory displays all running Java processes (Linux) or all IIS websites (Windows) on application server or worker machines and lists them in JSON format.

Figure 7 – Outputs from automated data collection from server.

Step 3: Containerize Using App2Container

The containerize command Dockerizes selected applications using extracted application artefacts, to build application container images and generate additional artefacts.

The files related to additional artefacts contain information about applications identified during the analysis. This is used in configurable fields for container settings.

Creation of Dockerfile: App2Container not only creates a container image but also generates a Dockerfile and makes it available in an AWS CodeCommit repository it creates for the application. If it needs to be changed further, this Dockerfile can be integrated with CI/CD pipelines and directly reused to regenerate Docker image for changes. This is a great value add for use cases where applications are modernized further after migrated to cloud.
Image tagging: App2Container automatically applies image tagging and tags the generated image as latest, thus handling versioning automatically.

Step 4: Generate Pipeline in App2Container

App2Container auto-generates AWS CloudFormation templates and leverages them to create the entire underlying AWS stack, including virtual private clouds (VPCs), subnets, and other components.

In addition, App2Container generates the Amazon ECS task definition and registers the task to run on the created ECS cluster. Further, it uses the Docker images created earlier to launch the applications into ECS as containers.

In DXC’s scenario, Amazon ECS is used but App2Container also auto-generates the EKS deployment manifests if this service to be used instead. In addition, it makes these generated manifests available for any edits needed. For instance, DXC uses AWS Fargate for its use case as the ECS launch type.

If needed, we can also use an Amazon Elastic Compute Cloud (Amazon EC2) launch type instead. This can be easily accomplish by simply editing these manifests.

Step 5: Deploy Pipeline in App2Container

In this example, App2Container created an AWS CodeCommit repository for each application and auto-uploaded all generated CI/CD artefacts and manifests to this repository. This allows the artefacts and manifests to be reused as needed if the application is changed in future.

In addition, App2Container created an AWS CodeCommit project to automate builds for future changes. It also creates the CI/CD pipeline (AWS CodePipeline) for application.

For scenarios where a CI/CD tool other than CodePipeline is used, the artefacts are available to be integrated as needed into any DevOps pipelines. As shown below, we have a basic CI/CD pipeline along with the basic ECS task and services definitions that is ready for consumption by the respective application teams.

Figure 8 – Generation and deployment of release artefacts and pipelines.

Conclusion

The key takeaways for DXC Technology from this use case for AWS App2Container is the automation and elimination of manual activities. This enables the migration team to confidently commit to parallel iterations of containerizing the application portfolio. It also enhances the capability of DXC’s Applications Containerization as a Service (aCaaS) offering.

App2Container allows teams to identify a particular “type” of application in the customer landscape which can be migrated (containerized and deployed into Amazon ECS or EKS) in bulk into the cloud container platforms.

.

.

DXC Technology – AWS Partner Spotlight

DXC Technology is an AWS Premier Tier Services Partner and MSP that understands the complexities of migrating workloads to AWS in large-scale environments, and the skills needed for success.

Contact DXC Technology | Partner Overview

*Already worked with DXC Technology? Rate the Partner

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

AWS Partner Network (APN) Blog