I recently had the privilege to take a week of training on Windows Azure. I learned a lot and had fun while doing so. The parts that interested me the most were the parts that played well to my own strengths, which are in software development, as opposed to the other parts that focused on the infrastructure aspects of Azure. When I started looking around for blogs about Azure, I would find a lot of content that focused on the latter, but not very many that addressed the former. So in an effort to combat that trend, I plan to start writing about Windows Azure from my own developer’s perspective.
Azure offers a fairly daunting array of services and products, and so it can be challenging understanding the differences and knowing how to choose which one is right for your project. Before anything else, you need to know what kind of environment your executable code is going to run in. Azure broadly refers to this category of products as “Azure Compute”, of which there are three major players: Virtual Machines, Cloud Services, and Websites.
You may have heard terms like “Infrastructure as a Service” or IaaS in relation to Windows Azure, and Virtual Machines are a perfect example of that. They are whole virtual machines that you can rent time from a pool of hardware to run. They might be the least interesting offering because they’re the most familiar; there is hardly any difference between an Azure Virtual Machine and a Virtual Machine hosted anywhere else, and that is by design. The primary use case for choosing an Azure Virtual Machine is as a migration path to move an on-premises application into Azure with minimal effort. Azure Virtual Machines are the most customizable and expensive of the Compute options discussed here. You can access them via Remote Desktop, install anything you want on them, specify start-up tasks, and anything else you could want to do with a virtual machine. With this high level of control comes high levels of maintenance as well; you assume the responsibility to keep the OS updated, correctly configure the products you choose to install, and so on. Until recently, you couldn’t configure Azure Virtual Machines to auto-scale, but that is no longer the case.
Azure Websites represent the other end of the spectrum from Virtual Machines: they are just websites rather than entire systems. This is an example of “Platform as a Service” or PaaS. You lose a lot of control over the host (can’t connect via Remote Desktop, can’t install services or other programs), but gain conveniences as well (host OS and server software are updated and configured for you, auto-scaling, continuous integration support, and more). They’re at the opposite end from Virtual Machines on the pricing spectrum as well, being the least expensive option of the three being described here. It used to be the case that Websites didn’t support different deployment slots like what Cloud Services offered, nor an easy way to implement recurring background jobs either. However, Websites has caught up to Cloud Services in this regard and you can now deploy to a “Staging” slot and perform (or roll back!) a deployment to production by swapping slots, and you can create recurring or background jobs with the new WebJobs API as well.
Finally, occupying the middle ground between Virtual Machines and Websites are Azure Cloud Services. Cloud Services are composed of a combination of one or more Web or Worker roles. Web roles are basically a website plus a machine configuration, which grants you more control over the web host than an Azure Website does. Worker roles are like console or service applications plus a machine configuration. Like Azure Websites, they sacrifice some control over the host server and in return gain such conveniences as automatic OS updates, server configuration, and automatic scaling. Unlike Azure Websites but like Virtual Machines, you can connect to a Cloud Service with Remote Desktop and install any software you want on it and configure custom startup tasks. As alluded to in the prior paragraph, Cloud Services used to be the only platform capable of deploying by performing a Virtual IP (VIP) Swap, which allowed for staging a new version in Azure for testing and fast deployment with worry-free ability to roll back if required, but Websites has recently acquired its own version of this power. Cloud services also used to be the only platform capable of defining background tasks with Worker roles, but Websites has caught up with WebJobs there as well.
What’s it all mean? In my opinion, there is little reason not to target Azure Websites as the first choice for most cloud applications. You get all the good stuff in the box: Simple deployment from Visual Studio, Continuous Deployment from source control plus optional unit tests, no worries over IIS configuration, separate deployment slots with VIP Swap deployments, and background or recurring tasks with WebJobs. The only reason to step up (or is it down?) to Cloud Services is if you need the extra control that Cloud Services offer over their host environment, and that’s even more true of Virtual Machines, which should really be seen as a last resort for porting legacy applications to the cloud. Virtual Machines are probably never an appropriate target for brand-new cloud-targeted applications.
Latest posts by Falafel Posts (see all)
- Matching Complex Query String Rewrite Rule in IIS - March 22, 2017
- Using Google Services in UWP C# Apps – Part 2 - February 7, 2017
- Using Google Services in UWP C# Apps – Part 1 - February 6, 2017
- Redis Caching in the Google Cloud Platform - February 3, 2017
- Entity Framework with Google Cloud SQL - February 2, 2017