Spying the Spout of Hyperbole Surrounding Windows Docker Containers

To get to the meat of the matter: using Windows Docker Containers (WDCs) as a solution to running legacy Windows Server applications on WS2016 is simply a whale of a myth.

But first: we believe in using containers for new greenfield application development. There are no conceptual problems with using APIs, containerization, application virtualization, or a microservices architecture as a basis for a new path forward. Go ahead and invest in new application development or complete legacy application re-development and build something new, leveraging the most advanced orchestration and services tools to do so. If this approach is in your scope and budget, we recommend that you investigate Google Kubernetes, which will be implemented on WS2019 on a Beta basis next year. A word of caution, however: don’t expect the investment to be small.

Now, back to the blow hard myth. The claim that Windows Docker Containers on WS2016 can be used to solve the problem of running legacy Windows Server applications on a modern WS2016 operating system (with or without API support) is false. IT shops with real world experience running applications in the current implementation of WDCs on WS2016 are familiar with the significant limitations on their use.

You can see a demo on how to use VirtaMove containers to move applications to Windows Docker Containers on WS2016:

Please accept statistics, marketing cookies to watch this video.

Production use of Windows Docker Containers on WS2016 environments is virtually non-existent today

At VirtaMove, we’ve been working on Sun Solaris, Linux, and Windows Server containers for more than a decade. We have deep domain expertise in using our proprietary containers as moving boxes to provide stateful, production re-installation of thousands of legacy Windows Server applications on modern OSs for hundreds of customers. We know a lot about the topic and about Windows Docker Containers. While others claim to do what VirtaMove does, we recognize these claims for what they are: hype. We can easily spot the spout and spray, marked with similar words, yet with few or no production references. Imitation is the sincerest form of flattery, but it doesn’t distract VirtaMove from execution and from being clear regarding WDC facts.

Fact 1: The production use of Windows Docker Containers on WS2016 environments is virtually non-existent today. You don’t have to take only our word for it, however. Journalist Beth Pariseau has recently written about the many hurdles and caveats of WDC use. According to Pariseau, large enterprise companies in the early stages of Docker on Windows Server projects indicate that the work “has not yet reached full production scale.”

Fact 2: On WS2016, the Docker orchestration layer is part of the Docker Open Source project on GitHub. However, the WDC isolation and intercept layer on WS2016 is part of the WS2016 operating system and Microsoft code base. Being part of the WS2016 operating system code, the container itself is not open source. This means that developers can’t change the features of the container nor what application capabilities are supported in a WDC.

Limitations of Windows Docker Containers on WS2016

Two years in, Windows Docker Containers remain only partially implemented on WS2016. As implemented on WS2016, there are significant limitations on using WDCs to run legacy applications. Notably:

  • User Interface (UI) capabilities are currently a work in progress.
  • The Docker code base on WS2016 is focused on the orchestration of containers and still has a dependency on Linux. As Beth Pariseau states, “Docker Enterprise Edition’s manager nodes still require Linux hosts, which puts companies without Linux expertise in a bind.”
  • Dockerizing an application can be done only if you have the application install scripts. Additionally, ”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. These are severe limitations for most legacy applications.

The core concept of containerization is to isolate a legacy application from the underlying OS by placing it in a proprietary container. One way to do this is to use install scripts to install an application into a container on a modern OS. The problem with this approach is that application install scripts and source code are often missing. If they’re around, they’re likely out of date. Using out of date install scripts means that the current state of legacy applications, with all their patches and updates, is not captured or containerized. You’ve simply put the original version of the application in a box.

Additionally, applications that are loaded into a container shouldn’t depend on the container to run. Legacy applications are always stateful; they’re not stateless microservices. The container is simply an empty vessel and not a destination. Relying on the container as a destination means living with permanent management, system overhead, and another layer of lock-in. As Pariseau says, “modernization requires innovative DevOps tools that support stateful and data-intensive applications.”

At VirtaMove, we use our own lightweight container for isolation and testing on a target 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 Windows OS. This allows you to manage legacy applications using a conventional change management process.

Where containers hold promise

As stated earlier, where containers, microservices, and APIs do hold promise is in new system development and greenfield projects. The sophisticated infrastructure involved in managing and orchestrating container technology helps developers build scalable systems that take full advantage of both APIs and a microservice architecture.

Lessons from a decade of experience

Pariseau states that bringing legacy applications into the DevOps fold requires IT teams to think in ways “that may differ sharply from approaches to greenfield projects.” Our decade of experience aligns with this view. Our experience tells us compellingly that Windows Docker Containers will not run WS2003 and WS2008 legacy applications on WS2016, now or in the foreseeable future. We’ve learned from experience that many issues need to be addressed to make legacy Windows apps run in a container and outside of it.  It’s never as simple as load an app with an install script into a container and run the app. It’s never just copy the ASP.Net file and run it.

It’s only a matter of time before the world discovers that making legacy applications run in a WDC involves re-work and high overhead. Relying on the current limited implementation of Windows Docker Containers to run legacy applications will lead to a costly porting and re-development effort.

Most IT shops can’t wait for full implementation of Windows Docker Containers or find budget for legacy app re-development. Extended support for WS2003 ended last July and will end for WS2008 in January 2020. The time to move legacy applications to modern, secure servers is now.

There’s a better way: an automated, stateful install

Instead of permanently containerizing legacy apps in a WDC, you could consider an alternative: an automated, stateful re-install of legacy apps on a modern server and a modern OS. Here are some of the benefits of this approach:

  • It closes known security exposures on old W2K, WS2003, and WS2008 servers.
  • It eliminates WannaCry, NotPetya, and Vault 7 malware risks. New hardware closes Spectre and Meltdown security holes. Your apps will run on a supported OS and your IT audit and compliance teams will be happy.
  • New hardware improves performance. New servers are scalable and run faster. You’ll get more work done with your existing apps.
  • Fresh installs allow applications 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.
  • Some application software components, such as IIS and SQL, can be upgraded on-the-fly on new servers. New software components are offered as PaaS, run faster, are more secure, and provide advanced features.
  • It reduces application clutter, cleans up log files, eliminates unnecessary apps, and lets you run on modern datacenter VMs or on the cloud. It also reduces OS patch management and lets you manage servers with advanced DevOps tools.
  • The life cycle of legacy apps can be extended. New development over time can address extended functional requirements. You’re not forced into costly app re-development simply because you want to run apps on modern servers.

At VirtaMove, we don’t need install scripts, developers, or app owners to learn and re-install apps. Day in and day out, we successfully automate the stateful installation of Windows 2000, WS2003, and WS2008 applications on new virtual machines and servers running WS2012 and WS2016. The proof of our Windows Server application migration work is that we move legacy programs into production on modern secure servers.

If you need to move 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 our domain expertise and what we know, without the spray.