Picture Credit: Cartoonstock.com
Last week at CloudOpen 2012, a group of vendors in the platforms space announced a new set of specifications to help simplify management of applications in the public and private clouds. Called CAMP, these specifications are submitted to OASIS to develop it as an industry standard. The initial reaction from the industry and some cloud pundits is “Meh”. Even though I wouldn’t say the reaction is wrong, I thought I will wait for the noise from VMworld and CloudOpen (LinuxCon) to go down before I write about my thoughts (yeah, I agree it is a good justification for laziness).
The following are my thoughts on the announcement:
- I am still not convinced that there is a pain point for standardization at the infrastructure level itself and there is no way I am going to agree that it is time to standardize on the platform level. However, unlike in the infrastructure layer where pundits are clamoring for standardization around AWS API which has the maximum mindshare in the market, the standardization efforts on the platform layer is not around the platform that has maximum mindshare at this point (a.k.a CloudFoundry). I strongly feel that Platform as a Service segment is still at its infancy. Different players are attacking the market from different angles. We have CloudFoundry and OpenShift leading the effort on with a hosted + private model, Folks like Apprenda and ActiveState are taking a purely private model. Heroku, EngineYard, Tier 3, AppFog, etc. are taking a pure hosted model and we have CloudSoft and Cloudify taking a more DevOps route. I think we need to let these guys innovate a little further before we start talking about standardization. Any pre-mature standardization will stunt innovation. Coming from this angle, I will say that it is too early to standardize on PaaS.
- Another disturbing factor for me (no, I am not talking about Oracle’s deep interest in this effort) is that the starting point for their specs is the NIST definition of PaaS. Even though I respect NIST for bringing order into the numerous attempts to twist the definition for cloud in the past, I only consider them as a starting point and not the bible. I especially disagree with their definition of PaaS and SaaS. Last week we saw how rPath was misusing the term PaaS for marketing purposes. They are hiding behind the NIST definition to justify their use while rPath’s offering is nowhere closer to PaaS. Starting the specs with NIST definition will let PaaS-washers have their field day.
- As a follow up to the above point, I see PaaS as a platform for building and deploying distributed applications. Yes, some PaaS platforms may help run legacy apps but a platform built purely for running legacy apps is not PaaS. In my definition, PaaS should allow not only scaling out of infrastructure but also the applications itself. Any standardization effort with PaaS in their title or description should include this constraint.
- Having said that I want to point out that PaaS has a potential to lock-in. Yes, there are some offerings that helps users to avoid getting locked in at the infrastructure level but there is no offering or efforts to stop the lock-in at the platform level. Yes, we can still avoid getting your applications locked into some of the PaaS offerings out there but there is a cost involved in portability and this message comes out as an unreadable footprint in the PaaS marketing messages (including my own PaaS evangelism). With this in mind, we will soon reach the pain point for standardization. When such a pain point arises, if CAMP specs offers the necessary standards for the industry, it will be a good thing to have happened.
- Keep in mind that all the PaaS offerings we see today are bound to evolve as we enter into the so called big data world. Current PaaS offerings are more suitable for scaling the users than meeting the scale and depth of big data. Once this evolution happens, the platform services we see in that future may have very little resemblance to PaaS as we know it today. CAMP specs, if done right with this future in mind, might come handy then.
To conclude, I don’t think we have the pain point (yet) to have standardization around PaaS. However, if done right, CAMP can play a critical role in the future platform services industry (note that I am not saying PaaS industry). If CAMP has to be the standards in that future, there should be involvement from the current bunch of PaaS players. An Oracle driven effort will go nowhere and it has to include everyone from VMware to Microsoft to Salesforce to all the startups in the space. Let us see how this effort takes shape in the coming years.
Disclosure: ActiveState, VMware, Tier 3 (client), AppFog, CloudSoft, Apprenda, Redhat, Heroku, Cloudify were sponsors of DeployCon 2012
Thanks for this thoughtful writeup. While I agree with many of your observations, I wouldn’t arrive at the same conclusions. Not because I happen to be one of the authors, but because I believe there may be two misunderstandings that are worth pointing out. First, CAMP makes no assumptions as to what type of application a particular PaaS supports, be it “distributed” or “legacy”. It merely operates on “Assemblies” and their constituent “Components”. Second, the set of CAMP operations has been designed to be as basic as possible so as to expressly not impede innovation in the PaaS itself. As a result, it seeks to standardize only uncontroversial operations such as importing application artefacts, discovering assemblies, or monitoring components.
Best,
-Tobias
Thanks Tobias. My stance against standards as inhibitor of innovation is not against CAMP but against any pre-mature standardization efforts. Even on the IaaS side, I am against standardization on AWS APIs. I feel that cloud market is still immature and we should let innovation happen before we standardize.
As far as the constraint I had pointed out, I agree with your point. Rather, I want the constraint to be part of it to avoid any abuse of the term PaaS. Either way, it is a great effort and I will be closely watching the progress.