Yesterday, Microsoft announced the Azure Services Platform, which is their entry into the cloud computing market.  I have spent quite a bit of time reading through the materials, starting with Microsoft’s press release which is full of buzzwords, but otherwise about as uninformative as could be.  In usual Microsoft fashion, they have thrown the kitchen sink into the announcement trying to tie together .NET services, with Live Services, with loads of other services that have gone through multiple different names before even fully launching (e.g., the data services).  It was fascinating to skim the blogosphere, as so many posts simply rehashed the language from the Microsoft press release.  And no surprise.  There simply was not a clear breakthrough announcement here.

The only actually meatier piece to read on the Azure main site is a white paper by an outside party.  You can find it in the white paper section.  I would link to it directly, but again in typical Microsoft fashion, the whitepaper is available as a .docx file only (does anyone at Microsoft see the irony in this?).  From the “Introducing the Azure Services Platform” white paper, it seems that the core execution engine essentially consists of a load balancer that distributes http requests to application instances that run inside of a Windows VM.  Various parts of the site refer to automatic scaling, but one of the instructional videos show editing a config file to influence the number of running instances.  Other than better integration with Microsoft development tools, this does not seem to go beyond what one can actually do right now with the beta Windows version of Amazon Web Services, as The Register points out in their coverage.

Throughout the Azure site, there is a lot of mention of “industry standard SOAP, REST and XML protocols”.  For instance, the data services have a URL scheme with RESTful access sort of like CouchDB does.  That’s nice, but at this point it should go without saying that in the cloud everything should be exposed as a web service, including data storage.  So the real reason for repeating SOAP, REST and XML like a mantra throughout the site appears to be to mask the fact that everything else about Azure is closed and extremely proprietary.  Yes, several of the diagrams show Ruby, Python and PHP as coming soon and  I would like to see Microsoft provide support for these languages through some of their efforts for having dynamic language on the CLR.  But I have a strong feeling that even then it will be in some proprietary fashion.

In the meantime, for anyone interested in multi-language framework-based cloud computing running on a VM (the JVM), get going and support the open source effort underway at our portfolio company 10gen.com!

Yesterday, Microsoft announced the Azure Services Platform, which is their entry into the cloud computing market.  I have spent quite a bit of time reading through the materials, starting with Microsoft’s press release which is full of buzzwords, but otherwise about as uninformative as could be.  In usual Microsoft fashion, they have thrown the kitchen sink into the announcement trying to tie together .NET services, with Live Services, with loads of other services that have gone through multiple different names before even fully launching (e.g., the data services).  It was fascinating to skim the blogosphere, as so many posts simply rehashed the language from the Microsoft press release.  And no surprise.  There simply was not a clear breakthrough announcement here.

The only actually meatier piece to read on the Azure main site is a white paper by an outside party.  You can find it in the white paper section.  I would link to it directly, but again in typical Microsoft fashion, the whitepaper is available as a .docx file only (does anyone at Microsoft see the irony in this?).  From the “Introducing the Azure Services Platform” white paper, it seems that the core execution engine essentially consists of a load balancer that distributes http requests to application instances that run inside of a Windows VM.  Various parts of the site refer to automatic scaling, but one of the instructional videos show editing a config file to influence the number of running instances.  Other than better integration with Microsoft development tools, this does not seem to go beyond what one can actually do right now with the beta Windows version of Amazon Web Services, as The Register points out in their coverage.

Throughout the Azure site, there is a lot of mention of “industry standard SOAP, REST and XML protocols”.  For instance, the data services have a URL scheme with RESTful access sort of like CouchDB does.  That’s nice, but at this point it should go without saying that in the cloud everything should be exposed as a web service, including data storage.  So the real reason for repeating SOAP, REST and XML like a mantra throughout the site appears to be to mask the fact that everything else about Azure is closed and extremely proprietary.  Yes, several of the diagrams show Ruby, Python and PHP as coming soon and  I would like to see Microsoft provide support for these languages through some of their efforts for having dynamic language on the CLR.  But I have a strong feeling that even then it will be in some proprietary fashion.

In the meantime, for anyone interested in multi-language framework-based cloud computing running on a VM (the JVM), get going and support the open source effort underway at our portfolio company 10gen.com!