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

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.

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

  • Massimiliano

    Dear Massimo first of all thanks for your interesting blog.

    I work for one of the big international Telco that is pushing a lot on cloud computing services.
    I think that the points your are raising are very hot at the moment in all the MSPs and they have an intrinsic difficulty that require new efforts in terms of contract management, financial risks and legal.
    As you know the idea behind the managed services has always been to move the CAPEX to the OPEX as much as possible, this implied that the upfront investment from the Service Provider was absorbed mainly in the CAPEX, and in some cases spread over the OPEX subject to contract time constraints, as such the customer willing to contract out before the term was subject to penalties.
    Now with Cloud Computing business model the CAPEX is simply not there (or it is negligible) and in my opinion the contract, other than guaranteeing profitable business to the provider and a service level to the customer, it is becoming more and more a tool for governing the demarcation point, that in the Cloud seems so vague.
    As for your point regarding the “IaaS pre-loaded”, I totally agree with you: moving the management bar up the stack in an IaaS delivery model does not make the service a PaaS or a SaaS, simply for the fact that there is no economy of scope: a real PaaS or SaaS service is built with the objective of maximum efficiency (for both provider and consumer) with no management effort for customer and limited or none customization freedom, as such the underlying infrastructure and CSP processes are very likely not the same as the IaaS.
    I think that the big focus of the discussion is not about the technology but more about the underlying processes and procedures that the CSP deploys to support the service, there is where the hidden costs are lurking.
    I feel to say that the topic might go beyond the pure service delivery aspect and IT responsibilities domain, IMHO it is difficult keep out from the discussion the GRC aspect (Governance, Compliance, Risks). You mentioned Amazon AWS, I have met few customers in Italy who have never spared a thought about potential Data Privacy breach by hosting their business data somewhere in US, even less on the consequences.
    Law again is lagging behind this new Cloud Computing business model, and this is one of the reasons why security is the main concern in adopting it, but we should see the cup half full and take this as an opportunity to force the systems (legal, standard bodies etc) to converge to a better set of rules, because Cloud Computing is unavoidable, full stop.
    Apologies if I have drifted away from your points but I tend to think that all these aspects are intertwined and cannot be really dissociated.

    Massimiliano

  • Paolo

    I totally agree with you !!! The 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” is truly the point, in my opinion, in order to build new services based on the cloud. I know it’s really difficult to do but we (service provider) must address this objective during the next months. But also the developer and system integrators must change their way of work in order to accomplish the new cloud paradigm !

  • Ronak Shah

    You have made great points. I work for an major integrator. SaaS is supposed to make end-user and architect interaction minimal. PaaS will lead into providers monopolizing on their own platforms and migrations hard – if need be. Organizations that will benefit from PaaS most will be medium sized organizations. SaaS migrations of non-business critical applications will gain tremendous momentum for all organizations.

Leave a Reply