Random Thoughts and Blasphemies around IaaS, PaaS, SaaS and the Cloud Contract

calendar Nov 30, 2010 · 8 min read  ·
Share on: linkedin copy

As I am sitting on my plane to Frankfurt with 45 minutes of delay due to heavy snow I thought I'd give this thought of mine a place on this blog. A few days ago I have posted an article regarding the concept of the cloud "Sandbox". Here I'd like to post something about another angle you can use to view cloud computing. I call this the cloud "Contract". Most of the thoughts below can apply to both private and public clouds although I'll talk more about the latter.

The cloud "Contract" explained

The concept is fairly easy. If you look at the relationship between who is building infrastructures today and who is consuming the resources made available, it's typically very difficult to draw a line between the responsibilities of the "IT Admin" (the "provider" in the cloud terminology) and the responsibilities of the "end-user" (the "consumer" in the cloud terminology). This is particularly true in traditional in-house deployment where IT isn't really operating (most of the time) as a service but it also applies to external relationships such as those between Enterprises and service providers (telcos, outsourcers etc). I spent most of my professional life working with Enterprises for their internal deployments but the more time I spend with external service providers the more I get this feeling that there isn't any "managed services" standard and even the point-in-time relationship between a given service provider with a given customer has many grey areas (to say the least). No later than last week I was talking to one of these big outsourcing players and they were telling me that their "managed services" contract has the following boundaries of responsibilities:

"...well it depends, when customers want us to manage their OS, middleware, application stacks we usually do everything although sometimes they want to do some stuff too... when this happens we ask them to, at least, tell us in advance so we know what they are doing...."

I found it particularly interesting because it essentially maps the concept I was trying to visualize in my Cloud 101 presentation at VMworld 2010 when I was talking about this cloud "Contract". This is the slide I have used:

And that's the other angle you can use to look at cloud. Cloud is all about moving into an as a service paradigm where the roles of the providers and the roles of the consumers are well defined. This is what we do when we sign up for a car lease plan, for example. I signed a contract where I know exactly what the leasing company is supposed to deliver (ordinary and extraordinary maintenance, winter tyres, insurance, etc) and what it is outside of their responsibilities (driving the car, filling the gas, etc). By the way I didn't buy a car because I thought that, working on the public side of the cloud, I should eat some of my own food so I rented one and went with what I call the CaaS (Car as a Service). And I have to admit this was an excellent decision so far.

Anyway, contract is the key word here. A few months ago I was reading the "Use Cases and Interactions for Managing Clouds" document published by the DMTF and I noted that the term "contract" appears as many as 261 times. And this is clearly not by chance: cloud, at the end of the day, is a service contract.

"IaaS Managed Services". Does it make sense?

There is something that lately is driving me crazy: most of these service providers standing up public clouds typically mention the fact that they want to provide a "managed service" for their IaaS cloud offerings. And this is where I get a bit lost. If you have read my post on the concept of the cloud Sandbox you have the background of why I am struggling. Long story short I see the cloud Sandbox as the ultimate experience of the DIY (Do It Yourself) approach. There are various use cases for the cloud Sandbox concept described: one may be a developer looking for a very agile environment where to develop an application (examples of these clouds could be vCloud Express or Amazon AWS) or big organizations looking for enterprise-grade public cloud resources to extend/federate their own datacenters (example of these clouds could be vCloud Datacenter). No matter what, the provider is only supposed to provide raw capacity (CPU / Memory / Storage / Network) that the consumer will manage. This doesn't mean that the software stacks being used in the IaaS cloud Sandbox are "unmanaged". It simply means that the stacks are managed by the consumers based on their needs, processes and standards. Basically, the governance of the inside of the sandbox is a consumer responsibility not a provider responsibility.

I had another enlightening discussion with another service provider a few weeks ago where they were discussing how to provide "managed services" on top of their future IaaS offering. Their point was that they are expecting a high degree of standardization across the board in those stacks to be able to manage them (effectively). But how can you create this level of standardization in the stacks if what you are selling is a cloud Sandbox where end-users has full control and the ultimate self-service experience? Should an "IaaS managed" offering be considered a contradiction in terms? I think so.

So does this mean that the service providers are no longer in a position to offer "managed services"? Not at all. And this is where the cloud contract and its very well defined boundaries comes to rescue. In the cloud space you can still offer "managed services". They are just called differently. When I had the discussion above I started to wonder: "so you want all users to use a standard stack that you have provided and standardized on and that you can manage for them. This management can go from the operating system and middleware all the way to the application...Mh.. wait a second, this is called PaaS and SaaS in the cloud!". Yes, in the cloud, that's the new name for "managed services": PaaS and SaaS.

In other words, IaaS, PaaS and SaaS just define how deep the cloud "Contract" is and what the service provider responsibilities are:

  • IaaS: SPs will provide and manage the hardware infrastructure for you and they will expose virtual CPU, Memory, Storage, Network services that you can consume with your own OS / Middleware / Applications
  • PaaS: SPs will provide and manage the HW/OS/Middleware infrastructure for you and they will expose application frameworks, database services, messaging services (and more) that you can consume with your own Applications
  • SaaS: SPs will provide and manage everything for you and they will expose the application service that you can consume directly (typically from a web browser but not limited to).

Another important aspect to note is the terminology I have used in defining IaaS / PaaS / SaaS. Note that I have stated that the service provider will provide and manage those layers. This has at least a couple of very important implications and ramifications:

  • if the SP provides the consumer with a pre-load of OS and Middleware (and Application perhaps) but let/ask/allow the consumer to manage these layers, this is not PaaS (or SaaS) this is just "IaaS pre-loaded". Can you appreciate the difference? Cloud is all about providing a service not giving a piece of software pre-loaded.
  • it is the SP that provides and manages those layers. If the consumer provides those layers and let/ask/allow the SP to manage them, this is not PaaS/SaaS but it's rather traditional "managed services".

This is the other picture I used in the Cloud 101 presentation to visualize this concept:

Put it in another form:

Conclusions

This PaaS / SaaS approach may sound to you a bit inflexible and not very suitable to ad-hoc deployments compared to the nature of today's "managed hosting services". And perhaps it is. However consider that cloud is all about standardizing and normalizing to achieve, in the final analysis, economy of scale, fast provisioning and a much better framework to define roles, responsibilities and ultimately establish prescriptive and measurable "contracts" between providers and consumers of services. Consider also that there is an adoption model for the various "contract" layers depending on where you want more flexibility (IaaS) all the way to less management burdens for the whole stack (SaaS). This slide in the Cloud 101 deck was supposed to summarize this adoption model with advantages and disadvantages:

In conclusion I believe that all this discussion can be summarized in the following (bold) statement: We used to design infrastructures that support applications. We are now developing new applications that support the cloud platforms and these new services contracts and paradigms.

I'd like to hear what you think about this. Especially if you are one of the service providers out there. After all you know your business (and how it could evolve) much better than I do. Am I making any sense with this?

Massimo.