At the 2010 Hosting Summit you used a reference to cloud being like rock climbing. It's exciting and scary at the same time. What scares you about the cloud?
The thing that's interesting about the cloud is you're running everything yourself. We are responsible for what our customers are experiencing. If we have a problem, it's a problem that's visible to our customers. We have to make sure we are world-class. We need to continue to improve every day. Anybody who runs an operations system has some moments anywhere from concern to terror. That's one thing.
But the reference I made at the time was really to the hosting partners about how the business model is transitioning here and how Microsoft has decided to jump in with both feet and embrace the change. That change will affect the partner ecosystem as well and certainly affects our hosting partners. I was encouraging them to embrace it and to drive their business forward, because it is where the future is going. We've embraced the future and are driving it forward.
So, from a business perspective, how do you smoothly make the transition from the big upgrade cycles, the big surges of revenue, to the subscription model?
The first thing to realize is that we don't really see that surge of revenue at the time of an upgrade anymore because the majority of our customers are buying on multi-year annuities anyway. We have to provide incentives for our customers to upgrade. One of the great things about the cloud is that it's a good business for us because it's a continuation of that annuity cycle. We're very confident that the cloud will drive down the cost of [customer] operations substantially and, thus, enable our customers to save money and, at the same time, actually be able to build a good business for ourselves.
Talk about the Azure appliance. What's the goal with that and what has the uptake been?
I've got to back up to Windows Azure before I talk about the Azure appliance. What is the benefit that we can see for moving to a cloud environment? We learned this ourselves as we deployed consumer services. Our initial consumer services, our initial MSN services, were deployed largely the same way that any enterprise would build an internal application. They used standard servers, standard operational practices. As we built a large number of these services and they started scaling at large numbers, the cost of operations associated with that just got out of whack for us. It wasn't a sustainable business model.
And when we created Bing, we knew we were going to create a massive -- we needed to create a massive scale service because that's what an internet search system is. I mean it's a service that's measured in hundreds of thousands of servers, you know, not even tens of thousands. If we ran that in a traditional way, it was going to be non-viable. So, we built a system with Bing that was a proprietary system designed to enable us to roll out thousands and thousands of servers with very low operations costs. And it worked. It was not general purpose, however. It was not something we could take and offer to our customers or even, frankly, apply broadly within Microsoft.
So, we used the technologies that were pioneered with Bing and we built Windows Azure with the fundamental idea that the application is what you focus on. You don't focus on the infrastructure. With Windows Azure, the application never thinks about a virtual machine. To me that's the definition of PaaS [platform-as-a-service]. With infrastructure as a service, you're managing virtual machines and there are benefits to managing virtual machines at scale. With PaaS, you never see a virtual machine. You focus on the application. With Windows Azure that's the design point we built. The whole system, the infrastructure is all self-maintaining. All you worry about is how you write that application so it scales out and uses these underlying services.
When customers looked at that in our public cloud environment, many said to us, 'We love that, but we want to run it in our own data center .' Or, hosters and systems integrators have said, 'This is a great model to enable applications to be built, but we want to provide it to our customers as well.' That's why we are creating this Windows Azure appliance -- to essentially package what we've learned, the service that we run every day, and deliver it together with hardware that you acquire from one of our industry partners, one of our OEM partners, and run it in a customer or a service provider data center .
The reception, basically, is that, at the moment, I have way more customers that want this than I can fulfill. Way more. But we started with four customers because it's a service we're delivering. We're starting an extension of our existing Windows Azure public service. We're working with those four customers to understand what capabilities they want to take on. When an alert comes in, how do you want to manage that alert? What level of visibility?
How does Microsoft get involved in that? We're hearing different things. Some customers, for example, want a hardware failure to be reported directly to them or directly to their OEM.
Others want us to aggregate those things. Those are options we may wind up providing. That's what we're learning right now as we deploy this. But, as I talk to different service providers, different enterprise customers, we have a fairly long list of customers that would buy one of these things tomorrow if I could deliver it. Next year we'll expand and bring on a few more and then over a period of time we'll make this very broadly available. But, remember, these things are not small. Today, a Windows Azure appliance with the first four customers is about a thousand servers each. This is not a toaster. It will never go down to just a handful of servers. How small is a question we're still working on.
Would you compare it with the sort of Acadia offering -- the Cisco, EMC, VMware kind of 'data center in a box'?
If you look at what VMware, for example, is providing, they aren't providing this massive scale PaaS service like Windows Azure. Windows Azure is actually pretty unique in terms of being a general purpose platform as a service.
Would you compare it with CloudBurst and what IBM has done with the Java platform?
No. Goodness no. What IBM is doing with CloudBurst is that their services teams are building specific installations. It's not at all like the engineering teams are building a single consistent platform that's being offered within their own environment. IBM is doing nothing at all like this. I mean IBM is more taking their existing technology and repackaging it in a form that they deliver as a services offering that's a cloud. They're bundling with it the services people. To me that's the opposite of what cloud is about. Cloud is about taking operational cost out, not adding it in.
Windows Azure is really the only ground-up cloud operating system that the industry has really seen. The only providers in the market that are really platform-as-a-service providers are Google and Salesforce.com. Both of those are very narrow in terms of what they're offering -- single language or a limited set of languages, limited set of services focused on a given set of applications. Windows Azure is very broad in that it supports a wide variety of languages: Java, .NET, PHP, Ruby. It's really meant for a broad set of applications and is a broad set of services.
So it's not all on top of .NET?
No. Windows Azure is language agnostic completely and the services can be built using any language. And then, of course, we're writing a set of services and those services expose Web services or REST protocols so they actually can be consumed by any language. But then, of course, we provide a .NET platform that's a very sophisticated platform for people who want to build using Microsoft tools.