AWS MAP Mobilize phase containerization approach for Windows workloads

AWS MAP(Migration Acceleration Program) has three phases, and the second phase is called Mobilize. During this phase, we are focusing on several topics, including

• A detailed migration plan
• All development activities required for the next migration phase, including CI/CD pipelines, infrastructure-as-code together with PoCs of the technologies planned to be used,

A common approach for the migration of the Windows workloads is Lift&Shift which means migrating the Windows workloads as-is. Although this may seem more straightforward, it requires you to find solutions for the CI/CD and for the infrastructure management. Customers who are in their AWS MAP journey may be unwilling to continue with their existing on-premises practices for CI/CD and infrastructure management, which means Lift&Shift is not something they are looking for as they have the desire to benefit from native AWS services and industry practices.

Here are some of the challenges of the Windows-based migrations in our experience:

- Complexity in CI/CD: To integrate with the "Code Family" with Windows, you may need to deep-dive into PowerShell. Besides, in some cases, not only Powershell, but you may need to develop custom solutions for CI/CD with Serverless Lambda or with custom development.

- Complexity in OS provisioning: There will also be several Windows OS or IIS-related configuration and provisioning requirements. 

In summary, all of those I have mentioned above may relatively make the Mobilize phase more challenging for Windows workloads.

Kloia is suggesting approaching Windows workloads also from the containerization perspective to bring more value to the migration. Without containers, you have to deal with Windows-specific CI/CD and OS provisioning challenges. By leveraging containers, your approach to managing Windows workloads will be similar to Linux workloads:

- Infrastructure-as-code: You will be able to use Kubernetes for both. EKS now also supports Windows workloads.

- CI/CD: You will be approaching CI/CD similar to other Linux-based container workloads. For instance, if you have existing Helm Charts, you will also have Helm Charts for your Windows workloads.

To be able to containerize the Windows workloads, you first need to put your application into a Windows container, and now the container image becomes the artifact of your CI. You need to enhance your CI(Continuous Integration) pipeline accordingly.

As we are in the Mobilize phase, one of our targets is to agree on a Migration Plan.

If Windows dependency is in place, those workloads need to be Dockerized. Here is an example of a Dockerfile that we used in one of our projects:

Here is the runBuildCommand output building and pushing the image to ECR:

Here are the completed steps:

Next would be to define your CI steps. Here is a sample screenshot from CodePipeline:

​​

Here is the list from ECR:

As you noticed above, the main downside of Windows containers is the size. But the benefits would be worth giving it a try!

In conclusion, approaching your workloads the same way will bring operational efficiency. In our case, having containers for all your applications, including Windows, means you may have a standard approach for

• Scaling
• Provisioning, and Infrastructure-as-code
• Deploying and Releasing
• Deploy-time Configuration
• Secret Management
• HA(High Availability) and DR(Disaster Recovery).