The market may be starting to shake-out in terms of dominant cloud APIs, major efforts to manage/govern cloud infrastructures, and who will (or will not) influence/direct these efforts. But the end-game is far from clear.
From the cloud API perspective, there are a few likely contenders/winners here:
- The Amazon Web Services (AWS) approach: arguably dominating the market at the moment, explicitly supported by Eucalyptus, as well as by Nebula, and CloudStack
- The OpenStack approach, which likely will adopt some of the AWS approach, but possibly in favor of another
- The VMware vCloud approach, arguably dominant in the enterprise space, and being partially adopted by large service providers.
- Other dominant SP/vendor approaches such as Google and MSFT Azure
- The open-sourced OpenStack.org effort
- The open-sourced CloudStack.org effort, newly affiliated with the Apache Software Foundation
- The commercial Eucalyptus.com effort, closely affiliated with AWS
- Many 'proprietary' vendor code bases for managing/automating cloud infrastructure
The third "leverage point" of cloud management and standardization is of the virtual machine images such as the Amazon Machine Image (AMI) or the VMware VMDK.
I'm looking at all of this from the perspective of the future cloud ecosystem - one where cloud services (and infrastructures) can easily interact with each other.
The question that got me thinking is whether hybrid cloud service and provider ecosystems will ultimately be loosely-coupled or tightly-coupled? In other words, will there be significant consistency between "like-designed" and "like-implemented" services... or not?
The foundation of my question consists of two scenarios I believe will be played-out:
- A few close-knit ecosystems, each using a single cloud API and Machine Image, creating a small number "tightly-coupled" clusters of providers. (No one would deny that AWS/AMI will be one of the winners) In this world, it would be relatively easy to achieve portability between cloud service providers - which doesn't just mean code, but would include portability of policies, monitoring, etc. as well.
- An larger, fragmented ecosystem with a more "loosely-coupled" set of players. Here we might see a number of heterogeneous APIs, Machine Images and infrastructure technologies, perhaps based on special-case uses, e.g. for community or vertical-industry cloud providers.
In the second Loosely-Coupled scenario, there might be quite a number of varied implementations, Image types and APIs. This approach might be advantageous for individual special-purpose cloud uses. But it would also require that integration across providers would rest on the shoulders of the user, likely Enterprise IT. Lots of "glue logic" would be needed to integrate the various SP services into the enterprise's own technologies and processes, and potentially even use of conversions of code from one image type to another.
Are Allegiances Forming?
I'd say so, particularly of the "Tightly-Coupled" variety. Already, Amazon has licensed its API to Eucalyptus (see James Staten's blog "Has Amazon Solved Its Private Cloud Dilemma?" or Lydia Leong's "The Amazon/Eucalyptus Partnership"). In my opinion, we'll see even more of these API alignment agreements, perhaps after this deal has some early user successes.
Similarly, VMware is fronting its vCloud approach and machine images to a host of aligned Service Providers. And even Microsoft is encouraging the use of Azure APIs and technologies to create private clouds.
As the public and service provider cloud market matures, natural "Camps" will form around them. Ultimately, the first question that we might find ourselves asking is "Are you a Microsoft, Amazon or VMware Cloud?".
Kind of a modern version of the "are-you-Mac-or-PC?"