I’ve been playing with Windows Azure quite a bit lately, in an attempt to get this blog running over on that cloud service. Through the Microsoft Student Insider program, I have been given an MSDN subscription, and that comes with some significant Azure compute resources. While I’ve used DreamHost for years, and they’re an excellent web host that has been very good to me, they’re still shared hosting. Azure is a chance to play with some dedicated computing hardware which is much nicer than I’ve used in the past. Additionally, Azure is a service I’d like to be able to describe to several of my fellow students here at Case Western Reserve, in order to be able to discuss the differences between Azure and it’s main rival, Amazon’s EC2.
Azure and EC2 conceptually do the same thing. They are incarnations of the “power-on-tap” systems which were first foretold more than a decade ago. However, they are the first such systems to be successful, and the way they operate is significantly different than the first “power-on-tap” ideas first floated “back in the day.” Both services work on the basis of the Virtual Machine model. You run your service in VMs (or “instances”) on top of a hypervisor (Xen in EC2’s case, Hyper-V in Azure’s case), and the cloud provider runs the actual hardware on which that hypervisor runs. You delegate management of that physical hardware on over to EC2 or Azure, and worry about the software only. Despite both being built on top of the VM model, the services have significant differences.
Azure lacks EC2’s “Instant, Easy” nature
So, I logged in with my MSDN subscription, cruised on over to the Windows Azure portal, and promptly… got confused. EC2 is brain-dead simple. You create a virtual machine, you start that virtual machine, and are given Remote Desktop access to that machine. That’s it! EC2 does provide some services which allow you to dynamically create instances on the fly, and some facilities to perform load balancing and such, but if you don’t want those things, you don’t need to use them.
This is EC2’s biggest strength: it’s conceptually simple. Anyone who’s ever used any VM software is going to be able to grasp what it does immediately. There’s no learning curve; just instant gratification. Ask for a VM, get one in Amazon’s cloud, no questions asked.
Azure’s model does more for the developer
I knew that figuring out Azure on my own would be a major problem, so I went on over to DreamSpark’s Pluralsight On Demand service, which contains a several hour long class on Windows Azure. It covers everything from setting up Visual Studio with the developer tools, running Windows Azure projects on your own hardware, deploying your solutions to Azure itself, and other interesting tidbits.
After spending some more time figuring out Azure’s model, I found out that while Amazon’s system makes having applications understand that they’re running in the cloud optional, on Azure, it’s required. Rather than use a plain old VM that you could setup yourself, Azure provides an application hosting platform. That is, you give them what is essentially a ZIP containing setup instructions for whatever application you’d like to run, and Azure follows those instructions to get a VM running. Azure itself handles getting the right operating system installed, getting IIS or SQL Server configured and ready to go, as well as ongoing things like operating system security updates. Azure does more for you than EC2 does for the same price – management of the underlying OS and application server are included in addition to management of the hardware.
This is actually quite nice. You can deploy an application to Azure, and it will be load balanced, patched, and have maintenance performed on it without you having to lift a finger. (Amazon does provide a load balancing service, but it costs more money) Unlike EC2 where you’d have to go through the motions of cloning your existing AMI (Amazon Machine Image), running your updates and such, starting new instances one by one as you remove instances running the old AMI, et cetera, on Azure this is automatic. When you do need to update your web application (to fix bugs, add features, or the like), Azure lets you piggyback on top of their own failover process – simply deploy your new application to a staging environment, “upgrade” it to the production environment, and you’re set – no code required. The instances running your old code will be shut down, and the instances running the new code will be started, transparently to the user.
Azure requires the well constructed architecture that EC2 makes optional
All of this complication in getting Azure setup, however, really is the platform pushing the developer to a more effective use of cloud services. Sure, you can take any server and virtualize it in Amazon’s cloud service. However, to make best use of what either cloud service offers, the application needs to be aware that it’s running on the cloud – to scale up by starting more instances as required, or save money by shutting down instances when they’re not needed.
This means that new instances need to be able to construct themselves on the fly, without user intervention. Any programs or services required for a given web server need to be able to be installed in an automated fashion. Servers need to be tolerant of complete and absolute failure – the instance on which they are running being terminated – as the natural course of things. (Some users, notably Netflix, have a dedicated machine whose sole job is to randomly terminate their cloud instances to ensure things operate correctly when they fail) Moreover, the application running on these instances needs to be structured so that it can handle a varying number of webservers facing the Internet at any one time. This applies whether you’re running on EC2 or Azure. Azure simply makes these kinds of requirements a part of getting an instance running, while EC2 simply will create instances with no initial instructions if desired. EC2 might be simple to start with, but as your application grows you’re going to end up much happier if you lay this kind of scalable groundwork ahead of time.
If it runs on Windows, it will run in Azure
Out of the box, Azure is optimized for running ASP.NET (and ASP.NET MVC) applications. Also, there are some out of the box provisions for PHP or other FastCGI based applications. This has led to a misconception (at least in my area) that Azure is limited to Microsoft approved languages and frameworks, or that it’s limited to specific application types. This is not true – most any language can access the automated provisioning bits for Azure using it’s Managed, Native, or REST based APIs. Steve Marx, who works on Azure, gave an excellent talk on this entitled Node.js, Ruby, and Python in Windows Azure: A Look at What’s Possible at MIX11, which is available for viewing online. He details the bits one would need to do to use alternative web scripting languages, storing the contents of the scripts over in Azure’s blob storage, and running those scripts on demand on top of Azure’s services. He demonstrates how one can get Azure to do most anything – even without going through the trouble of acquiring a Windows Server 2008 license and uploading it to Azure yourself.
Jury’s Still Out
I’m still not entirely certain which service I like better. Azure is certainly more difficult to start out with, but looks like it might make more sense in the long run. However, I‘m not really qualified to talk much comparing the services until I’ve actually constructed a Windows Azure application. I’ll be back after it’s running for a few weeks with more information. 