As a technology leader in your organization, many of your decisions come down to allocating resources: balancing and prioritizing risk and reward, stability and velocity, the present and the future. In an ideal world, technical debt would always be addressed before it started accruing interest. Long-term maintenance and operations expenses would be accurately weighed against the short-term development expenses that could mitigate them.
But in the real world of limited budgets and resources, compromises need to be made. If a software system is working well enough as-is, it might be difficult to make a case for major changes. Windows containers are becoming increasingly popular to manage the ongoing costs and distractions of legacy services, and help keep teams focused on building for your future needs and architectures. Here are some pros and cons to consider when using Windows containers to containerize monoliths.
The Rise of Containers
These days, software is increasingly built for deployment in containers. This technology allows for improvements in management and monitoring of your systems that help with reliability and the efficient use of your teams’ time.
But these forward-looking architectures often depend on languages and cloud-native technologies that take time and resources to adopt. Teams can only focus on a limited number of projects to make timely progress.
Advantages of Using Windows Containers
The increasing availability of Windows Kubernetes containers lets you bring existing systems into the same cluster as your newer work. You can gain many of the advantages of containers this way with minimal (if any) code changes required for many legacy Windows server applications. Rather than having a scattering of older servers and VMs, you’ll have a single cluster to monitor and maintain, creating a more unified and supportable system for your business.
As of now, Windows containers are available in production-ready releases. Not just in Kubernetes itself, but on many managed cloud providers including Amazon EKS (Oct 2019), Azure AKS (May 2020), and Google GKE (May 2020).
Challenges of Windows Containers
Windows containers are still a relatively new technology, especially within the context of managed cloud platforms, so they come with certain limitations. In Amazon EKS, they must be managed via Command Line Interface (CLI) and do not currently work with the Fargate launch type.
Across Amazon EKS, Azure AKS, and Google GKS, Windows Containers also have some specific limitations compared to Linux containers. All the listed providers support only some of the networking modes available on Linux with Windows containers, and they all require Linux nodes within the cluster to provide system services as well as Windows nodes.
There are also some general caveats, regardless of your hosting choice, such as the fact that Windows container images still tend to be significantly larger than Linux images (often over 9GB).
Final Thoughts
Judicious use of Windows containers for legacy services you expect to maintain for the long haul could pair well with investment in new or substantially refactored cloud-native microservices for more future-focused work. By shifting existing services into windows containers with limited refactoring to simplify support and infrastructure, your team can stay focused on the organization’s next steps.
DragonSpears has teams who can help you with both aspects of your work. 
to discuss the best path forward for your needs.
