The Virtual Data Center

I’ve spent the past day reviewing all that’s floating around the Interwebs on the Azure announcements from the WPC this week. There are definitely a lot of nice nuggets to digest and stuff that’s going to take a while to process. Most of the Azure talk at WPC has been, as expected, about how partners can benefit from and build solutions on top of Azure. That’s a compelling message and one I think Microsoft got 100% correct. Now if only they’d franchise Azure we’d really be cookin’ ;). But what about enterprise customers using Azure? Since enterprise virtualization is the overwhelming topic here on The Virtual DC, I’m going to focus on that rather than the partner angle.One thing that struck me straight away today was a comment from Bob Muglia in a CNET interview:

Businesses and hosters will want to offer their own clouds he said, and Microsoft will have tools for them, but Azure isn’t their answer. Instead, he said, Windows Server, System Center, and Virtual Machine Manager will get a lot better at operating in a cloud-based environment, while still offering customers lots more choice.”We will be taking our Virtual Machine Manager product and evolve it over time to much more straightforwardly allow customers to build their own private cloud,” Muglia said.”

I do like the idea of them embracing private clouds with VMM, a logical step when competing against VMware and vCloud, but then I pause. Will Azure ever compete against vCloud? vCloud is designed to allow enterprise customers to build a services-based application bundle in-house (ie running in a private cloud) and then push that entire application service bundle up to a service provider also running VMware and supporting vCloud (ie the public cloud). Build at home, push to the cloud. Makes sense. When people think private cloud, they think vCloud.But Azure is different than vCloud: it’s a service and development cloud, closer to Google Apps than vCloud. If Azure proper won’t support private clouds (and I’m making a huge leap of assumptions on definitions here, but I’m going with that data I have), either because MS has chosen not to or because private dev clouds don’t make much sense (yet), here’s my question: Will an enterprise looking at a branded Microsoft cloud solution have to choose between a private cloud vs. Azure? If the goal is to build everything in-house, then a private cloud on VMM makes sense. If the goal is to develop a MS service-based application for and running in the cloud, then Azure makes sense.But these are two distinctly different use cases, a binary decision based on what type of cloud I’m looking for. In other words if I write an app for Azure, do I need a private cloud running on VMM at all? Customers will choose to re-write their application for Azure and possibly choose to run their MS apps completely hosted in Azure – on one of the Azure services listed here – or they’ll build a private cloud in-house and run everything locally.I guess my hold up here is getting my brain around the Azure model when compared to vCloud. With vCloud, I get the idea of building my application in-house in a virtualized environment and then shipping that application – lock, stock, and barrel – off to my vCloud provider for remote hosting in the cloud. But Azure is different: if I start building an app from scratch to run on Azure I’m going to build it on Azure, in the cloud already. I won’t need to build it in-house first and ship it anywhere; it’s already there.Maybe I’m comparing apples to oranges here and I shouldn’t even be thinking about private clouds, yet there is a lot of talk about private clouds from Microsoft – even from Bob Muglia – so I have to somehow equate the two. They’re comparing and contrasting Azure with private clouds, creating a message that they’re the same type of cloud, yet one is for home and one is remote.Maybe the model will be to build some apps on Azure and run some apps in-house on my VMM private cloud, and then use the new interoperability between 2008 and Azure to let the apps running on Azure become extensions of my private cloud. Maybe my Sharepoint web tier is run in-house but my Sharepoint search and data tiers are run in Azure to keep storage and processing off my network and out of my private cloud.Does Microsoft have it right in keeping Azure and private clouds completely separate for enterprise customers because they are in fact two different beasts, yet saying they’ll work together? Or is Microsoft comparing the two because it’s not yet sure how customers will use and embrace Azure?

Technorati Tags: microsoft,azure,cloud,cloud computing,private cloud,vmm,virtual machine manager,virtualization

DISCLAIMER: This is long and the opinions are mine.I’ve written a good bit here about the various ways Microsoft and Citrix overlap in the hypervisor space, ranging from topics like shared code base through competition for the desktop space. To me, these two players have always been the underdogs battling for the right to go head-to-head against VMware in the main enterprise (and now cloud) virtual data center event. I’ve long said here that I think Microsoft is in the best position to make that move, but to be honest, Citrix currently has better technology. In other words, Microsoft has a better strategic play, Citrix a better tactical play. The announcements that came of out Synergy last week prove that. Citrix knows what it’s doing and they know how to build virtualization products to compete with VMware.As has been asked many times before, here and elsewhere: What would happen…what would be the benefit to the market…if Microsoft were to acquire Citrix and merge the best strategy and tactical solutions into one? The idea and rumor has been around for a while, so why am I revisiting it today? Since these rumors first started to really circulate in September of 2008 (around VMworld) there’s been very little advancement from the Microsoft camp on Hyper-V, and a tremendous amount of advancements from Citrix and the Xen products. We’re also seeing a few cases where the two have opted to work together. Case in point: the Essentials family for managing XenServer and Hyper-V VMs and storage. Citrix has made some excellent headway in the VDC with product announcements this year; that’s the real reason to take another look at this idea.For better or for worse, Microsoft and Citrix are already collaborating, both individually and to an extent togeter, to go after VMware. In the grand scheme of things why continue to do that on their own when they can do it together, mount one single offensive with one single goal, and bring enough technology to actually make a dent in VMware’s VDC footprint? Join forces and all that 2 against 1 stuff. Let’s look at a few categories where this makes sense, where Microsoft acquiring Citrix technology would go head to head against VMware and actually have a chance of winning:

• Networking and Application Delivery: To me recent movement from Citrix in this space is the paramount camel’s straw/tipping point for why Microsoft should finally take the leap. Citrix’s application delivery product line, NetScaler, has been a good appliance-based product for Citrix. Not a market leader, but they’ve held their own against F5 and Cisco. They manage application delivery well enough. With the announcement last week of NetScaler VPX, their virtual appliance version of MPX, NetScaler has made the leap into software-based application delivery, ala Zeus. This is huge for the acquisition discussion. First of all it could bring networking and application delivery into Microsoft’s world, something they’ve avoided with Hyper-V to date. Customers use virtualization for applications and they need to deliver those applications outside their data center. Couple VPX with the new software switch Citrix announced to compete against Cisco’s Nexus 1000v and you have the critical missing pieces for application deliver via Hyper-V (as well as another angle for Microsoft to compete against Citrix). And then add in the Citrix desktop and access-related apps for the non-MS platforms, like the iPhone, and Microsoft makes a huge push owning the application delivery stack from the VDC to the client, any client.
• VDI: Citrix has done an amazing job on virtualization geared towards the client. Going back to Metaframe and Presentation Server and then today with the work they’re doing with Xen on client virtualization, Citrix has always been focused on the client. Ironically, even though Microsoft is the de facto enterprise desktop client (in a sense), it hasn’t addressed the client virtualization markets too well. App-V is a step forward, but MED-V (with desktop virtualization code based on Virtual PC rather than Hyper-V) is a step back. VMware is making a huge push in this market with VMware View; if any player is going to win the VDC space completely they have to include a VDI solution, one that works locally and remotely, in their portfolio. Citrix could help Microsoft make that push by combining their respective solutions for hypervisor and application virtualization technologies. Many of the enterprise desktops and apps are Microsoft; the underlying technology running those desktops and apps in the data center and over the network are Citrix.
• Cloud Platforms/Providers: Xen owns a good bit of real estate in cloud and service provider data centers. Although Microsoft has good presence with customers running Windows operating systems, it doesn’t have the same exposure for Hyper-V as a platform that VMware and Xen have. I think MS is looking to change this with Azure but it will still be limited to the MS-only solution (for the short term anyway). Acquiring Citrix would give Microsoft that cloud provider mindshare by name alone. They could then take that business and technology model that Xen has built and create a best of breed service provider platform between Xen and Hyper-V for customers that want to run non-Windows apps on Xen and .Net-based apps on Hyper-V. This could drastically help Microsoft’s Oslo application lifecycle plan moving forward with cloud providers while not alienating non-.Net apps.
• Application Virtualization: As you know, I’m a huge fan of a true application virtualization model, something that I believe App-V will ultimately be able to deliver. However it will most likely be focused on .Net and Microsoft apps only and is still a few years away from full delivery and even more from adoption. In the mean time we have this bridging technology between VDI, client virtualization, and streaming apps. VMware is getting there with tools like View and ThinApp, but Citrix is staying in lockstep. Microsoft could use a Citrix acquisition to springboard App-V into a multi-focused application delivery platform, taking what’s good today with streaming apps and client virtualization and continue to work on true application virtualization for all apps.
• Customer/Device Support: And as a roll-up benefit of the above categories, we have application delivery to devices. I don’t want to place too much emphasis on supporting remote access via the iPhone, but when you look at Microsoft’s historic relationships with Apple and Linux (as a whole), of which Citrix has obvious ties into both now, that’s an appealing way for Microsoft to jump right into those groups. That doesn’t mean they’ll keep the momentum alive, but at least it would give them more opportunity than they have today. The overlap between VDI, XenApp, secure remote access, and the iPhone is an extremely appealing proposition for mobile users; a turn-key solution for Microsoft to cover a huge gap in their overall cloud and virtualization offerings.

And let’s be honest: Microsoft has had some challenges with their virtualization solutions and their overall direction. Client virtualization based on Virtual PC and no enterprise VDI solution? Hyper-V management hiccups through SCVMM/SCOM and delaying live migration for so long? Azure wanting to change the way applications run and are written on-premise? These raise questions in my mind, a lot of “Why?” questions. Citrix, on the other hand, is heading squarely in the right directly for virtualization solutions.  Citrix continues to plow ahead against VMware at a good pace, whereas Hyper-V isn’t quite at that same pace. The virtual switch announcement from Synergy last week is an excellent example; we haven’t seen any movement or advancements on virtual switching or networking for Hyper-V at all. Sophisticated virtual networking and switching management is an absolute critical component for virtual and cloud-based platforms, IMO. Moving internal roles and tasks to VMs running on the platforms is something we’ve seen for a while with VMware, even going so far as to running the full version of ESX 4.0 in a VM on top of ESXi 4.0. Citrix is doing the same with their Dazzle product. In other words both VMware and Citrix are finding optimized ways to use their own technology for their own benefit. We’re not seeing this today from Hyper-V. Again, there’s nothing to say that Microsoft acquiring Citrix would change that, but at least it might help grease the skids a bit towards internal product unification. Citrix knows how to do it well.To be clear, I am not being critical of Microsoft technologies or business practices (as any long-time readers of my blog will undoubtedly know). I am suggesting that when compared on a chart, Citrix is closer today to where the market and VMware are going for virtual platforms, and if the goal is to compete with VMware for both enterprise and cloud virtual platforms then Microsoft could benefit in leaps and bounds by acquiring Citrix for both Xen and their networking products. Microsoft would get virtual platform, application, and networking tools that they don’t have today.I’ll leave you with one final thought on how compelling a Microsoft/Citrix acquisition could be: Imagine a year from now if Azure launched out of beta running on both Xen and Hyper-V. This would be the best of both worlds: Microsoft could continue to push it’s current developer-based approach to Azure, SaaS, and application cloud computing, focusing on .Net and helping to push users to re-write their current and new apps. They could also support non-.Net customers by allowing them to run their services on Xen in Microsoft’s cloud. Customers wouldn’t have to choose based on their app needs. That would be the ultimate competitor to both Google and Amazon for cloud mindshare, bridging the two cloud models together and backed by the Microsoft brand.  Awesome. Will we ever see it? I hope so for market and customer needs.“Wish You Were Here” Image © 1975 EMI, Storm Thorgerson

After pushing my latest post, Securing the Cloud: Shared Hardware and the Data Plane, Hoff posted a series of excellent questions and responses to the post via Twitter. I thought responding via another blog post, so that his questions could be addressed alongside my last post, was the way to go. I’ve trimmed some of his questions here for brevity but all of his questions can be found on his Twitter stream. And here we go.

@thevirtualdc I hate to tell you this, but your last blog isn’t about securing “the Cloud” at all. You are interchanging cloud & virt…

You are correct that I am presumptively interchanging the cloud with virtualization within the cloud. The primary point of this series of cloud security posts is to break out all the areas that securing the cloud entails, taking a huge topic that many people are discussing and breaking it down into small bits. A very large bite of those small bits, in my opinion, is the platforms that run each individual cloud. It’s been my experience that the majority (definitely not all) of cloud providers right now, and the customers that are seeking out these cloud providers, are using some form of virtual platforms. This is an assumption I’ve discussed here before. I’m definitely not saying virtualization=the cloud, but rather that most cloud implementations rely somewhat on virtual platforms. Virtual platforms introduce a layer of transparency in cloud providers; a customer who choose a provider that’s running virtual platforms will most likely know what that platform choice and what version it’s running. To that extent, the security of those platforms is paramount to the security of the cloud itself.

@thevirtualdc …not that they aren’t related, but by lumping everything into the IaaS bucket (which is what you are essentially doing)…

I’m not necessarily lumping all cloud providers into the IaaS bucket. Non-IaaS providers, such as AWS, Azure, and Terremark, are cloud providers that build their solutions on top of virtual platforms. These are the types of cloud providers that fall into my assumptive clause above. I’m not so concerned in this post with what those providers are doing with virtual platforms or how they’re marketing their service, but rather the fact that they are running shared virtual platforms and relying on shared data plane management from companies that are outside their control. No matter how they’re implementing these technologies, the customers are trusting the providers and the providers are trusting the platforms (along with a ton of other pieces in the cloud puzzle that I’ll delve into later as part of this continuing series) to keep things secure. Basically I’m talking here about any cloud provider that’s implementing a solution on top of stadard virtual platforms.

@thevirtualdc I totally buy everything you wrote, except you decided to call it Cloud instead of Virt which will add 2 the confusion.

I completely agree with you on this one. Goodness knows I get all up in arms about terminology and definitions when it comes to technology, but the choice to lump a discussion about virtual platform and shared data security under the Cloud nameplate was intentional. I want people who are looking at the cloud, who are looking at security concerns in the cloud, to start thinking about security risks of what’s actually running most of the cloud. For example, a major cloud provider recently discussed their solution for cloud security was to deploy individually managed distributed firewalls for their customers. That’s good, but has nothing to do with the security concerns of the virtual platforms that are running those distributed firewalls. That’s the reason I want to associate virtual platform security with cloud security. Sure, there are providers and customers that won’t need to worry about this, but I believe the majority of both will. I don’t want people to think that the cloud is magical and mystical. It’s not; most of it is running some of the same software that we’re running in the enterprise, software that’s highly prone to security breaches.

Hoff concluded with this comment, which I’m unable to find in his Twitter stream but is available via Google cache:

 @thevirtualdc What about folks who use Xen derivatives…like the 800lb gorilla of Cloud, Amazon?

You are correct; I omitted Xen from my “take responsibility” list in that post. Xen introduces a different element that’s slightly harder to control: the OEM’ing and open-source nature of their solution(s). There’s no question that a provider like Amazon who’s depending on Xen as their platform foundation should be concerned about the security of that platform, however, Xen has the ability to be modified (to varying degrees). With respect to security, this makes it much more difficult for Citrix to be ultimately responsible for a secure running environment. The ESX hypervisor is always the same. The Xen hypervisor may be different across every implementation. That introduces risks to the data plane that are much harder to control. Still as critical but it’s harder to lump Citrix in the same bucket as Microsoft and VMware in this scenario for that reason. Regardless, you are correct in that I should have addressed this in my last post.

As always the feedback from Hoff is much appreciated and enjoyed. Even if I’m way off the planet on this (and most of what I wax about here) at least it contributes to the discussion and makes us think about these things. Security risks associated with virtual platforms and not controlling the data plane won’t directly impact all cloud providers or all cloud customers. But it will impact a good number of them, and the fact that we’re not looking to these technology creators (ie the platform vendors) to lead the way and create safe computing environments for shared data…well, that keeps me awake at night.

Frequent readers will understand my love of lists, my affinity for the 4D attack plan methodology (Define, Design, Develop, Deploy), and my need to break things into small addressable (bite-sized) chunks. Over the past week I’ve been laying the groundwork for securing the cloud; not the technical “Use this VM, configure these VLANs, tether the clients this way” stuff but the larger macro business planning for techies on securing the cloud. Today follows suit in the Define category, going straight to the hardest problem first in cloud security: securing shared data plane resources: CPU, RAM, and bus.

Like it or not, we’re going to have to address and solve security of physical computing resources in the cloud sooner rather than later. And by sooner I mean now. First thing. Put down your VM security appliance and step away from your network and packets. This morning. Stop what you’re doing because I’m about ruin the image and the plan that you’re used to*. We need to figure out how to secure VM computing traffic over shared resources like CPU, RAM, and bus – the data plane implemented by virtual platforms and thus the backbone of the dynamic cloud. We’re going to deal with near-limitless attack vectors across all parts of the cloud but if we don’t secure the running environment first then we’ll be asking for someone to find an open door and take our virtual CPUs, our virtual networks, our virtual I/O.

Tools like VMware’s vShield Zones are good starts but they don’t go deep enough (at least from what about Zones today; I’ll know more after the Partner Exchange in April), managing policies and trust levels in the zones down to the bit level, not just the packet level. Exploits against the physical and virtual data planes will make network and application attacks looks like child’s play because the data plane owns the transport and storage of the targets of those attack. It’s going straight to the source. It will allow attacks from inside the cloud out through all those oh-so-useful networking and framework tools that have built up the cloud. It’s a like a microwave: attack the molecules from the inside.

Saying we’re going to do it is one thing, actually doing it is something different. Many moons ago I wrote a three-part piece about the hypervisor/platform vendors taking responsibility for their own virtual space. Their virtual CPUs, their virtual switches, their virtual IPC between host and guests; these items can all easily be secured by the vendors. But what about securing data in the hardware and the step that moves data from virtual software to the hardware? That, too, is mostly the platform vendors, but not all. With virtualization now happening in the CPU, securing that shared data in transit will require the platform vendors to work with the hardware manufacturers to address the problem and establish trust. How can the CPU trust bits from the hypervisor are safe and vise versa?

So how are the manufacturers and vendors going to do that? Easy: the platform vendors will need to create dedicated virtualization security teams that include working with hardware vendors, and start talking about this today. Get the word out that this is a critical issue and concern. Sound familiar? See, it’s all coming together to form an easily manageable plan of attack and execution for securing the cloud from the inside-out. But we have to start somewhere, and I prefer to start with the most difficult task first, the core issue and technologies at the center of the cloud, and then move out from that.

You’re reading this Microsoft and VMware, right? I thought so, just wanted to make sure.

*Yes, I did just borrow and paraphrase the opening line from The Humpty Dance, thank you very much.

My heart is truly warmed (which isn’t easy) by all the talk around cloud security. This may mark the first time in my career that I’ve seen a non-security bleeding-edge technology (c’mon, the cloud is bleeding like a sieve) hit the market coupled with concerns and ideas about security. Even if we look to the virtual foundation of the cloud, none of those technologies (hypervisors, virtual CPUs, shared RAM, storage virtualization, etc) hit the market with any care or concern about security. In this way the cloud is creating a new model of accessible computing in more ways than one.

But all the talk still isn’t enough. I know, I’m never happy. The talk needs to lead to action, and that action should be led by the big three platform vendors: Microsoft, VMware, and Citrix. Regardless of how they’re addressing the cloud in public with marketing and solutions right now, these three platforms provide the backbone (figuratively, not as in networking) for both service provider and enterprise cloud computing. There are limitless other components to the cloud I’ve talked about before, but all of those components have some reliance on solutions from one of these three vendors. Sure, you can argue that the cloud can happen without any Microsoft, VMware, or Citrix technology, but that argument would be so short it wouldn’t be worth the coffee that was ordered for the argument. So keeping in tone with most of my recent posts, this is a call to arms for the big three: Why don’t you each have very public virtual security teams canvasing the globe to gather data and offer solutions?

Here’s what I’d like to see from Microsoft, VMware, and Citrix:

1. A massive evangelical thought leadership virtual security push. I’m talking a carpet bomb attack where all you do it talk, talk, talk about the risks associated with security of virtualiztion and in the cloud. It doesn’t have to be accompanied by solutions at this stage, just spread the word and solicit feedback. I want to see deep technical security tracks at VMworld and MS TechEd. I’ll save a suggested list of topics for another post (’cause I got ‘em). At this point in the plan topics should cover all three types of virtual security.
2. Cloud security teams: It’s not enough to offer cloud services like Azure and AWS, you need to offer cloud security services as well. It (I’m generalizing here with the ‘it’ part) should be a click button when I provision a new system or service. There should be a toll-free number that I can call right now and ask Amazon what they use to secure storage calls over HTTP, or call MS and ask how they guarantee my sensitive traffic can’t leak across VLANs. I don’t want to search for it, I don’t want to submit a ticket, I want this information right in front of me and at my fingertips. And I want the people answering those calls to be security experts.
3. Behind-the-scenes security swat teams. As I’ve discussed before, virtual pentesters looking for ways to exploit hypervisors, to escape the guest, working with Intel and AMD on security risks of moving logic to the CPU, to MitM bus traffic as it moves from one CPU to another. I’m not picky on whether they publicly disclose this information (that’s not true, I would prefer they do but understand why they wouldn’t want to yet) so long as their doing the research today.
4. And finally, a single funnel-up management of all these teams. I want the hypervisor security team to work side-by-side with the cloud platform deployment teams. It does no good if these teams aren’t a single entity with weekly triage meetings. The evangelist who’s talking to an ISP in Japan needs to know the person back at HQ who’s responsible for securing traffic into the cloud data center. And no using the term ‘virtual teams’ here for the obvious reasons, and for the not-as-obvious reason that these need to be real teams that do nothing but cross-technology security research.

Not only will this plan help propel security of virtualization and the cloud, it will also do wonders for customers who are looking at the cloud for mission-critical apps. If I know how to deploy a secure vApp in my internal cloud, know how to secure the channel to move that vApp to my external cloud provider, and know that they are monitoring the security of my application data on the wire and on the bus, then I’m much more likely to move forward with a complete cloud model. Security geeks and business units unite! I want this group to explain to the world the security risks of VDI and how those compare/contrast to security risks of client virtualization.

I’ve heard from so many people in the field (partners, customers, friends) that virtual security isn’t a concern today, and that’s good news. But will you be ready when it is a concern, and who will you turn to for help getting ready? Hopefully you’ll be able to rely on your platform and cloud providers, so start asking them  your questions now.

As reported by Practical Technology yesterday, Citrix has announced that it will be giving away XenServer (the hypervisor portion of their acquired Xen solution) for free. Very similar to the VMware model, they will continue to charge for management and advanced features as add-ons to the XenServer platform but the core virtualization technology will be available for free. Will this have any impact in their market share or their stake in the virtual data center? I’m skeptical for a number of reasons:

1. Free doesn’t always mean better, and usually it’s the exact opposite. I’m reluctant to think that enterprise customers and mission-critical cloud providers will take the free route solely to save money. Maybe that’s more likely this year than last but I’m still not sold it will make that much of an impact, especially since this won’t be an OSS offering ala XenSource. They’re also competing up-stream against VMware’s ESXi and Hyper-V, both of which have value-add above and beyond the hypervisor. For Citrix to make this move work they’re going to have to prove that they have the same type of value-add with XenServer that the other two big players offer. And free doesn’t count as value where your mission critical apps are concerned.
2. They’re relying heavily on management solutions to bring in the money for XenServer customers. We all know you can’t deploy a truly reliable virtualization solution without having management. In practice free deployments of XenServer will be few and far between, instead they will be bundled with some management solution. But which one? If MS System Center will manage both Hyper-V and XenServer, then we’re back to that value-add question for MS shops. If I’ve already deployed MS SCOM/SCVMM then what’s the value in deploying a Citrix solution instead of Hyper-V — which is also integrated into my server platform? VMware shops will stick with VMware because they’re the only company that has an end-to-end solution today. So is management the golden ticket for Citrix?
3. They’re announcing a new partnership with Microsoft. Excluding their existing partnership (whether that partnership has benefitted Citrix is a decently debatable topic so let’s gloss over those particulars for now) — Has a partnership with Microsoft between competing companies ever worked out for the non-Microsoft partner? Yes, MS is an excellent partner resource for technologies that don’t compete, but really, this partnership (and the ability to manage XenServer) will drastically benefit Microsoft by extending their heterogeneous virtual management solutions with Systems Center. I don’t see it going the other way for Citrix. Again, we’re going back to the value for a complete solution and who offers the most value here: Microsoft or Citrix? My vote is very strongly printed in the Microsoft column.

Maybe this will work in Citrix’s favor by at least getting XenServer in more hands to play with, and maybe their technology value will bubble to the top. But how many times have we watched a better technology (assuming XenServer is better) go by the wayside because they didn’t offer enough business value? In this case, I question whether a free XenServer offers any business value above and beyond what Hyper-V or VMware ESXi already offer.

I’ve hinted in the past on my ultimate application virtualization scenario – where I want the market to be for deploying and supporting remote applications for clients in the future. I’m still working on that giant whiteboard architecture map in my basement on what AppVirt looks like from the DC computing side, but today I want to write about the client side of that architecture. And while brevity has eluded me in all parts of my lingual life recently, I’m going to try to be succinct here (expect failure).

I attended the first of a four-part series on Cloud Computing last night held by the WTIA, which included an excellent presentation by Aaron Kimball from Cloudera on the basics of the cloud from the data point of view. Having retired the engineer title for marketing a few years ago, it always makes me happy to see someone who spends their career designing complex systems stand up and give an intro presentation that also includes the business benefit. So often engineers address the How rather than the What and the Why, and Aaron did an excellent job with the latter.

His presentation, along with others last night, got me thinking about what application virtualization in the cloud would look like to the client (and I’m not talking about GMail here).  Let’s look at a real example:

I bought a Mac a few months ago primarily to run Lightroom, so I spec’d out the Mac to go high-end because it would be running a very beefy photo application (along with Photoshop in the future I’m sure). The machine also had to run VMware Fusion in parallel (no pun intended; sorry to my Parallel friends) - I have a photo stitching application that’s currently Windows-only. Standard operation keeps me stable at 75% RAM and 40% CPU on average.

But what if I didn’t need to buy local computing resources and everything was processed remotely? Let’s jump ahead 10 years (a big leap, I know) and look at how this could be different if client apps were in the cloud.

I buy a local processing machine that’s drastically stripped down from my current Mac. I boot this machine to a web browser, where I head over to Adobe and say “This is Alan; I need to run Lightroom.” Adobe says “No problem. Let me push down the secure Lightroom App Shell. Ok, now you’re ready. Here’s a list of your albums pulled from Amazon S3.” I say “I need to process the latest batch of Mt. Baker HDR images.”  HDR images take a substantial amount of computing power to process, so Adobe comes back and says “No problem. I’m going to need 2gig RAM and a dedicated CPU core for this, but your monthly subscription only covers 1gig and .5 core. I’ll charge you $0.021/minute if you’d like to burst.”  I say “Great, let’s do it.”

Amazon then pulls its own resources from AWS and start distributing my HDR processing over thousands of machines/cores/RAM, all controlled from my local Lightroom App Shell. To me it’s displayed as one 8ghz core (remember, 10 years from now:) ), but in practice that value is an aggregate of distributed resources pooled from thousands of machines.I process my HDRs, they’re stored back in my Lightroom library which is managed by Adobe.com, I take my tiny laptop over to the client’s office, rinse, repeat.

But what if I don’t want the processing done exclusively in the cloud? I mean after all the above scenario is very similar to what I can do today with a web browser. What if instead my local computing platform is moderately beefy and I process everything locally. But as my machine starts to bog down from stitching together HDR panoramas it uses the Lightroom App Shell to request raw computing resources from AWS, and I become part of the distributed cluster? I scale and process background tasks remotely and only use my local resources for rendering the images to my display. My machine is part of the cluster and the line between local and remote processing becomes blurred. That’s some cool client-based application virtualization. The application running state is spread across elastic resources, of which my local resources are a part of.

True application virtualization will be a huge undertaking and this is simply one part and one idea. But why not think big? Go for the gusto I say. Oh, and there’s more here, but I’ve long since crossed the brevity line. Maybe more later.

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 was reading Alex’s post on SearchServerVirtualization this morning and really focused in on this comment from John Humphreys at Citrix:

If you think about what the operating system does, it only does three things. It provides an interface to the hardware [and] to the software and provides middleware,” Humphreys said. “If the hypervisor is doing one-third of that job, that’s a potential price cut for [Microsoft].”

This comment has had me thinking all morning, and now as I sit down to enjoy some lunch, I’m really starting to noodle a this idea (the boucing between past and present is intentionl - this has been sitting with me all morning, seriously).  First I started thinking about the OS vs. hypervisor idea. Do these two ideas compete? Is it really the goal of the hypervisor to replace the OS, or at least take on 1/3rd of the duties as John suggests? I think the answer is “No” to both of these.  I think the hypervisor’s role is to manage access to and, to a certain extent, emulate hardware, for operating systems, not instead and not to replace. Long term I think this will allow the OS to function more on resource management for its own applications rather than having to also worry about where those resources come from.  Seperation of duties: let the OS manage the apps so they all play nice together and then let the hypervisor manage the hardware for the OS, while the OS still owns allocating the resources. Even better when the OS’ and hypervisors start working together ala paravirtualization, which is an interesting side note to all of this and may have answered my question, but before I get to that…

So then I latched on to this comment from Gordon Haff:

Haff believes Microsoft’s attitude is misguided. Rather than “stress out” about delivering a hypervisor, it “could have done more in the partnering arena and saved the world 75% of the ‘Microsoft doesn’t get virtualization’ stories’ and never lost a penny.”

…and that got me thinking about the “Why didn’t MS partner for the hypervisor?” idea. And here, I’m stumped. We all know MS isn’t a hardware company, and minus the XBox they admit this as well. So if the hypervisor truly is meant to emulate hardware rather than software (ie the OS), why would MS want to build a virtual hardware platform? As far as the OS is concerned, the hypervisor is the hardware platform. Why buy then build rather than partner? Why not work with a company that’s 100% focused on the hypervisor?  I think we all also agree that MS is a software company; their revenue comes from software licenses. They make apps and operating systems to run those apps.

This begs the question: What was the original benefit evaluation for MS to start building Hyper-V (knowing that Hyper-V grew out of Virtual Server which was acquired by their puchase of Connectix in 2003)?  Why did they head down that path rather than working with VMware (remembering that until recently, Xen wouldn’t have been an option due to its *nix lineage)? MS makes money every time an enterprise installs VMware to run a Windows operating system. With issues like sprawl, MS could stand to make a good amount of money on both OS and app licenses.  And as we saw on Mike D’s blog (although take it with a grain of salt b/c Mike does work for VMware and has vested interest in propogating the MS vs. VMware price war), the MS licensing model does require a finite number of virtual instances of their OS for every license except with a full Data Center license, which makes sense.

Now please don’t misunderstand me: I am in no way suggesting that MS shouldn’t be in the hypervisor business or kill Hyper-V.  I’m simply thinking out loud. Long time readers of this blog will know that I actually think MS is in the perfect position (long term) to completely change how we think about using discrete hypervisors, operating systems, and apps. The day I can run Sharepoint on a bare metal, bootstrapped hypervisor (ie hardware -> Hyper-V/WinKernel -> Sharepoint) is the day I jump for joy. Now that we have Hyper-V, I think MS does have the ability to own the virtual stack and deploy true application virtualization better than anyone. And I also disagree with Haff’s comments about MS not getting virtualization. I think they get it extremely well, they’re just up against a technology originator (in the x86 space anyway) and have to defend every thing they do. Which is funny given the nature of this post I guess. 

But before we had Hyper-V…To me it seems they would have had nothing to lose from partnering with a VMware hypervisor company and jointly developing a “WinOptimized Hypervisor” or something of the like, in a similar manner to working directly with Intel for CPUs. Was their goal to own the stack for app virtualization without an OS? To create a paravirtualized running environment where Server 2008 and Hyper-V, for example, separate duties (which they’ve done on the hypervisor-only front)? Even if that comes at a huge cost from competing with VMware and having to become hardware experts for things like virtual switches and infrastructure? What’s in it for MS?

Anyone know the history (more recent than Connectix) and/or want to chime in? I’ll be the first to admit if I’ve got this wrong, so let the opinions fly! What am I missing?