More than just hot air
Round the CAMPfire: talking PaaS standards with Oracle, Cloudsoft and CloudBees
reported on CAMP (Cloud Application
Management for Platforms), an API spec for cloud management
proposed by several industry members. Intrigued, we managed to grab
some time with three big names involved with the spec:
Jeff Mischkinsky, Oracle’s Senior Director of
Fusion Middleware and Web Services Standards; Duncan
Johnston-Watt, CEO of Cloudsoft Corporation; and
Steven Harris, Senior Vice President of
“This is an effort that started a year and a half ago, and we believe this is the first attempt to standardise application management, basically the cloud platforms,” Mischkinsky tells JAXenter in a roundtable discussion. “It's to provide a common basis for managing your applications. We've defined what we believe to be the basic operations, that there shouldn't be a whole lot of disagreement on, for deploying and managing your applications like start, stop, sleep, and deploy, and things like that.”
All three emphasise that the spec covers just enough “basic operations” to be practical without limiting innovation within the fledgling industry. “I think the main challenge here was that we kept it simple, so that we design what I like to call a 'framework for innovation',” says Mischkinsky.
“A number of us have been in this movie before,” adds Johnston-Watt. “[We’ve] been involved in standards, and sometimes they can be perceived as somehow inhibiting innovation. The phrase I love, that Steve [Harris] uses, is about ‘not wanting to put the standards cart before the innovation horse’.
“But I think in this case we are trying to keep it very much to the core, common server operations that it's really very hard to argue against. I think the most interesting response that we had was from another group called the Open Data Center Alliance [...] we got a very quick thumbs-up from them.”
One of the most significant repercussions of a universal API is that customers will be able to switch providers with greater ease. If this is the case, then doesn’t that put companies implementing CAMP at a competitive disadvantage when compared to other PaaS vendors?
Johnston-Watt disagrees: “I think, from my standpoint, it actually means we're more, rather than less, likely to work with PaaS providers if they conform. So if you look at it the other way, it will drive customers towards those that are supporting it. Rather than being in some shape or form a competitive disadvantage, I think it is actually a competitive advantage.”
Instead of each PaaS vendor providing a “slightly different” API for cloud management, says Mischkinsky, it makes far more sense to standardise. “[The lack of a universal standard] causes more friction, and it limits the growth of the market. So one of the reasons Oracle as a company is usually behind standardisation, is that we view it as a way to grow markets, and growing markets is usually better for all the players in the markets. And then of course, people just compete on the implementation and so forth.”
It remains to be seen if the big fish of the PaaS pond - AWS, Google, Windows Azure, et al - share the same philosophy. Still, if the spec gains OASIS’ approval, it’ll be more than just the whim of a few PaaS players.
“If you look at the charter, one of the things you'll notice is that we've left lots of room for, as additional companies come on board to participate and finalise the spec, that we'll be able to make modifications to it,” says Mischkinsky.
“It’s also important to empathise that this is not some cabal,” says Harris. “This is not seven guys who got together - this is actually putting forward a proposal. And we're all aggressively seeking participation from other folks within the industry that we know.
“We can't say who at this stage,” he adds cryptically, “because it's all sort of being figured out, but there is definitely a lot of interest beyond the original announcement.
“Think of this as the start, not the end.”
For a longer version of this interview, check out next month’s edition of Java Tech Journal.