AWS supporting Azure DevOps with container migration service for Java and .NET

cri-o 1.22

AWS is showing that there is no such thing as a competitor when it comes to making it easier for customers to deploy to its cloud, by supporting Azure DevOps for setting up a continuous integration pipeline for its App2Container service.

App2Container was introduced two years ago and is designed to migrate existing on-premises applications to containerized deployments. The service supports Java applications on Linux, and ASP.NET applications either on Linux (using .NET Core) or on Windows with .NET Framework and IIS (the Windows web server).

The tool first performs an inventory analysis to identify the application components, generating a JSON file which is then read by a containerize command that builds one or more containers. The tool does not attempt to migrate databases.

The containerize process also generates a deployment.json file, which includes ports to publish, environment variables, and the cloud resources that are required. Containers can be deployed to EC2 VMs or to one of the AWS container services including EKS, ECS, or the Fargate serverless container platform, or to the AWS App Runner service. Windows containers have more limited options.

In addition, the tool generates a pipeline.json file that covers AWS CodePipeline, Jenkins, and (now just added) Azure DevOps.

AWS has its own DevOps services, CodePipeline and CodeCommit, but these have relatively small usage. Support for Azure DevOps may make App2Container more attractive for Microsoft-platform customers already working with Azure. Azure has its own container services but no exact equivalent to the App2Container tool.

It is perhaps surprising that AWS is choosing to support Azure DevOps Pipelines rather than the more widely used GitHub Actions, particularly since the two services are similar in many ways: Actions began as a fork of Azure Pipelines. That said, there is nothing to stop developers from using App2Container and setting up a DevOps pipeline with GitHub Actions or other CI/CD systems. The key factor here may be that writing the YAML code for Actions or Azure Pipelines can be tricky, hence the attraction of a tool that does much of the work automatically.

Containerizing existing applications has appeal as a way of migrating workloads from legacy systems without requiring too much porting effort. That said, the output of a tool like App2Container is unlikely to meet all the requirements of a modern CI/CD pipeline, particularly in respect of testing procedures. It makes best sense as a kind of lift and shift tool for legacy applications that work well but require little maintenance.