The Unintended Performance Consequences
The option of running legacy Windows Server applications in Windows Containers on WS2016 or on the new WS2019 has garnered lots of hype. Containers and containerization seem to be the “software du jour.” Before you permanently containerize Legacy Windows Server applications, it’s wise to understand the fundamental process of containerization as well as the security risks and performance implications that come with containers. Is containerizing Windows Server applications always a good idea?
Early, early days
Running containers on Windows Servers today is both new and complex. Have a look at the compatibility matrix here and you’ll see the complexity involved in the compatibility requirements between host OS versions and the core OS container versions, compounded by the additional problem of container versions running on Hyper-V. Daunting!
Windows container technology is in its infancy. Containers as implemented currently don’t support all features of an app. For example, there are significant User Interface limitations. Documentation on running Linux containers on Windows also appears to be at early stages.
In addition, if you containerize your Windows Server apps, you’ll need to consider performance optimizations around security, Active Directory (AD), and the use of antivirus (AV) software.
Containers and performance: the fat stack
Let’s
focus on performance overheads of the multiple layers of software that you’ll
need to run apps in a container. First, you’ll need a host OS or a hypervisor. The host
and core Windows OS components of the Windows container share the host kernel
(make sure they’re compatible). Other core OS software components mean
additional overheads. In the hypervisor scenario, the Azure container runs its apps
on OS kernel components inside the Azure container.
In both scenarios, you’ll need an orchestration stack (usually Docker), which might rely on Linux components, (so you might need a Linux server). You may also want to run Kubernetes for some microservices. Finally, there’s the overhead of the app itself. The app might be built as a microservice in the Windows container or, in the case of legacy applications, somehow installed into the Windows container. We’re not quite done: you might want to harden the stack with antivirus or security software, and implement authentication and user access control, given the recent security issues discovered around both Kubernetes and Docker.
Figure 1: Host Server Container Model
Figure 2: Azure Container Model
Wow. The stack is getting fat and performance overheads are high. With such a porky stack, app performance is bound to be an issue, and sorting out performance bottlenecks across stack components will be a challenge. You might well discover that it’s the Docker and the Year of the Pig in more ways than one.
Let’s imagine that you want to upgrade some or all the components of the software stack. What needs to be patched? The VM, the host OS, the core OS and Windows container, Docker, Kubernetes, Linux components, the AV or AD software, or the app? All the above? Maintaining compatibility will be an ongoing challenge. There’s also no easy way to install app patches into a container. Keep in mind that this fat software stack is composed of early adopter components, so you should anticipate lots of patches for all the software. Ready to sign up?
Production use of Windows Docker Containers on WS2016 or WS2019 environments is virtually non-existent today
Journalist Beth Pariseau recently wrote about the hurdles and caveats of Windows Docker containers (WDC). According to Pariseau, large enterprise companies in the early stages of Docker on Windows Server projects indicate the work “has not yet reached full production scale.”
Two years in, WDCs remain only partially implemented on WS2016 and WS2019. Notably:
- User Interface (UI) capabilities are a work in progress.
- As Pariseau states, “Docker Enterprise Edition’s manager nodes still require Linux hosts, which puts companies without Linux expertise in a bind.”
- Dockerizing an app is based on application install scripts. ”You can run any application in Docker as long as it can be installed and executed unattended,” says a developer advocate at Docker. Therefore, you can’t install an application that requires a GUI at install time. A severe limitation for most legacy applications.
Application install scripts and source code are often missing. If available, they’re likely out of date. Using out of date install scripts means that the current state of legacy applications, with all their pre-installed patches and updates, is not captured or containerized. You’ve simply put the original version of the application in a box, not the legacy system version that is currently in production.
In addition, apps that are loaded into a container are permanently dependent on the container, there’s no easy rollback to a native OS install. Relying on the container as a destination means the app lives with management overhead, system overhead, and another layer of lock-in.
Windows Docker containers won’t easily run WS2003 and WS2008 legacy applications on WS2016 or WS2019, now or in the foreseeable future. We’ve learned from experience many issues need to be addressed to make legacy Windows apps run in a container.
So, let’s go back to our original question: Is containerizing Windows Server applications always a good idea? Containers may make sense if you’re using containers for new greenfield application development or on mature Linux platforms. In this scenario you could leverage APIs, containerization, application virtualization, or a microservices architecture as a basis for new applications. However, using containers by default for legacy applications may not pay off given the performance and management overheads we’ve discussed.
There’s a better way: an automated, stateful, native re-install on the Host OS
Instead of permanently containerizing legacy apps with all the security, performance and maintainability issues in a WDC, you could consider an alternative: an automated, stateful re-install of legacy apps on a modern server and Host OS.
At VirtaMove, we use our own lightweight container for isolation and testing on a host server. However, there is no permanent reliance on our container: it can be removed at the end of the moving process. Free of the container, the legacy application can run natively on a modern Host Windows OS. This allows you to manage legacy applications using a conventional change management process and eliminate the permanent overheads of containers.
Benefits of an automated, stateful re-install include:
- Closing known security exposures on old W2K, WS2003, and WS2008 servers as well as a step forward to modern Windows Defender versions on WS2016 or WS2019.
- Eliminating WannaCry, NotPetya, and Vault 7 malware risks. New hardware closes Spectre and Meltdown exposures. Apps will run natively on a supported OS.
- New hardware improves performance. New servers are scalable and run faster. You’ll get more work done with your existing apps.
- Stateful re-installs allow apps to be split and installed on separate servers. Or, apps can be consolidated and installed on a single server. It’s a chance to reconfigure where apps run.
- Software components, such as IIS and SQL, can be upgraded on-the-fly on new servers. New software components run faster, are more secure, and provide advanced features.
- Application clutter is reduced, log files are cleaned up, unnecessary apps are eliminated, and you can run apps on modern datacenter VMs or on the cloud. It also reduces OS patch and container management and lets you manage servers with standard DevOps tools.
- The life cycle of legacy apps can be extended. New featured can be developed gradually. You’re not forced into costly app re-development simply because you want to run apps on modern host servers.
At VirtaMove, we don’t need install scripts, developers, or app owners to learn and re-install apps on a Host OS. We automate the stateful installation of Windows 2000, WS2003, and WS2008 applications on new virtual machines and servers running WS2012, WS2016, and WS2019.
If you need to move forward with your legacy Microsoft Server applications or would like to understand more about what VirtaMove does, don’t hesitate to give us a call. We are pleased to share what we know.