Standards Disconnect at Cloud Connect

Yesterday’s panel session on the future of Cloud standards at Cloud Connect is still resonating on Twitter tonight. Many were shocked by how acrimonious the debate turned. It didn’t have to be that way but I am not surprised that it was.

The debate was set up and moderated by Bob Marcus (ET-Strategies CTO and master standards coordinator). On stage were Krishna Sankar (Cisco and DMTF Cloud incubator), Archie Reed (HP and CSA), Winston Bumpus (VMWare and DMTF), a gentleman whose name I unfortunately forgot (and who isn’t listed on the program) and me.

If the goal was to glamorize Cloud standards, it was a complete failure. If the goal was to come out with some solutions and agreements, it was also a failure. But if the goal, as I believe, was to surface the current issues, complexities, emotions and misunderstandings surrounding Cloud standards, then I’d say it was a success.

I am not going to attempt to summarize the whole discussion. Charles Babcock, who was in the audience, does a good enough job in this InformationWeek article and, unlike me, he doesn’t have a horse in the race [side note: I am not sure why my country of origin is relevant to his article, but my guess is that this is the main thing he remembered from my presentation during the Cloud Connect keynote earlier that morning, thanks to the “guillotine” slide].

Instead of reporting on what happened during the standards discussion, I’ll just make one comment and provide one take-away.

The comment: the dangers of marketing standards

Early in the session, audience member Reuven Cohen complained that standards organizations don’t do enough to market their specifications. Winston was more than happy to address this and talk about all the marketing work that DMTF does, including trade shows and PR. He added that this is one of the reasons why DMTF needs to charge membership fees, to pay for this marketing. I agree with Winston at one level. Indeed, the DMTF does what he describes and puts a fair amount of efforts into marketing itself and its work. But I disagree with Reuven and Winston that this is a good thing.

First it doesn’t really help. I don’t think that distributing pens and tee-shirts to IT admins and CIO-wannabes results in higher adoption of your standard. Because the end users don’t really care what standard is used. They just want a standard. Whether it comes from DMTF, SNIA, OGF, or OASIS is the least of their concerns. Those that you have to convince to adopt your standard are the vendors and the service providers. The Amazon, Rackspace and GoGrid of the world. The Microsoft, Oracle, VMWare and smaller ones like… Enomaly (Reuven’s company). The highly-specialized consultants who work with them, like Randy. And also, very importantly, the open source developers who provide all the Cloud libraries and frameworks that are the lifeblood of many deployments. I have enough faith left in human nature to assume that all these guys make their strategic standards decisions on a bit more context than exhibit hall loot and press releases. Well, at least we do where I work.

But this traditional approach to marketing is worse than not helping. It’s actually actively harmful, for two reasons. The first is that the cost of these activities, as Winston acknowledges, creates a barrier for participation by requiring higher dues. To Winston it’s an unfortunate side effect, to me it’s a killer. Not necessarily because dropping the membership fee by 50% would bring that many more participants. But because the organizations become so dependent on dues that they are paranoid about making anything public for fear of lowering the incentive for members to keep paying. Which is the worst thing you can do if you want the experts and open source developers, who are the best chance Cloud standards have to not repeat the mistakes of the past, to engage with the standard. Not necessarily as members of the group, also from the outside. Assuming the work happens in public, which is the key issue.

The other reason why it’s harmful to have a standards organization involved in such traditional marketing is that it has a tendency to become a conduit for promoting the agenda of the board members. Promoting a given standard or organization sounds good, until you realize that it’s rarely so pure and unbiased. The trade shows in which the organization participates are often vendor-specific (e.g. Microsoft Management Summit, VMWorld…). The announcements are timed to coincide with relevant corporate announcements. The press releases contain quotes from board members who promote themselves at the same time as the organization. Officers speaking to the press on behalf of the standards organization are often also identified by their position in their company. Etc. The more a standards organization is involved in marketing, the more its low-level members are effectively subsiding the marketing efforts of the board members. Standards have enough inherent conflicts of interest to not add more opportunities.

Just to be clear, that issue of standards marketing is not what consumed most of the time during the session. But it came up and I since I didn’t get a chance to express my view on this while on the panel, I used this blog instead.

My take-away from the panel, on the other hand, is focused on the heart of the discussion that took place.

The take away: confirmation that we are going too fast, too early

Based on this discussion and other experiences, my current feeling on Cloud standards is that it is too early. If you think the practical experience we have today in Cloud Computing corresponds to what the practice of Cloud Computing will be in 10 years, then please go ahead and standardize. But let me tell you that you’re a fool.

The portion of Cloud Computing in which we have some significant experience (get a VM, attach a volume, assign an IP) will still be relevant in 10 years, but it will be a small fraction of Cloud Computing. I can tell you that much even if I can’t tell you what the whole will be. I have my ideas about what the whole will look like but it’s just a guess. Anybody who pretends to know is fooling you, themselves, or both.

I understand the pain of customers today who just want to have a bit more flexibility and portability within the limited scope of the VM/Volume/IP offering. If we really want to do a standard today, fine. Let’s do a very small and pragmatic standard that addresses this. Just a subset of the EC2 API. Don’t attempt to standardize the virtual disk format. Don’t worry about application-level features inside the VM. Don’t sweat the REST or SOA purity aspects of the interface too much either. Don’t stress about scalability of the management API and batching of actions. Just make it simple and provide a reference implementation. A few HTTP messages to provision, attach, update and delete VMs, volumes and IPs. That would be fine. Anything else (and more is indeed needed) would be vendor extensions for now.

Unfortunately, neither of these (waiting, or a limited first standard) is going to happen.

Saying “it’s too early” in the standards world is the same as saying nothing. It puts you out of the game and has no other effect. Amazon, the clear leader in the space, has taken just this position. How has this been understood? Simply as “well I guess we’ll do it without them”. It’s sad, but all it takes is one significant (but not necessarily leader) company trying to capitalize on some market influence to force the standards train to leave the station. And it’s a hard decision for others to not engage the pursuit at that point. In the same way that it only takes one bellicose country among pacifists to start a war.

Prepare yourself for some collateral damages.

While I would prefer for this not to proceed now (not speaking for my employer on this blog, remember), it doesn’t mean that one should necessarily stay on the sidelines rather than make lemonade out of lemons. But having opened the Cloud Connect panel session with somewhat of a mea-culpa (at least for my portion of responsibility) with regards to the failures of the previous IT management standardization wave, it doesn’t make me too happy to see the seeds of another collective mea-culpa, when we’ve made a mess of Cloud standards too. It’s not a given yet. Just a very high risk. As was made clear yesterday.

9 Comments

Filed under Amazon, Cloud Computing, Conference, DMTF, Everything, Mgmt integration, People, Portability, Standards, Trade show, Utility computing

9 Responses to Standards Disconnect at Cloud Connect

  1. Bob Marcus

    William:

    Thanks for your write-up on the Panel.

    Your perceptive statement that “if the goal, as I believe, was to surface the current issues, complexities, emotions and misunderstandings surrounding Cloud standards, then I’d say it was a success.” is exactly right. The only way to avoid many of the past mistakes in standardization is to engage many people (customers, providers, developers, formal/informal standards groups)in open discussions. Hopefully the Cloud Connect Standards Track will be the first of many follow-on events in the next few years.

  2. Excellent points William!

    It’s always been my position that professional standards bodies (where there is a “pay wall” that you have to cross to have any meaningful input and that wall generates a pool of money that pays salaries and consultants fees) are an inherently bad thing. Pretty much anytime you allow a standards effort to be effectively controlled by people who have a paid interest (whether it’s a salary or consulting fee of some sort or pushing their own company’s agenda) you are starting from a fundamentally corrupt process and can only do damage control from there. It’s just the simple forces of human nature at work.

    The only case where these professional organizations may play a useful roll is when the market has already sorted out a de facto standard. But formalizing, publishing, providing certification courses, etc. is a very very different type of activity then actually creating the standard!

    In this age of massively networked communication at almost zero cost, why not let the users in the trenches sort these issues out?

    Just my $0.02

    -Damon
    http://dev2ops.org

  3. Stu

    The biggest problem with the standards efforts (and I think Bob might agree) is a dearth of customer involvement and feedback. It’s not just a standards problem, it’s a problem with any cloud product vendor attempting to deal with enterprise customers, which is why most of them target developers or service providers. There is a tendency, particularly among enterprises, to “let the vendors sort it out”, and only adopt the technology once it is standardized, rather than going through the pain to think through what the issues are, what worked & didn’t work, etc.

    Mostly (with notable exceptions), there is tire kicking and limited adoption of even the prior generation of data center automation tooling. One quote I loved was “We bought Opsware 6 years ago, and made no progress since then, since the Opsware rollout was coming just around the corner…. for 6 years”.

  4. Stu, I agree but I also think it’s irrelevant. I just don’t think the incentives are there for customer involvement at the level needed. Which I why, as much as I’d love to see it happen, I don’t waste my time trying to make it happen. And I focus on the next best thing, which is to get independent experts and individual consultants involved, as a proxy for customers. I just think it has more of a chance of happening, and even then the current standards org are structured to make it next-to-impossible.

    I applaud Bob for trying and I would be delighted to see him succeed. I just don’t think it will work.

    At best, we’ll have a very specific and large customer, with a pretty specific approach and set of needs (e.g. the US gov). Better than nothing, but hardly a substitute for the involvement of a representative set of customers.

  5. Pingback: For Open Cloud Computing, Look Inside Your Data Center

  6. Pingback: For Open Cloud Computing, Look Inside Your Data Center - A Collection of Latest Happening in Technology Field

  7. Pingback: William Vambenepe — Introducing the Oracle Cloud API

  8. Pingback: William Vambenepe — The Tragedy of the Commons in Cloud standards

  9. Pingback: Tyranny of Choice in the Cloud | OpenLogic Blogs