With Amazon or Rackspace, you are responsible for creating, managing and updating your OS images and writing the code that enables your application to scale out to multiple machines. With Windows Azure, the fabric contoller does that for you. You don't need to worry about creating OS VM's, applying patches etc. and you don't need to write massive amounts of new code to enable your app to scale out. For example, say you create the next Twitter. On day 1 you only need one machine. On day 2 you need two. On day 10 you need 100. On day 20 you need 1000. With Amazon or Rackspace you'd need to (somewhat exagerating but you get the point) essentially re-write large portions of your app each time you add new machines. With Windows Azure it just happens by setting a parameter. Say on day 10 you need to apply an OS update or patch. With Amazon or Rackspace you'd need to do that yourself, re-built your VM's and redeploy them. With Windows Azure, the fabric contoller rolls out the updates for you automatically - on the schedule that you want...without bringing down your application. Also, with Windows Azure you can request geo-distribution of your application. You can specifiy that you want X instances running in the Chicago datacenter, X in the Dublin datacenter etc. The rest just happens.
Finally, the Windows Azure development environment works with Visual Studio and, soon, Eclipse. When using Visual Studio you can do development and test on your local machine and then deply when the app is ready. It's pretty simple.
The biggest downside of Windows Azure is that - today - you can't just drop an existing application running on Windows Server onto Windows Azure and expect it to work. It's better for net new applications - at least until Microsoft offers raw VM's that you can manage yourself. But that sort of defeats the purpose of the fabric controller and the other management features of Windows Azure.
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
