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.

Massimo.

18 comments to The Cloud Magic Rectangle ™

  • Brett Parlier

    Great post Massimo, thanks for the easy to use terminology. The pictures made it! :)

  • Doug B

    An interesting post. I agree 100% with this statement!

    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.

    I am curious, though, where your bike falls in the magic rectangle :)

  • Excellent post that describes the categories of services.

    I agree completely that no one type is ‘right’ – each business has different requirements for their applications, users, and industry regulations. This is a good roadmap so that enterprise IT can create a timeline plan for their cloud strategies.

  • […] is the opposite of elegance.  Complexity breeds failures.  Systems that are not designed for failure, which are complex or sprawling, will fail catastrophically.  Frequently catastrophic failure will […]

  • Frank De Gilio

    Well said. – The most important thing I want people to have a successful IT organization in todays market has nothing to do with technology. To me cloud is a IT business model. I realize that IT does not need to make a profit like other organizations in the business. Rather it needs to understand where it spends it’s money in order to understand what lines of business need to pay. This business model will also allow IT to understand where it needs to streamline to gain efficiencies. It’s the cloud business model that is paramount not the technology. Until people grasp that important cloud concept, no matter which horse they ride they will most likely be in the design for fail category. At best they will be sub optimizing their design…

  • […] is the opposite of elegance.  Complexity breeds failures.  Systems that are not designed for failure, which are complex or sprawling, will fail catastrophically.  Frequently catastrophic failure will […]

  • Frank,
    I agree its about the business. I noticed the table missed another key metric. The businesses will go for lowest cost and most agile. The table correctly indicates that design for failure is lowest tco. I believe that devops on design for failure clouds are also the most agile.
    The statement that many companies will take 20 to 30 years to get there is a bit naive given the extremely fast adoption of cloud technologies. Now I’m not saying that companies will get their entire infrastructure on this type of cloud, they never will move entirely. But as companies start to realize the benefits application by application, I expect adoption will accelerate dramatically. In fact I think early adopters are already on this path.

    • Massimo

      > The statement that many companies will take 20 to 30 years to get there is a bit naive given the extremely fast adoption of cloud technologies.

      Considering that, probably, IBM still makes more money on the AS/400 compared to how much AWS makes out of cloud I’d say 20 to 30 years is an aggressive statement. No doubt there are a lot of companies that are deep into cloud already but the like of Netflix is the exception, not the norm.

      Thanks for chiming in. Two IBM Distinguished Engineers commenting on my private blog…. I am getting more attention now than when I was working there. Thanks.

      Massimo.

  • […] have discussed many of these concepts in a previous blog post titled The Cloud Magic Rectangle (still one of my favorites). I thought that it would be interesting to (try to) map the software […]

  • […] happening overnight, obviously, but a trend is a trend. I have been talking about this in my Magic Rectangle blog post and if I have to pick up a single characteristic among the many of what differentiatates […]

  • Massimo,

    Interesting post, I like the differentiation between the different focus areas of cloud solutions. Though I find the naming of the three cloud value positioning very technology oriented; Orchestration, using policies and design for failure are techniques that can be very well used in all the three categories. I myself see two categories; the left one you call “orchestration”, which I would call “cloud enabled” and the right on you call “design for fail”, which I would call “build for cloud”. I feel that the one in the middle is just hanging there, don’t see what’s really unique about it, maybe you can elaborate.

    If I look at the IBM proposition, for which I work at the moment, I see that IBM currently has two public IaaS/PaaS cloud services; SmartCloud Enterprise+, primarily build for “cloud enabled” (your “orchestration”) purposes and SmartCloud Enterprise, primarily build for “build for cloud” (your “design for fail”) purposes. See an elaboration on my blog here: http://edwinschouten.nl/2012/08/28/enterprise-versus-enterprise/

    As an architect I must say that I don’t agree with the images you have created to illustrate the three categories, as all three images just show a different viewpoint on, perhaps, the same architecture.

    Regards,
    Edwin.

    • Massimo

      Edwin, I think this is the typical thing that, if you ask 1000 people, you are going to get 1000 different names / characteristics / pictures etc. It’s perfectly fine. I am not trying to say this is *the* market segmentation but it’s rather *my* personal view of how I would segment this market. I have called IBM out in the first column because I think this is where they are strong (and where the perception of the people is if nothing). IBM may very well have a design for fail cloud service available but I don’t think that the perception (and the meat) is there (yet). Of course BMC had their own view of the world re my post as everybody would like I said above (https://communities.bmc.com/communities/community/bsm_initiatives/optimize_it/blog/2012/03/07/my-cloud-is-better-than-your-cloud-im-telling-mom)

      Yes in a way the second column is “hanging there” (I somewhat agree). That column exists to try to capture this notion of a “virtualization 2.0” type of cloud. This is a concept that has been discussed at nauseam on twitter / other blogs and it’s typically coming from “people” associated to the third column blaming people on the second column that “that isn’t really cloud”. I think it does have its place and it differs (LARGELY) from the first one because it assumes an x86 architecture only (Vs *everything* in the first column). Also the first one usually have a total orchestration approach (ie I will automate what you do manually today on very low level technology components) Vs the second column that is implemented with higher level of out of the box abstractions (that, if nothing, will allow you to start orchestrating at a very higher level compared to the first column). I am biased but the best example I can think of is vCloud Director and vShield Manager.

      I do like the pictures as I think they do represent this different view of the world. Particularly the first one shows the typical top-down alignment of app and infra (I have this app, I’ll build an infra for it). The second one is more of a flat shared infra (yet Enterprise oriented with SAN and stuff) that is supposed to be able to host different type of applications whereas the third one really represents the typical scale out, Direct Attached Storage, no resiliency, commodity type of infrastructure typical of the “design for fail” (or “cloud enabled”) applications.

  • Thanks for the reply, let’s agree to disagree.

    A cloud service with a “build for cloud” (your “design for fail”) positioning can be build using software/hardware that you describe as “orchestration” and vise-verse, the differentiating factor is what kind of workloads the cloud service can support. The concept of cloud is about getting IT “as a service”, and not fussing about the underlying technology.

    Sure, cloud providers need to worry about this, but in my view cloud services should be arranged towards the value proposition for cloud consumers: what’s the time to provision, what’s the payment model, how is integration supported, what’s the availability, what kind of platform services are available (lifting standardization to the application level), what kind of support is available, where is the service located (hence where is my data).

    These characteristics are than mapped to the requirements each of a businesses workload; there is no one-size-fits-all cloud service. For instance, I see large enterprises working towards a hybrid model; private for sensitive data/high performance workloads and public for the rest of the workloads. All the private cloud workloads need to fit on one cloud solution (from a cost perspective), the public workloads can be hosted on best-of-breed cloud services (SAP workloads on a SAP cloud service, CRM workloads on a CRM cloud service and so on.

  • I really liked your post to position the orchestration, policy-based & design for fail clouds.
    I think it’s worth mentioning technologies at my previous employer (IBM) and current (same as yours :) ) that may complete the panel.

    For PaaS, i think technologies exist at IBM (Workload Deployer) and VMware (vFabric) that would position both of them in the top-middle boxes.

    Same for IaaS, there is a brand new technology at IBM (named SCP) which would position them in the bottom-middle square.

    My 2 cents.

  • […] “Private Cloud” by Simon Wardley, “Private Cloud” and “Public Cloud” by Matt Asay, and “Policy-based Clouds” and “Design for fail Clouds” by Massimo Re Ferrè, who also categorized these models as “Design Infrastructure to support Applications” versus […]

  • […] Massimo Re Ferrè charts the many types of cloud according to value proposition and positioning, how providers build them, and what customers receive in return. […]

  • […] Wardley, “Private Cloud” and “Public Cloud” by Matt Asay, and “Policy-based Clouds” and “Design for fail Clouds” by Massimo Re Ferr&egrave…, who also categorized these models as “Design Infrastructure to support Applications” […]

Leave a Reply