Tuesday, September 08, 2009

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.

2 comments:

Thomas said...

Just watched your presentation "Situation normal: everything must change" on InfoQ, and I really enjoyed it. I hadn't been aware of Ubuntu's ventures into cloud computing with the EC2 API, but I'm excited for it now. Sounds a lot better than trying to sync between VMWare and EC2, which is what I am currently doing.

Thanks and keep up the good work.

swardley said...

Hi Thomas, thank you for your kinds words which are much appreciated.

We're deliberately following an approach of not creating more confusion in the cloud(i.e. releasing a new API) but instead one of adopting the growing de facto standard and ensuring that there are open source systems which provide this.

Back in 2005, the company I ran built what today would be called a PaaS, it was a Google App Engine equivalent with JavaScript (way before GAE itself). We announced in 2006 our plans to open source the system in order to help form a marketplace in the platform layer of the cloud computing stack and we had already solved the issues of portability between different providers.

Alas, my parent company, didn't see this as the future and the service was discontinued.

The reason why we intended to open source the system was that the key to formation of competitive marketplaces in the cloud has always been the creation of standards based around open source reference models (to increase adoption, own usage etc). Without a competitive marketplace the user concerns over a lack of second sourcing options will continue.

The approach of adopting exiting market standards and providing open source reference models is one that Canonical will follow. This is both for the infrastructure layer of the stack and more importantly in the platform layer where the real cloud battle will be.