Virtualization has been around for a long time, and sometimes the pace of its advance has seemed dizzying. The truth is that it’s probably just getting started, and so it’s important to look a little at where we came from and what’s new, to try to get a hint of what’s going to be even newer.
Virtualization started off with the notion that you could utilize servers more efficiently if you created “virtual machines” that were co-hosted on a single server but appeared to both applications and operations processes as real, independent, computers. Nearly all the early applications of virtualization ended up inside a data center, but these still launched the notion of a virtual resource pool that had an indirect connection with the real server resources.
The next phase of virtualization was the cloud, which used the greater efficiency of virtual hosting to provide a commercial infrastructure-as-a-service offering. IaaS took virtualization out of the data center, and it also exposed a clearer vision of what virtualization was. A resource pool in the cloud is an abstraction of hosting that users think is real and that providers know has to be mapped and managed to resources.
Beyond IaaS we have both “hybrid cloud” and “multicloud”, which are a form of virtual resource pool that span not only servers and data centers, but also administrative domains. This is where we are today in terms of virtualization, attempting to create a unified application-side vision of resources spread across multiple hosting domains. My enthusiasm for Apache Mesos and the Mesosphere DC/OS stuff was generated by the steps that framework takes to accomplish this goal of unification of resource pools under a common virtual hosting model.
These developments in virtualization have been paralleled, in a sense, by developments in DevOps and orchestration. Deployment of multi-component applications has been an increasing challenge for operations people because every component is in one sense an independent application, deployed under its own rules, and in another a part of an integrated workflow that has to be sustained as a whole to do its job. DevOps in its early form presumed that development teams would, while structuring the components of an application, define the necessary deployment (and redeployment) steps. Most early DevOps tools were really “scripting” tools that recorded operations steps to ensure accuracy.
The cloud changed this too. One logical mission for public cloud services is to act as a backup or incremental resource in which to add application component instances under load or during a failure. Scaling and “hot replacement” represent a more complicated mission than deployment or redeployment, and so the notion of “DevOps” as a simple development/operations handoff evolved to what’s now more commonly called “orchestration”, the idea of making a bunch of separate elements sing the same tune in the right key through the entire number.
As orchestration evolved to deal with more complexity, the whole notion of “deployment” was demonstrating it was a moving target. An application running on an elastic, distributed, resource pool and taking advantage of scaling and failover, is a dynamic system. The goal isn’t just to deploy it, but to manage its complex lifecycle, a lifecycle in which pieces appear, disappear, and are replaced as needed. Application lifecycle management was a term already used to reflect the development lifecycle, and in the cloud provider and network operator spaces these new challenges emerged as services got more complex, so I like the term “service lifecycle management” to describe the process of sustaining the services of application software in a virtual world.
The state of virtualization, stated in terms of current goals, is a combination of creating a true abstraction of hosting that can be spread uniformly over all kinds of resources, and creating a model of service lifecycle management that operates on that abstraction. We’re only now starting to recognize that these two goals are important, and will inevitably have to be met to make virtualization as useful as everyone wants it to be. It’s this recognition that will drive the future of virtualization.
It doesn’t take an expert to understand that the goal here is a three-layer structure. At the top are the applications, components, and hosted features that combine to create a user/worker experience. At the bottom are the resources needed to run them, including servers, databases, and network connectivity. Virtualization is the layer in the middle. This view is useful, because it demonstrates that what we call “orchestration” may be more complicated than we think.
Today, orchestration and DevOps cross that middle layer, meaning that the focus of service lifecycle management is to create a binding to resources at deployment and redeployment, but to link the resource layer explicitly to the application/service function process. That linkage makes it harder to make these processes truly independent. Might it be better to keep applications and services above, and resources below?
The problem with this is that it may collide with the notion of universal resources. If the application has to run on anything, then the orchestration processes have to be able to deal with anything. Is the specialization needed to accommodate hybrid cloud and multicloud appropriate to what’s supposed to be an application-layer orchestration process?
The complication we face achieving a true abstraction layer is the fact that the abstraction layer of virtualization has to be harmonized two-directionally, and the harmonizations are interdependent. A virtual host has to be linked to an application, but also to a real host. Some of the dynamism that virtualization is aimed at could be achieved either by managing the abstraction-to-resource part or the abstraction-to-application part. There are likely two “orchestrations” taking place, and how the work is balanced between them and how coordination is achieved is our next big issue.
Another way of thinking about the problem (the right way, IMHO) is saying that there is orchestration modeling taking place on both sides of the boundary, with some specific coordinating behavior between the two. This could be done via a multi-layer modeling and orchestration function that simply assigns a boundary point. Above the boundary, we call what’s happening “service” or “application” orchestration, and below we call it “resource orchestration”. I’ve used this approach in my ExperiaSphere work, both in the original project and the new version.
The advantage of an elastic boundary supported by modeling on both sides is the elasticity. We could define a particular “virtual resource” with properties that included both scaling and self-healing, in which case most of the complexity is pushed down into the service. We could also define it more as it’s done today, where a virtual resource/host is something that can fail or be overloaded, and the application/service is then expected to remediate if it does.
Having a hierarchical model of the service/application/resource structure, with an elastic boundary that frames the point where remediation is expected to be applied, lets us either shift to a model of virtualization where resources self-heal, or to a model where application-specific mechanisms respond to faults and overloads. That seems the best approach to take, in no small part because it reflects how we’ve been evolving virtualization all along.