Windows Azure Websites vs Cloud Services
The question of the week is. When do you use Windows Azure Websites as your web platform and when do you use Cloud Services. These two platforms provide similar functionality in that you can deploy your ASP.NET or other IIS based web application projects to either of these platforms. There are some general cases of when to use one over the other and some specific differences that may help in making that decision. In this post I am going to go through these differences and attempt to give some guidance on what to use when.
When to use Websites
You Are Just Starting - Compared to Cloud Services, Websites may not be as flexible but it is definitely easier. You can build your website using Visual Studio, WebMatrix, or any other IDE of your choice without the need for an SDK or any other additional software.
You can deploy to Windows Azure Websites using WebDeploy, FTP, or even DropBox. You can sync your site code straight from GitHub, BitBucket, Codeplex, or TFS Online. It is incredibly easy and require little to know buy-in to Windows Azure if you want to create an IIS website.
You Have a Single Compute Tier - If you are running an application that does not require internal communication then it would be much easier to use Websites. Again, the stance that I usually take is use the easiest option until you are required to change. If you need multiple machines that talk to each other over a private network, then you cannot use Websites and you need to use Cloud Services (or Virtual Machines).
With Websites you can have multiple servers handling requests if you have a high load, however those servers know nothing of each other and do not have internal addresses or endpoints.
Your Site is Written in PHP, Python, or Node.js - This point is not to say that you cannot use these platforms on Cloud Services, it is just easier with Websites because the machines are configured beforehand. With Cloud Services you get a base Windows Azure Image to deploy onto. The Windows Azure Website system uses that same base image however extra software has been installed to IIS for your convenience.
When to use Cloud Services
You Need Machine Level Access - If you compare the underlying platform of Websites and Cloud Services, Cloud Services provides you with a completely provisioned, unique, stateless virtual machine whereas Websites provides pre-configured IIS application pool, and you may be on the same machine as other sites. With IIS there are many restrictions, not the least of them is machine level access. This restriction could affect the base functionality of .NET like using PFX certificates to sign network tokens, or accessing local user profile data.
When deploying to Cloud Services there is no shared option, this deployment owns the entire virtual machine for its lifetime (which could vary, it is not a state-full instance). This gives you much more control over the deployment environment compared to Websites.
You Perform Background Processing - The Cloud Services platform has two different Role Types, a Web Role, and a Worker Role. If you are familiar with on-premise architectures you can compare the two to an IIS Application and a Windows Service. Windows Azure Websites is all IIS, the web server provides the entire platform, there is no room for long running processes or threads that can sit and wait for communication on another port outside of IIS.
If those Windows Service type scenarios are sounding familiar to you, you may need to consider using Cloud Services for the Worker Role capabilities.
Your Application Requires Internal Communication - With Windows Azure services there is a general level of scalability. Both Cloud Services and Windows Azure Websites can scale up and down as needed, even automatically. However, if you want to use 2 web front-end machines and they need to communicate to each other, you need to use Cloud Services Roles and Instances. Windows Azure Websites take routed requests in a farm of IIS hosting servers, they have no knowledge of other machines in the same site.
Cloud Services however runs as an overall deployment with multiple Roles and each of those Roles can contain multiple Instances. You can scale different components of your system separate from others. Cloud Service deployments also have an internal network all to themselves to use to communicate between the Roles and Instances. The Windows Azure SDK contains .NET Libraries to determine which machine is the current instance and where to contact the others.
Feature Breakdown
For those more specific features that may sway your decision one way or the other, here is a quick table comparing the two.
| Feature | Web Sites | Cloud Services |
|---|---|---|
| Scale Out to Multiple Instances Without Redeploy | Yes | Yes |
| SSL | Yes | Yes |
| Visual Studio Integration | Yes | Yes |
| Deploy from TFS On-Prem or Online | Yes | Yes |
| WebMatrix Support | Yes | No |
| Fast Deployment | Yes | No |
| Instances Share Content and Configuration | Yes | No |
| Multiple Deployment Environments (Production and Staging) | No | Yes |
| Network Isolation | No | Yes |
| Support for Windows Azure Traffic Manager Preview | No | Yes |
| Support for CDN | No | Yes |
| Remote Desktop Access | No | Yes |
| Execute Start-Up Tasks | No | Yes |
Summary
If the above information has just left you more confused, here are some basic guidelines that I use for many Windows Azure service match-ups.
Use what you need, until you need more, then switch.
That said, start by creating a Windows Azure Website (hey, it's free right), get your application out into the world. If you find that you require more complexity and you are considering a multi-tier scenario, consider switching to Cloud Services.
As always, thanks for reading!