| By Kevin Hoffman |
Article Rating: |
|
| September 8, 2009 09:30 AM EDT |
Reads: |
1,737 |
Recently a friend of mine showed me Heroku, an "instant Ruby platform". Basically what you can do with Heroku is build your Ruby application and the deployment to the remote Heroku site is not only brainless, painless, and simple, but it can be done entirely from the command line (which means it can be automated even further than it already is). But don't take my word for it, check out this screencast showing exactly how simple it is to build Ruby applications in the cloud using Heroku.
This got me thinking about Windows Azure, Microsoft's "cloud operating system". I'm not really sure I like that particular marketing slant on what Azure is, because at the same time Azure is so much more than an OS and yet doesn't function like what a lot of people would consider to be an OS. Regardless, the promise of Azure is that you can build your hosted services on your local machine and deploy them "to the cloud" quickly, easily, and simply. What Microsoft says you get in return for hosting your services is scalability, reliabiltiy, and ease of maintenance without having to have all of your own data center infrastructure.
There are plenty of other resources avaiable on Azure so I won't go on and on about it here but the main idea is that you can build your data-driven web application to work against a cloud-based data source, communicate with cloud-based services, and deploy to Microsoft's data center in the cloud (which now has configurable geography-based affinity). The main barrier to entry that I see here is how EASY things are. If an ASP.NET developer attempts to go build a web application that is based entirely on Azure services and they encounter road blocks, headaches, sources of frustration and places where "it's just broken" instead of "it just works", they aren't going to use it. In fact, they will probably start blogging about how bad the experience was.
What Microsoft needs to do is ensure that going forward, it is as easy to build and deploy Azure hosted services ASP.NET applications as it is to build and deploy Ruby applications with Heroku. I should be able to seamlessly build against a local version of the cloud data store that requires NO CHANGE on my part to work against the remote cloud store. Right now, this is broken and there are subtle incompatibilities between the local fabric simulator and the actual cloud fabric in Microsoft's cloud. This is annoying and a speed bump. When I'm satisfied that my local application works the way I want it to, I should be able to migrate that application from my machine to the cloud quickly, easily, and in a way that I can automate or control. This includes a way to migrate the data currently stored in my local fabric to the data stored in the cloud fabric. Right now Azure doesn't do this - your local fabric Azure Storage data has no way of being migrated to the remote storage unless you write code to do it.
So, to summarize - if Microsoft can make the process of developing Azure-based ASP.NET web applications as simple, easy, reliable, automatable and pleasant as the Heroku deployment process then they will find developers flocking to them in droves, begging to get their apps hosted in the cloud. On the other hand, if they make the process brittle, rigid, slow, painstaking, and what some people consider "Microsofty" then developers will universally cry "Meh" in response to Azure and possibly even pick up Ruby as a new tool just so they can take advantage of services like Heroku.
