Cloud & Virtualization Stacks: Users Fear Lock-In, Ecosystem Fears Lock-Out…
I don’t think I’m verbalizing something very well…so I decided to write it down. I still don’t think I’m managing to stick my point, but perhaps clarity will come by discussion.
Simon Wardley has written about market dynamics and behaviors associated with the emergence and ultimate commoditization of things many, many times, but I’m not sure that I’ve found satisfaction in being able to accurately describe the dysfunctional co-dependency between consumer, leading vendor and ecosystem supporters to my liking.
Here’s an example…
There’s an uneasy tension that seems to often become nothing more than wink-and-nod-subtext in discussions relating to the various stacks offered by leading cloud and virtualization vendors. Even those efforts with the “open” or “open source” descriptor bolted on for good measure.
It occurs to me that this can be attributed to many things; the business and licensing model of the solution provider, the ultimate “consumer” the offering targets, the area(s) of differentiation around technology, the maturity of the ecosystem, and the amount of self-integration versus vendor support required to successfully operationalize and maintain the solution.
More directly, the tension I refer to is the desire (or at least oft-verbalized complaints) on the behalf of “consumers” of cloud and virtualization stacks to not be “locked in” to a single vendor balanced against the odd juxtaposition — but not entirely unreasonable requirement — of simultaneously not being subject to the “integrator’s dilemma,” and having to support it all themselves.
Stir in the ecosystem of ISVs and solutions providers who orbit around these stacks, adding value where they have the “permission” to do so before either the stack provider obviates their existence by baking those features in directly, or simply makes it increasingly more difficult to roadmap given engineering dependencies they can’t control or count on.
I alluded to some of this in my blog titled Cloud Computing, Open* and the Integrator’s Dilemma wherein I mused:
I am just as worried about the fate of OpenStack and its enterprise versus service provider audience and how it’s being perceived as they watch the mad scramble by tech companies to add value and get a seat at the table.
Each of these well-intentioned projects are curated by public cloud operators and technology vendors and are indirectly positioned for the benefit of enterprises, but not really meant for their consumption — at least not if they don’t end up putting enterprises right back where they were trying to escape from in the first place with cloud computing: the integrator’s dilemma.
If you look at the underlying premise of OpenStack — it’s modularity, flexibility and open design — what you get is the ability to craft a solution finely tuned to an operating environment of your design. Integrate solutions into the stack as you see fit. Contribute code. Develop an ecosystem. Integrate, manage, maintain…
This is as much a problem as it is a solution for an enterprise. This is why, in many cases, enterprises choose to use a single vendor with a single neck to choke in order to avoid having to act as an integrator in the first place or simply look to outsource to one or more public cloud providers and avoid this in the first place.
Chances are, most are realistically caught up somewhere in the nether-regions in between the two.
This all sounds so eerily familiar…
- Cloud Computing, Open* and the Integrator’s Dilemma(rationalsurvivability.com)
- Citrix Leverages OpenStack With Project Olympus Cloud Platform (ostatic.com)
- RackSpace’s OpenStack Targets Cloud Lock-in (pcworld.com)
- More Signs of the Multiple-OS, Virtualized Future Are Appearing (ostatic.com)
- On balancing economic power in the FLOSS ecosystem (markshuttleworth.com)
- Citrix Commercializes OpenStack & Takes on VMware (gigaom.com)
- Impact of OpenStack Project Goes Beyond the Cloud Industry Leaders (readwriteweb.com)
- Incomplete Thought: The Curious Case Of the Carnival Cloud (rationalsurvivability.com)