I had the privilege of talking to a number of customers, members of the community and reporters last week about our web / cloud technologies. In those conversations, a few things became clear. First, there is a ton of interest (in general) about cloud computing with folks wanting to understand what it is and how it will ultimately impact IT. Second, IT organizations want to better understand specific scenarios that might be more favorable for cloud computing. Third, as you might guess, there is a lot of interest in understanding how Microsoft will approach the business model for cloud.
First things first… Microsoft thinks about the web workload (including cloud computing) holistically. There are tools and technologies that help developers build interesting web based applications (Visual Studio, Silverlight, ASP.NET, WCF, IIS, etc.). Separately, we think about running and scaling these applications using Windows Server & Internet Information Server (IIS, our web server) on local machines, clusters in a data center, capacity from a hoster and more recently through Windows Azure. Lots of the conversations this week focused on the differences between enterprise datacenters, hosters, and the cloud and SaaS. It’s important to note that Microsoft has thousands and thousands of hosting partners and we support all of them. Hosting is a critical service for many companies and one that will to add value for customers for years and years to come. We license technology like Windows Server to them through our Service Provider License Agreement (SPLA). We use SPLA to license Windows Server to partners like Amazon.
Here’s a way to think about it:
· Enterprise IT – I buy the server and the software (CapEx).
· Hoster – I rent the use of hardware and potentially software (OpEx)
· Cloud – I pay for the consumption of a compute fabric as my app needs it (OpEx as my app demands)
· Software as a Service (SaaS) – I pay to use an app which is hosted by the ISV directly, or the ISV uses capacity from a Hoster or Cloud provider.
I also like the way GigaOm put it in this post. The features and engineering that Microsoft is driving with Windows Azure powers this computational fabric – that’s what makes Windows Azure different from the technology we license to hosters and businesses. Over time, the innovation in Windows Azure will be cross-pollinated with our on-premises server products and Windows Server, offering increasing capability to transition workloads between on-premises and the Azure cloud. Driving a consistent approach across both premises and cloud technologies ensures that developers and IT professionals have the power of runtime choice and the freedom to change their minds between running workloads on-premises, the cloud, or a hybrid of both to best fit their needs.
Second, people are beginning to speculate on the types of workloads that might be best suited for cloud computing. While the list is hardly definitive, there are some uses that seem to resonate:
· Workloads that are highly elastic. We see examples in the insurance business on a regular basis – policy calculation and risk analysis. Many companies update their premium tables on a quarterly basis. This means we have an app that is computationally intense but only runs for a few days / weeks per year.
· Revenue generating applications that need to scale linearly with demand. Going back to my insurance company example – let’s say we have a web app that allows prospective customers to get an insurance quote and potentially begin service all through the web. Instead of having idle capacity and managing to peak loads, I could use a cloud model and pay for consumption on a near real time basis. That allows me to look at that app as a profit center.
· Though not really an app type, the third example is helping our customers and partners accelerate their innovation and improve time to market. Think of this as pilot or skunk work projects you want to kick-start or scenarios in which you want to minimize upfront investment. A lot of the conversation on cloud computing has focused on start-ups that are eager to minimize their CapEx and want to get to market quickly. The same logic applies for pilot projects in an enterprise. Examples here abound – just about any app type or scenario. a key consideration here is whether or not you will continue to run this app in the cloud or will, at some point, run it on premises. More on this one in a later post…
Third – on to business model. People continually ask why we haven’t yet announced pricing for the Azure Services Platform. There are a couple of reasons for this:
· It’s early. We’re still in feedback collection mode with commercial availability targeted for the end of 2009. Right now we are focused on getting feedback on the services and making improvements where needed.
· We want to encourage development free from economic constraints. The moment you introduce an economic model, developers begin architecting around it based on what they perceive to be most cost effective. We just want folks to build architecturally sound applications and tell us what they think.
What can we say about our business model? Three things:
· First, we’ll have one. We see this as a business and will run it like one. We’ll provide a reliable service and ensure that it is compelling for our customers and reflects the feedback that they have given us.
· Second, as always, we will be competitive with market pricing. Microsoft has a long history of being a high volume, high quality, low cost provider and this will be no exception.
· Third, we hear from developers that there is a strong preference for simplicity and consumption-oriented pricing. Still more work to do here, but we hear that and tend to agree that it makes the most sense for our platform services.