Q&A on the Docker on Windows – Second Edition

The book Docker on Windows - Second Edition by Elton Stoneman teaches readers how to run new and old applications in Docker containers on Windows - modernizing the architecture, improving security and maximizing efficiency. 

InfoQ interviewed Stoneman about the significant changes in the 2nd edition of Docker on Windows, typical use-cases, benefits of CI/CD Pipelines, containerization, guidance, operations, and collaboration between Microsoft and Docker.

InfoQ: Why did you write an update to the Windows on Docker book? What has changed between the first (2017) and the second version (2019) of your book?

Elton Stoneman: Windows containers were a brand-new feature in Windows Server 2016. The Docker and Microsoft teams did a great job bringing the philosophy and user experience of Linux containers to Windows, but there were some technical gaps - things that worked differently in Windows. Windows Server 2019 closes those gaps, so you can do pretty much everything with Windows containers that you can do with Linux containers. That opens some exciting new opportunities, which I wanted to cover in the book. But I didn't want to do a small update, so for the second edition, I re-wrote every single sample to use the latest version of Docker, with Windows Server 2019 and Windows 10. 

InfoQ: What are the typical use-cases of using Windows on Docker? Are more use-cases possible than two years ago?

Stoneman: I think so. The original use-cases are for legacy and brownfield apps. You can move old apps to Windows containers with no code changes, which is a great way to get apps off older versions of Windows and on to a modern platform. Think about a .NET Framework 2.0 app which is running on Windows Server 2008 - that's going to be out of support soon. You can update that app to .NET 4.7 on Windows Server 2019 in a container just with one Dockerfile, and no app changes.

The next is brownfield apps. These are old monolithic apps which are still in active development. It's hard to add new features to big monoliths without risk, which is why there's usually a considerable regression test phase for even the smallest change. With Docker, you can run the original monolith in one container and break features out into new, separate containers, which have their test and release cycle. That gets you a lot of the benefits of a microservice architecture without spending two years rewriting your app. There are some established patterns for that using reverse proxies and message queues which I cover in detail in the book.

And the new use-case is greenfield apps. Microsoft has worked hard to shrink the size of Docker images for Windows, particularly with Nano Server. Now it's possible to build apps into Windows Docker images which are small and lightweight. That means they're faster to share, they run more efficiently, and they have a smaller surface area for potential attacks. That makes Windows an excellent choice for teams who want to build cloud-native architectures, but aren't comfortable with Linux.

InfoQ: How does one benefit from the CI/CD pipelines with regards to Windows on Docker? 

Stoneman: Pipelines become ridiculously simple with Docker. You write a Dockerfile to package your app, and it can have multiple stages. A typical pattern is to compile the app in one stage and package the compiled binaries in the next stage. All those steps happen in containers, so your compile stage runs in a container which has the SDK installed. The final stage has the app runtime without the extra tools of the SDK.

What that means is that Docker is the only dependency to build and run apps, so you don't have to spend any time cultivating build servers and keeping the toolset in sync with the dev team. Your build pipeline is literally `git clone`, then `docker build`. That goes for full .NET Framework apps and .NET Core - you don't need to have any versions of .NET installed to build and run .NET apps with Docker.

Ultimately, that means you can use any build server (or managed service) that has Docker support - and they pretty much all do. Whether it's Jenkins or Azure DevOps, the build scripts for your pipeline are just simple Docker commands.

InfoQ: You’ve dedicated an entire chapter to containerization and guidance for implementing docker. Can you sum up it here, please?

Stoneman: No way - you should go and buy the book. Just kidding :) Docker is straightforward to pick up - you can get a working Dockerfile to run your app in a Windows container in just a couple of days, even starting from zero. But the path to production is going to be harder because you're fundamentally changing how your applications run. You're going to need to get lots of different parts of your organization on-board, and they'll all have a different take on what containers mean to them. So the guidance is basically: do a small proof-of-concept with an app you know well; get it working and then demo it to the people who are going to get it to production. There's advice in the book for putting together a value case that works for management, ops and security teams.

InfoQ: The book makes use of real-world case studies for docker implementations. Do you want to provide some best practices?

Stoneman: In the book, I cover a few different projects I worked on where Docker made a massive difference to the delivery schedule, the handover to ops and the ongoing support of the app. For all these different scenarios, the best-practices are the same: optimize your Dockerfiles, and add health checks, logging and metrics. That's going to get you a lot of the way to deploying self-healing applications, where the container platform keeps your app running even if there are container or server failures. And it's not hard to do - I have a bunch of Pluralsight courses that will help. Try Modernizing .NET Apps with Docker and Monitoring Containerized Application Health with Docker.

InfoQ: What about the operation part for docker; can you tell us what are the trends you see nowadays?

Stoneman: What's nice is that the ops part is the same for all your apps and all your environments. You can have a cluster of machines running Docker which is a mix of Linux and Windows servers. On the cluster, you can be running brand-new microservices apps in Linux containers, legacy apps in Windows containers, and brownfield apps using a combination of Windows and Linux containers. You deploy, manage, update and monitor all those apps, in the same way, using the same tools. 

What's interesting now is that Windows is supported in both the main container orchestrators - Docker Swarm and Kubernetes. Swarm has supported Windows since 2016 so it's very solid, and it's a great choice if you're starting out because it's built right into Docker and it's super simple to use. The cloud providers have centred on Kubernetes, partly because it's easier to integrate as a managed service. Windows recently went GA in Kubernetes, so we'll see all the clouds support Windows nodes soon. Kubernetes just runs Docker containers though, so you can easily migrate from Swarm to Kubernetes if you choose.

InfoQ: To finalize, how connected have you seen Docker and Microsoft?

Stoneman: I have insider knowledge here because I work for Docker and I'm a Microsoft MVP :) On a technical level, the Docker team and the Windows Server team have been working closely since 2014 getting Windows containers up to parity with Linux containers. On a business level, I can't say too much, but there's a huge opportunity to help organizations ship better software more quickly, and Microsoft and Docker are working together to make that happen. On a customer level, it's a great story because the licensing for Windows Server 2016 and 2019 includes Docker Enterprise, so you get production support for your Windows containers from both Microsoft and Docker.

About the Book Author

Elton Stoneman has been a Microsoft MVP since 2010 and a Pluralsight author since 2013. Before joining Docker he spent 15 years as a consultant, architecting and delivering large and successful solutions built on .NET and powered by Windows, Docker, and Azure. He's enjoying working with the new evolution of Microsoft stack, helping people understand the great opportunities to modernize existing .NET Framework apps with Docker and run them alongside new .NET Core apps in Windows and Linux containers.