I’ve had the opportunity to spend most of June engaging with customers on topics related to VMware, NetApp, and Cloud Computing. While the experience was enlightening, it did consume much of the time I would normally take to blog. As it is, there always seemed to be a common set of discussion points that I thought would be great to share with a larger audience, so prepare the blog cannon and fire on my mark…
Taming the Cloud Monster
I’ll spare you the traditional opening around defining clouds. Suffice it to say, every customer that I engaged with maintained a different definition of cloud with respect to server virtualization. I did not expect any different, on that this continues to prove to me that one definition of cloud will not exist, ever. I think instead, a common understanding or reference will surface that we can point back to.
Those that I spoke to could, in the very least, agree that they were on journey as it pertains to their server virtualization projects. Many went so far as to say the cloud monster was just another unbounded manifestation from the offices that begin with “C”. And that with products like vCloud Director from VMware, clouds are stood up simply by installing the vCD software, making some vDCs and simply connect it to the finance department and you have an “as-a-service” IT shop.
To which I respond with: Have you seen the new cloud-enabled Swiss Army Knife? No? What about the new cloud-in-a-box product? No? Well, it is likely that you won’t, not for some time. Now, some would have you believe that it does exist, or that it is on the immediate horizon, but the truth is, it’s not. How can cloud exist today or be just around the corner—I mean, what is it? And there-in lies the rub: you see, “cloud” is really like porn: not everyone agrees how it’s defined, but everyone recognizes it when they see it.
Let me not overlook the fact that there are companies that are delivering cloud services (Amazon, Google, RackSpace, etc). And arguably they’re successful. You only consume and pay for the resources you ask, derived from a management and orchestration tool, based on what appears to be a flexible infrastructure. Isn’t that a cloud? Well, maybe, but, I don’t know the specifics of each layer—and I don’t need to. However, to truly be a cloud (in my definition), the orientation of service delivery must occur and be measured on three (3) distinct levels: the infrastructure, management/orchestration and the financials. External cloud consumption is easy—if the price is right you burst for the length of time you need those resources. Internal cloud adoption is harder because success hinges on the three orientations I briefly mentioned, and requires incredibly strong people skills. Why emphasize the later? Successful cloud adoption and implementation is an unending series of negotiations to affect a positive change in perception.
Naturally everyone wants a single infrastructure, available today, that provides you with everything you need to deploy a cloud—who wouldn’t want that? An infrastructure that internally contains all the components and interconnects to enable cloud/virtualization so you can host application-specific workloads isolated from legacy and siloed equipment in the datacenter. From the moment it lands on your loading dock, if the only effort you had to put forth was rolling it to the datacenter, then you would truly have the “Cloud Swiss Army Knife”. Your CAPEX and OPEX would likely improve in segments of time that are near-impossible to measure, not to mention the positive effects on your user community – ahhh Utopia or… Virtualutopia – like that plug didn’t ya. So back to the question—does it exist?
No…well, kind of…well, uhm, maybe it does…right?
The question I just asked is the root of the problem—“is there a single infrastructure?”. Within IT, we refer to objects as tangible items that can be manipulated and referenced; that can be provisioned and managed. The vernacular association between the “cloud infrastructure” and those tangible objects that make it up is crippled. You see, defining “infrastructure” depends on where you are in the stack. To the compute layer, the network and storage are the infrastructure. To virtualization, the compute, network and storage is the infrastructure. To the application, the infrastructure is the virtual machine it runs in, on the hypervisor that hosts it, based on compute, network, and storage components that support it. This is why cloud adoption becomes a series of negotiations based on the capabilities of each underlying component (physical and virtual) in the infrastructure presented from the point of view of who/what consumes it. You cannot sell the value of cloud, nor accelerate its adoption, based solely on the infrastructure that will provide the resources for it.
The negotiations that I am talking about are not the traditional types that occur between a vendor and a purchaser. Instead, these must occur between you and your peers, you and the application owners, you and your business leaders, and even you and the person that looks back at you in the mirror.
Here’s a quick analogy: When someone looks to purchase a car, what most look for are the characteristics and amenities they need from the car—they accept the fact that the underlying components will enable the car to travel from point A to point B. So how does the tie into the conversation? In this analogy, auto sales would not be successful if the salesperson started the engagement by trying to sell you a specific motor, a drivetrain, electronics, and then a series of modification parts that increase power and speed—no, they sell you a car based on your current needs and incentivize you with how the car will meet your future needs. And ultimately you value the car based on its ability to do just that. Now, I’m not suggesting that we sell cloud as one sells cars, but we have to overcome the problem we have in our industry: we continually focus our conversations and engagements on the individual components and that makes it nearly impossible to make cloud a reality.
The hypervisor capabilities are not what are being called into question here. Nor are those companies focused on delivering integrated infrastructures like NetApp’s FlexPod, HP’s Matrix, VCE’s vBlock, or the like. And not those “<NAME>-as-a-Service” providers like Amazon, RackSpace, GoGrid, etc. I’m talking about more than that—what I am really talking about is perception. In this series, I will do my best to arm you with the mental arsenal necessary to capture mindshare and affect the perceptions of cloud computing in those around you. Call it what you will, then goal in this 3 part series (based on my definition in bold above) is to enable you to get to a 100% virtualized data center — regardless of whether or not you want to turn it into a cloud.
Ready… Fire!
About Scott
