Edelweiss - Fotolia
The arrival of Docker native support for containers on Windows Server 2016 is a big deal for developers. Analyst Chris Tozzi lays out the big pros and lesser cons.
Ready to Dockerize your Windows apps? Microsoft software engineers who take advantage of Docker on Windows Server 2016 can gain the advantages of containerized development, which include better portability and environmental consistency, as well as quicker deployment, according to Chris Tozzi, DevOps analyst for Fixate IO.
According to Tozzi, the availability of native support for Docker containers on Windows Server 2016 is a big deal.
"All the advantages that come with Docker are now available on Windows," he explains. "It's exciting for the community as a whole -- not just for Microsoft, not just for Docker, but for anyone looking for an easier way to deploy Windows apps. This is a big step forward."
Tozzi takes a soup-to-nuts tour of development with Docker on Microsoft Windows Server 2016 in this podcast, examining the advantages it provides for microservice and application development. He also explores the emergence of containers as a service (CaaS), the possibility of Docker support for macOS and more.
Listen to Tozzi share his observations about developing microservices and apps using Docker on Windows Server 2016. For your convenience, the transcript is below.
Transcript - Exploring benefits, limitations of Docker on Windows Server 2016
For software engineers and architects, what advantages does Docker unveiling native support for containers on Windows Server 2016 bring?
Chris Tozzi: You get to use Docker on Windows, or you get to Dockerize your Windows apps. Docker was originally a Linux-only technology. And because of the way Docker works, if you Dockerize a Linux application, the application itself has to be one that can run natively on Linux.
So, Docker support on Windows means that you can take an application developed for Windows and compiled for Windows -- an application that only runs on Windows -- and now you can run it as a Docker container.
Chris TozziDevOps analyst, Fixate IO
That brings all the advantages that come with containerization. You get a lot of portability [and] more environmental consistency because Docker will always be the same environment. And any Windows server -- it doesn't matter how the server is configured at the underlying level -- actually gives you that kind of consistency. You get quick deployment because you can deploy inside the container, which is often easier than deploying an app on Windows the old-fashioned way.
Just to kind of sum this up, all the advantages that come with Docker are now available on Windows. That's a big deal, because originally it looked like it would be very, very hard to bring this sort of functionality to Windows. I think it's impressive that Docker did it in only three years.
In which way could using Docker on Windows Server 2016 be beneficial in microservices development and deployment?
Tozzi: Here you get to do the same thing now on Windows that you were doing with Docker containers on Linux. Part of the appeal of Docker on Linux is that Docker makes it very easy to take legacy monolithic applications that were written to run … one big chunk of code and put them up to run as microservices. So, you can separate your storage layer, for example, from your networking layer and run each service inside containers which makes things much more agile [and] much more fault tolerant than they would be if everything just, kind of, ran under the same hood.
That's because if your app is running as microservices, it's easy to scale individual parts of the app up or down by adding or subtracting containers that are hosting each of those microservices. It also provides some security, because if one of your services is compromised, it doesn't mean that the whole app is necessarily compromised. And then you can turn off one service if you need to without having to shut down the entire app. So, you get all that flexibility now on Windows as well as on Linux.
Chris TozziDevOps analyst, Fixate IO
So, again, that's a big deal and I can see that changing the game for a lot of Windows applications, which traditionally have been developed in a very monolithic kind of way. SOA was kind of a precursor to microservices. And SOA, in a lot of ways, saw only limited success. But I think even when you're talking about SOA, what people were doing in [the] 2000s to try to distribute apps instead of running a monolithic fashion, there was more success there in the Linux world than there was on the Windows world.
I think that Docker support for Windows Server 2016 is, in some ways, a second chance for the Windows community to really embrace the idea of distributed applications, but in a very modern way by using microservices, instead of just trying to do old-fashioned SOA.
What might be some limitations that developers find working with Docker on Windows Server 2016?
Tozzi: Right now, the big limitation is that certain key parts of Docker functionality are not supported on Windows, and Microsoft and Docker are working on resolving these things. But, right now, that functionality is just not there. It's simply because it hasn't been implemented. And that hasn't been implemented yet because in order to make Docker containers work on Windows, a lot of new stuff had to be introduced … to the operating system itself, to the Windows kernel … at a deep level.
Chris TozziDevOps analyst, Fixate IO
The Windows kernel, unlike Linux, was not designed from the get-go to support Docker containers. The Linux kernel also wasn't designed from the get-go to support modern Docker containers. But Linux for a number of years has had LXC (Linux Containers). It was a plug-in to the kernel, so there wasn't as much very low level work required with Linux to make Docker work in it. Even Docker today no longer uses LXC, so it's kind of a complicated story there.
But the point is that there's still work to be done to make Docker containers work on Windows with all of the features that you get with Linux. Today, most of the basic functionality is there. You can use storage, you can containerize your app and you can run it. The area where Windows is still a little short is in networking. So, certain networking components for Docker don't yet work on Windows. In some of the conversations I've had with Microsoft developers and executives, they tell me that this is on the way. I haven't gotten any hard dates for when it might arrive. My suspicion is that it will be probably sometime this year. I don't think this is going to take years to materialize, but right now this is an important limitation.
And I think it really limits the ability of Windows DevOps teams to deploy Windows containers for production. If you don't have full networking support, in most cases, you're not going to be able to do production, unless for some reason you have an app but [it] doesn't need networking. But it's kind of hard to imagine one these days that wouldn't.
Can you give a brief history of Docker support for Windows?
Tozzi: That's a very good question, because things here get really complicated, and this is partly owing to the language that Docker has chosen to use, which I think is a little confusing. Docker released programs called Docker for Windows … and Docker for Mac.
What both of these programs do is allow you to install Docker on your Windows or Mac PC. All of the modern versions of Windows are supported, and Docker calls them native Windows or Mac apps. And they are native in the sense that you install them like you'd install any other Windows application or any other Mac application. But there's a huge caveat there -- and this is where things get confusing -- and it's important to look into the details.
Chris TozziDevOps analyst, Fixate IO
So, Docker for Windows actually requires a Linux virtual machine to run. So, what Docker for Windows really gives you is kind of an easy way to set up a Linux virtual machine on your Windows PC, and then you would run Docker on that Linux virtual machine. There are some integrations that the package does so it makes it easy to interact with the Linux or with the Docker environment running on the virtual machine from your Windows desktop, which is all good.
There's certainly value in that software. But it's a very different sort of thing than what Docker has done with native support for Windows Server 2016 where you have containers actually running, but not depending on virtual machines, not depending on Linux in any way. These containers are instead actually running on Windows itself, which is important.
Another important difference here is that with Docker for Windows Server 2016, you can Dockerize native Windows apps. You can't do that with old-fashioned Docker for Windows because, again, Docker for Windows still requires you to run Linux under the hood and Docker itself is still running on your Linux virtual machine. As a result, the Docker apps that you can run have to be Linux apps. Because of the way Docker works, you can't take a Linux app and run it on a Windows environment unless you have a virtualization layer there, and vice versa. You can't take a Windows app and run it on a Linux server with Docker. It's just not how it works.
So, I think that there's a little confusion here. It has to do with the way that Docker has chosen to use the word native when it calls Docker for Windows a native application. … I don't think that Docker intended to mislead people, but I think it is a little confusing because it's really not native containers. But Windows Server 2016 is native containers, and that's a huge deal because it takes Docker on Windows much, much, much farther than the old Docker for Windows package used to do.
Wow, that's a pretty complex history there. What is different about Windows containers versus, say, Linux containers in the hypervisor area?
Tozzi: You don't have to use hypervisors to run Docker containers. When we're talking about a hypervisor, at least if you're using the term in the traditional kind of sense, you're talking about a virtual machine. You're talking about an emulation layer like VMware or [kernel-based virtual machine]. A large part of the value of having a Docker container on any kind of operating system is that you don't have to have that layer. That layer wastes resources, because system resources are being devoted to the emulation layer, which means you have fewer resources available to actually run your apps.
With the Docker container, your app can run. It's not really accurate to say it's running on bare metal because Docker also has its own overhead -- it has its own abstractions in various ways -- but I think it's fair to say that with Docker your apps are running much closer to bare metal than they would be if you had a hypervisor in the way.
I guess it's worth noting, too, there's nothing stopping you from running a Docker environment in a virtual machine that's running on top of the hypervisor. And lots of people do that. There are good reasons to do that; the primary one being that gives you easy portability. If your Docker environment is running in a virtual machine and you want to move the Docker environment from one bare-metal server to another, you can simply move over the virtual machine. It's a very quick way to migrate the environment and you also get lots of other vendors of virtual machines. You can have automatic failure or failover, etc.
The reason I say this is [because] I think it's important for people to understand that Docker and virtual machines, or Docker and hypervisors, is not an either-or proposition. It can be, but in a lot of cases you're going to see these things used in conjunction with one another, and that's true on Windows as well as on Linux.
How to start Dockerizing Windows apps
Make the connection between microservices and Windows containers
Survey shows how companies are using Docker