The Virtual Data Center

In case you don’t have it on your RSS feeder list, check out the blogs by a few of my colleagues over at DevCentral. Lori has written two excellent posts (scroll down to find) recently on the idea of an enterprise cloud. I’ve given that some small press here but it’s definitely one of the most interesting parts of cloud computing to me. The whole idea of where the enterprise stops and where the cloud begins — be it with a more traditional VDC as outlined in the Maturity Model, or one that’s looking to keep everything internal but still offer programmatic services to internal groups — will be one of those big questions over the next 5 years or so. I actually think it’s already happening in larger enterprise data centers all around, we just don’t call it the cloud because we’re so stuck on the idea that the cloud has to be “somewhere else.” Anyway, Lori does an excellent job debunking that myth on DevCentral.

But two examples that I like to use when talking about how the cloud has already blown into the enterprise data center:

1. VM Chargeback: Chargebacks were all the rage last year as one of the key benefits to implementing virtual machines and moving towards a fully virtualized infrastructure. The idea is that one department in the enterprise, typically IT, will build virtual computing platforms for other departments and charge a per-computing fee for those services. For example, a software QA group may only need to test legacy environments once/year for major code drops. They own their own QA test lab for daily testing and for all minor releases, but it would be inefficient for them to maintain legacy or fringe operating systems like Windows Me for their annual testing. So instead, IT builds a virtual WMe farm and only spins it up when QA needs it once a year, keeping the virtual images spun down and archived on infrequently used Tier 3 storage the rest of the year. And they charge QA only when those images are in use. Once Dev finds out there is a virtual WMe farm available, they may want to test on it a few times/year as well, creating more revenue for IT. This is an application service cloud very much like Amazon’s EC2, except it’s 100% within the enterprise.
2. Single Sign-On: As intranet security finally becomes more of a recognized security threat (it’s taken 3 years, but I won’t complain and moan too much ), many enterprises are requiring that intranet sites be protected behind an SSO system tied to corporate authentication. Any department in the enterprise that puts up a new intranet site, such as Sharepoint or Wiki collaboration sites, must authenticate all users and track all access requests through the internal SSO system. IT owns SSO and no department has access to that or the auth directory on the back-end, yet each department is responsible for writing their new application to require this service. This architecture basically becomes a security cloud element.

So I do believe that the move to the enterprise cloud is going to happen and in fact is already well underway. The problem isn’t with writing remote services within the data center; like many things to do with virtualization, the problem is getting people to understand the ideas and not get all wrapped up in words and the terminology. Thanks Lori for braving the downpour and helping to weather the storm. I know, the cloud metaphors just won’t stop…

A few months ago, I wrote a paper and started pushing out this idea of a Virtual Data Center Maturity Model, a roadmap of sorts for you to map your current data center, with respect to virtualization technologies, to a progression plan based on your implemented levels of virtualization. The general idea is that there are 5 levels of virtualization maturity in the data center, ranging from a level 1, the most basic data center with “virtually” no virtualization through a level 5 data center, which is a complete implementation of Service Virtualization. I didn’t come up with these ideas on my own; they were done with the help of a few of my colleagues including Kieth, one of my co-VDC posters on this blog.

I also recorded a podcast with Network World’s Beth Schultz which was posted earlier this week as part of their New Data Center site. Rather than go into all the details here, why not take a gander at the podcast and content below and see what you think. How does your Data Center fit into the model today and what are your plans moving forward?

Network World Podcast

Other “Voices of Virtualization” and Network World content on The New Data Center

The VDC Maturity Model - Moving Up The Virtual Data Center Stack Whitepaper

The VDC Maturity Model Explained (A two-page handout for your wall )

Up next in the next day or so (taken with a grain of salt given my posting schedule lately): How do Cloud Computing and solutions like SaaS fit into the Maturity Model?

As has already been widely reported this morning, a bug in VMware’s ESX Update 2 caused more problems than it fixed, in fact it caused catastrophic problems. It appears to have mistakingly included a build time-out that impacted ESX licenses, ultimately keeping VMs from spinning up (no valid license, ESX won’t start VMs). I don’t want to trip the sprinklers quite yet, but I think I am going to tiptoe over to the closest Red Breakglass box and pull the fire alarm on this one. Oh yeah, this is bad.

We’ve talked it about here quite a bit, but ESX is basically a “Data center in a data center;” it’s a complete DC solution that offers systems, hardware, networking, management, security (in the form of VMs)…basically everything. And this simple software coding mistake was able to take down that entire DC platform for some customers. Imagine if your colo provider called you one morning and said “Um, yeah, we had a guy call in sick this morning so we just unplugged the entire data center. We have a backup person coming in soon though, so you should be able to turn on your machines in about 2-4 hours. We’re working on it. It happens.” That’s basically what VMware has done. And most importantly, there was no redundancy that could have prevented this (beyond a company not patching all of their hosts at the same time).

My first thought this morning when I saw this pop up was service providers: companies providing virtual hosting services to customers. These providers have SLAs in place for their customers and if a data center goes off-line for any amount of time, the end-customer isn’t going to be happy and is probably going to either walk from that SP or want a nice big refund on their monthly bill. When my broadband goes out for more than an hour during the business day I want a refund, and I have redundant connections for when that happens. I can only imagine how much this would cost a SP who pushed out the update on a large scale. Now granted, I’m sure that production houses using ESX didn’t push this out live, but what if the timeout bug didn’t show up for 30 days. Patch testing would have looked fine, then it would have been rolled out to production, then BAM!

Bottom line: this type of issue has the ability to cost customers (both SP and enterprise alike) a tremendous amount of money. We’re all putting so much faith on a relatively nascent technology in the grand scheme of data center things. You know that old phrase “Don’t put all your eggs in one basket?” Well maybe this is a good wakeup call for evaluating your VDC migration plan, and looking at ultimate costs, building a redundant failover plan for when this happens again once you’ve deployed ESX, maybe thinking as heterogeneously as possible, etc. It’s your data center; do you want to entrust it all to someone else without maintaining ownership and control?  And more importantly, can you afford to trust someone else, ’cause it could be an expensive gamble.