The Open Cloud Manifesto is live at http://www.opencloudmanifesto.org. I wrote my opinion of it prior to its release based on some concerns that were already voiced in the community. Now, I get to comment on the real thing.

On the one hand, the manifest is described as trying to bring about a core set of principles around cloud computing for vendors to agree to and users to count on. The problem is that the set of principles was decided by a group that doesn't include three of the biggest players in the cloud today: Google, Amazon and Microsoft. I am babbled at how a group can get together and form a manifesto like this without first including these major players in its definition. This has already started off badly and doesn't say much for the credence people will place in the manifesto going forward.

I think the biggest problem with the manifesto is its discussion of interoperability and portability.

It isn't clear to me what are the interoperability goals for this manifesto. If interoperability means that a cloud vendor can't provide a service to its customers that is not based on standards such as HTTP, WS* and REST...I say why not? Hey, if I want to use a set of functionality exposed a protocol other than HTTP isn't that up to me, the customer? What if that particular set of functionality happens to be useful to my application? What if I don't require interoperable standards for all communications between moving parts of my application? Let me decide what is best, thank you. If my goal is to be able to move my application to another platform (next topic = portability) then I won't consider this option...but I may not care!

The manifesto doesn’t directly target a specific vendor – but it does indicate some unreasonable goals, specifically related to application portability and vendor lock-in. Vendor lock-in is a frequently discussed anti-pattern that describes the problem where customers cannot easily move their applications from one platform to another without significant cost and effort. Avoiding vendor lock-in is at odds with the benefits a specific vendor can provide with its own brand of unique features and productivity tools. The pros and cons of vendor lock-in have been debated for a decade now. Attempts to remove vendor lock-in with J2EE failed in my opinion. One of the goals of the J2EE platform was to enable customers to port from one vendor to another without pain – but I can tell you from first-hand experience this is not easy to accomplish. Each vendor supplies additional features and tools that make you more productive and effective if you use them. In fact, part of the decision to purchase a J2EE platform is these extended features. You have to explicitly avoid using extended features if you want to be truly portable. But why lose productivity to build a product just so you can move it to another platform? This is a good question…if this is a priority to your business, you will pay up front in development effort and associated cost to enable portability. If time to market, productivity and cost saving is a priority and you trust the vendor, you’ll happily forego portability.

My point is that ultimately the decision to make an application completely portable or to rely on a rich set of vendor-specific features and tools is up to the customer. The Open Cloud Manifesto principles are essentially discouraging (if not disallowing) vendors from producing any features or platform tools that are not offered by another cloud vendor. This is very simply NOT ok. If we expect cloud vendors to produce completely homogenous hosting environments with identical programming APIs then we stifle the creativity of each vendor. Each vendor should be free to supply a unique set of features and platform tools to form its own value proposition. Perhaps one cloud vendor will provide better productivity than another because of such features and tools – and this benefits the customer.

The Open Cloud Manifesto should focus on much more important matters such as the details vendors should produce in a Service Level Agreement (SLA) for their customers. This includes describing how the equipment, data, applications and all other assets are secured; describing their topology for load balancing and fail over; describing how they handle backup and recovery of applications and data; describing how they meter, monitor and report on this data; and describing how deployments and updates managed. Some of these things can be standardized, others are just guidelines for what a good cloud vendor should do to be trustworthy.

Ok, that's just my opinion...let's see where it goes. In the meantime, Google, Amazon and Microsoft - keep doing what you are doing...we like the diversity of options and we are grown-ups so we can decide which platform works best for our needs.