Virtualization may be the most successful technology ever to cross the threshold of the enterprise data center. Vastly better hardware utilization and the ability to spin up VMs on a dime has made virtualization an easy sell over the last decade, to the point where Gartner recently estimated that 70 percent of x86 workloads are virtualized.
Yet the fancy private cloud stuff on top of that virtualization layer has been slow in coming. Yes, virtualization management tools from VMware and Microsoft have enabled cloudlike behavior for servers and storage, and even OpenStack is finally getting a little enterprise traction -- but the advanced public clouds offered by Amazon, Google, IBM, Microsoft, and Rackspace deliver much more advanced autoscaling, metering, and self-service (not to mention hundreds of other services). Plus, the PaaS cloud layer for developing, testing, and deploying apps -- now offered by all major public clouds -- has found its way into relatively few enterprise data centers.
Then Docker roared onto the scene last year, offering a new cloud stack based on containers rather than VMs. Containers are much lighter weight than VMs and enable applications to be packaged and moved with ease, without the hassle of conventional installation. If VM-based clouds have stalled, and the new container-based stack offers such obvious advantages, will the new stack leapfrog its way into the enterprise to deliver a new private cloud?
Zorawar Biri Singh, former head of HP Cloud Services and now a venture partner at Khosla Ventures, thinks the triumph of the new stack is inevitable -- but we're still years away from enterprise adoption. Here's where he sees the bottlenecks:
First, for traditional enterprises and traditional production workloads, the current IT spend is focused on simplifying and managing the VM sprawl via converged solutions in the data center. Second, the new stack is still brittle and early. Real utility around containers, like hardened security, is still nowhere near adequate. Right now the new stack is a very good seeding ground for dev and test workloads. But the real friction point is that enterprise production-workload IT teams lack the devops orientation or agile IT backgrounds to be able to deploy and support distributed or stateless apps. One of the biggest issues is that there's just a huge skills gap in devops in traditional enterprise orgs.
On the other hand, says Singh, "certain dev teams and greenfield lines of business are already riding on this infrastructure." In such cases, either devops methods are already in place, or pioneering developers are handling the operations side of the container-based stack themselves.
Just as developers have driven the adoption of NoSQL databases, they're on the front lines of the new stack, downloading open source software and experimenting -- or turning to public clouds like EC2 or Azure that already support containers.
The microservices imperative
Why do developers like the new stack so much? In large part because containers are conducive to microservices architecture, where collections of single-purpose, API-accessible services replace monolithic apps. Microservices architecture enables developers to build applications that are more adaptable to new requirements -- and to create entirely new applications quickly using existing services.
John Sheehan, co-founder and CEO of the API monitoring and testing service Runscope, sees microservices as a "modernization" of SOA (service-oriented architecture). "The core responsibilities are largely the same," says Sheehan. "We want to distribute different parts of our software architecture across different systems and break it up not just by code boundaries but by service boundaries. That learning has carried over to microservices."
The types of microservices that we see and that our customers tend to use are very devops-driven. Internally, we deploy about 31 times a day at our company across all of our different services. We're 14 people and we have about 40 different services running internally. So big part of it is putting the necessary infrastructure in place so each team is able to independently deploy, scale, monitor and measure each service.
In such a scenario, the line between dev and ops blurs. Ops personnel write code to manage the infrastructure, essentially becoming part of the development team. "There's very little distinction between ops team and apps team," says Sheehan. In ops, "you happen to be coding against servers instead of coding against the service."
Singh believes the devops-intensive microservices approach might obviate the need for "formal" PaaS. Such PaaS offerings as Cloud Foundry or OpenShift offer predetermined collections of services and processes for building, testing, and deploying applications -- whereas, in the new stack, rich sets of API-accessible microservices can be embedded in every layer. Both dev and ops can plug into microservices up and down the stack, without the constraints imposed by PaaS.
A different kind of hybrid
Microservices architecture may leapfrog PaaS, but the entire new stack will not take root overnight. For example, Netflix is widely considered to have the most advanced microservices deployment anywhere, and it makes many prebuilt services available to the open source community as Docker images on Docker Hub -- but Netflix doesn't use Docker in production. Nor does Runscope, for that matter. Both use conventional VMs instead.
Despite the huge interest among developers in container-based solutions, it's early days. For one thing, the orchestration and management tools for containers, such as Mesosphere and Kubernetes, are still evolving. For another, it's not clear which container standard will win, with CoreOS posing a major challenge to Docker last December. The container-based stack may triumph eventually, but it's going to take a while.
"We see the most likely outcome is that containers and VMs will be used in combination," says Kurt Milne of the multicloud management provider Cliqr. That could mean running containers inside VMs -- or it could simply mean that new container-based stacks and VM-based stacks will run side by side.
This hybrid scenario opens an opportunity for VMware and others who have built management and orchestration for virtualization. In an interview with InfoWorld last week, VMware executive vice president Raghu Raghuram refused to view containers as a threat. Instead, he said:
We see containers as a way to bring new applications onto our platform. When developers or IT folks wonder what they need to run containers in a robust way, it turns out they need a layer of infrastructure underneath -- they need persistence, they need networking, they need firewalling, they need resource management and all those sorts of things. We've already built that. When you plop the container mechanism on top of this, then you can start to use the same infrastructure for those things as well.
We're seeing patterns where the stateless Web front end is all containers, and the persistence and the databases are all VMs. It's a mix of both. So now the question is: What is a common infrastructure environment and a common management environment? We see that as a tremendous opportunity for us.
Raghuram declined to say when VMware might extend its management tools to the container layer, but the implication is clear. It will be interesting to see how VMware's ops-oriented approach will be met by the developers who are driving today's container-based experimentation.
What's clear is that, despite the current excitement, the new stack will not supplant the existing one in some dramatic rip-and-replace wave. As with cloud adoption, the container-based stack will almost exclusively be used for dev and test first. The huge existing investment in virtualization infrastructure will not be thrown out of the data center window.
Nonetheless, the new container-based stack is a big leap forward in agility and developer control. Developers are discovering and adopting the tools they need to build out microservices architecture and to deliver more and better applications at a fantastic clip. As the pieces fall into place, and devops skills become ubiquitous, you can bet the new stack will take root as relentlessly as virtualization did.