Thoughts about how Azure is architected have been jumping around my brain for a long time now. Subconsciously I was trying to tie all of these thoughts together, but as usual it took some idle time when I wasn’t thinking about anything else for it to come to the foreground.
I first began seeing problems with the way Azure is architected over a year ago at the San Diego Day of Azure (Saturday, Oct 03, 2009). There I ran into a brilliant guy, who I hadn’t seen in a while named Jason Diamond. Jason is a fellow DevelopMentor instructor and former co-worker. He was playing with NServiceBus and asked if you could deploy both web and worker roles to a single machine. This pointed out a limit in the ability of Azure to scale down. While we were talking I pointed out another limit – that in order for the service level agreements (SLAs) to take effect you have to run two instances of each role. These two problems together meant that if you have both a web role and worker role you basically needed four dedicated instances in order to achieve the SLAs. Ouch!
Then in preparation for writing my cloud course I started reading more about Google App Engine. I was marveling out how they could offer so much for free, until I realized that they weren’t dedicating *any* hardware to a particular App Engine “customer.” As a customer you might be running on a box with hundreds or even thousands of other customers. Heck, for all you know you might not be running on a box at all. The interesting thing is, until you hit the limits, you don’t really care. When you do hit the limits then you can start paying money and Google might upgrade you to your own machine (actually, I am not really sure what they do – it is difficult to tell from reading the skimpy documentation on how it actually works under the covers).
Then last Friday Ike Ellis and I were writing an article about SQL Azure vs. Amazon RDS. Probably the most interesting parts of the article were the graphs (price, and performance).
I think that if SQL Azure can flatten the storage cost line a little bit, then they are a much more compelling scenario. They are also more “cloudy”. By that I mean that SQL Azure is SQL Server re-architected for the cloud, not just an instance of SQL Server running in the cloud. SQL Azure is multi-tenet, it supports 3 replicas automatically, and if a box is “getting hot” SQL Azure can move it to another box with less running on it in order to better support that customer’s needs. I think it is a great abstraction and ultimately will win in the long run.
Regardless of what the marketing materials say, Azure was architected as Infrastructure as a service. I know it is positioned as Platform as a service, but underneath the covers it is definitely – without a doubt – an infrastructure based system. That is both good and bad. It is great as you get big enough to need your own dedicated hardware, but until you get to that point, you really don’t need all of the expense that goes along with paying for multiple CPUs owned solely by you. Google has proved that if you put a lots of customers together on the same hardware, it is much cheaper than giving each customer there own hardware. That is how they can afford to give away so much for free.
If Azure really is a platform then they should start acting like one. To me a platform is something that you can stand on, without having to know how it was constructed underneath. In Azure, due to the law of leaky abstractions, some of the Infrastructure details come leaking through. This is most notable through the fact that you have to manually or programmatically adjust the number of instances that your application is running on. “Instances?! I am running on instances? I thought I was running on telepathic robots! I am going over to Google, where telepathic robots do my work for me, instances are so 2000-an-late.”
If Azure had the same free entry model as Google where they ran in a multi-teneted environment then you would simply deploy your application to the platform, and the platform would make sure that it never fell down. Microsoft knows how to setup a system like this, as they have demonstrated with SQL Azure. This is the ideal entry level system, and an ideal on-ramp for customers. As the applications outgrow the free system, they can move to dedicated hardware. This is something that Google currently doesn’t offer and it gives companies the best of both worlds. In fact Microsoft could apply that same philosophy with SQL Azure, and compete against Amazon RDS’s high-end database in the cloud scenarios.