I went to Linuxcon 2015 NA with a friend this year. It wasn't hard to figure out what the flavour of the year was -- containers. And Docker was the overwhelming favourite. As usual, I found it way easier to see the negative in the hype, rather than the positive.
But I'll try to see the positive first. There's a lot of value in having a thinner layer, thinner than a full virtual machine, between an application's context and the bare metal. There's also value in packaging an application and distributing it in a way that's thinner than shipping a whole virtual machine. Containers have the potential to provide these features.
The container has many historical roots, but from what I saw, we're mostly excited today because this is what Google has been using for 10 years to run their vast server farms. They have a very particular use case: Huge numbers of users accessing a small set of relatively homogeneous functionality. Perfect for a light-weight way of deploying a huge number of instances of applications across the smallest number of physical resources possible.
There were a number of presentation where the engineering challenges around containers were discussed. And there are significant ones, primarily around networking and privileges (all processes in containers run as root on the containing physical machine). These challenges will be solved, but not for another 18-24 months, I'd guess. Only then can we start to talk about adoption in the enterprise world.
In the enterprise world, the one I get paid to play in, we're mostly still dealing with servers as pets. Even at my current client, who have drunk the DevOps kool-aid and have Puppetized a lot of their deploys, we're talking about very few duplicate instances of a server in production. (They get value from Puppet by cleverly factoring the Puppet configuration across development, test, UAT, and production environments.)
Given the engineering effort that was evident in the containers model, I think there's going to be another significant adoption hill, like there was for virtualization. Perhaps even more so, as I'm not convinced that the math will be quite as compelling for containers as it was for VMs. The problem is that the definitions of containers have to be hand-crafted. Once the container is defined, you can spin up thousands, quickly and efficiently. But as I just said, most enterprises just need a few instances of any particular application.
Some of the speakers talked about containers being just another stop on the continuum from physical machines to virtual machines and other models (Amazon Lambdas, for example). SaaS (not PaaS) providers can use containers to realize savings on hardware, because they can amortize the container definition cost over all their customers. Enterprises that use SaaS will use containers, without even knowing it, as it should be.
Compounding the problem of enterprise adoption of containers in-house, is the fact that the orchestration tools (tools for spinning up, shutting down, and monitoring a large number of instances), are largely split along the underlying model: You use VMware or Openstack to manage virtual machines, and Kubernetes (or any one of hundreds of other offerings) to manage containers. Most enterprises won't have the personnel or the volume of applications to justify developing two different skill sets and platforms to manage their VMs and containers. There needs to be a unified orchestration platform that covers the spectrum of deployment models.
In summary, I think that containers will be a significant deployment option in the near future, but the way they will be used in practice is still to be determined, and they may never end up being adopted for in-house enterprise deployments.
No comments:
Post a Comment