The Virtual Data Center

One of the oft discussed business challenges of cloud-based application deployments – or any remote app deployment where a service has to communicate over the public internet – is latency. It takes more time to fetch data when a request has to leave the LAN, and latency is usually variable and at the mercy of both the Interwebs and the cloud provider. This isn’t so much of an issue when your entire app is deployed in the cloud and users are going directly there for data; the user won’t notice any difference between accessing your app after it’s moved to AWS than they did when you had it deployed in your own data center. In fact some times it might even be faster.

The latency monster rears its ugly head when apps are spread across data centers, either in a split architecture or with bursting, where the user is first directed to your local data center and then a decision is made to move that request (and possibly that entire user session) to the cloud portion of the app. Solutions exist today to help optimize the applications and the network to provide a better user experience, but there’s a new(er) trend that’s not getting much attention to help combat geographic latency: regional cloud providers.Regional cloud providers are exactly as the name suggests: providers that offer cloud services close to your physical data center. Think of these providers as “buy local” clouds. Today these providers offer local cloud hosting services that compete with the larger players, such as Amazon and RackSpace, with local knowledge and local support.

But what about a hybrid model, the Cloud Franchise: local owners and operators that offer local cloud services but also offer branch versions of the larger cloud options. Some of this model exists in the platform levels today, in fact there is a thriving marketplace for start-ups who are offering AWS-based solutions, pre-packaged and ready to go. But those solutions, once deployed, still run in AWS data centers (although AWS doesn’t publish this information, their US data centers are rumored to be located on the East Coast). If I have latency concerns about bouncing my users from one part of my app in my private Missoula data center to another part of my app located in Baltimore, then a pre-packaged AWS solution won’t really help me with that. I want all parts of my app to be as local as possible, especially when I need to burst into or direct users to the cloud.

That’s where the cloud franchise model comes into play: regional cloud providers can offer pre-packaged AWS services as well as be a branded AWS hoster, hosting those deployed services in a local data center rather than in Baltimore. The customer is still using AWS and has access to 100% of the AWS products and features, but the end result – the hosted application — is running on an AWS platform in Missoula instead of Baltimore, run by the local provider.

AWS is just one type of architecture: Azure is another place where the cloud franchise architecture could come into play. If I write my .Net app to span between both my local data center and an Azure cloud, I want to make sure that I have the shortest path in place between my data center and where my app is actually running in the Azure cloud. Mainstreet is going to perform so much better if it only has two hops between my local DC and Azure, both in Missoula, than if it has to bounce over multiple providers to cross the country to one centralized data center in Dallas.

At the end of the day the goal is to reduce latency between my data center and my public cloud. The more I can control in my user’s experience the more likely I am to deploy into the cloud, especially for latency-sensitive apps such as VDI. One way to control access to the my cloud apps is to control location: buy local from a regional cloud provider who is also a cloud franchisee. Use the services and products of a trusted brand (AWS, Azure, etc) with local hosting, management, and support, and keep the apps local.

It works for fast food, why not the cloud?

Technorati Tags: cloud,regional cloud,regional cloud providers,intercloud,context,data center,cloud computing,aws,azure,cloud franchise,application delivery,network,latency,vdi

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

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.

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.