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.

Citrix has announced that they’ll be offering an alternative to traditional on-line VDI deployments (ala [Xen|Presentation]Server) in the form of a client hypervisor. In essences, a client hypervisor allows a user to run a full-blown virtual machine on their desktop — basically a throw-back to running VMware Workstation/Player in the enterprise before we had all these fancy virtual platforms like Virtual Infrastructure and Hyper-V.

Functionally, I’m a fan of this model: it allows users to work anywhere without concern about having an uplink. On planes, in coffee shops where there’s no Wifi or the connection is too small to reliably delivery a VDI experience, or even in the woods (solor panels for power optional). It also paves the way to true application virtualization, where the CPU-based hypervisor can be trimmed down to support running applications directly without the bloated guest operating system.

But this un-tethered model also brings up concerns, specifically around management. IT departments are going to have to face tough questions before deploying this type of technology. For example:

• How to deliver client VMs to users, especially remote users? Off-line via media or online?
• Change control: Will users be allowed to do anything with these images and run them like their own laptops? Will there be any type of reconciliation between the remote VM and a central policy source? How often?
• Mobility: Will users be able to transport these VMs between machines? Or will the VMs be bound to a single piece of hardware? If the latter, how will this be implemented and regulated?
• How are these VMs backed up and kept in state? What if the user drops the host (ie laptop) off the side of a ferry while finalizing her critical presentation just minutes before she’s scheduled to present (something a true VDI model would address)?
• In the case of remote users, what happens when the user “checks” their VM back into the corporate network when they’re at HQ?
• Remote access: Will these VMs be tied to a VPN solution? If so, how will that differ from how the host laptop/desktop connects?
• Policy management: How will tools like GPO apply to the host and guest simultaneously?
• Support: What happens when a user has a hypervisor-related issue? Will the support staff be trained to troubleshoot the host, the guest, and the hypervisor?

Many of these questions apply to any IT desktop policy, whether it’s a physical machine or a virtual machine. And to me, many of these issues beg the question “Are off-line client hypervisors worth the cost and effort?”  How does offering client VMs differ than just issuing everyone in the field a “normal” laptop?  In practice I’m inclined to agree with Kane Edupuganti on this issue:

We haven’t explored the idea of putting a [hypervisor] kernel on the devices, because you’d still need a regular PC.”

VDI solves many of the management problems listed above, but not all of them and also brings its own list of issues to the party (network, storage, advanced virtual platform management in the data center). There are security concerns for both models as well, but before we can address how to identify and solve security concerns, we need to be able to manage the environment first. If the goal is to make managing desktops easier and more streamlined, then I do think VDI is looking like a better alternative.

But I do think that the client hypervisor model is an important step towards pushing the computational tasks of running applications down to the client. That application hypervisor is getting closer, and steps to figure out how to manage local computing resources through a client hypervisor are all right by me. 

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.

For the most part, I’ve avoided talking about the current state of security in the cloud.  For one, there are many, many smart people and great bloggers already talking about it and I love reading what they write (and almost always agree with it, almost ).  And two, I spend a good bit of my day job (and have for the past 3 years) focused on the ideas around contextual-based access and security: security has different meanings and requirements depending on the context of how a particular service is accessed or invoked.  Now that’s some cool stuff, and the cloud access model is a natural extension of contextual-based access. You’ll see much more on this idea from me over the next year-ish or so.

Over the holiday break, I spent a good bit of time thinking about how and when cloud security was really going to become a watercooler issue (while playing Super Mario World on the Wii Virtual Console, ironically enough). We’re nowhere near there yet - heck, we’re still discussing the nuances of the cloud itself; we have to build that before we can worry about who or what gets in. But there a few anecdotal things that kept coming back to me:

1. In a previous life, I used to audit the security of data centers, from the physical rack and cage installations (even testing the man gates, now that was fun) all the way down to the network and applications.  I even conducted interviews of all DC staff, both enterprise and hosting, on what they knew, how they responded in the event of a breach, where root passwords were kept, all that meaty security goodness. My goal was to verify that a particular application was installed in the most secure running environment available, primarily to limit legal exposure should there be a breach against this application.  What I took from that multi-year experience: It’s extremely expensive to conduct these types of audits, and at some point the liability baton is passed to the people actually implementing the technology, away from those who designed it.  I could interview people all day, and spend weeks walking through their network, but once I left the premises and filed my report, it was up to them to stick to those procedures. We had to trust (in our case legally) that what I saw remained in place.

2. As I’ve mentioned here before, I own a small photography company, so small in fact, I use a cloud provider (for lack of a better term) for all our business documents, including balance sheets (very basic stuff: sold 10 photos, bought a new lens, etc). Before the end of the year, I was spending a nice, cold, snowy Sunday in beautiful downtown Bellingham at a local coffee shop where, over their WEP-enabled wifi network, I was working on said balance sheet, getting ready for the fun that is tax season. Me being extremely security conscious, I immediately noticed that the cloud App provider doesn’t use SSL to access my docs, and in fact, says they don’t even offer SSL unless I pay a much higher premium. Now lucky for me simply changing the login URL manually to HTTPS worked fine and I was happily encrypted. But I’m guessing I’m in the minority and most of their users won’t notice that they’re accessing what could be sensitive documents in a completely insensitive manner, or that it could easily be forced to work. Most users who got to step two would read the Help and see they had to pay for that service and then do their own value assessment: is the risk worth paying extra?

3. Amazon’s lack of security notification in their AWS mid-December, well documented by Craig on CloudSecurity.  A weakness in Amazon’s signing algorithm opened up the possibility for more-frequent-than-normal cryptographic collisions (yep, the same core issue that’s currently plaguing SSL CA providers who use MD5). Amazon did fix the problem, but it took them 7.5 months and they kept it under wraps, a very common response in the security world.

So noodling on these three things while on vacation led me to this realization: Cloud services are going to create a new level of trust between end-users, providers, and enterprises. There’s no way around it, simply because there are so many moving pieces to a cloud service that are outside our control.  There’s nothing in the world I could have done during the 7.5 months that Amazon was fixing their signing flaw except change my transport to Amazon, and I probably wouldn’t have done that because the issue wasn’t public and I didn’t know about it. Once I start sending requests into the AWS, I have to trust that the systems in place are going to work and work securely.

Now that’s a big leap: one that I wouldn’t make with a more standard computing model. But in the cloud model, we have to trust so many new components in the stack. Of course we can have safeguards (SSL) and checks and balances (pen-tests, people who responsibly disclose security flaws) but at a minimum, those require near unfettered access to systems that are no longer in our control and require knowledgeable people to address them. In my auditing days I had unfettered access, during a specific window of time. Once I was done my access went away, so even then there was no continual checking of those systems.

So moving forward, as the security people tear apart the (in)security of cloud computing, the rest of the world will just need to take that leap of trust. A lowering of our standards for what we can control in the cloud’s outsourced data model. As an end user it kills me, but I know I have to make those sacrifices if I want to use those services. So I have to modify my level of trust, and apply new and stronger safeguards to the rest of my workflow processes (personal and professional) to make sure I’m able to recover if/when there is a massive breach that’s beyond my control.  My recovery is something I can control, and I definitely trust myself.