Daryl Plummer

Today the Open Cloud Manifesto is supposed to be published and it has a laudable set of goals, not least of which is the idea that the cloud should be an open and interoperable environment. I have limited information at this point. I applaud the effort to move in this direction but I have to note some concerns I have, because “This has all happened before. And this will all happen again” – with apologies to Battlestar Galactica.

Let me repeat, though, we NEED an open cloud – as long as it is not co-opted by vendors seeking to dominate a “next generation of infrastructure and platforms” or to protect their ability to generate business. That will lead to over-complicated solutions that allows a variety of competing features that will ultimately keep prices high and vendor lock-in alive.

The Cloud versus Cloud Services: My first glance concern is that the OCM almost reduces the entire cloud phenomenon to just “the next generation of infrastructure and platforms”. It falls short of painting a complete picture of what cloud computing is and what it could represent. Now if you have read any of my blog posts or my research you will not I am steadfastly against using the word cloud in its plural form when it comes to the public cloud. The reason is all over the pieces of the manifesto I could get access to before it was finalized.

• - The problem is that when people insist on thinking of “clouds” instead of “Cloud services”, they invariably reduce the entire phenomenon to just an argument about platforms and infrastructure. Then they start talking about why those platforms don’t work together and why we need standards. What we need is interoperable cloud services, not just portable and interoperable cloud infrastructure.
• - Note that I do believe we need standards, but standards just for the “Cloud Infrastructure” will not solve the biggest problems of the cloud model. We still have to work out issues like remediation, disaster recovery, new business models, data ownership rights, legal responsibilities between service providers, and brokering aggregations of cloud services.
• - Infrastructure standards will make it easier to port a service from one cloud platform to another, but – vendors being vendors – they will all add custom features that circumvent this portability in the interest of making their cloud platforms more attractive to their customers. They will support the basic standards while pushing their custom (non portable) features.
• - Lock-in is not prevented by standards.

This has all happened before: Remember WS-I? When web Services started, they were supposed to be simple ways to link different systems together using a small set of web compatible technologies. But, the vendors and enterprise IT got involved and decided it had to have standards and along came WS-I. It was supposed to make web Services Interoperable. How has that worked out for most of you? WS-* was born, and now we live in a world of such SOAP based Web Services complexity that the concept is suffering and being assaulted by more simple RESTful approaches. WS-I did not prevent the WS-* glut of standards – mostly aimed at making Web Services “Enterprise Ready”. And lack of Web Services interoperability is often cited as one of the worst problems with the concept. Let’s hope the same thing will not happen to cloud computing.

But my fears remain strong. When enterprise interests become central to any discussion about technology, complexity and vendor control begins to increase. Vendors take sides and user organizations follow suite. My colleague David Smith wrote a post on what the motivations of the players are in the cloud computing manifesto.

We need a manifesto that recognizes that cloud services span the gamut of requirements and that cloud service consumers will often NOT be application developers and architects. We need a manifesto that recognizes that standards at the infrastructure level need to be buttressed by a stronger support for a service oriented business approach. At the service level, data formats, contractual guarantees, and service provider partnerships will rule the day. We need a manifesto of openness that includes how we will retain our rights in an open cloud, how we will establish trust in chains of services from the bank through to the storage provider to a partner company. We need a manifesto that opens the dialog into what cloud services are all about, not just what problems cloud infrastructure presents us.

I believe in an open cloud and look forward to more detail on the manifesto. But I hope the final manifesto does not just equate Clouds with Cloud Infrastructure and turn it into another WS-* complexity nightmare. If so, a lot of the point of the phenomenon will have been missed.