Monday, April 23, 2012

Will The "Stack Wars" Impact the Hybrid Cloud?

It's been a busy few weeks in cloud O/S land, first with the Amazon/Eucalyptus announcement and then with Citrix/CloudStack announcement, then last week's OpenStack show in San Francisco.

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
From an infrastructure management code base perspective, we also have
Note that it's important to distinguish between the cloud APIs and the infrastructure management code bases.  As pointed out in the Rightscale Blog, there will likely be multiple implementations of given APIs... and that's good because it allows for innovation around factors such as performance and underlying technologies.

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.

    What this all means to the future of Hybrid Cloud Computing

    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:
    1. 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.

    2. 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 first Tightly-Coupled scenario, which smells more like a "standards" play, use of only a few winning APIs and Image types would make it easier to deploy consistent tools for monitoring, metering, compliance, security, availability, etc. across different providers' infrastructure, simplifying efforts for enterprise IT.  Providers might compete on efficiency of implementation, for example.

    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?"


    xbrlspy said...

    "Stack Wars" or the conundrum of which of multiple Cloud IaaS/APIs to choose (VMWare, Amazon or Microsoft) is going to have little impact on hybrid cloud implementations. the PaaS layer is essentially becoming the Cloud O/S and the differentiator of Hybrid Clouds enabling application deployment, auto-scaling and bursting across multiple cloud hosting providers and taking advantage of services regardless of what VM or AMI is under the hood. PaaS abstraction layer provides integration across clouds and delivers the "glue logic" to integrate the various services and technologies enterprises and developers require across providers. IMHO, rather than thinking of Cloud APIs as Macs or PC - think of them more as the "Intel-inside" and all the generic chips and hard drives that we (as consumers of the cloud) should really not have to think about other than availability, size and regions.

    Ken Oestreich said...

    Good point. So, to take this one step further, then is all the competition around superiority of vendors' cloud stacks, OpenStack, CloudStack, Amazon, etc. a moot point?

    If so, then does the "real" value lie in developing differentiated PaaS services rather than IaaS?

    Market Research Companies said...

    Your post really helpful for my research and development....Thanks a lot!

    Data Center Infrastructure Management Market research report