The Virtual Data Center

There’s a nice write-up at the New York Times site today about HP using their ProCurve line to go after Cisco in the data center. It’s a nice follow-up to the piece posted last week on Cisco’s play in the virtual server space.  This is definitely an interesting tug of war to watch, I’ve got my popcorn ready.

What’s most interesting to me is the way each of these companies is coming at this based on where they’re coming from. Here’s what I mean, and where I think each stands in this virtual fisticuffs:

• Cisco: They obviously bring the networking heavyweight to this rumble. No question they know L2/L4 backbone gear – speeds and feeds – better than anyone. And they have a vested monetary interest in VMware and are driven to bring these two technologies together; everybody wins in that scenario. The concern I have is that today, networking and virtualization (in the scope of virtual platforms and VMs) really are night and day. In fact, they’re not even the same ballpark, game, or sport. So this is a leap into new territory for Cisco. I’m not saying that can’t make it work or be successful, it’s just going to take a lot of work in both becoming proficient in virtual technologies and then delivering compelling solutions that integrate that newly created expertise into their networking arm. Cisco is also extremely divested already from a product stand-point, so will the market accept yet another non-core solution from them? What will it take for the Cisco name to be synonymous with application servers in the data center?
• HP: On the flipside, HP knows servers, and they know hardware management for virtual platforms extremely well. They’ve been working closely with VMware in the data center for years supplying solid, stable, and beefy hardware for products such as ESX. I think HP is a trusted name in the hardware server space for virtual platforms. But beyond that they also have ProCurve and a solid history of networking. They have resource virtualization experience with blades and chassis, they have WAN experience, they have management experience, and they have it (mostly) under one umbrella product line. So they bring a bit more to the ring than Cisco in that they have good experience and a name in both networking and virtualization.

So to sum, this challenge feels like a topic for the debate team on the colonial formation of the United States in the 18th century: both sides know their history, but one team also has the war buff who knows how war impacted the formation of the US. It feels like one side is stacked.

Now how this plays out in 12 months when the economy (hopefully) opens up and IT departments start looking at how all these siloed technologies in the data center can work together to provide new services while saving money…well, that remains to be seen. But in my view, the winner will be the company that figures out how map virtual platforms and virtual networking into a solution that makes sense, not a solution where these two disparate pieces are cobbled together. You can’t do virtualization in the data center without networking, but you can do networking without virtualization. Which giant walks out a winner depends on which one can marry those two into one solution that makes sense, that works, and that tells IT departments everywhere that they can’t use the cloud until they deploy this gear.

Douglas Gourlay wrote an excellent post yesterday over on Cisco’s Data Center blog about what doesn’t work in the current cloud model.  He had two great points. Point one:

And the most important point, about Cloud Computing is that it is in the cloud. and the cloud is the Internet.

This, to me, is one of the fundabmental problems with cloud computing that we need to address from the get-go, and why initiatives like Infrastructure 2.0 are catching on so quickly. We’re moving critical applications — and the back-end tools to mange them — out of our isolated, sadboxed, controllable enterprise data centers and on to the public internet. When someone in the office needs to access their newly-clouded sales app, they’re competing with upstream bandwidth against everyone else in the office catching up on YouTube and Twitter.

And the 2nd is in the comments:

Many people are astounded at the amount of data transmitted to support video, but that may be dwarfed by the movement of VMs.

Wow, that may be the best example to sum up the challenges with portable workloads I’ve read. Video streams content in a very deliberate way, video can buffer, video has bandwidth negotiation built in; copying straight VMs over TCP doesn’t, barring a technology on top of the connection for rate shaping. Pushing fully bundled vApps from vCloud to vCloud, with clusters of GB-sized VMDKs, across the public network is going to bring a whole new scale to “Start copy, get coffee.”  How these issues are dealt with from the DR and SLA perspective is going to be interesting.

Check out the rest of Doug’s post for the details. I’m exercising brevity on this cold Friday morning.

I’m back from VMworld, later than most. I took a detour out of Vegas and avoided McCarran (one of my least favorite airports) by driving back to the great Northwest through Death Valley, Yosemite, Oregon Coast. Sure, it took 4 days, but going from smoke-filled Vegas to hot, then cold, fresh air is so much better than just jumping on another airplane.

VMworld was an excellent show; much better than I’d expected. Most of it has been well covered by the likes of Hoff and Chris Wolf. Hoff has a few excellent posts that summarize the Cisco and VMware partnership and announced products. I don’t necessarily share some of his concerns or some of his plaudits, but it’s important to have differing opinions. Makes the world turn and all that, right? But I do have to very strong opinions on Cisco’s integration with VMware’s software switch:

1. The Good: Although its first incarnation (VN-Link) is more of a shim solution using VMsafe, I think Cisco building any switch functionality on/in ESX is an excellent move. We all know that the current vSwitch just ain’t up to par. VMware admits it’s nothing more than a L2 device, meant to move packets from the pysical interface to one of many virtual interfaces. Basically one big software CAM table and that’s about it. While VMsafe was launched with mostly security companies and the idea was to pass packets off to a guest VM for payload inspection, Cisco is headed in the correct direction in realizing that a packet has much more to offer in life beyond a malicious payload.
2. The Possibly Great, Possibly Not: If Cisco takes this idea beyond the [fast|slow]path implementation of the Nexus 1000v and starts looking to VMware’s VI4 release and what they’ve dubbed the vNetwork/DVN API, then we could be seeing a complete on-board Cisco vSwitch in VI4. Now that’s some cool stuff, especially if we start thinking about how a DVN vSwitch could impact moving services into the Cloud. Cisco knows how to manage L2-L4 (that’s about it; they blow when it gets to L7), but they know how to do it in hardware. The question right now is which direction will they go post VN-Link? Will they embrace the software side and go for a full vSwitch replacement? Or will they move more towards “let’s move the packets off of ESX and route everything to an off-box appliance”? I hope it’s the former. If they go the latter, what’s the point? Do your packet/session inspection _before_ you send it to ESX in the first place and you don’t need to pass it off-box. It’s redundant.
3. The Terrible: I’ve made no secret of my disdain for Cisco’s idea of converged networking. I think it’s just way too much to try to cram and manage every possible data center networking device and protocol in one box. At some point there are just too many clowns in the car and it becomes un-drivable. The Nexus series is well on its way to becoming the DC Jack of All Trades and Master of None. It’s taking us back to the days when we all had a generic *nix box at our perimeter that did routing, NAT’ing, IDS’ing, VPN’ing, etc. We’re to a point now in the DC where the tools we use are becoming extremely complicated, and to a certain degree, should be managed individually and independently so they provide the best service possible. Now if/when Cisco moves all of these protocols into a single vSwitch on/in the hypervisor (or even multiple distributed vSwitches across hypervisors) then they’re going to be further cramming resources into one giant cesspool.

So my recommendation to Cisco would be: Stick with what you do really well, L2-L4 IP networking, and let the people that do storage networking well do storage networking. By all means extend that L2-L4 knowledge and expertise into the virtual platform arena by working with VMware on building a usable and robust vSwitch, but stop there. We need a virtual data center platform that includes an enterprise-class virtual switch. But on storage…there’s already going to be a push towards storage VM appliances in the next few years; let them fail on their own without you mudding up the waters by trying to manage the storage network underneath that.

Oh yeah, I don’t like storage VMs either. Talk about redundancy…don’t get me started, at least not in this post. Maybe some other time, assuming I don’t throw in the towel and head back to the desert any time soon.

I know I’ve picked on Cisco’s Data Center blog a few times here, but they make themselves such an easy target, how can I let it slide? Case in point, this post from a few weeks ago called “The Dreaded V Word.” This posts starts on a good note: Doug jumps right into the hype of the “V Word,” although I think it surpassed SOA sometime last year both on the CIO hype scale and with companies claiming to have a buzzword of the year solution. This is one of the reasons I love answering the “Isn’t Service Virtualization just SOA?” question. “[Buzzwords] are colliding!! George is getting very upset!!”

But ironically enough, Doug actually makes the virtualization buzzword factor exponentially worse. Here’s how he defines virtualization:

“Virtualization as a technology rooted in the data center requiring network, storage and server to work together and thus drives IT collaboration. It allows the business to extend the lifecycle of capital assets they’ve already invested in and then reduce the operational expenses for remedial tasks (e.g. administrative change control, server batch moves, etc.) which allows them to free up more resources to focus on business critical applications and strategic new market entrances and such.”

Huh? Rooted in the Data Center? Drives IT collaboration? Extend capital assets? Reduce operations expenses for remedial tasks? Wow. Virtualization does all that? If I had a sales guy from a company come into my IT department and give me that answer when I asked him why I need to start looking at virtualization in my DC, I’d toss him out on his ear. That doesn’t tell me anything about what virtualization is, the problem statement, or the business benefit. Talk about using a lot of buzzwords. The term only becomes “dreaded” when you define it like that.

Wait, I just got it: now I know what Doug is trying to say:

• I call up my network guy (IT collaboration)
• Tell him to cancel the order for more Cisco switches (Extend Capital Assets)
• I’ve decided to consolidate in the DC (Free up resources)
• And move all my L2-4 switching over to all those awesome Application Delivery Controllers I just bought (Reduce OpEx for remedial tasks, ie switching)

Seriously, I couldn’t agree more that we’re still dealing with the virtualization buzzword, but to address the issue from a company like Cisco, who obviously has vested interest and virtualization technologies in the data center, is really a bad idea. And then to throw in Green IT and “Data Center 3.0″ all in the same post…a term you know I can’t stand. Did no one at Cisco cleanse this post before it went out or pass it through the Buzzword BS Meter first?

And while we’re at it, have you seen one of Cisco’s other blogs, Virtual Worlds, or basically their Second Life Marketing Blog? If I was new to data center virtualization and I wanted to get Cisco’s take, from their blogs I would think that Cisco is one big publicity company that’s more concerned with marketing names, buzzwords, and playing virtual games than the infrastructure of my Data Center. I know that’s not the case, and I know they have some deep virtualization technologies, but that’s the face their presenting through these blogs. It’s one thing to spout poetic on a personal blog; it’s something completely different when your spouting via a domain named blogs.cisco.com. I hope someone in the Technical Marketing team over there is reading this and their own blogs.