The battle that wasn't ...

Chris Boos wrote an interesting post about a debate that @samj and I were having on twitter regarding APIs in the cloud space. I thought I'd leave my comment here as a general view on the subject.

A couple of things to point out. Twitter is not the best tool in the world to determine the exact context of a discussion because those listening aren't generally privy to the history of the discussion. Hence in this case, it may not be clear that Sam Johnston and I are in absolute agreement on the importance of open source and efforts like OpenStack in this world.

Any difference between us is on the necessity of reverse engineering APIs and co-opting as the main short term tactical play. The long term we're both totally in agreement on - open standards, open formats and open source are critical.

Our difference in views on short term tactical plays hardly constitutes a battle but is merely debate. As for being a "giant", whilst that is very flattering it doesn't coincide with my view of the world. Nevertheless, it was an excellent post by Chris and much appreciated.

Comment --

Just to clarify my view - as it currently stands any company can reverse engineer an API for reasons of interoperability. Hence when trying to make a market of providers in the IaaS space with semantic interoperability between providers, I strongly support adoption where there is clearly a dominant API.

It should be noted that such a market can have multiple open source and proprietary implementations around the API. However, running code through an open source effort is necessary to form a market place without a single (or consortium of) vendor(s) being able to force a tax on that market. In other words, providers need to have an operational means of implementing the service and compete in the market without a necessity to purchase software licenses (a tax on competition). They may choose to buy software to do so but a free market is one unencumbered by such forced taxation.

This is why I do no support MSFT Azure's effort, despite the provision of open standards because there exist no open source implementation.

This is why I did not support Google's AppEngine, despite the provision of an SDK as there existed no fully operational open source means of implementing the service.

This is why I strongly support open source efforts which reverse engineer the dominant API for reasons of interoperability e.g. open stack, eucalyptus etc.

It is also why I strongly support open source efforts which attempt to create the dominant standard in a fledgling market, such as CloudFoundry in the PaaS arena.

Once the marketplace of alternative providers is large enough and it has the dominant ecosystem then the open source effort in effect becomes the defacto standard for implementation and the API in that market. If necessary, due to abuse of position by the original provider, then the API can be differentiated away from the original provider including providing an entirely new API where applicable.

I don't find attempts to differentiate on API in a utility world where one API is clearly dominant meaningful. Of course if an open source effort (such as openstack) creates a large enough ecosystem then it is in effect the dominant and can do as it pleases.

I find re-inventing the wheel by creating an API by committee and attempting to get the market to adopt as a wasted effort when a market has in principle chosen.

I do find the way to standardise is through creating the largest ecosystem and in such cases both reverse engineering the dominant API for reasons of interoperability combined with provision of open source running code is necessary.

Co-opt rather than compete is the order of the day in this world.

A question of standards.

I'm all in favour of standards for the "cloud" world because such standards should enable and accelerate innovation in IT through componentisation effects as well as encourage the formation of competitive markets of compute utilities

However, that said, I'm against standards committees and the concept that open standards (as in APIs & data formats) are enough to create the portability required for competitive markets.

In the former case, the market will decide the standard and the job of any standards body should be to rubber stamp what is an existing practice. Unfortunately, standards committees are often used as vehicles to promote specific vendor interests and in many cases their efforts are counter productive. For example, whilst IPX/SPX was the committee approved standard, it was TCP/IP which won the marketplace battle. The only impact that approving IPX/SPX as a standard had was to temporarily slow adoption of TCP/IP in some quarters and hence inhibit innovation.

Standards should have a positive effect but defacto has to precede dejeure. There are some exceptions to this but they are exceptions.

In the case of open standards, a competitive marketplace requires multiple providers, access to code and data (ideally with syntactic interoperability) and semantic interoperability of services. Whilst open standards provide part of the solution, it is critical for reasons of semantic interoperability that a common reference model (i.e. running code) is provided.

Since, we're talking about a world of service (and not feature) differentiation for activities which are fundamentally commodity by nature and hence suitable for utility service provision, then the obvious solution is an open source reference model as the standard. Potential examples of such would be the OpenStack effort.

Such open source reference models would ideally exploit the dual nature of GPLv3 which is both restrictive in the product world but simultaneously permissive in the service world to create a functioning marketplace. Unfortunately, many vendors promote open standards (as in APIs etc) as the solution to these problems of portability and hence describe their systems as open when they're quite clearly not.

So, in general :-

• Are standards good for the cloud?
  Absolutely, it'll encourage innovation through componentisation effects.


• Are standard committees good for the cloud?
  Generally no. At best they should rubber stamp market chosen approaches however in reality they're more likely to get in the way or slow progress by promoting vested interests.


• Is portability between providers important for the Cloud?
  Absolutely, it's the route to formation of competitive marketplaces and reducing outsourcing risks.


• Will open standards provide the portability needed?
  Only in the most trivial cases but not for the vast majority of activities. Open standards are necessary but they are not sufficient to provide the portability required. The idea that open standards alone will achieve this will inhibit the formation of competitive markets.


• Is open source essential for the cloud?
  Absolutely, the formation of competitive markets without loss of strategic control to a specific vendor depends upon the provision of open source reference models as the standard.

Platforms and all that jazz ...

Back in early 2006/7 the transition of I.T. activities from a product to service world was often described using three distinct layers - software, framework and hardware. These layers had specific acronyms :-

• SaaS (Software as a Service)
• FaaS (Framework as a Service)
• HaaS (Hardware as a Service).

The terms separated the boundary between what a user was concerned with and what the provider was concerned with.

In the case of HaaS, the provider was concerned with hardware provision (as virtual machines) and the user was concerned with what was built on that hardware (the operating system, any installed framework components such as databases, messaging systems and all code & data).

In the case of FaaS, the provider was concerned with the framework provided (and all the underlying subsystems such as the operating system, the hardware etc) whilst the user was concerned with what they developed in that framework.

I summarised these concepts and the overall stack in a much later blog post during 2007, "The SEP Boundary and more rough thoughts"

Of course, the plethora of 'aaS' terms was foolish especially since the industry had quickly embarked on what can only be described as the 'aaS' wars, a constant renaming of everything. Robert Lefkowitz ( in Jul'07) warned that this was going to lead to a whole lot of aaS. He was right.

Today, those three central layers of the stack have settled on software (though this often yo-yo's to application and back again), platform and infrastructure. However, this seems to have created its own problem.

Platform is being used at all layers of the stack, so we hear of cloud platforms for building IaaS and many other mangled uses of the concepts. The term infrastructure itself has many different meanings. Several SaaS offerings (despite many calling this layer applications, no-one wants to use the acronym AaaS) are described as core infrastructure and of course everything is built with software.

That which is, and still remains very simple, has become fraught with confusion. Life seemed so much simpler back in 2007.

This why, I argued that the CCIF needed to focus on a common taxonomy because we desperately need to talk about the same thing. Now, don't get me wrong, I'm more than aware of the pitfalls of a mechanistic definition of cloud and its inability to impart a wider understanding of the change that is occurring but confusion is a much greater foe.

So, I strongly urge you to adopt the NIST definition for everyday practical use.

The cloud computing standards war

Over the last couple of years, I've consistently talked about the necessity for standards in the cloud computing space and the oncoming war that this will create. This was not some insightful prediction but simply the re-application of old lessons learned from the many industries which have undergone a transformation to a service world.

That standards war is now in full swing.

The principle arguments behind standards comes from componentisation theory (the acceleration of innovation through the use of standardised subsystems) and the need for marketplaces with portability between providers (solving the lack of second sourcing options and competitive pricing pressures). The two main combatants at the infrastructure layer of the stack are shaping up to be Amazon with the EC2 API and VMware with vCloud API.

Much of the debate seems to be focused about how "open" the standards are, however, there's a big gotcha' in this space. Whilst open standards are necessary for portability and the formation of markets, they are not sufficient. What we really need are standards represented through open source reference models, i.e. running code.

The basic considerations are :-

• A specification can be controlled, influenced and directed more easily than an open source project.
• A specification can easily be exceeded providing mechanisms of lock-in whilst still retaining compliance to a 'standard'.
• A specification needs to be implemented and depending upon the size and complexity of the 'standard' this can create significant adoption barriers to having multiple implementations.
• Open source reference models provide a rapid means of implementing a 'standard' and hence encourage adoption.
• Open source reference models provide a mechanism for testing the compliance of any proprietary re-implementation.
• Adoption and becoming de facto are key to winning this war.

So, in the war of standards whilst the vCloud API has sought approval from the DMTF and formed a consortium of providers, the Amazon EC2 API has widespread usage, a thriving ecosystem and multiple open source implementations (Eucalyptus, Nimbus and Open Nebula).

There appears to be a lot of FUD over the intellectual property rights around APIs and a lot of noise over vCloud adoption. You should expect this to heat up over the next few months because these early battles are all about mindshare and will heavily influence the outcome.

However, whilst VMWare has struck boldly it has exposed a possible achilles heel. The only way of currently implementing vCloud is with VMWare technology, there is no open source reference model. If Reuven is right and Amazon does 'open up' the API, then Amazon have a quick footed route to IETF approval (multiple implementations) and can turn the tables on vCloud by labeling it as a "proprietary" only solution.

Of course VMWare could pre-empt this and go for an open source route or even attempt to co-opt the various open source clouds into adopting their standard. I'd be surprised if they weren't already trying to do this.

This space is going to get very interesting, very quickly.

Our cloud offering is ... a stamp.

I was all excited about Red Hat's entry into the cloud computing space until I read the press release.

Here's my problem ...

Today, a whole range of public cloud providers offer Red Hat as a virtual machine operating system (along with every other operating system). Tomorrow, Red Hat will certify some of those cloud providers.

Either I'm missing the point, or this is just the same as before but with a stamp of approval from Red Hat? Is it me or does that just seem incredibly arrogant? We can fix the cloud by applying our magic pixie dust stamp of approval.

I've worked extremely hard with the Ubuntu team and Eucalyptus to provide users with their own open source cloud system for building private clouds. We've created official images which run both on your private cloud and a public provider (i.e. Amazon EC2) and an ecosystem of management tools (RightScale, CohesiveFT).

We've provided real products for real users and our aim has been to provide an open source reference model for cloud computing at the infrastructure layer of the stack.

Whilst I agree that the solution to many of enterprise concerns over cloud can be resolved by such a common substrate, this needs to be far more than just saying run our operating system in your VMs and here's our stamp of approval.

I'm seriously disappointed. However, disappointment collapses into despair at sight of the following statement:

"How can a CIO be sure that an application written for a Google cloud will work with Salesforce, Amazon, or another cloud?"

[Hint: You can't, they're completely different levels of the computing stack]

I keep on getting this horrible feeling that they haven't got to grips with the changes in the environment but that doesn't make sense because the changes are plainly visible. Every time I look at the landscape it gets me confused ... what on earth are they upto? Have they found some new area of value I just don't get?

The cloud isn't just vapour.

I was recently asked whether I thought cloud was vapour, whether open sourced cloud systems could solve many of the adoption concerns over cloud computing, whether it was likely that such systems would appear, what standards would they support and which distribution would make the first move? I know I haven't been blogging much recently but I was surprised by the questions.

First, regardless of whatever definition you use to describe cloud computing (a fairly hopeless task in my view), the term merely identifies an underlying shift of I.T. from a product to a service based economy. It's a consequence of :-

1. Certain I.T. activities becoming suitable for service provision through volume operations (i.e. those activities are well defined and ubiquitous
2. The existence of mature enough technology to support this (Popek et al wrote the book on virtualisation back in 1974)
3. A change in business attitude towards I.T. (Carr and others, namely Strassmann, pointed out that much of I.T. is simply seen as a cost of doing business.)
4. The concept of utility computing provision (i.e. the provision of suitable I.T. resources much like other utility providers, as forecast by McCarthy back in the 1960's.)

Take away any of these elements and cloud computing wouldn't represent the upheaval and the disruption that it does today. As for trying to precisely define it, try first coming up with a short and punchy description of industrial revolution without hand-waving and referring to numerous tomes. The problem with cloud computing is that it isn't one thing, it's a transition caused by many factors.

I do believe that open source reference models (or what I used to call open sourced standards) are key to the development of the cloud industry because of the second sourcing concerns of enterprises. I strongly believe that private and hybrid clouds (using both private and public resources) will help develop this industry in the short term. Open source should also dominate this change as it is the only viable route to utility computing marketplaces with competition based upon services rather than lock-in. I've not changed my tune since 2006, I see no reason to change now.

During this time of transition (which is after all what is happening) standards will be incredibly important. Despite all the noise we already have a defacto standard at the infrastructure layer of the computing stack - it's called the Amazon EC2 API.

As for when open source systems will appear that match such emerging standards, the first truly credible system was released almost a year ago. It's called Eucalyptus and it's backed by a commercial company.

As for which distribution would make the first move. Well Ubuntu Server Edition has included Eucalyptus since 9.04. Building a private cloud using open source technology that matches the EC2 API is almost as easy as apt-get install and it's going to get easier. We call this concept Ubuntu Enterprise Cloud and you can find details here.

It's also worth noting that Ubuntu Server Edition is also provided as official images on both UEC and on Amazon EC2, so you can run the same base image in both environments. Matching standards and using uniform images brings us a step closer to portability between environments but most importantly simplifies the process of bursting. It takes us a step further away from the dangers of the cloud net neutrality style argument that I highlighted at E-Tech'07.

It's also essential to build ecosystems around open source cloud computing which is why we work with companies like RightScale and CohesiveFT as well as our own tools like Landscape. Everything we do is around openness and freedom in the cloud computing space. This is not some ideological pursuit but simply a realisation that the future cloud markets will depend upon such openness to form. There is plenty of revenue opportunity without the need to tie people down in an old product mentality.

In short :-

• You can already build clouds with open source technology matching the emerging standard of EC2.
• You can already use single images across both private and public environments.
• The technology is entirely open sourced technology and there exists no lock-in to a proprietary framework or solution.
• It's free.
• It's supported.
• It's already in a distribution, go check out Ubuntu Server Edition.
• You can already use a range of different management tools.

Ubuntu already dominates the linux desktop market, and from the reports I've seen recently we're going great guns on the server market as well. As far as I'm aware, we're the only distribution which provides you with a simple means of creating an open source private cloud and images spanning both private and public environments. Maybe we should get a bit better at shouting about it.

Well, I'm going to be speaking at Velocity and then I have a keynote at OSCON. I was thinking of a tag line for what we've being doing and a friend of mine, Alexis Richardson, chipped in with the following :- "Ubuntu is Cloud for Human Beings"

Perfect.

How do you want your cloud?

As I've said before, I don't make predictions. So here is my non-prediction for next year.

When the Azure services platform is launched, we will see the creation of an ecosystem based upon the following concepts:-

1. build and release applications to Microsoft's own cloud environment providing Azure and the Azure Services.
2. build and release applications to a number of different ISPs providing Azure and specific Azure Services (i.e. SQL, .Net and Sharepoint services).
3. purchase server versions of Azure and specific Azure services for your own infrastructure.
4. buy a ready made scaleable "Azure" container cloud from Dell, for all those large data centre needs of yours.

Since the common component in all of this will be the Azure platform itself, then migration between all these options will be easy as pie through the Windows Azure Fabric Controller. If this happens, then the lower orders of the computing stack will end up becoming less visible and the hypervisor wars will become an afterthought. It could be Game, Set and Match to MSFT for the next ten years.

This vision however is only possible, if the network effect parts of Azure actually work (I'll post about that some other time) and the advantages of componentisation through an acceleration in business innovation are realised.

Of course, all of this will create a huge dependancy for all parties concerned on this technology layer but without a clear cut alternative, the pressure to adopt could be immense. The real battleground for the "cloud" has always been in building an ecosystem around the framework layer of the computing stack.

Anyway, this is not a prediction but simply what I would do in order to create a closed marketplace. Naturally, I'd prefer the market to be open and it'll be interesting to see how this pans out.

One step at a time ...

It was several years ago that I started to talk about portability and interoperability (what I later cheekily called patration) with large scale computing providers (what is now called the 'cloud').

I used the ideas of componentisation (Herbert Simon's work on the theory of hierarchy) to describe the acceleration of business evolution on the web that will result from the shift of the computing stack from a product to a service based economy.

I raised most of these points in various discussions at web 2.0 summit in 2006, hence I was pleased to read the following ZDNet post about this years summit in which industry executives such as Cisco's Chief Technology Officer, Padmasree Warrior, described the need for federated clouds and portability at all layers of the computing stack.

I couldn't agree more with the posts comment that "eventually, cloud computing providers at all of the layers will become more open and adhere to standards that allow for federation and movement between clouds. Maritz sees cloud computing as helping to drive the information economy and stimulate new information marketplaces."

Marketplaces, open source ... absolutely. My only word of caution is that people need to carefully consider why the framework layer of the computing stack is so important and especially the dangers that exist within it.

I provided a link to my OSCON 2007 talk on commoditisation, federation, utility computing markets and the need for open source standards - it's a bit old and tired but still covers most of the main points.

Head Conference

I'm speaking Aral Balkan's most excellent Head Conference later this evening. It's the first totally online conference and it really has been fabulous so far.

Anyway, I like to experiment in formats, as with my use of Hegelian dialectics at FOWA. So this time, I'm going to try something completely different.

I've already recorded my talk which I'll broadcast during my slot, and while it's playing I'll answer questions and stop and explain bits where necessary. Of course people can watch the talk at their convenience and if you want to watch beforehand then please feel free. I've provided the video below.

Why open matters from innovation to commoditisation

Far from the Madding Cloud ...

Today I was faced with a challenge.

Explain cloud computing and why interoperability, portability and markets based upon open sourced standards are important IN layman terms!

Now as James' says, I've done this subject to death over the last few years. So I thought I'd try to explain all of this using example for cloud computing and an analogy to explain why interoperability, openness and so forth is important.

So here goes ...

Imagine that average Joe has taken out a big loan to buy lots of very expensive computer hardware.

Tom rents this hardware from average Joe and uses his technological wizardry to make it all appear as one big computer.

Dick rents this big computer from Tom and uses his virtualisation technology to make it appear as lots of small virtual machines.

Harry rents some of these virtual machines and creates a multi-tenanted storage service and messaging system.

Alice also rents virtual machines from Dick to provide a multi-tenanted framework for developing applications in. Rather than building all the elements of the framework she rents Harry's storage and messaging system however she provides access to it through her own API.

Bob rents an instance of this multi-tenanted framework from Alice in order to build a multi-tenanted application which provides transport routing information based upon user provided data, some super smart algorithms and an external cartographic web service from Dave.

Sue, who runs IT for a multi-billion dollar transport company, decides to use Bob's new transport routing system as a key part of her business processes. It's provided on a software as a service basis and marketed as "cloud" which is the latest hot thing, so Sue is happy.

Sue has never heard of Dave, Alice, Harry, Dick, Tom or average Joe. That's cloud computing!

The downside is that average Joe forgets to pay a bill and his machines get repossessed.

As for the analogy;

Imagine that average Joe has taken out a big loan to buy lots of very expensive houses.

Tom uses his financial wizardry to make it all appear as one big security.

Dick divides this security into smaller ...

... you know the rest.

Almost .... but not quite

So according to James Urquhart's post, Google App Engine is going to be supporting JavaScript.

Well, it's about time. JavaScript everywhere (browser and cloud side) will open up the framework to a much wider pool of talent.

Well it's a positive move in my book seeing that I've been there, done that and bought the T-Shirt.

The one major downside is that they're not opening up all the other ancillary components of the framework including bigTable. If they did this, then we might actually start to see an ecosystem of providers develop in the cloud.

I might actually find a cloud service that I'm happy with.

Stop dithering ... you're going to have to in the long run.

Three Rules Happy ...

When it comes to cloud computing, I have three basic rules of happiness. However, before we get to my rules, I have some absolute minimum requirements that any service must meet before I'd even consider it to be cloudy. These include :-

• I have readable access to all my data, code, frameworks and meta data that may have been created as a result of me using the service. It's my data after all, not yours.
• The service is appropriately secure, scalable & resilient and must be charged for on an "as use" basis. I certainly don't want to pay for something that I'm not using, which means I also don't want to pay for using my own machines.
• The T&Cs should be clear and provide me with some guarantee that the service will not be terminated nor fundamental elements changed without reasonable notice and an alternative solution.
• Pricing should be transparent, efficient and competitive.

Assuming the service meets my basic requirements, then I have three basic rules of happiness:-

Rule 1: I want to run the service on my own machine.
This enables me to trial out a service before even considering adopting a cloud version and gives me a last resort fall-back option. I certainly don't want to be in an environment where I can't do this for whatever reason, including vendor failure or discontinuation of a product.

Rule 2: I want to easily migrate the service from my machine to a cloud provider and vice versa with a few clicks of a button.
If the test went well then I'll probably consider dipping my toe in the water. Hence I want an easy to use transfer mechanism for my data (including any code or framework elements) from my machine to an external cloud provider and vice versa. I do not want to learn any specialised skills nor require any technical knowledge beyond pressing a button.

Rule 3: I want to easily migrate the service from one cloud provider to another with a few clicks of a button.
If I'm going to use a cloud service then I want a choice in providers and an easy mechanism of switching between alternatives. I do not want to discover that switching only covers half of the service and fails to cover other elements like the storage subsystem or a messaging service.

For these reasons, I'm not very happy with most of the current cloud offerings.

Standards and Innovation

The emergence of standard components for ubiquitous and common activities does not impair innovation but accelerates it. This is the principle of componentisation; the speed at which a system develops is directly related to the level of organisation of its subsystems.

Mashing up web services to create a new application depends upon layers of standard components, including standard protocols, operating systems, CPUs etc. If there were no standard components and you had to start with chip design before writing an application, the rate of innovation on the web would be snail like.

The only people who oppose standardisation are generally those who sell their product on the basis that it provides a differential. Of course, an activity which is ubiquitous is not a differential in any sense of the word. The arguments against standards are false.

"Cloud" computing is ripe for emerging standards and those standards won't hamper innovation, they will accelerate it.

The obvious dangers of the cloud ...

We've had numerous instances of downtime, changes in TOCs and services disappearing in the cloud computing world. To this list of shenanigans can now be added Nings unilateral closing of WidgetLaboratory.

I'm not going to go on a rant about the need for open sourced standards to protect the interest of businesses built upon such services, because both James Urquhart and those smart guys at Reasonably Smart have already said what needs to be said.

It seems that Reasonably Smart are also planning to raise further investment. If you're looking at getting into the cloud computing space, I'd strongly recommend you talk to them. To be open in my dealings, I know James Duncan very well but I have no vested interest in the company; I just happen to strongly agree with what they are doing.

I want to clearly emphasise one important point. The value of large scale utility computing provider of a JavaScript based application platform can be measured in the tens of millions. By following an open source route, the value of the technology is in effect zero. However, the potential value of a marketplace of utility computing providers based upon an open sourced standard (with revenues from utility sales, switching services, maintenance contracts, brokerages and exchanges) can be measured in the tens of billions.

If I had the cash I'd invest in the company myself, unfortunately I don't. They have a reasonably good chance, with a little bit of luck and support, in hitting the big time.

Finally, I'm overjoyed to see this post by Tony Lucas (the guy behind FlexiScale) on the importance of Interoperability and Portability in the cloud computing world. I couldn't agree more, and I believe that FlexiScale (at the infrastructure layer of the software stack) and Reasonablysmart.com (at the platform or framework layer of the software stack) have the potential to be real game changers in this service world.

To James Duncan and Tony Lucas, fortune favours the brave ... I'm cheering for you both.

We can see what you're upto ...

We might not yet have our plethora of open sourced standards and compliance authorities, but we're starting to see more and more monitoring services appear for the cloud.

A slight drizzle ...

There has been a lot of noise created recently about the downtime in GMail and the issues this has caused. Alan Patrick posts about how this is "pouring rain on the cloud computing parade".

Let's be clear, this is a minor hiccup compared to the potential black swan event that could occur. We desperately need some resolution on the issues of portability and interoperability between different providers for what are, after all, ubiquitous activities.

I've argued many times for the need for open sourced standards at different levels of the software stack as it moves from a product to a service based economy. These arguments are based upon the concepts and dangers caused by a lack of second sourcing. I've also argued that many technology vendors (except the most enlightened) are unlikely to shift willingly to a service based world without trying to maximise their position through lock-in.

In the past, the usual response I received was that this would limit innovation and competition. This has never been true, as innovation in the service world should be in operations and not product differentiation. Competition can be created by encouraging operational excellence whilst maintaining a standard reference model, hence my argument for AGPL as the ideal license. Whilst some agree with such a view, few are willing to accept that business consumers need to form associations to push vendors towards open sourced standards.

If you want interoperability and portability, you're almost certainly going to have to fight for it.

For those who haven't seen my talk from OSCON last year, I thought I'd re-post it here. It covers some of the basics.

Oscon talk, July 2007

Caveat emptor ...

In a blatant attempt to add more wickedness into the world of aaS ("as a Service"), I thought I'd create the pointless terms of PaaS? and PaaSee (I hate the acronym wars anyway).

So here are my two new definitions:-

PaaS? (Product as a Service?): A PaaS? vendor, is a vendor who has not yet quite grasped that a utility-like service world is only suitable for those activities which are well defined and ubiquitous. As such, competition should be based on price and quality of service (service differentiation) rather than features (product differentiation). Without an ecosystem of vendors competing around the provision of an open sourced standard (i.e. an operational open sourced reference model of what it to be provided), then consumers will be faced with serious strategic concerns regarding second sourcing, security and competitive pricing which will in turn increase the barriers to adoption of this new technology. Due to this lack of understanding, PaaS? vendors attempt to bring their products into the service world with little or no thought regarding the questions of interoperability, portability and competitive ecosystems. PaaS? vendors tend to focus on:-

• The innovative benefits of their Product as a Service : the reality is that any componentisation of the IT stack will create such benefits.
• The competitive advantage that their Product as a Service brings : the reality is that as the activity in question is ubiquitous (i.e. suitable for utility-like service provision) then there will be little or no strategic value in the service as it is more of a cost of doing business.
• The ability to customise their Product as a Service: the reality is that customisation, new features and any activity which shifts away from a core reference model of the service will decrease interoperability and portability. The strategic gain for a consumer of customisation of a ubiquitous activity is likely to be far less than the strategic loss caused by a lack of second sourcing.

PaaS? vendors are obviously clueless and not to be trusted with your data.

PaaSee (Product as a Service - extremely evil): A PaaSee vendor is one who is well aware of the commoditisation of IT and the shift to services for ubiquitous activities and hence is actively attempting to bring lock-in into a service world in order to protect and maxmimise revenues until such time as they forced to change their behaviour. PaaSee vendors assume that business consumers of IT lack the strategic wit to see the game that is being played and they are quite willing to sell your grandmother to turn an extra buck. PaaSee vendors are definitely not to be trusted with your data.

So what should a budding adventurer in the world of cloud computing do? Simple, unless you have marketplace of service providers with interoperability and portability between them, then make sure you have a plan for a complete loss of service.

Raging Clouds ....

There have been some interesting debates on cloud computing over the last few days. I thought I'd mention Tim O'Reilly's and Hugh MacLeod's posts.

I left a comment and I've summarised my thoughts here just in case my comments don't make it onto their blog posts (this happens quite often).

Comment =====

The question of large scale monopolies in what is today called "cloud computing" has been raised many times before in the past by Tim O'Reilly and others. There does exist a real danger here of network effects particularly through mechanisms such as aggregated services (i.e. market reports, preferential pricing or performance) along with the more obvious danger from the creation of a large proprietary technology based cloud.

None of this has been kept secret, it however has only just recently (in the last few years) become more popular. My reasoning, back in 2006, for the need to open source Zimki (a now defunct utility computing cloud) was based upon much earlier conversations that were raging about the dangers of a lack of portability & interoperability in a future utility computing world. None of this was new stuff then, it was just not widely known.

The move towards the cloud is almost inevitable (the business equivalent of the Red Queen Effect) due to cost efficiencies and speed of new service release. The use of open sourced standards (operational open source reference models of services to be provided) such as Eucalyptus (as Tim points out) is a way to prevent the formation of artificial markets, though as JP notes it does require concerted community action. Such action is in the interest of general business consumers for all the reasons of second sourcing.

As for the connection between cloud and services (as in service oriented design, architecture and "as a service") this is simply the shift of a number of business activities along the S-Curve of transformation from innovation to commoditisation. This is also allowing for greater componentisation and hence new innovations such as mashups etc. It is all connected by the same underling process and a tri-partite effect of participation, network effects and componentisation which is both accelerating innovation in the IT field and commoditising that which is ubiquitous. The pipeline of creative destruction has accelerated and this is what connects it all.

Finally, James Governor's comment that "Customers always vote with their feet, and they tend vote for something somewhat proprietary" whilst insightful is also somewhat unfair. It was clear from CloudCamp London that potential consumers are concerned about the issues of interoperability and portability and none thought that proprietary technology would resolve this issue. I feel compelled to defend those users, as the assertion that James puts forward is that the average CIO lacks the strategic wit of their counterparts in manufacturing.

This might be true, James might be right and maybe CIOs of today have become lazy on the easy pickings of IT. In such a case, the move by some companies over the last few years to put former heads of manufacturing in charge of IT and to bring in those skills honed through years of cut-throat commoditised activities and the strategic imperative of second sourcing may well turn out to be wise moves indeed. It would be unwise however to simply focus on the commoditisation of IT as both extremes of innovation and commoditisation need to managed simultaneously.

I remain hopeful, that those governing consumption of IT within business will realise the need to form consumer associations to push the industry towards open sourced standards for ubiquitous activities. What I cheekily called "Gang up now before the *aaS cloud gets you"

Time will tell.

We own your clouds ...

I've long argued that we need open sourced standards combined with compliance authorities using trademarks in order to ensure a functioning utility computing market.

However, companies trademarking generic terms like "cloud computing" is not that helpful. Thanks to James for spotting this.

Trust the Government ...

According to Alastair Otter of MyBroadband, whilst the South African government has been a long advocate of open source software, 72% of IT "companies that supply technology to government favour open standards".

Minister Fraser-Moleketi was spot on the money by noting that open source and open standards were important to government because they ensured interoperability and portability. If my straw poll at Cloud Camp London is anything to go on then this is a concern for almost all business users of SaaS and the cloud computing world.

Obviously vendors want to create some form of competitive advantage for themselves, so some sort of compromise is needed between interoperability, portability and vendor competition. A solution to this conundrum is the use open sourced standards, as in the standard itself is an operational piece of open source code.

Whilst compliance to the standard means matching the open source code exactly in terms of functionality, this still leaves plenty of room for operational advantages in how the code is implemented. This approach is suitable for those activities that are ubiquitous, well defined and in reality a cost of doing business i.e. those suitable to an "as a service" world. However despite this, many vendors and their pundits seem prepared to champion SaaS as a new sales vehicle but at the same time they appear unwilling to engage in a world of service competition.

This is why we need people like Fraser-Moleketi fighting our corner.