The Cloud Magic Rectangle ™

This isn't the counter argument to Gartner's Magic Quadrant (I think). Oh, and notice I am not even going into the "this is cloud, this is not cloud" type of discussions. How boring? World peace folks, everything is cloud, even my bike (according to the NIST definition anyway).

In all seriousness it is becoming pretty obvious that the classification we have been using so far isn't cutting it. IaaS, PaaS and SaaS are obviously required to describe the type of services a given cloud provides but only one dimension won't cut it. I have seen lately attempts to create this second dimension where analysts introduced the notion of "Enterprise" and "Next Generation" clouds. I am purposely avoiding the abused marketing word "Open" (although many are using it, solely for marketing messages purposes).

I came to the conclusion, after two years of customers meetings, partners engagements, and twitter / blog battles that there are really three buckets that relate to this second dimension. We will, of course, also continue to use the first dimension to create the Magic Rectangle(tm).

I'll try to be as neutral as possible and I'll call these buckets: Orchestrated Clouds, Policy-Based Clouds and Design for Fail Clouds.

I am listing three distinct tables that aim at describing the characteristics of these different type of clouds from different perspective. I will say upfront that if I was to write these characteristics again they would very likely be different. As usual, try to depict the forest , don't look at the individual trees.

Value Proposition and Positioning:

How You (Provider) Build These Clouds:

What You (Consumer) Get with These Clouds:

You can't bother reading those tables? They don't make any sense to you? No worries, you are not alone. Pictures are the only thing that (really) explain these stuff:

All this reminds me of a blog post I wrote back in November 2010 where I said (I love to quote myself):

"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."

That is exactly what's happening. And this is how I see the IT world twisting (admittedly in the very long run):

If you have been in these discussions on twitter you may have noticed that pretty much (almost) everyone agrees on this. Depending on how fast the world is moving for your organization, you may perceive that these are three parallel options (the world for you is still) or you may perceive a progression from left to right (the world for you is running furiously fast). If you are making a strategic investment in one of the first two columns and, after reading this post, you think that that is not the right thing to do strategically... think carefully. While there are organizations on the third column already (Design for Fail), there are many of them that will get there not sooner than 20 or 30 years. You may very well be one of them. No need to feel ashamed about it.

Note how the model in the middle is the gateway towards this new world (according to the way I see it at least, your mileage may vary).

And now for the Cloud Magic Rectangle(tm), this is how I think products and technologies map to this progression I have just discussed.

There are at least a couple of thousands way to misinterpret the picture above. Let me be clear one on of these: if a product is represented in a given position, it doesn't assume it won't move left, right, up or down over time. For example AWS is moving up (quickly), Azure is moving down (with the VM role).

I did put logos on the slides the way I honestly feel they should be placed. I didn't put those logos where they are just to try to drive a point home. It's interesting to notice that many of the logos that ended up on the third column represent online services and not software products. I am wondering if this means something and if there is a trend.

Also, looking at the picture I am kind of coming to the conclusion that IaaS may be a great choice to "cloudify legacy workloads". It seems, from the picture, new workloads may be best positioned to be re-engineered on the PaaS "Design for Fail" layer rather than on the IaaS "Design for Fail" layer. Perhaps that is the reason why AWS is marching north so quickly.

You may assume I am saying this because I am biased as that's how the VMware products line up on the picture. Fair enough. You can however also assume that VMware gets this right (which is, at least, my hope).

Discuss, if you want.