Windows Azure- promoting simplicity and flexibility
In a recent article from the Register regarding Ray Ozzie’s comments on Google Wave, Ray Ozzie is quoted on the “complexity” of Google Wave and some potential challenges with the architecture on the Web. As part of an attempt to compare and contrast Google Wave with Live Mesh and Microsoft’s Windows Azure platform, the article includes a few inaccuracies regarding Azure that need to be cleared up. Here’s what Gavin Clarke had to say regarding Azure:
You still need to buy into the Microsoft SQL Server architecture, for all Ozzie’s talk of the complexity of Wave and the implied openness of things like Mesh and the Exchange and SharePoint services. Azure’s storage system, for instance, is based on Microsoft’s SQL Server. Also, you’ll still be building applications for Azure and all those Microsoft services using Microsoft’s Visual Studio and relying on .NET.
First, Azure isn’t based on the SQL Server architecture. One of the core components of the Windows Azure platform is Azure Storage Services, which includes support for blobs, tables and queues and can be leveraged for a broad range of storage application needs. This is a new framework that is not based on SQL Server. For apps that require a more traditional DBMS, the SQL Services component of the Azure Services platform can be leveraged and this does incorporate SQL Server into the architecture. For more details on both of these components and the architectural distinctions, see David Chappell’s Azure whitepaper. And more specifically, Mesh has no dependency on SQL Services as part of its architecture.
On the topic of building applications, contrary to the Register’s claim Azure does not require Visual Studio or .NET in order to use the platform. In fact, in this particular area Azure is likely to excel with developers. First, Azure has announced support for integration with third party IDEs including Eclipse and will support Java and Ruby SDKs. We also have examples of the JRE running in Azure, enabling developers to leverage Java for their server-side Azure applications (not fully supported, at least not yet, but still an option). Additionally, Azure supports a range of protocols, including HTTP, SOAP/WS*, REST, and Atom. Sam Ramji has a run down here.
The discussion of Wave and its complexity aside, I think that most people would agree that having this range of protocols, languages and tools for Azure developers promotes simplicity and flexibility for developers using the platform. As a user of the Azure platform today and someone who will likely be working with customers to help them implement Azure-based solutions, I look forward to more announcements from this team on their support for open, heterogeneous Web technologies.