Amazon and Azure

I was reading my esteemed colleague Dmitry Sotnikov's overview comparison of the proliferation of cloud platforms, and it inspired me to write down my take on these two approaches to the world of 'cloud computing', whatever that is.

I am a big fan of Amazon Web Services (AWS) because it's available now and you pay only for what you use. No startup fee, no minimum subscription charges, no relentless mailings offering upgrades. I am able to boot up remote systems and interact with them without having to do an install from scratch, etc. This works nicely in my world, but then I am a technical guy so I am not put off by having to write a program or login to a machine with ssh to do something.

So it's great, you do everything yourself, and it's a pain because yes, you do everything yourself. As I am often reminded in yoga class, maximum flexibility yields maximum pain. Even though I am not afraid to write a program, there is a big conceptual space to absorb before I can start writing that program. First I need to understand what an Amazon machine image is, how to attach persistent block storage, etc. It's really no surprise that although AWS has received a lot of attention from the press, hobbyists, and academics, it's not what you could call mainstream.

Microsoft's Azure is not yet completely defined, but I think I can see where they are headed. While not as feature-complete as Amazon, they are focusing on providing a nice layer of abstraction that offers what will likley be full-on system management of systems which physically reside who-knows-where. A small number of services that works simply and well is arguably better than a raw interface on a comprehensive set of services. Plus Microsoft is able to buy themselves some time to finish building out the data centers, and use the early adopters as guinea pigs to drive out the operational issues.

So as not to cannibalize their lucrative desktop biz, Microsoft is positioning this so that you have many options for creating applications. They say you can build your application with the new Azure APIs and tools such that you can leverage services in the cloud only if and when it makes sense to do so. In other cloud-computing scenarios, you need to commit to a particular application architecture which is either resident 'offsite' or very local. If they deliver on the promise of making it easy to dynamically leverage cloud services, or bring the whole thing inside your firewall, or mix these notions as needed, then there might truly be some useful software here. You bet you are still committing to the Microsoft stack with all its various pros and cons, and the essential feature the deliver with Azure is that you get a new architectural option for lateral scaling, hopefully without having to work too hard.

Somewhere, there is, no doubt, a giant room of people coding like crazy to build out more services, create the tutorials, and clean up the APIs. So while Microsoft is not offering as much granularity as Amazon, they are offering what will eventually be a highly usable interface on the web which allows people to do stuff that they normally do. You can build on your local machine, and push the result to the cloud right from your desktop. No ssh is (apparently) involved, and, for most people, that's the right answer and removes an important barrier to entry for many people.

For Amazon, there are things like ElasticFox, a Firefox plug-in application for managing one's AWS services. But it's really just syntactic sugar on top of the raw APIs-- it lacks the abstraction that captures the work being done in the way that actual people think about it. Microsoft's focus on application hosting deployed right from the IDE represents an important distinction: Amazon offers the ability to do whatever you want, Microsoft gives you an application development environment AND a nice web front end to what you probably need to do anyway for production systems. Three are compromises here because you naturally don't have the same flexibility with Azure that you have AWS, but in many, many deployment scenarios, all that flexibility just gets in the way.