The cloud is essentially a vast collection of discrete hosting resources, which can make management a challenge. And when you start to use multiple cloud providers and platforms, that challenge grows. The best way to minimize the complexity of multi-cloud management is through abstraction, which can make various cloud platforms look more like a single cloud or host.
There are two broad approaches to abstraction for multi-cloud. One is resource abstraction, which creates a layer
above
your cloud resources and providers to make them appear as a single resource or host. The other is
orchestration-based
abstraction, which makes any differences in software or hardware combinations across the multi-cloud environment insignificant -- as long as your application lifecycle processes can operate the same way on every host. Whichever multi-cloud management approach you choose should depend on your overall IT infrastructure and strategy, as well as the nature of your cloud applications.
Resource abstraction
Resource abstraction is based on the simple theory that, if all the application hosts appear the same, then a single, simple set of tools can deploy and manage applications across a multi-cloud environment. In multi-cloud applications, resource abstraction can make all public cloud platforms look like a single cloud, as well as abstract data center resources in a private cloud. The broader the scope of resource abstraction, the less significant the boundary points between cloud providers or between public clouds and the data center become.
Cloud computing software, such as OpenStack, and container software, like Docker or CoreOS Rkt, provide basic resource abstraction. They also demonstrate that the essential element in abstraction is explicit support for a pool of abstract resources -- sometimes referred to as a cluster or swarm. The organization of resources into clusters is a task that borders on orchestration, which means that it's common for tools to do both resource and orchestration abstraction.
The best strategies for resource abstraction embrace some degree of orchestration.
In fact, the best strategies for resource abstraction embrace some degree of orchestration. Two examples of this are Apache Mesos and Datacenter Operating System and Univa's Grid Engine and Navops Launch. Both combinations can create clusters within each cloud platform you use and abstract them upward to form superclusters that you can use for elastic hosting. This shows that, for multi-cloud resource abstraction, it's critical to have specific virtualization support for each cloud provider you use.
Resource abstraction tools enable you to define deployment and connections for features that are unique to a certain cloud platform; Univa, for example, has a sophisticated capability for deployment in AWS. But if an application uses unique features or web services from different cloud platforms, you can't scale or redeploy the same image across the multi-cloud deployment. At that point, our second strategy comes into play: orchestration abstraction.
Orchestration abstraction
Rather than aim to make resources look the same, this approach attempts to make resource management look the same. In a sense, orchestration abstraction embraces the differences among cloud providers rather than abstract them away. The goal of this multi-cloud management model is to create orchestration and automation steps with tools that enable you to complete standard and consistent application lifecycle tasks -- regardless of which combination of hosting or cloud providers you use. Resource abstraction operates, in a sense, "below" application lifecycle processes, while orchestration abstraction simply adapts general processes to specific cloud or data center infrastructures.
The first type of orchestration abstraction tools are extensions of popular virtualization frameworks. For example, Kubernetes offers some orchestration abstraction for containers, and OpenStack does the same for private or public infrastructure-as-a-service platforms.
The second type of tools, which offer more "pure" orchestration abstraction, emerge from DevOps. Application deployment automation is the aim of DevOps, and you can extend those capabilities to standardize deployment across multiple clouds. Some DevOps tools, notably Chef, standardize the processes associated with application lifecycle management (ALM). Others, like Puppet and Ansible, are based on defined operating states, which the software then seeks to attain through changes in configuration. The trend in the industry seems to favor the second approach, and IT teams can more easily adapt this model to multi-cloud orchestration abstraction.
A good orchestration abstraction tool works at two levels. First, a set of general processes should define how application lifecycles work. Second, a plug-in, or second layer of functionality, will
adapt
that general model to the specific needs of a particular cloud platform or data center. To add in a new cloud provider, simply define that second layer for the features on the new platform.
Choose between the two abstraction models
To decide between these two abstraction approaches for multi-cloud management, focus more on your existing
tool sets
rather than on how these models work. For enterprises that already use DevOps deployment and ALM tools, extending these tools to host workloads in the cloud or in multi-cloud is the logical choice. For those who have embraced a new hosting technology, especially containers, look at resource abstraction, as it maps well to emerging virtualization and container models.
If multi-cloud environments with a mix of private and public clouds are the endgame for your enterprise --- which they are for many -- it's likely that all your abstraction tools will converge into a common model anyway. But remember that orchestration abstraction might be the better fit for multi-cloud if it also provides some resource abstraction, while pure resource abstraction approaches can't accommodate differences in hosting features.
