The Virtual Data Center

For some strange reason I choose to work even when I’m not working and have what some could call two jobs (well, one real job and another job that supports itself, anyway). My day job is what you see here: helping to change the way people think about and implement virtualization in their data center. My moonlit weekend job that doesn’t quite pay any bills (yet) is professional photographer. To date, these two worlds haven’t had any relation or overlap at all (although I did take the main picture you see in the blog header, which is a shot of freshly installed data center racks, so maybe that counts). Last night, however, my separate professional lives collided in a storm I hadn’t witnessed before, and I felt rouge waves on both sides.

As has been widely reported, Amazon’s S3 service was down for a good while on Sunday, July 20th. I don’t personally or directly use their service (although I do know of individuals who are looking into it as a safe and secure backup system), however I do use SmugMug as my back-end photo “store” and processing lab for the pro photog business and (as I learned on Monday) SmugMug uses S3 for all of my valuable and (hopefully someday) bill-paying photography. I have my own local backup systems that I manage (more on that some other time) and I don’t rely on SmugMug as my content storage house, but I do rely on them to make my photography available for purchase (always available, always fast, and always securely). But I don’t want to know what they use in their data center or how they manage and store my content; I only want to know that my content is safe and available. And all was good in the fields until Sunday evening when S3 went down, and took SmugMug (and all of the pro photographers they support) down with it (details available here).

So on Monday morning I began looking into the S3 outage for the Day Job and just happened to see that my Night Job was impacted by the outage, and that got my head all spinning. It got me spinning primarily because this is the 2nd outage that S3 has suffered in the past few months, and that’s big business for a lot of people beyond SmugMug. For most normal enterprise IT shops that kept their storage in-house, a critical outage and unavailability of dynamic data twice in such a short amount of time would cause the higher-ups to start asking questions about what, why, who, and how to make sure this never happens again. I imagine those types of questions are happening for large-scale S3 customers, like SmugMug, all around the globe.

The other reason I got so spun up was the response, or lack-there-of, from Amazon. As far as I can tell, the first reports came into their public forum from customers in droves reporting a “Service Unavailable” error message. Shouldn’t Amazon have known before the customers, and shouldn’t they have done a better job (beyond posting a green/yellow/red dot on a service page) notifying all their customers? Does SmugMug really want to find out about a storage outage when they try to retrieve my galleries for perspective customer, or would they prefer to know before hand so they don’t let their app spin indefinitely? Or here’s a novel idea: Perhaps Amazon should architect their storage service in an HA/DR manner so that a customer never sees a “Service Unavailable” message, or more importantly so that their service never goes down beyond a simple blip while service requests are redirected. Highly available data centers ain’t rocket science, and since Amazon is building VDCs like nobody’s business, perhaps they should already know this…

I don’t want to be too short or critical here, but f anything, Amazon is blazing a trail in the Clouds on how not to build a production-class cloud service. The core requirement for offering a cloud service has go to be availability above everything else. Otherwise there’s no reason for a customer to trust the service with their mission critical data. My Night Job customer persona is hoping that SmugMug is really sticking it to Amazon for taking them down (and at the same time making sure all their own eggs don’t fall off the tree when the S3 nest crashes again).

I think I’m going to write Amazon’s regular storefront customer service and ask for a credit in their MP3 download store to compensate for all the money I lost by not being able to sell my photographs while S3 was down. Think they’ll go for it?

I just read an interesting post by Craig over at Cloud Security about Second Life avatars that can jump from one “grid” to another, and then watched Michael Thumann’s discussion on hacking the SL software and platform (which to me is somewhat different that using the built-in tools to escape the bounds of confined grids, but I’m willing to be wrong on that). Now I know virtually nothing about the architecture in Second Life, and I’d like to keep it that way. I have something in my core that fundamentally disagrees with Second Life so I stay away. However, voyeuristically it is interesting to read about people who don’t agree with my opinions and do play around with SL. Everyone has a hobby.

One of the interesting items from Craig’s post is the implied association he makes between SL and the cloud, linking the security of virtual worlds to cloud security. Maybe he didn’t mean to make this association (although the post is called “Collaboration in the Cloud,” so I have to assume) but I’d have to disagree with this association for a number of reasons, primarily the use of the term cloud in relation to anything consumer driven. I know, I’m a stickler for using the right word to describe the right thing; what can I say? Someone sitting down and logging into Second Life isn’t logging into the cloud, they’re logging into a MMOG to play a game, not to invoke a cloud-based service. This would be like saying every time I log into my online banking site I’m invoking Cloud Banking. I’m not. My banking site may be calling methods and functions from the cloud, but I don’t see that. I see a web page.  Or when I pull up my cable DVR’s “On Demand” option; this isn’t called the Cable Cloud or the VoD Cloud.  Just because it sends a packet outside my house doesn’t mean it’s a cloud service.

Maybe it’s took picky, but I think this is how technology terms are co-opted in the first place and become way too overused. Cloud Computing has a very specific definition, as does Cloud Security. But there is no such thing as Cloud Gaming (nor Cloud Banking), and just because an internet-based game has security flaws doesn’t mean that those are Cloud Security issues. They’re just security flaws in software. The first time an analyst asks me my opinions on how Second Life is impacting the cloud or Cloud Security, I’m going to literally blow a gasket, right there on the floor, and coredump screaming “Does not compute!”

Enterprises and Service Providers have a Cloud; consumers have the Internet. They’re not in the same ballpark, not even in the same freakin’ game. Let’s call a spade a spade and the cloud the cloud. Or maybe I’m just grump because it’s Friday afternoon and 72 deg outside in the Pacific Northwest and I’m inside reading instead of relaxing on the beach with my dog, picking out Cloud Animals.

Wow, has it really been almost a month since my last post? Goodness…first and foremost, I should apologize. I have no excuse for the lag beyond being heads-down working and contemplating the virtual universe. No vacations. No burning the midnight oil for weeks at a time. Just working. Although I do love my job, so maybe I can just default to “Time flies when you’re having fun” and realize that I’m getting older and everything sweeps by faster now.

And during my silence, I’ve also been fighting with Vista issues across the board. Not all Vista’s fault, but still all Vista related. However, even though I may fault Vista for their heavy reliance on the GUI, my biggest problem these days is with VMware Fusion on the Mac (Why do these virtual platform vendors frustrate me so? Am I alone?). The thing that gets me is that I’m the target market for these products. The marketing and product is geared towards me, and yet they still can’t deliver a product for the professional IT administrator.

The first thing I did with the MacBook after it was up and configured was install Vista via Boot Camp, which kicked ass! The speed was amazing, and so far, everything has been running very smoothly (although I haven’t tested BitLocker yet, which is my next big endeavor and a requirement for me). The only downside is the dual-booting. My goal is to eventually go 100% MacBook, but my work environment has to stay MS focused. So dual-booting is an option, but not an optimal. Enter VMware Fusion 2.0 Beta, which can run a Vista Boot Camp partition in a VM environment. Good idea: I can keep my OS’ isolated but still access my work environment from any running state. If I’m working all day, Boot Camp; if I happen to be in Leopard but need to grab something from my work environment, no problem. But it just doesn’t work that way.

For one, Fusion doesn’t support 3D acceleration. Now this may seem trivial for the non-gaming work environment, but unfortunately Vista is so dependent on graphics for everything, having a less-than-stellar graphics driver in Fusion takes the entire VM down to a crawl, either when running in full mode or with Unity. Office 2007 applications take in the double-digits-to-minutes timeframe to launch. Using the Vista Performance Meter, all other hardware is on-par with the screaming Boot Camp install, so the video driver is responsible for slowing everything down. Makes it unusable. VMware’s marketing for Fusion 2.0 wants you to believe that you can run 3D games on multiple monitors, but not with Vista, only XP. And if I dual-boot into Boot Camp, I have to manually re-run the performance meter because it keeps the VMware driver score as the baseline, which takes my Boot Camp install down from a 5.2 system performance level to a 1.0. Re-running fixes that when the perf monitor loads the Boot Camp video driver, but it’s a manual process I have to do every time I dual-boot. Which leads me to…

And then the licensing issue, which to me is a huge one. Boot your Vista install as a VM and then boot it natively with Boot Camp and your install becomes unlicensed. Microsoft thinks you’re trying to steal money from their food fund, dogs start living with cats, the world is in chaos. You can re-enter your license key and it re-registers fine, but that takes time and requires you to keep a copy of your key handy just in case you need to hit Boot Camp for any reason (ie a presentation). This is supposed to be fixed by Beta 2 or RC1 so we’ll see.

So here I am, unable to reach my vision of running one platform for all my needs. Now I’ve talked here before about how I just want to run one physical machine and virtualize everything else, mainly my apps. I don’t want to have to choose between multiple OS’s, or Office 2007 running in a VM over Office 2008 on Leopard. I just want to boot then run. But all the local virtual environments I’ve tested so far have failed me. We’re just not there yet. VDI doesn’t help me here either b/c I can’t rely on an upstream connection. I want complete cross-platform virtualization locally. Is that so wrong?

So maybe that’s why I haven’t posted in so long…the virtual market is failing me and I don’t want to face reality. And now I’m depressed and need a minute. I’m going to mount my virtual storage NAS over my wireless VLAN and play Another Somebody Done Somebody Wrong Song in hopes that someone else’s pain will make me feel better…

Once my brain starts spinning around one particular topic, it basically stays there until I’ve reached some sort of mental closure. Now that closure may be achieved when I’ve reached a personal conclusion, or it may come when I throw my arms up and say “I’m out!” Either way, I need to keep processing something until I’ve reached one of those points. This week, it’s the overlay between VMs, VMDK/VHDs, and OVF, which I started a few days ago with this post. So here I am again, and now I’m wondering if there’s even a point to OVF.

As reported at Server Virtualization, the DMTF is saying that OVF is still a few months away from a standard. Now a few months may not seem like a long time, but there are going to be some big movements between now and then, depending on which projects release on time and which are delayed, most importantly we should see Hyper-V moving out of beta. Chris Wolf has some interesting comments on that post and to be honest…I just don’t get all the fuss. Mounting VMs so any hypervisor can run an application? Telling the hypervisor what the packaged VM OS needs in order to optimize the running environment? It just seems like too many steps to get to the endgame. Here are two examples where I think OVF is just going to get in the way:

• Converting VM Disk Images: Chris states that even with OVF (right now it’s just a packaging framework standard, not a runtime standard) an interim conversion step will most likely be required. So when I grab a pre-packaged VM appliance from VMware wrapped in OVF and decide I want to run that on Hyper-V, I’m going to have to extract it, do a full conversion (which amounts to running P2V, or V2V in this case), and then re-wrap it before I drop it on Hyper-V. Hypervisors are platforms, and every hypervisor is going to run VMs in a different manner. Running 2008 in Hyper-V probably won’t take as many hypervisor resources as running it on VMware simply because 2008 shares kernel code with Hyper-V. So my app on 2008 will require X resources for Hyper-V but Y resources for VMware. Then what’s the point in packaging that data with the app? Is OVF going to have an XML switch element that contains running information for every possible hypervisor scenario? If I’m that concerned with app performance, I’m going to build the VM and app natively and not trust two translation layers (the original hypervisor the VM was built for and the OVF management metadata to allocate resources for me). To me, this is pushing OS virtualization further away from production environments.
• Lose the OS: OVF and virtual appliances deal with full-blown VMs; the OS, the disk image, and the running hypervisor. But we’re making such strides towards true application virtualization these days, I don’t see the need to focus on a solution that’s only concerned with bloated OS and disk images, pieces of the virtualization puzzle that only exist to run applications. I’d much rather see work being done on something like APS (Application Packaging Standard). Unlike VMs and VMDKs/VHDs, applications truly are portable. I’m looking forward to the day when we don’t need a full-blown OS in the data center, where we run apps directly on a hypervisor, where a packaging solution like APS can really be valuable. But even until then, something like APS has more value today because it’s “future proofing” our solutions for tomorrow. With VMs, both the OS and hypervisor have to become hardware resource managers. With true application virtualization, you only need the app hypervisor to manage your resources.

So why OVF? Why not let the DC admins worry about the hypervisor and OS installs? These are platform decisions, just like choosing HP vs. Dell. You don’t see Microsoft offering a pre-built 2003 image installed on a Dell with a conversion utility to run it on HP hardware (more on that in a few days as I start to drift into the problems with P2V…stay tuned) because that wouldn’t make any sense. OVF is the exact same thing: it’s a system to create a full-blown OS image and move it around the heterogeneous data center. But why? Every OS install is different, and it will continue to be that way until we get rid of the OS, even with major band-aids like OVF. Focus on the application and why you’re virtualizing in the first place. Right now, OVF appears to be an extra step we don’t need.

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.

I know, it’s been quiet around here lately. I’ve been heads down in research and haven’t had a lot of time to digest new ideas and pick up old ones (or respond to Hoff ). But the Symantec+Veritas+Xen announcement today gave me good reason to poke my head up, log in, and revisit an idea I’ve been working on for a while.

When I’m not noodling virtualization and data centers, I’m a semi-professional photographer; most of my evening/weekend free time in 2008 has been spent on building a solid digital workflow from shooting to selling. One of the technology choices I’ve implemented in the middle of my workflow is converting from my camera’s proprietary RAW format to the Adobe’s open Digital Negative file format, DNG. I made this decision because I don’t want to be stuck fighting with specific RAW format support down the road, and I can edit and process files natively in DNG using Adobe tools, which I use already. So you could say I’ve “Future Proofed” my workflow for tomorrow, even if I change cameras or processing software.

So the above started me thinking a few months ago about virtual machine filesystems and what’s going on under the hood. The whole model today seems silly to me: I have a VM guest that has filesystem, say NTFS; that filesystem is packaged in a proprietary flat-file format for the virtual hypervisor platform, VMDK in VMware’s case, and that flat file is stored on top of another filesystem (VMFS, again for VMware), which is vaguely connected to the host OS filesystem (let’s say ext3 for ESX), and then layered on top of yet another file management tool with iSCSI, only to finally be stored on a real disk on a SAN. So my ‘index.html’ file hosted on my guest IIS VM has to go through approximately 6 virtual<->physical layers before it’s physically stored on a device that can manage that block data, such as VMware’s DRS. That seems excessive and very inefficient.

So that brought up two questions:

1. Why can’t we have a solution like DNG for VM filesystems that will allow me to take that flat-file and manage it as part of my virtual infrastructure on any platform? Granted we do have the OVF, but this is mostly a transport and packaging solution; it’s not a running solution. And yes, I know that disk formats are part of each hypervisor secret sauce, but that’s exactly what I’m suggesting: Let each vendor continue to refine their secret sauce (just like Nikon and Sony will continue to refine their particular flavors of RAW), but let me store and run that secret sauce in an open utility so I can simply click to push a VMDK from VMware to Hyper-V.
2. Beyond the above, do we even need that extra secret sauce filesystem layer at all? Why can’t ESX write directly to a block device in my SAN over iSCSI without storing my guest filesystem in a flat package that’s stored on VMware’s proprietary VMFS file system, only to be pushed out over an iSCSI network? If we’re going through so much trouble to virtualize the OS anyway, why can’t we simply write a translator that takes the guest block read/write request and map that to a physical block on our remote SAN/NAS disk? Basically, let’s virtualize the guest filesystem. Think about the I/O we could save…may make those VMware storage benchmarks near moot. Which leads me to…

The Symantec announcement. If it’s true, it’s exactly what we need in the VM storage space and a no-brainer. Anything that removes middleman components while also adding manageability is a great thing. We remove moving parts, which in itself can remove complexity, and then obfuscate the management (or probably integrate it an existing management platform)…we move <this much> closer to a functional VDC. And since it’s Xen based and is purported to work with Hyper-V, this could also be a driver in customers choosing one hypervisor platform over another. If it delivers and specifically doesn’t work with VMware ESX, VMFS, Virtual Center, etc, then it could be end up being a platform driver for Xen and Hyper-V. We’ll have to wait until the end of the year to see if this solution delivers as promised.

I’ve read two posts in the past few days that spin around the idea of how the network factors into a complete security solution. The first from Hoff goes after the concept of moving security management responsibility to the network; the second from Richard over at TaoSecurity covers terminating SSL at the perimeter and moving your trust network closer to the edge. Being a guy who started on the network and moved up the stack, both of these posts gave me heartburn for different reasons.

First, Hoff: No one..er, no sane one, anyway…is suggesting that all networking management tasks be relegated to the network, anymore than anyone is suggesting that virtual security solutions (such as firewall VMs) are going to be the be-all, end-all security touchdown for both virtual and physical platforms in the data center. Hoff knows better than anyone that there is no smoking gun, and no one is suggesting that In The Year 2000 the network will own all of your security. I love Hoff’s “All My Life’s A Circle” security model, but it falls victim to the same thing that he’s railing against in the first place: There is no one security solution for everything in the data center at any given time. These solutions, regardless of where and when they fall on the cyclical time scale, should work together to provide one unified security solution, with the appropriate emphasis for any one solution being placed on the appropriate technology. We may fluctuate that emphasis, but we’ll always look at the entire solution. SSL is an application security solution, yet it is an integral part of a complete network security solution and the network can play a major and critical role in managing secure application transport and policy enforcement. Which leads me to…

Second, Tao: The interesting thing to me with this post is the assumptions that are made. You don’t have to terminate SSL only at the perimeter, nor do you have to do it passively. You can terminate SSL anywhere in your network, be it at the edge in a border device, within your DMZ or at the DMZ/private edge, or even completely within the private network. It all depends on what you’re cracking SSL to look for. If you’re looking inside an SSL VPN connection coming into your network before it hits the firewall, yes, you want to look at it as soon as possible. But you can still examine the traffic in your existing “trust zone” by moving and sandboxing that connection into a secure location, terminating SSL, examining, and if clear, re-SSL’ing and passing it back into the untrusted network. There are all kinds of great examples on how to terminate and sandbox encrypted traffic for firewall inspection, even at near-line speeds with modern SSL termination devices. If you want to crack SSL for your apps, do it completely within your DMZ or trusted private network where your apps live, far from the edge. And to Ivan’s question (which I personally thing was self motivated by the company he works for), it doesn’t have to be passive. For complete trust and control, actively terminate at the device with different keys than you use on the backend. Let the user know you’re doing this, no need to be coy about it. Actively terminate SSL to inspect it, don’t simply bridge it. You end up being your MITM.

So long story short, the network is an extremely powerful tool in your complete data center security batbelt. It’s not the only tool, but it’s also not a tool that should be taken for granted. In other words, don’t commodotize your network (or anything in the DC for that matter) or the security resources you can use on your network. Make the network work for and with your security tools. Packets and data are just electricity; you can do anything you want with them, including using your network to help secure them. Take off the silo blinders and look at what you can do at every step in your DC with networking and security. You’ll find out you can do some really cool stuff…

Ok, I was going to hold off on posting anything until I was back in the home office next week, but a post over at CNET by Jon Oltsik called “The real issue around server virtualization security” caused a minor ulcer eruption in my core being and I had to let out some steam.

First off, the good: Jon is correct in the 2nd half of the post that the primary threat today is virtual infrastructure management, and how to integrate virtualization into our existing physical data centers. Management is the #1 issue that’s keeping us from fully moving to a complete Virtual Data Center. Before we can virtualize everything in our data center, we have to guarantee that we can manage it just like we can today with physical resources. So yes, Jon did have something good to say.

But unfortunately this is outweighed by his complete incorrectness on devaluating the security risks associated with virtual platforms. He uses the argument that since there hasn’t been an exploit ever against a virtual environment platform then you shouldn’t worry about it:

Starting with IBM and virtual machines on the mainframe, there hasn’t been a single compromise at the virtualization operations layer that I know of.

This has 3 problems:

1. This is the exact same argument we faced 3-4 years ago with Web Application Firewalls (WAFs), and look where we are now. PCI not only includes a clause that specifically addresses WAFs but they’ve recently released a clarification document on what it means to use a WAF within the PCI guidelines. 3 years ago, that would have been unheard of, because we didn’t have press every other week about web application vulnerabilities. We do now, and of course everyone is cramming to install a WAF in front of their apps and we’re inundated with reports of identity theft via applications (in state or over the wire). Had those customers evaluated and been conscious of their risk up front maybe they wouldn’t have been open to all those SQL Injection and XSS attacks. Risk Management is all about planning, not reacting.
   
2. Yeah, IBM virtual machines on mainframes have been around for a long, long time, and there hasn’t been a public exploit since day 1. However, any homegrown hacker can’t simply download the IBM virtualization solution in 3 clicks and beat the hell out of it in her basement for 6 months just to gain virtual street cred. It’s a different time, Jon, and everyone has access to all three major x86 hypervisor platforms today for free (and with Xen, they even have source). And she knows that every enterprise in the world is looking at x86 virtualization right now so her addressable insecure market is limitless. There’s more incentive to hack VMware’s hypervisor than IBM. It’s simple hacker economics.
3. No compromise of the “virtual operations layer?” I would disagree, as I’m sure VMware, Xen, and Joanna would. Has there been a mass (or at least public) “ownership” of a major x86 hypervisor yet? No. Does that mean there won’t be? No. A comet hasn’t hit the earth and destroyed all mankind, but we still have people watching out for it.

Long story short, it is a disservice to tell the public not to worry about virtualization security threats. Is it a good idea to tell people it’s so insecure not to implement it? Absolutely not. But to tell people “Nah, it’s all good; there’s nothing to worry about with security. I’m sure it will be fine; these aren’t the droids you’re looking for” is just plain wrong. You should always be prepared, and aware of your possible threats and risk. And adding another processing and computing platform of any type to your data center does introduce a risk metric. Is more likely that someone is going to take down your data center through your hypervisor than because of a natural disaster? Probably not. But at least ake sure you measure that security risk and metric and don’t ignore it.

I’m headed out to take the VDC message on the road next week. This trip will be focusing on the business benefits of “Future-Proofing” the Data Center and blowing out the smoke that the vendors are telling customers today. The basic premise is to architect your Data Center and your long-term Virtualization plan around your applications, not around single-point virtualization solutions like OS virtualization and the hypervisor. I’ve been working out the kinks in my “VDC as a Service Model” presentation, and it’s almost ready for primetime, so it’s going to be nice to focus on the business benefit of the VDC on this trip and talk about what happens after you adopt the Service Model.

I’m sure I’ll come back with all kinds of stories, rants, suggestions, etc…

Sticking with the Cloud theme-of-the-week, I just read Diane Greene’s, President and CEO of VMware, comments over on Server Virtualization Blog about Cloud Computing. Yep, everyone’s talkin’ about it. Here’s the paragraph in particular that struck me:

Greene told the event attendees that the evolution of virtualization begins with users deploying VMs for testing and development, then easing into server consolidations for production environments. The third phase is resource aggregation, with entire data centers being virtualized, followed by automation of all of those aggregated workloads. The final “liberation” phase is cloud computing, Greene said.

Here are my two problems with this statement:

1. Phase 1 and phase 2 towards Cloud Computing are virtualizing Operating Systems. Ok, they’re the easiest part of the DC to virtualize and the most virtualized component to date, I’ll give her that. Then phase 3 is the entire data center being virtualized? That’s quite a leap. And then we just have to automate the VDC and “liberate” it and we’re there? What’s automated? What are we liberating? And more importantly, who says Cloud Computing is liberating?
2. Data centers are much, much more than just operating systems; we all know that. She’s basically lumping everything but the OS into “resource aggregation.” But what resources? What about all the other components in a data center? And of course I love how everyone talking Cloud today conveniently omits the network, which is (by definition) the backbone of Cloud Computing.

She’s basically saying “Create Virtual Machines, use them in production, then you’re ready for Cloud Computing.” Talk about your 30,000 foot view. If only it were that simple we’d all be passing packets in Cloud City already. But it’s not that simple.

And to disagree with her comments even further, I don’t believe that the virtual OS is going to be the driver to push people to the Cloud. I mean do we really care what the OS/platform is? No; we care about the Applications. I don’t want to issue a request to my Cloud vendor that says “I need SuSE v10 running kernel 2.6.25.4 with glibc 2.7 and…” I want to ask for Oracle with 10TB of available storage. Great. Done. I don’t care what OS platform (physical or virtual) they standardize on, I just want my apps to be fast, available, and secure. Cloud Computing is so interesting because it takes a good bit of the daily burden, such as OS management, off of ITs shoulders.

I know VMware has a vested interest to keep OS Virtualization at the forefront of the IT mind, but eventually even VMware will have to acknowledge that our data centers are very rapidly moving away from “OS Centers” and becoming “Application Centers.” But then again, the VMware Virtual Appliance Marketplace is up to ~1300 VMs; full operating system virtual images almost all created to distribute applications. If I want to test 10 apps, I grab 10 OS images. Seems silly if I’m just testing the apps.

Until the market tells them otherwise, I guess VMware will happily continue to think that ESX is a VDC-In-A-Box, the solution to your current virtualization problems, and the Golden Gate to Cloud Computing. Between this, Gerald Chin’s comments last week, and their half-baked storage I/O performance report today, what’s going on over there? My advice to VMware: Whatever you’re smoking, Just Say No.