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 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.
|
Increasing the automation levels may seem like modernization (Which is the last phase of the MAP). In kloia, our approach for the Modernization phase focuses on software refactoring or rearchitecting. |
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.
|
One could argue that those challenges may also exist for Linux-based workloads. My answer would be “it depends”, but very limited and not as complex as the Windows workloads. Besides, containerization for Linux workloads is pretty common and straightforward compared to Windows. |
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.
|
Our initial suggestion would not be leveraging Windows containers. The decision regarding Windows containers depends on the application requirements. If the cost of porting or refactoring your application to be Linux container compatible is feasible, you may not need to continue with Windows anymore. We refer to this process as “deWindowsification”. |
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