Last week, CloudBees made public along with Red Hat, Rackspace, Oracle and others a specification we had been working on for some time with the goal of submitting it to a standards-setting organization. The specification is called CAMP, and it is a first attempt at improving interop across PaaS vendors, but limited in scope to the basic lifecycle operations everyone has to support.
Should you care about CAMP? Opinions among the cloud pundits and various vendors vary from “No” to “Maybe” to “We will have to see.” Even though CloudBees was at the table from the beginning in putting together the spec, I can find a lot to agree with in these cautious and even skeptical assessments. That’s because a standard only matters if it’s broadly adopted and delivers real interop value to end users. Announcing a spec that will be submitted for standardization, a process that will take a year at minimum, is about as newsworthy in itself as announcing that you and your spouse expect to have a child one day.
xkcd on standards - http://xkcd.com/927/
What is newsworthy about CAMP is that a set of competitors, including traditional middleware vendors and infrastructure cloud providers, felt that getting started on PaaS standards was important. As Chris Tacy says, it’s a great leading indicator that PaaS is winning. Infrastructure providers are increasingly seeing PaaS as a way to add value upstack. But, companies aren’t going to want to be locked into a world that consists of the competitive CloudFoundry children depending on free rent from Papa VMware, while worrying about how they’re going to pay the vSphere tax next month when VMware finally clarifies its plans for CloudFoundry monetization.
It’s always fun to do some tea leaf reading about a new standards effort by looking at who isn’t at the table. We don’t even know yet who will join the still to-be-formed OASIS Technical Committee. The CAMP spec itself took a fairly typical path. We gathered some vendors together who were similarly motivated to find common ground and work constructively to hammer out a document that captures a means to interoperate. You need enough variety in design points at the table to discover areas of conflict and areas of consensus. It should be clear that between CloudBees’ production PaaS, Red Hat’s Beta OpenShift offering, and Oracle’s - well, frankly I have no idea how to characterize its readiness, so let’s just call it an “upcoming PaaS offering” — and others, CAMP reflects a pretty diverse set of interests and approaches to PaaS implementation and deployment. So does it make CAMP irrelevant if none of the CloudFoundry crowd participated in the initial spec? I feel certain that nothing in the spec is at odds with the lifecycle mechanisms of CloudFoundry, so technically, it makes no difference. And if there are issues, that’s what the OASIS committee is there to deal with. Will CAMP be irrelevant if VMware don’t participate in the OASIS TC? Will CloudFoundry support the standard that emerges, or will they gamble that their market presence gives them enough strength to ignore it? What about IBM and Heroku and Google and Microsoft? That all remains to be seen. So, as Krishnan says, stay tuned.
Working on standards is important, but hard and often unrewarding work. It can also be a political nightmare of competing corporate interests, strong-arming and game playing. And as someone with hard-won experience in a lot of standards work over the last dozen years, I can state definitively that you get the standards cart in front of the innovation horse at your own peril. Look in your RESTful rear-view mirror at WS-* fading into the distance for your lesson. With its limited scope, CAMP tries hard not make the same mistake, while opening the door for further work as vendors drive products and services forward. At CloudBees, our focus is on driving PaaS to deliver even more value more quickly to developers and enterprises. We won’t be doing that in a standards committee meeting, but we believe that open standards and cross-vendor cooperation have an important role to play in achieving interoperability and broader adoption, particularly in the enterprise space. You should, too.