I have used one of my recent posts in some off-line discussions about the use and penetration of virtualization in some accounts. In this post I’d like to expand a bit on that. I will just start with a nice picture that is supposed to summarize with a different graphic (but with the same core concepts) what I was trying to argue in the post I was referring above. In this case, I think a picture is worth 1,000 words:
Specifically I want to position where cloud infrastructures are going to fit into an organization. While this picture is really focused on internal (enterprise) deployments it also maps how service and hosting providers are going to shape their offerings for their end-users (more specifically, on the right hand-side the traditional hosting business and on the left hand side the new virtual servers /cloud business).
To make a long story short, most enterprise will have to accommodate – like it or not – these four platform pillars (right to left):
* Proprietary platform: essentially all non-x86 platforms. Think of mainframes and the AS/400 as prime examples. While many may not refer to Unix as a proprietary platform, I believe it is.
* Physical x86 platform: traditional Windows and Linux deployments on physical servers. This is the typical old way where a single OS image maps to a dedicated physical server. Many customers still have physical server deployments as part of their regular practice. Sometimes this is required; sometimes they do this simply for “irrational fear of virtualization technologies”.
* Virtualized x86 platform: this is the first deployment policy for many organizations. Think of VMware VI3 or VMware vSphere deployments. This has proved to work well for the last five to six years and it’s an established good practice. As mentioned in the post I referred to at the beginning, the level of penetration may vary depending on many factors.
* Cloud platform (IaaS): this is the new potential player in your infrastructure and it’s probably going to support the less critical and more dynamic environments you have to deal with on a daily basis (test and development is one common example; there are many others).
One could spend hours commenting on this slide but I’ll try to be dry on some key points that you need to digest (in my opinion).
First and foremost there is clearly a trend where the left pillar(s) is taking over some of the workloads of the right pillar(s). And this trend is consistent across the board: x86 physical deployments are cannibalizing proprietary platforms. It’s the same pattern for virtualized deployments eating up typical x86 physical workloads (more and more we hear about the “virtual first policy”). Last but not least expect the new player, cloud infrastructure, to cannibalize most of the traditional virtualized x86 deployments. Stopping the trends I am describing here will be as difficult as trying to stop a moving train with your fingertips: good luck.
At this point you may wonder why, given that cloud infrastructures build on top of and leverage virtual infrastructures, I am calling out two specific and separate pillars. That’s a good point, especially because it’s true that clouds (specifically IaaS clouds) build on top of hardware virtualization. In fact I argued just this point in the other post I referenced at the beginning of this blog: since the first cloud instantiation will tend to trade-off the complexity of many tuning options for a better and easier end-user experience, we expect some workloads that require a bit of tuning and visible infrastructure layout options to remain on more traditional vSphere types of deployment.
If you think about this, cloud is all about agility and with agility comes less control (i.e. tuning). As time goes by these two pillars will converge. The Cloud pillar will take over the traditional virtualization pillar. Indeed, I expect that most of these tunings and controls will no longer be needed because of the additional automation and auto-tuning concepts that cloud-related technologies offer. Last but not least, let’s not forget that Cloud technologies will also mature over time and will fill holes we see in the first wave of cloud technologies.
Finally, I’d like to touch briefly on management. I think we need to be all very pragmatic here. I know many customers are looking for the nirvana “one tool to manage them all”. The fact of the matter is that the more you try to normalize these pillars under the same management umbrella, the more benefits for each of the pillars you must sacrifice. I have had an interesting discussion lately with a colleague at VMware and I think he did hit the nail on the head when he said, “They want to have one tool because they think it’s more efficient. It’s not. It’s more efficient, and more effective, to run two tools that manage two systems well than to run one tool that manages ten systems poorly“.
In my previous IT life I was in the business of trying to homogenize heterogeneous virtualization platforms under a single management umbrella so I have to (strongly) agree with my colleague’s statement. In fact, these pillars are very different in the way you manage them. This is true not only from a technology perspective but also, and even more so, from a process perspective. For example, the process to request a partition on a legacy Unix system may be totally different than the process required to instantiate a new physical server, which in turn is totally different than the process to request a new vSphere virtual machine. To complicate things more, the Cloud pillar, by very definition, doesn’t require any process whatsoever to instantiate a new workload from the self-service portal.
Try to homogenize this with common processes, a single management umbrella, and a single pane of glass. The moment you think you have done it, you wake up all sweaty.
I am not making the case that your application or service will not span different pillars. You may very well have your scale-out web front-end on a dynamic cloud pillar and your scale-up back-end database on a more tunable virtualized pillar or any other combination. After all, the concept of application layer tiering isn’t that new in this industry. If you think about that we have just added another interesting pillar (Cloud) into a picture that we have been using in the last ten years. This is not going to shake our world, but it is going to make it much better.