Windows Azure defined
Yesterday was the opening day of Microsoft's Professional Developers Conference (PDC), a four-day extravaganza that is the place Microsoft typically announces major new product initiatives. .NET was rolled out at a PDC, as was "Longhorn," the code name for the version of Windows eventually released as Vista.
This PDC is going to include a lot of information about Windows 7 - unless someone went a little crazy and put a bunch of Windows 7 posters around the Los Angeles Convention Center by accident. That information, however, is slated for today (and I'll have more to say about it tonight). Monday was devoted to Windows Azure, a project that is of special interest to Ray Ozzie, the driving force behind Lotus Notes and co-founder of "Groove," a maker of peer-to-peer business software whose purchase by Microsoft brought Ray Ozzie into the Microsoft fold.
To be honest, Windows Azure was a hard product to roll out at 8:30 in the morning on the first day of a conference. I have a decent grasp of the concepts now, though I must admit that I gained the most insight into what it involved through the sessions which followed (though it wouldn't be the first time that has happened).
Ignoring the pithy sentences Microsoft sprung on everyone at the keynote (e.g. "an operating system for the cloud," which makes sense from hindsight, but didn't give me much of a conceptual understanding), I would define Azure as follows: A framework that allows you to scale from 10 users to 10 million users without additional coding. There are a pile of services that Azure adds to the mix that makes it easier to write complex distributed applications, but bottom line, Microsoft wants to make highly scalable applications a "no brainer" for developers through Windows Azure.
One thing Microsoft claimed during the keynote was that the framework could enable ZERO downtime for applications (assuming developers don't upload broken code). This would normally be impossible, as operating systems must be updated, as must application-specific production code. To achieve this, Microsoft developed a system that dynamically manages control flow so as to allow operating systems to be patched without shutting down a running application (move code and flow to a different server while it is being patched), as well as enable production code to be brought seamlessly online after updates. In this respect, Azure can also be considered a framework for location-agnostic distributed applications.
How Microsoft does some of these things I can't say as of yet, and I'm not likely to have an answer while locked inside a conference hall in downtown Los Angeles. The abstractions used within Azure applications, however - which are critical if dynamically-changing distributed applications are not to affect runtime performance - fall into five categories: Live Services, .NET Services, SQL Services, Sharepoint Services and CRM Services. Though its important to know those categories given that Microsoft is likely to repeat them in documentation, I got a much better sense of what Azure was all about by finding out what is actually inside some of those buckets.
.NET Services contains a new Identity management system, code named "Geneva," that is to distributed Identity what Windows Communication Foundation (WCF) is to wire protocols. Apparently, it allows any kind of authentication and authorization system to be automatically "plugged in" to an Azure application. Obviously, this includes Windows authentication technologies such as Live ID and Active Directory, but it also includes non-Microsoft authentication protocols, such as Tivoli.
The principle of protocol and technology agnosticism seems to extend widely throughout Azure. It is Microsoft's intention to support PHP and Java in Azure applications (each of which will have bindings to Azure services). Eclipse will also get the Azure treatment, as plugins will be developed that make it easy to use the open source development tool to make Azure-compliant applications.
A number of storage abstractions exist (or will exist), such as "blobs" for storing large amounts of data (later to include file streams), table abstractions as part of SQL Services (later to include some distributed caching system), and communications concepts such as queues and distributed locks. All these abstractions are designed to make it easy to scale transparently without extra effort on the part of developers (well, beyond the need to write to Azure abstractions, which encapsulate the design principles necessary to achieve those scales).
Though .NET clearly will get special emphasis, Azure is not confined solely to .NET code. As noted, bindings will exist for Java, PHP, and other non-Microsoft technologies. They also intend to support native code (which will likely run within virtual servers to keep them isolated from other applications), though support for this feature is not included with the current demonstration release.
The Azure concept is, in my opinion, rather interesting, and continues a trend at Microsoft to simplify use of complex functionality through easy-to-configure abstractions. This serves a real need, and seems to bring massively scalable applications within reach of ordinary developers.
There are, however, a number of business issues which need to be worked out. First, I have no idea what Microsoft plans to charge for these services (and if I might hazard a guess, Microsoft isn't all that sure, either...at least, not yet).
Second, I'm not so sure how willing people will be to write an application that can ONLY be hosted in the globally-distributed server farm Microsoft is building to host Azure applications. Though I'm sure there will be disagreement in the Talkbacks, I believe some legal contract can be worked out that will provide the confidence that businesses will have absolute ownership of their business-critical information even though their infrastructure is hosted entirely by Microsoft (Microsoft hates lawsuits as much as the next company). Committing oneself permanently to use Microsoft as your hosting provider may be a harder pill to swallow.
To be fair, Microsoft probably hasn't decided whether Azure will be a Microsoft-exclusive hosting environment. A Brazilian engineer asked during one of the post-keynote sessions whether there would be any other Azure hosting providers besides Microsoft. The answer from the panel was that, for now, it will be Microsoft only service (which isn't saying much, as this is clearly still a work in progress), though many of the features will find their way into Microsoft operating systems. Azure, in other words, will be a hothouse for new scalability features that will appear later in other Microsoft platform products.
To my mind, that leave the door open to the possibility that others will be able to host their own Azure applications. I hope so. Allowing competing hosting providers is essential to trust of such a wide-ranging service, and is more fully in the spirit of the open protocols that serve as the foundation of this new infrastructure. Strictly speaking, Microsoft doesn't NEED to make this a Microsoft-exclusive. The company will still have the resource advantage, not to mention a track record of managing extremely large server farms as well as a status derived from their role as developer of the framework.
The idea, I think, is a good one. Even so, the Microsoft exclusivity angle could be a sticking point. Perhaps a Microsoft-controlled certification process for Azure-compliant hosting providers could be an acceptable middle ground.