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

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

I am the king of starting blog posts with “I know, it’s been a while…” So I’ll dispense with that intro here and get right to the goods.

I’ve been traveling a fair amount lately, speaking on the impact virtualization has on your applications, and talking to customers about their current virtualization issues. As you know I typically talk about the virtual platforms: hypervisors, resource management, virtual networking, and how all of that trickles up the stack to your applications. In other words: What happens to my web app when I move my web farm from physical servers to virtual servers?

More and more my conversations have been moving from concepts around introducing virtualization into the data center and towards how to efficiently use virtualization in the data center. The difference here is subtle in verbiage but huge in impact: customers are saying and showing that they understand, trust, and are standardizing on virtualization technologies and now they’re attacking deployment of these technologies. We’ve moved beyond the whiteboard phase and now we’re into the data center. For those keen on the 4Ds, we’re past Define and Design and now somewhere in the midst of Develop and Deploy. This may seem like old news to people who live and breath virtualization every day, but to customers who are not early adopters or bleeding technology implementers, this movement is a huge step for the virtual data center.

The key litmus test I’ve used for this evaluation is how frequently I talk about architecture. Last year I spent all my time talking about virtualization technologies, the challenges they introduce into the physical data center, and how to start planning to adequately manage those challenges and migrating to a truly dynamic virtual data center. I talked plumbing. Today I’m talking much more about how to architect virtualization technologies in the data center; how to use these tools as building blocks for service delivery (the real reason we use data centers in the first place). And those architecture conversations have likewise changed scope, moving from talk about how to add virtualization to the data center to talk about how to build the data center around the dynamic nature of virtualization. Oh yes, I’m talking dynamic infrastructure (or Infrastructure 2.0 as it’s been called for a while) conversations with IT architects. Awesome.

And while it may be an obvious and slight change in perception from those of us who are looking at virtualization 2-3 years down the road, we can’t forget about what a drastic leap it is for data center architects who are building applications and systems that have to be reliable. Services that are re-sold; applications that provide a business presence; 5 9’s SLAs that are dependent on virtual platforms.

Paradigm shifts are often subtle because we’re looking from inside. When viewed from the outside, though, the dynamic data center is finally coming to fruition, and the implementers – the customers — are the leading the way. We’ve built the rollercoaster; now let’s try out that exhilarating first drop.