posted

4 Comments

By Massimo Re Ferre’, Staff Systems Engineer – vCloud
Architect

 

As I mentioned in my previous
post
I started working on virtualization technologies years ago. It was
around 2003 when I started talking, at public events, about what one could
achieve using VMware ESX (which at that time was the only VMware offering for
the enterprise market). I still remember the very first two questions I got
asked in one of those events that year. The first one was "wow, does it
really work?" Answer: "Yes, it does indeed". The second question
I got asked was, "Can I virtualize SAP"? The answer in 2003 was a no
brainier and it was something like, "We don't want you to virtualize the
SAP instance. We want you to virtualize the 20 plus infrastructure servers you
have sitting around it that support that SAP instance because they are what
cause you so much trouble".

 

For the next event, I decided that I should
anticipate the "what is virtualization good for?" and "where do
I start with it?" type of questions so I built the following slides to
give the audience a rough idea of where (and why!) these technologies would
fit.


Pict1


Pict2  

Pict3


For years I have pitched a typical datacenter
deployment as a pyramid on the side where, on the left, we have many instances
of dynamic, non-critical, non-resource
intensive
types of workloads. Test and development environments are a good
example. As we move to the right, workloads start becoming less dynamic, more critical, and more resource intensive. The SAP
instance above would be a good example of what sits on the other side of this
spectrum. In the middle we have a broad mix of infrastructure, tier 2 and tier
3 types of workloads, each of which comes with various infrastructure
requirements.

 

As you can tell from my graphics above, the virtualization adoption model I was
suggesting was pretty straightforward: "start from the left, move to the
right and stop where you like". This slide was built in 2004 and could
still be used in 2010. I think this adoption model made tons of sense at that
time for many specific reasons:

 

1) Organizations were losing control of the left part
because of the many little workloads that were popping up every other day
without any sort of governance (virtualization helped a lot with consolidation
and containment);

 

2) Organizations were not dynamic enough on the left
part because the deployment lead time for physical servers was too long
(virtualization helped a lot with the concept of "your new server is three
clicks of mouse away");

 

3) Organizations were happy to introduce new
innovative technologies on the left part because it was less critical compared
to the part on the right side of the pyramid.

 

In a way, this was a win-win. The advantages of this
solution were an excellent fit for the characteristics of the dynamic workloads
on the left side and the limitations of this solution (limited enterprise
maturity with associated risks) weren't really an issue for those types of non-critical
workloads. Well, you know what happened next. End-users started this
"journey" and there are now many organizations that are running SAP
virtualized.

 

That was the picture in 2003. How about now in 2010?
As I started working more closely on public IaaS cloud aspects, I have heard
many concerns and doubts that reminded me of those questions I was getting back
in the early years of this century. Can I move my core business application out
there in the cloud? How can I ensure that my own customers' data are protected?
Well I am sorry to rain on the party but, honestly, I don't believe these will
be the first workloads to move into the public IaaS cloud.

 

First, there is a technology argument. We are still
talking, by and large, about early offerings in the public cloud space. Similar
to what happened with ESX and with the overall virtualization ramp-up, we will
see technical improvements in public cloud offerings that will make it easier
to migrate critical workloads onto future stages of the IT infrastructure. This
doesn't mean ESX wasn't initially an enterprise-grade product. In fact, I
worked with a number of customers that were moving relatively important
workloads on to that platform, but arguably vSphere is a better and more mature
technology.

 

Other than that, we can't ignore another, probably
more important, fact.  Organizations
will want to take the time to learn what the public cloud is and will gradually
move workloads there. Most of them recognize the value of doing so in the same
way that they recognized the value of VMware ESX 1.0 when they first saw it.
This doesn't mean they jumped onto it overnight to migrate their core apps.

 

No matter how good the technology is (and while there
is space for improvement, it is good indeed) it will take time. You may want to
call it "fear of the unknown" or "risk management," but we
need to accept it for what it is. You will probably see me using these slides
again in 2010. I will just need to change the title to "The Public Cloud
(likely) Adoption Curve".