The widely reported VMware acquisition of Heptio raises a lot of very interesting points about cloud computing, application development, and the newly competitive world of platform software. It even has implications for the network operators and vendors in that space. Finally, the scope of change the announcement is part of shows that the ecosystemic vision of IT and networking so essential to our future is getting a lot harder to follow. And remember, confusion about direction is always a risk.
At one level the VMware deal for Heptio is all about containers (a way of standardizing and simplifying host virtualization for the data center and cloud) and Kubernetes (an open-source tool for the orchestration of container deployments). In another, it’s about supremacy in the world that containers and orchestration are just now creating. That new world holds the key to the future of IT, and indirectly the future of networking, and it may be that the success of players in both spaces will depend on how quickly they see that truth, and what they do with it.
Heptio, interestingly, isn’t selling Kubernetes, which as I said is open-sourced. It’s really an integrator, one of an increasing number of players who have launched in the IT space to act as a bridge between an incredibly interesting and complex new model of computing and a market and tool set that have no real sense of the new ecosystem. Heptio and others like it are doing by synthesis what a thoughtful approach what cloud computing should be would have done by analysis. That’s not said to diminish Heptio, only to help frame the problem we face, and that it and VMware are working to solve.
That problem, simplified, lies in transition. We used to view “applications” as monolithic software that runs somewhere, accepts transactions from outside, and returns results. From a development perspective, this meant redoing a lot of common stuff across multiple applications, so we developed methods and tools to reuse things. Software included “platforms” or “middleware” tools, and also packaged features and functions—“Classes” and “methods”. These came to be generally known as “components”. We now view applications as coordinated behavior among distributed functional pieces, which have come to be generally known as “services”.
Thinking of applications as a set of separate, and in fact separated, services is critical for optimal application design in cloud computing. You can scale services, change them easily, implement them differently, and because they always behave the same way and work through the same API, everything works out. The way that service-based applications impact performance through network latency can be balanced against these benefits at the time you design the services, and again when you invoke them.
You can see from the description of “services” that the concept, in effect, creates a virtual computer. Anything that can run software and be connected could be part of it, but if you let your concept of the populist virtual vision run away, you end up with something that’s an integration nightmare and way beyond nightmare from a development perspective. It’s easier for everyone if you can build a standardized framework, employ standard tools and practices, to create that new virtual computer. That might have been a great project a decade or so ago, in fact, but nobody got around to it. So what happened is that we started solving distributed-service problems a little at a time, and evolved (by accident, in a real sense) a general solution.
“Containers” are deployable units of logic. That means that they are a combination of software and all the parameters and rules and policies that are needed to deploy it. The concept is fairly old (it’s part of Linux, for example) but it got hot and popular because the prevailing tool of virtualization, the “virtual machine” or VM, had perhaps carried the notion of machine-virtualization too far. A VM turns out to be just about as operationally complex as a real server, and it duplicates everything from an operating system and middleware software sense, for every application. Even if ten VMs run on a server, you have ten of everything and the VM “hypervisor” stuff besides. Containers run inside the operating system, in effect, and so you don’t have to manage virtual-but-separate servers or have all that overhead.
What makes containers work is that the environment in which applications run and how they’re networked is standardized. In effect, a container is a piece of our virtual computer. As tools developed to deploy containers, notably Kubernetes, those tools turned out to be not only good for deploying software, but for deploying services and connecting them. Others then started to build enhancements to Kubernetes and containers, to handle things like workflows (Istio), multi- and hybrid-cloud (Stackpoint). There’s a whole container ecosystem, and much of it has been directed at making containers the perfect way to host distributed services.
Cloud providers like Amazon, Google, and Microsoft have all adopted containers and Kubernetes to a degree, and to nobody’s surprise so have all the major IT vendors. You can look up “Kubernetes” and the name of any big vendor—Dell, HPE, IBM, Oracle, SAP—and find they provide something that includes Kubernetes and other stuff to create their own version of a cloud/virtual-computer ecosystem.
A pile of parts doesn’t make a car, which is why this kind of unified offering is happening. It’s also a big part of why VMware is buying Heptio. In the open-source world, you don’t “sell” open-source or in most cases just steal it and stick it into your own software. You integrate with it where the software is designed to support that, and comply with license restrictions. Heptio is an integrator and assembler, a company who knows how to create the car from the pile of junk. The fact VMware bought it shows that VMware is totally serious about this virtual computer future, and that they know that for quite a while it’s going to be as much about integration as tools.
Another critical development in the cloud and virtualization space is something called “GitOps”. This is an evolution of the fairly familiar concept of “DevOps”, the precursor to the current orchestration and Kubernetes wave. “Git” is the name of a popular code and version control repository, and GitOps is the concept that anything that’s software-based can be described in a repository, not only in terms of the code (the software) but in terms of all the parameters needed to load, run, and sustain it. “Single source of truth” is what it’s called. If you add GitOps to the Kubernetes and container ecosystem, you get a new model of distributed component/services, one that doesn’t require standardization of everything, but rather storage of everything relevant. GitOps is kind of self-integrating.
So how does networking fit into this? One fairly obvious point is that everything that the operators have been trying to define for NFV since 2013 could have been done better had they started with framing actual requirements and let cloud implementation trends frame the mechanisms. Top down, again. Another slightly less obvious point is that if there is such a thing as a cloud-general virtual computer (which of course is what’s being built with the container ecosystem) then there’s a network-feature-specific subset of that virtual computer. You can, if you like, jump on one of the current market terminology bandwagons and call this a “platform-as-a-service” or PaaS dedicated to service feature hosting.
The cloud, container, and GitOps model of services hits all the right buttons for operators. It’s based on a “platform”. It includes a single source of truth, an authoritative mechanism for assuring consistency in deployment. That repository is fully auditable and has full version control. The platform model includes a networking component that standardizes connectivity. You can extend the model across clouds, onto the premises, and just about anywhere else. Cloud tools already in use, and already proven, create and sustain it. It’s designed for scalability and resiliency. In short, it’s the only thing that’s going to work for networks, for operators, in the long run.
For operators and vendors who specialize in the network operator space, it also demonstrates that there’s a healthy dose of integration and forward thinking needed to get all this properly assembled and deployed. This means that vendors like Ericsson who have tried to specialize on professional services have an opportunity to be the Heptios of the network operator world. It also means, of course, that vendors like VMware have the opportunity to be the new integrators in that world.
What truly annoys me about all of this is that it was crystal clear five years ago that this kind of thing was going to happen. I’m not saying I predicted containers, Kubernetes, GitOps, and so forth, but I did predict that “NFV” needed to be specified purely in cloud terms. It could have been done. The pace at which the right answer has emerged is dazzling, which is a word we could hardly use in referencing any attempts by the network operators and their vendors to accomplish anything with respect to transformation.
We can’t recapture the past, but we can learn from it. ETSI’s Zero-Touch Automation activity is just as out-of-cloud-touch as NFV. The open-source ONAP project is likewise. Operators, and the vendors who plan to make money from them in the future, are at a crossroads with respect to the cloud, and if they fail to act differently today, they are perhaps aligning themselves with the ultimate in disintermediation.
Not so the cloud space. The pace of progress in the “cloud-native” approach is far faster than I’d believed was possible. Yes, we’re in the usual danger of “cloud-native-washing”, and you can already see vendors who want to tell you that if they support Kubernetes they’re cloud-native and in on this whole ecosystemic container push. Despite that inevitable hype risk, really good stuff is happening here, and we are going to see transformational results from it. It’s not often in the last decade I’ve felt confident in that happy an outcome.