Jean-Pierre Laisné describes his journey to the cloud.

1. Cloud and Standards: What's the point?
Jean­Pierre Laisné
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 but1
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 OpenStack 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
1
to be moderated with the notable exception of http
Version 2.2 1/3 07/27/13

2. 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 facetious 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,
Version 2.2 2/3 07/27/13

3. 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.
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.
More information about CompatibleOne on http:/compatibleone.org/
Cloud and standards: what’s the point? by JP LAISNE is licensed under a Creative Commons Attribution­ShareAlike 3.0 Unported
License.
Version 2.2 3/3 07/27/13