Cloud and Standards: What's the point?

 1. Open Cloud = Open Source + Open Standards 
In 2010, we launched a project called OW2 Open Source Cloudware Initiative. The objective was to build an R&D agenda for open cloud in order to preserve the same openness we have in open source software. At this time I had a naïve and quite dogmatic vision: without open source and open standards,  no open cloud and no interoperability. I am proposing you to go with me through the journey which drove me where I am today.

 2. Open Standards 
I started discussions with cloud service providers, trying to explain to them why they should adopt open standards, why open standards are mandatory for interoperability, for the sake of users. It did not take me a long time to realise that I was talking non sense to them: none of them wants a standard, or at least they want to have their own. Amazon will never use Google standard, Google will not use Azure standard and none of them will use OpenStack standard. Hopefully Simon Wardley explained to me that Amazon EC2 is the de facto standard: it monopolises 90% of the market. So what is the point: why not use Amazon EC2. Plus he added “APIs cannot be copyrighted so you can freely implement it”.  Another guy added “Why would you need open source if you have open APIs?” And all of a sudden, things appeared clearly to me. Cloud providers do not want open standards because cloud computing is not about standards but about APIs. Cloud providers are not interested by interoperability because they have a deliberate vendor lock-in strategy. They control their market shares through their APIs. Tough times for Open Cloud = Open Standards + Open Source

 3. Open Source 
Nevertheless I tried to start another set of discussions with people that I thought would understand my point: the open source cloud management platform people. I was quite sure they would be interested by open standards. Once again I was wrong. These guys do not care about standardisation. They do not want to waste time on academic discussions of experts. On the other hand, we cannot honestly say that they have a deliberate vendor lock-in strategy. What they do have for sure is a world domination strategy: they want their platform - the one they are contributing to develop - and their API to become the de facto standard. And they want it now, not tomorrow. By the way, these days OpenStack is facing an interesting issue: what is a standard OpenStack? Who is operating a “real” OpenStack? What is a genuine OpenStack provider? These open issues drove me to another key question: “Do the open cloud operators have a different business model from the most established ones?” The answer is no. They are challenging the leadership of Amazon and they use the open source process and its disruptive effects as a competitive advantage. Then they out innovate their coopetitors with proprietary features. 2010 and early 2011 has been a quite interesting period. First I lost my naivety and second I had no dogma any more. In mid 2011,  I took the lead of CompatibleOne with a solid experience of what open cloud was not.

 4. Interoperability 
Interoperability is all what CompatibleOne is about. So how can we make workloads interoperate between different providers if those providers do not use open standards. Easy! Let's build some piece of open source software that these providers will install in their data centres and that will take care of all interoperability issues. Isn't that a good idea? The answer we got from one of our partners was without ambiguity: “we will never ever let you install anything like this in our data centres! End of story”

 5. SLA 
This became even worst when we started discussing SLAs with other providers. First answer: “SLAs  are not negotiable, take it or leave it. In case of problem, we will credit back to your account”. Second answer:”Interesting but we will never let you install anything to measure our performances in our data centres! Period.” The only ones who were really interested discussing with us about SLAs were the customers: they were so frustrated with the answers they got from the providers that we coined together the term SLI for Service Level Imposed.

 6. CompatibleOne 
In fact all these feedbacks have been really helpful to design the CompatibleOne Platform. Thanks to them we have established some rules which helped us to solve issues we had to deal with.
- Interoperability is not available: let's build it!
- Cloud providers do not accept intrusion: let's manage everything from the outside!
- Cloud providers are not equally transparent: let's favor the provisioning on the ones which are exposing valuable and measurable information!
- Users are dissatisfied by providers' SLAs: let's provide users with tools to negotiate properly!

These rules allowed to define the appropriate positioning of Compatible on the market:
- CompatibleOne is on the customers’ side of the food chain of cloud computing.
- CompatibleOne enables a clear separation of the roles and responsibilities of the cloud computing players (provider, consumer, broker).
- CompatibleOne is vendor neutral, cloud-agnostic, secured and auditable: all this makes CompatibleOne a trustworthy third party. This trustworthiness can be assessed by the examination of its design, its open model, its open source code, its audit trails and its governance.

7. CompatibleOne uses Open Standards 
To build interoperability, we needed to design a model which would help to make abstraction of any provisioning system, of any cloud service. Such a model would enable a detailed description of complex workloads in order to provision them in an automated fashion on heterogeneous providers. Plus we wanted CompatibleOne Platform to be interoperable with other services in a way to allow other players of the ecosystem to interoperate, to integrate and to create added value services. To achieve this goal we have selected an open standard OGF OCCI to be the core of our model, the CompatibleOne platform being an implementation of this model. These days we envisage other open standards implementation for the same pragmatic reasons and because there is no seamless interoperability without open standards.

 8. CompatibleOne is Open Source
The reason CompatibleOne is  distributed under an Apache licence is not dogmatic, nor ideological. First we want to guarantee that this tool which eliminates vendor lock-in, will always be freely available to anyone. Then as CompatibleOne plays the role of an intermediary between the providers and the consumers, the presence of the code is a way to guarantee that there is no biased negotiation between the two parties, nor any hidden back door which would make the intermediation questionable. Finally we want to foster the adoption of CompatibleOne by organisations aiming at operating a cloud service broker, a federation of clouds, a federated market place or a cloud exchange in a convenient fashion. Thanks to the flexibility of the CompatibleOne platform, these organisations will be able to customise the platform according to their needs and to their targeted business model.

 9. CompatibleOne is an Open Cloud
With CompatibleOne the intermediation is trustworthy. CompatibleOne offers a fully transparent and comprehensive platform from provisioning to audit trail, from SLA management to monitoring. This would not be possible without open source which helps to verify the compliant behaviour of the platform. This would not be possible without open standards such as OCCI and WS-Agreement. With WS-Agreement we have been able to reconcile the business criteria required by the consumers and the providers’ offerings: this open standard is instrumental for CompatibleOne to play the real role of the broker which is to protect the consumers’ interests while dealing properly with the providers.

Here on the behalf of all CompatibleOne partners, I would like to warmly thank OGF, its various working groups and their contributors for the openness and transparency of their process, for the quality of their specifications and for the relevance of their work. 

Transcription of the talk given on the 18th of September 2013 during the CloudPlugfest Workshop co-organised by OGF, ETSI, OW2 and OCEAN in Madrid.

About the author: Leader of the CompatibleOne project, Jean-Pierre Laisné is well known for his professional open source activism. Since 1992 with Pick Systems, Linbox and Bull, Jean-Pierre has been advocating and has demonstrated the richness of open source for business as a whole. President of ObjectWeb and OW2, co-founder of Aful, co-founder and president of Open World Forum, co-founder of OW2 Open Source Cloudware Initiative, Jean-Pierre has over 30 years of experience in IT business.

Cloud and standards: what’s the point? by JP LAISNE is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. 

This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 4.5.1 - Documentation - Legal Notice

Site maintained by