olly - Fotolia
It's no secret that thanks to Docker, containers are all the rage, and that Docker containers are based on Linux. Where does that leave Microsoft? In an interesting place, it turns out. Modern Infrastructure caught up with Microsoft veteran John Gossman, an architect on the Azure core team, for his take on the situation.
Modern Infrastructure: Containers have been around a long time. Prior to Docker, did you see much demand for the technology?
John Gossman: No, we did not. [Windows has had] some fundamental features that you need to do containers for a long time now. For example, Job Objects, which, like Linux cgroups, allows you to control resource consumption. And there have been third-party attempts to do [Windows] containers in the past, but without access to the kernel, it's impossible to do it well. What [Docker creator] Solomon Hykes did was combine a bunch of container technologies in to a nice feature set for developers. It was really an aesthetic innovation, and I think it took everyone by surprise -- even Solomon.
MI: What, in a nutshell, is Microsoft's container strategy?
Gossman: You can think of it as two separate efforts that dovetail well, but that can also been seen independently.
For one, we want containers to work well for Windows, which you can see as part of Windows Server Containers, a feature of Windows Server 2016 Technical Preview 3. That preview also includes a Docker agent, the same codebase that is used to run Docker Engine. It doesn't mean that you can run a Linux Docker container on Windows, or a Windows container on Linux, but you do get the same management experience. For example, you'll be able to use Docker tools like Swarm and Compose to manage Windows Server Containers. It also sets up some interesting hybrid structures: for example a back end running Microsoft SQL Server with a front end running Apache Linux. We will also support alternate sets of interfaces -- for example Canonical LXD and our own native APIs -- for managing containers, but we expect that most of the ecosystem will use Docker.
And then, for Azure, if customers want to use containers, we want to make sure they work well with Azure. Today, we are focused on Docker for Linux on Azure -- for example, making it easy to deploy a Docker image there. We have a Docker extension where you just click a box to make sure that a Docker Engine gets created when you create an instance. We're also building out our Docker management and monitoring capabilities.
MI: What kind of interest are you seeing from customers?
Gossman: We are seeing interest both on the Azure side as well as from the on-prem Windows Server side. There's a lot of overlap between the two. Part of that is because very few enterprises are entirely homogeneous. The hybrid story is what's attractive to them. Azure, too, is increasingly heterogeneous. The last time I checked a couple of weeks ago, 25% of VMs running on Azure were running Linux. At the beginning of the year, that number was at 20%.
MI: What about container security?
Gossman: First of all, I wouldn't say that containers are insecure. If you're running in your own data center and you trust all your own people, you should run containers without any concerns. It's when you're in a hostile multi-tenant environment [such as a public cloud] that we recommend -- as do all the other public cloud providers -- to run with VMs [for their hardware isolation].
In fact, we believe that containers and virtualization are two technologies that are completely complementary to one another. Both of them have their advantages and disadvantages, but I don't believe there's a technological reason to have those compromises. And this isn't the end. At some point, containers and virtual machines are going to converge. We've talked publicly about Hyper-V Containers, an upcoming feature of Windows Server, where we take the same public API as a container, and wrap a lightweight Hyper-V partition around it. This gets you the same level of security that you would have in a virtual environment, plus it allows you to run incompatible kernels. There are lots of other efforts out there -- for example HyperHQ, a startup out of Beijing. [Ed. Note: Not to mention VMware's Photon Platform.] It's an obvious place to go.