I recently had a conversation with Paul Divittorio, EMC IT’s Director of Enterprise Systems and Application Hosting Architecture. He’s the guy responsible for designing the next generation hosting platforms being installed in our production data centers here at EMC. When Paul is talking with EMC customers about our IT organization’s journey to Private Cloud, he’s often asked about Vblock. Where does EMC IT think it makes sense to use it? Where is EMC IT using it now?
Before we get into this, let’s set a bit of context.
There’s an easy tendency to think of Vblock as some kind of product you buy and deploy—and voilà! Instant Private Cloud!
That’s not, however, what Vblock is about. It’s not a product at all. Neither is Private Cloud. We’re using the term “journey” on purpose; Private Cloud is a desired state, a destination we want to get to.
Our journey began, as it has for many others, by virtualizing our systems. EMC IT set a bold goal of 100 percent virtualization on Intel architecture (see this post and others for more on why). Where is EMC IT on the path toward this goal? We’ve virtualized 60 percent of our servers and 65 percent of our mission critical applications so far. We’re just getting started on desktops (I’ll be talking about that again in another post).
What, Then, Is Vblock?
IT shops that, like ours, have gone “all in” on virtualization, started asking a simple question: what an infrastructure that’s purpose built for a fully virtualized environment look like? Would I want to use it in my data centers? Can I use it to get to a Private Cloud infrastructure?
We designed Vblock to provide an answer to these questions. It’s a new choice for building “all-in” virtualized environments: a pre-integrated package of best-of-breed components, with a single point of contact for solutions and support.
Vblock is not, however, the only choice for fully virtualized environments—or for building Private Clouds. You can get to your destination multiple ways, using different combinations of technologies. For example, you can continue to buy, and deploy infrastructure components à la carte like most IT shops today. We suggest instead that you can use integrated Vblocks as a new kind of data center “building blocks”
At this point, you’re probably wondering, “does this thing have an order number or not?” Sorry, but there’s no single product SKU. Vblock is a reference architecture. “So, how do I buy the things?” One of three ways:
Multiple P.O.’s, single support contact. As long as they are verified as part of a Vblock reference architecture, you can buy all the individual piece-parts, and still have your Vblocks supported with a single point of contact.
Single P.O., single support contact. You can purchase complete Vblock packages from one or more VCE Coalition partners.
A Build-Operate-Transfer service. Or, if you would rather rent than own, you can look into Acadia.
Another question that frequently comes up: “can I continue to use the stuff I have today in future Vblocks?” You bet. As long as your equipment is part of Vblock reference architecture, it can become supported as part of Vblocks you build later on.
Vblock and EMC IT
Now that we’ve set the stage, let’s return to our scene with Paul Divittorio. Where does EMC IT see Vblock as useful? Where is it used today?
Paul lists three kinds of situations that EMC IT has found to be a good fit for Vblocks so far:
New applications. These provide a much easier—and less risky—place to start, as opposed to rip-and-replace scenarios. A ready example within EMC is the new virtual desktop infrastructure (VDI) we building at EMC, which Paul describes as “one of our best use cases for it.”
Vblocks will also serve as physical home for hosting our virtualized, next-generation Microsoft Exchange Server 2010 environment. We’re currently running Exchange 2003 and 2007 in production. EMC IT will be rolling out Exchange Server 2010 late this year or early next.
General Hardware Refresh. The idea here is to take advantage of scale-out Intel architecture and migrate from legacy Mainframe, Unix and other platforms. EMC IT will use Vblocks as the default hosting platform for the company’s general-purpose VMware clusters.
These clusters become EMC IT’s home for our company’s general-purpose applications. We’ve been running VMware since 2004, and have gone through several VMware cluster design iterations, each containing various software and hardware revisions—all using “pizza box” style servers. We may still need to run some physical configurations like that, but we’re standardizing on UCS blades in Vblocks as the new default platform.
New Data Center Build. As I described in previous posts, we’re building a new data center in North Carolina. Virtualizing everything, and enables us to simultaneously accelerate server, network and storage consolidation. We’re building out new blocks of infrastructure, some Vblocks and some similar to Vblocks, and migrating our applications—in other words, moving virtual machines—“over the wire” from our old data center to the new one.
No doubt you’ve noticed the last two examples aren’t all-in on Vblocks. Does that mean EMC IT isn’t really all-in on VCE architecture—or, for that matter, Private Cloud?
Not at all. Vblock offers a new kind of data center modularity, but it isn’t appropriate for every purpose. Not everyone can—or will—give up the flexibility of building and operating individual infrastructure layers and components.
And there’s nothing wrong with that. The point of Vblock is to provide a pre-integrated “building block” that contains pooled storage, pooled networking, and pooled compute resources. But if you prefer architectural control—and management responsibility—over interfaces between those pools, or even implementations within those pools, you can certainly do that.
In other words, you can build a Private Cloud by hand. At EMC, we think we provide the best pooled storage, and our friends at Cisco and VMware provide the best network and compute pools for private clouds. But you’re not restricted to only those choices.
And, as we’ve said over and over, Private Cloud architecture is all about choice.
Solving Tomorrow’s Problems
Of course, our IT folks also face some interesting challenges. Some big hurdles appear to be technical—at first. EMC IT’s priorities, for example, include “increase IT agility” and “architect for the future.” Getting wrapped around the axle over what these mean can, however, become a huge stumbling block.
For example, there’s a concern over whether we’d be able to non-disruptively migrate virtual machines across multiple Vblock “frames.” For Vblock Type 2, that means migrating across multiple Symmetrix V-Max systems. Wouldn’t it be better to design a single, centralized SAN instead? Isn’t that the best way to both increase agility and architect for the future?
Not necessarily. Increasing IT agility also means embracing “good enough” in order to get new services up and operating more quickly and easily. We don’t do cross-frame migrations in our VMware clusters today. More important, new ways of addressing this particular problem are coming in future versions of the products we use in Vblocks—and we’ll likely have those capabilities by the time we really need them.
Really? You 100-percent certain of that?
Well, no.
That’s a tough point to argue, of course. I don’t know anyone that can claim 100 percent accuracy predicting product roadmaps. (If I did, I’d be in a whole different business!)
Here’s the thing. Balancing today’s capabilities and needs with tomorrow’s is the kind of judgement call technical decision makers face all the time. In this case, we’re talking about trading Vblock modularity for the greater flexibility—and complexity—of structures we’ve been building building and running in our data centers for years. From Paul’s point of view, which I happen to share, “architecting for the future” should mean more than “solve tomorrow’s problems with today’s technology.”
But, as many customers Paul and I have spoken with also predicted, the greatest challenges on our Private Cloud journey will probably have more to do with people than with technology.
What’s your virtualization/cloud adoption experience been like? What challenges have you faced? How did you deal with them?
As always, I welcome your thoughful comments.