One of the things that I have been pondering since the Windows Azure announcements is when you would use Web Sites over Web Roles (azurewebsites.net vs cloudapp.net). I’ve done a few Google’s over the last few days to see if anyone was blogging about it apart from the initial post by Scott Gu, but hadn’t found anything until a Stack Overflow post came up this morning and since then a couple of posts by Nathan Totten (creator of Accelerator for Web Roles, which has been deprecated by Azure Web Sites, and who works on Azure for Microsoft).

This, in combination with the thinking that I have already been doing and actually having a play with Web Sites has enabled me to come up with the following post. As a warning, some of this will probably change over the next few weeks and months since Web Sites is a brand new product that Microsoft are still probably actively developing. Also, I’ve tried to back up everything I’ve said with URLs, screen shots or just trying it out, but it’s possible I’ve got one or two things wrong since there isn’t much material out there on it yet.

Shameless Plug: If you are interested in using the power of Azure Web Roles with the nice deployment experience of Azure Web Sites (at least the msdeploy part of it) then check out the Azure Web Farm library I’ve been working on.

Web Sites

Long-story short: Convention over configuration (without much flexibility to configure on top of that relative to Web Roles) style platform to get you up and running quickly in Azure (kinda like App Harbor). Also, allows you to use a certain amount of Azure resources for free (10 websites on shared instances with limited bandwidth), which is a welcome addition and will be great for proof of concepts or just playing around with stuff!

The main advantages that Web Sites seems to have over Web Roles are:

• Out of the box support for Git, TFS, FTP and Web Deploy deployments, which makes automated deployments and continuous delivery easier (not that it’s terribly difficult using PowerShell for Web Roles).
  • Annoyingly (unless I’ve missed something), the git publishing doesn’t use private keys so you have to keep typing in the password, although from watching David Ebbo’s Youtube video on publishing from Git there must be some way to make it remember the password (I wouldn’t know as I always use private keys). [See update at end of post for instructions]
  • It would be cool if some of these features were added to Web Roles and Worker Roles; I’m not sure if this tweet from David Ebbo is any indication that might happen!
  • It seems that Microsoft have open sourced their Git-IIS deployment library, Kudu, which is cool
  • I tried to deploy a solution that had multiple web projects, but no matter what I did it kept deploying the first web project that I had deployed. I’m not sure what conventions it uses, but if you need to configure which project is deployed then I imagine you can consult the relevant Kudu documentation.
  • If you use the Git publishing model (and I assume the TFS publishing model) then you don’t have to commit your NuGet package binaries as they will automatically get resolved when you push (you do have to turn on Package Restore on the solution in Visual Studio for it to do it though). This is great because it makes your deployment much faster. It does mean that if you use packages that aren’t in the official NuGet repository (e.g. in a private repository, or using a package service) then you will need to include those ones – I haven’t tried seeing what happens when you do that though yet, so try with caution.
• Gives you the ability to roll-back to previous deployments instantly via the management portal if you are using Git (and I assume TFS) deployments.
  
• You can deploy almost instantly out of the box (with the above mentioned deployment methods), rather than in 8+ minutes or having to set up something like Accelerator for Web Roles.
• You can provision a new Web Site much faster than a Web Role (seconds rather than 15+ minutes); I’m guessing Microsoft will always have spare capacity spun up and ready at any point in time – their capacity management software must be fascinating!
• For .NET web apps: You don’t have to set up a separate project in your Visual Studio solution to deploy to Azure – you can simply deploy a normal web app solution as-is.
  • This also means you don’t have to maintain two sets of configurations and set up a storage account for diagnostics so you can be up and running much quicker.
• Out of the box support for installing a CMS (from a list of common CMS’s and blogs).
• The regions that you can deploy too are currently restricted while this feature is in preview, but there are probably plans to roll out wider (see point 3 in the link).
• Built-in, web site relevant monitoring from the management portal (Web Roles has CPU and (optionally) memory as well now, but this also includes HTTP errors, requests and data):
  
• Ability to inject configuration variables to your web.config file rather than having to package the final version with the deployment.
  • This means you don’t have to use encrypted web.config files if you want to keep production configuration information in source control so you can do automated deployments, but still prevent developers from accessing the production environment.
  • It does mean you potentially need to be more careful about who you give access to the management portal for your instances because the connection strings will appear in plain text.
• If you have a web.release.config file then the XDT transformations in this file will automatically be applied before deploying your site.
• You can add multiple host names that your site responds to (if it’s using reserved instances, but not for shared free mode).
  • It appears you have to do this if you want to point a CName record at the site – given there are multiple sites being hosted on the same IIS instances this makes sense.
  • Given Web Roles allow you to point as many domain names as you want at it and it will resolve for all of them (assuming you are trying to resolve the main web site that is deployed in the Azure package rather than using a solution like Accelerator for Web Roles, which does require you to specify the host name) this isn’t really an advantage that Web Sites has over Web Roles.
  • What it does mean though is that you can host multiple sites on a single set of reserved servers out of the box (which is why Web Sites deprecates Accelerator for Web Roles in combination with near-instant deployments).
  • There is an implication if you are using shared free hosting rather than reserved that you can’t point custom domain names to your web site and thus have to use the azurewebsites.net domain name (which is probably fine if you are doing a prototype or proof of concept).
  • It seems that for a given subscription in a given region you can have either shared or reserved Web Sites and thus any web sites that you add for a given subscription / region that has reserved Web Sites will be shared on your reserved servers.
    • I can’t confirm this explicitly, but it’s the only thing that makes sense to me after seeing the management portal and reading between the lines in the documentation.
    • I would suggest that it will be important to keep this in mind if you want to segregate the servers that certain combinations of web sites that you deploy. You might want to do this due to their load profiles conflicting with each other. This is important unless Microsoft provides an easy way in the future to segregate your reserved instances within a single subscription or provide an easy way to migrate a site to a different subscription or region (unless I am missing something!).
• You can use MySQL.
• It takes seconds rather than minutes to scale out more instances.
• You can’t join it to a Virtual Network
• You can host your “naked” domain name (i.e. without www.) in a supported way rather than having to resort to external services, clever programmatic solutions or being careful not to nuke your deployment

Web Roles

With all that in mind, this is what I see as the advantages of / situations you would use Web Roles:

• If you need to create an application that has non standard HTTP ports open (or frankly ports open for any other reason) you have to use Web Roles.
• If you want to be able to RDP into the server for debugging or other purposes you have to use Web Roles (or VM Roles).
• If you want surety about network / virtual machine isolation of your application for security reasons you may not want to use (at the very least shared) Web Sites. This is a bit of conjecture though because without knowing the internals of how Web Sites is implemented it’s hard to say what kind of isolation it provides.
• If you want to deploy a worker role to perform background processing alongside your web site via a worker role then you can do it using the same instance with a Web Role (thus costing less money).
• You can run elevated start up scripts with a Web Role that then allow you to install any software you want or configure it in any way you desire.
• You have full control over what diagnostic information is collected from a Web Role, which you may want to use for auto scaling, or customised monitoring solutions.
• You have full control over how IIS is configured in a Web Role.
• Your Web Role endpoint resolves to a static IP address assuming you don’t nuke your deployment. I assume the same thing applies for reserved mode Web Sites, but I haven’t confirmed.
• You can automatically scale your web site using Web Roles.
• You can scale out to a very large number of instances for extremely high load web sites (I know of a situation where at least 250 instances were used). Web Sites (at least at the moment, and with the default configuration when you first get it – it’s potentially possible to increase this) seems to have a maximum of three instances has a maximum of 6 shared or 10 reserved instances.
• Furthermore, as per above screen shot and at least for the moment, Web Sites doesn’t have Extra Small (great for cost effective hosting of low load web sites – but the free shared instances makes up for this) or Extra Large (if you need extreme vertical scale – but you probably only need this for intense Worker Role processing rather than for web sites).
• At the moment you can only have SSL connections to your custom domain name by using Web Roles since there is no ability to upload Security Certificates to your Web Site instances, but this will probably be added soon. There is SSL for the azurewebsites.net domain name that you get though.
• If you want Security Certificates for any other purpose e.g. config encryption, authentication, etc. then you will need to use Web Roles (for now at least).
• Apparently, during the preview there is a limit of 1GB of space per subscription that can be used with Web Sites and you can have a maximum of 10 web sites. I found this in a Stack Overflow answer from a Microsoft employee working on Azure. Free and paid shared instances have a limit of 1GB of space with free instances having a limit of 10 web sites (reserved instances have 10GB of space). With Accelerator for Web Roles there is no limit on the number of sites, and depending on your role size you can certainly have more than 1 GB of storage (apart from the fact you have have more than one hosted service, each with more than 1 GB of space).
• If you want to have any domain name you want to resolve against your web site using a CName without having to specify those domain names explicitly in the management portal then you will need to use Web Roles (see the comments section below for explanation).
• You have the option of using VIP swap as a deployment option – this allows you to fully test the deployment you are about to make and then switch between old and new very quickly (and more usefully, vice versa if something goes wrong)
  • While I think this is very useful in some circumstances, particularly if the act of deploying is accompanied by separate, long-running processes that could go wrong (e.g. complex database changes that are triggered before the vip swap) I think in general if you can simplify your deployment process such that it’s not required (and simply make it really quick and easy to rollback to the last version) then that’s better (Web Sites enables this due to it’s out-of-the-box deployment options)
• Affinity groups to allow you to ensure that Web Roles are close to storage accounts and potentially other roles within the datacentre (decreasing latency and increasing performance).
  • I suspect that Web Sites may well do this behind the scenes for the storage account you associate with the Web Site, but of course you can only do it with that storage account and not with multiple ones or other sites / roles
• Explicit upgrade and fault domains
  • Web Sites makes upgrade domains redundant given the deployment options (see note above about VIP swap) and I assume that fault domains are likely transparently implemented for you, but that could be wrong
• The cscfg file and ability to edit in the portal
  • You can edit web.config entries within the portal for Web Sites so this makes it somewhat redundant
• If you want to use Traffic Manager to distribute your application in multiple data centres across the globe then you can’t use Web Sites, however you can get a similar affect using an Azure Virtual Machine and IIS ARR as per http://stackoverflow.com/questions/13697863/is-it-possible-to-provision-the-same-domain-name-on-multiple-azure-websites

While reading up on this post I found out something about Web Roles that I didn’t know – apparently you can deploy a Web Role package that contains multiple web sites (by specifying their host headers).

I should note that at this stage I haven’t looked at the improvements that Microsoft have added to the .NET SDK, although I would say it’s unlikely any of them will affect the difference between Web Roles and Web Sites.

Conclusion

If you need enormous scale, SSL, South East Asian or West US data centres, a non-standard configuration (of IIS, ports, diagnostics, security certs or start up scripts), RDP, traffic manager or cost-effective Worker Roles (combined with your Web Role) then you are going to have to stick to Web Roles for now. If you want to overcome the deployment woes with Web Roles then check out the Azure Web Farm library I’m working on, which gives you a nice deployment experience using MsDeploy.

Accelerator for Web Roles

Unfortunately, the above list excludes me from using Web Sites for now because we deploy to South East Asia (lowest latency to Australia), need SSL and also need extra Security Certs for some of our apps. Also, for at least a couple of applications we need the surety on network and VM isolation that Web Roles has.

Given that a 8+ minute deployment for a web site is unacceptable for me that means I’m going to have to keep with Accelerator for Web Roles for now even though it’s deprecated. In some ways it’s a shame because I have had a couple of problems with it so I’m probably going to have to put some work into it before we use it for the really important web site my team is currently developing. I’ve linked to my Azure Web Farm project above.

At this stage it’s unclear whether it’s Microsoft’s intention to migrate all the Web Role features to Web Sites and in time replace Web Roles completely – that would be totally excellent! We will have to wait and see… Exciting times!

Update (10 June 2012)

David Ebbo send me a message via Twitter to let me know the solution he is using to remember his Git password. Also, I found a post that describes how to point to other NuGet feeds than the official one when using package restore.

Update (28 August 2012)

I read a truly excellent post yesterday about Virtual Networks and it made the point that you can’t join a Web Site to a Virtual Network, but of course you can join a VM or Web/Worker Role. Thus I added that as another limitation above.

Update (15 September 2012)

West US Azure data centres now support Web Sites.

Update (18 September 2012)

There were a few big announcements today about Azure Web Sites and I’ve updated this post with some minor corrections accordingly.

Update (9 October 2012)

Added some rather obvious differences I originally missed thanks to the comment below from Roland.

Update (1 January 2013)

Updated to reflect the fact that East Asia is now supported for Azure Web Sites (as per this announcement) and the fact you can now have up to 6 shared and 10 reserved instances rather than the original 3 (as per this announcement).

Update (27 April 2013)

Updated to add the fact that Traffic Manager isn’t supported for Web Sites.