Variety & Darwinism In Solutions Is Innovation, In Standards It’s A War?
I find it quite interesting that in the last few months or so, as Cloud has emerged as a full-fledged business opportunity, we’ve seen the rise of many new companies, strategies and technologies. For the most part, hype aside, people praise this as innovation and describe it as a natural evolutionary process.
Strangely enough, with the emergence of new opportunity comes the ever-present push to standards. Many see standards introduced too early as an innovation squasher; it inhibits free market evolution, crams down the smaller players, and lets the big fish take over — especially when the standards are backed by said big fish. The open versus proprietary debate is downright religious.
Cloud Computing is no different.
We’ve seen many “standards” float to the surface recently — some backed by vendors, others by groups of concerned citizenry. Many Cloud providers have published their API’s in an attempt to standardize interfacing to their offerings. Some are open, some are proprietary. Some are even open-sourced. Some are simply de facto based upon the deployment of a set of technology, solutions and an ecosystem built around supporting it. Professional standards organizations are also now getting involved.
In J. Nicholas Hoover’s blog post titled “Groups Seek Cloud Computing Standards,” Gartner’s David Cearly said :
“Community participation, deliberate action, and planning must be a vital part of any successful standards process…Otherwise, he said, cloud standards efforts could fail miserably.”
“Standards is one of those things that could absolutely strangle and kill everything we want to do in cloud computing if we do it wrong,” he said. “We need to make sure that as were approaching standards, we’re approaching standards more as they were approached in the broader internet, just in time.”
I suppose that depends upon how you measure success…
Tom Nolle wrote an interesting piece titled: “Multiple Standards Cloud Spoil Cloud Computing” in which he lists 7 standards bodies “competing” for Cloud, wondering out loud why if they all have similar interests, do they exist separately. After he talks about the difference between those focused on Public and Private Clouds, he bemoans the bifurcation and then plugs the one he finds best 😉
So now we have live public cloud services with incomplete standards and evolving private cloud standards with no implementations.
The best hope for a unification is the Cloud Computing Interoperability Forum. Its Unified Cloud Architecture tackles standards by making public cloud computing interoperable. Their map of cloud computing shows the leading public cloud providers and a proposed Unified Cloud Interface that the body defines, with a joking reference to Tolkien’s Lord of the Rings, as “One API to Rule them All.”
So make that 8 players…
This week we’ve seen the release of the VMware-sponsored and DMTF-submitted vCloud. We also saw RedHat introduce their Deltacloud API. We have the Open Cloud Computing Interface (OCCI) standards work which getting underway within the Open Grid Forum (OGF.) There’s a veritable plethora of groups, standards and efforts at play.
Some of it is likely duplicative.
Some of it is likely vendor-fed.
The reality is that unlike others, I find it refreshing.
I think it’s great that we have multiple efforts.
It would, for sure, be nice if we could all agree and have one focused set of work, but that’s simply not reality. It will be confusing for all concerned in the short term.
The Open vs. mostly-open debates will continue, but this NORMAL. In the end, we end up with a survival of the marketed-fittest. The standards that win are the standards that are most optimally muscled, marketed and adopted.
Simon Wardley wrote a piece called “The Cloud Computing War” which to me read like an indictment of the process (I admit my review may be colored by what I perceive as FUD regarding VMware’s vCloud,) but I can’t help but to shrug it off and instead decide to focus on where and whom I will decide to pitch my tent.
I’ve already done so with the Cloud Security Alliance (not a standards body) and I’m looking at using vCloud to find a home for my A6 concept.
A Cloud standards war? War is such an ugly term. It’s just the normal activity associated with disruptive innovation and the markets sorting themselves out. The standards arena is simply where the dirty laundry gets exposed. Get used to it, there’s enough mud/FUD flinging that you can expect several loads 😉
/Hoff
Chris:
So, I think the near-term result of this is the perception that "cloud stuff" is not full baked yet, causing customers to sit on the sidelines because no one wants to take the risk of choosing the wrong "side"–think HD-DVD vs Blu-Ray.
That being said, when all is said and done, I think customers choose "what works" over what is "standards complaint" if they have to make a choice. Most of your readers probably have mobile phones and I am guessing that most of them chose their carrier based on things like pricing, features, and coverage, not on if they adhered to GSM or CDMA.
I think the same dynamic can play out with cloud services, especially since part of the value prop for all these *aaS offerings is "don't worry what is happening behind the curtain." If a vendor can create enough market velocity, through a well-priced, well-featured, well-undestood offering, they will be in a position to really shape the market. AWS is a great example–how many companies are out there that are building on top of AWS? We saw announcements last week from Terramark and Savvis and we know other significant providers are on deck. All these folks are collectively shaping customer thinking because they putting hard edges on what has seemed an otherwise nebulous topic.
There, that should stir the pot a bit. 🙂
Regards,
Omar
Cisco Systems
Beaker, anyone who has been following my posts on utility computing (sic. cloud computing) over the last four years, will know my position is that de facto standards will dominate (not committee led) and open source is an essential part of that. This is not some insight but instead just a re-application of the same old lessons from the network wars (tcp/ip vs ipx/spx vs sna vs …).
RE: vCloud. To my knowledge, there is no open source cloud system which implements the vCloud API (unlike the EC2 API which is implemented by eucalyptus, open nebula …). Since you claim that I'm absolutely incorrect on this, I'd very grateful if you would provide me with a link to an open source cloud system which currently provides the vCloud API.
@Simon Wardley
Posted a reply to your Tweet/this on your blog, and X-Posting here:
You said: "@ChristoFer Hoff: As for reading the specification, yes I have but I now wait with baited breath for you to provide a link to an open source cloud system that currently provides the vCloud API. Whilst Eucalyptus, Open Nebula an Globus Nimbus are all open sourced cloud systems, they implement the EC2 API.
I'm absolutely busting to see the open source cloud system which you claim implement the vCloud API."
…perhaps I misinterpreted your comments here, but it seems to me like you are implying that the API somehow constrains a vendor who might choose to utilize the API to only utilize VMware.
It's certainly true that those who are developing against the API THAT WE KNOW OF are using VMware to do so, but are not limited as such. That's what I was pointing to.
I'd argue given the level of abstraction provided for in the API, it does the opposite and is not tied to a specific implementation, unlike the AWS API which allows one to manage only…?
I see you did use the word "currently," but I was reading between the lines. Perhaps this was impertinent.
/Hoff
Usually the dominant player in a market stands to lose if standards reduce switching costs. It makes sense for them to hamper standards using balkanization as a tactic. Think OOXML, for instance.
In the case of public clouds, Amazon is clearly the leader but they haven't engaged in any such dirty tactics. That said, once bitten twice shy and whenever there are too many standards competing, users tend to suspect something nefarious is going on.
@beaker: From my post "The only way of currently implementing vCloud is with VMWare technology", this does not imply that the vCloud API is constrained to VMWare Technology only that the current methods of implementation use VMWare technology. This is the source of misunderstanding.
As the old phrase goes, I think we violently agreeing with each other.
I too think multiple efforts are good thing, as long as they talk to each other about directions and overlaps. We're in an innovation cycle for cloud computing, and few standards too early can slow innovation. Cloud communications (telecom/Internet) is in a maturing cycle. There's much to learn and possibly transfer across from this maturity as well.
You'll see TM Forum enter the cloud services collaboration space soon. Current plans for its members' work will complement (not duplicate) many IaaS-specific, group-driven specifications that focus on computing resources and the resource-facing services layer, such as the case with DMTF's OVF and cloud incubator. Stay tuned for an annoucement in the next 30 days.
Standards between software products and commercial services (e.g., features, service levels, APIs) have some similar qualities, but also some very different qualities too. The qualities of open source software don't fully translate into commercial services, including how these services are developed, offered, and operationally delivered to and managed with Customers by Service Providers. If they did, open source software companies like Red Hat would have no revenue to fund their important role in facilitating open source into commercial application.
Also, larger enterprise cloud buyers must integrate cloud services into their existing IT development, sourcing, and service management operations (many running legacy apps). Most customers with meaningful money to spend won't be making cloud services procurements in a greenfield or low integration context. How public and hybrid cloud services and their management features are exposed by Service Providers to Enteprise IT Customers for integration with their legacy operations and service management systems will be in important factor that may determine what software and specs have the advantage of seeing adoption as standards in this vital customer segment. For that reason, I have questions about the longevity of new fast-moving "standards" specification groups that are forming service-oriented specs without strong alignment both with Enterprise customer requirements and involvment, and with mature, top-down frameworks adopted by large enterprise IT or service providers.