Welcome! This is a post that covers in great detail the differences between Windows Azure Web Sites and Windows Azure Web Roles. It was first written a couple of days after Web Sites was first released, but I have been keeping it up to date as changes to Web Sites are announced. There is a change log of updates at the bottom of the post and I have struck out content that becomes out of date over time. There is also an “official” Microsoft post that gives a similar comparison, but with less detail and it’s not quite as comprehensive that you can also refer to.
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. Note: I mention the library a number of times throughout the post where relevant.
The Windows Azure Training Kit has a slide with a really nice overview of the three options for deploying web applications in Windows Azure (note: Virtual Machines are outside the scope of this post):
Azure Web Sites has the following advantages:
- Out of the box support for near-instant Git, TFS, FTP, Web Deploy and Dropbox deployments
- Instant roll-backs (when using Git or TFS deployments)
- Much faster site provisioning and scaling
- Simpler Visual Studio solution (no need for extra Cloud project)
- One-click install of common open-source blog and CMS platforms
- Friendlier in-built (read: one-click to activate) monitoring and diagnostics
- Automatic configuration modification and config transforms on deploy
- Multiple websites (deployed separately) on a single farm out of the box
- A-record support (allowing naked domain names out of the box i.e. without www.)
- Memory dumps via a REST API
Azure Web Roles has the following advantages:
- Use non-standard HTTP and/or TCP ports
- Remote desktop into the VMs
- Use Windows Azure Virtual Networks to get network isolation
- Deploy a background worker to perform background processing on the same VMs as your Web Roles saving you money
- Run arbitrary startup scripts with or without elevated privileges
- Use Azure Drive to mount NTFS volumes from blob storage
- More control over what diagnostic information you would like to collect
- Full control to configure IIS
- Perform complex autoscaling
- Scale to hundreds of VM instances (max in Web Sites is currently 10)
- Use Extra Small (low cost) and Extra Large / A6 / A7 (intense workloads) VM sizes
- Install SSL for a custom domain name for free
- Securely use custom certificates
- Resolve arbitrary domain names to your site without specifying them in the portal
- Use VIP swap / staging slot for deployments
- Configure affinity groups and make use of upgrade and fault domains
- Use the CDN against your web site content
- Deploy to the South East Asia region
- 99.95% SLA as opposed to a 99.9% SLA
- If you only need your site “on” for small periods of time, but you don’t want to have to redeploy then you can stop the Web Roles and not be charged until you start them again
- Ability to use GDI+ and Report Viewer
Conclusion (pasted from bottom of post)
If you need enormous scale, the South East Asia data centre, a non-standard configuration (of IIS, ports, diagnostics, security certs or start up scripts), RDP, network isolation, traffic manager, GDI+ or cost-effective Worker Roles (combined with your Web Role) then you need Web Roles, but otherwise Web Sites is a great option!
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.
Long-story short: Convention-over-configuration IIS-as-a-service to get you up and running quickly in Azure with a minimum of fuss (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 (including hosted within Azure, CodePlex, Github and Bitbucket), TFS, FTP and Web Deploy and Dropbox deployments, which makes automated deployments and continuous delivery dead easy (not that it’s terribly difficult using PowerShell for Web Roles), and importantly, quick.
- 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 thatMicrosoft 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 (edit: looks like there are some ways to address it).
- 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 or update the nuget config – 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
85+ minutes or having to set up something like Accelerator for Web RolesAzure Web Farm.
- You can provision a new Web Site much faster than a Web Role (seconds rather than
158+ 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 ready-to-go, open source web applications (from a list of common ones; mainly CMS’s and blogs).
Built-in monitoring from the management portal(Web Roles has CPU and (optionally) memory as well now, but this also includes HTTP errors, requests and data):
- Extra diagnostics options:
- 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 textbe accessible to them.
- 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 instancesstandard or shared tier, but not for sharedfree tier).
- 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 RolesAzure Web Farm, 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
sharedfree tier rather than reservedstandard or shared tiers 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 free/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 (edit: You can use this with Web Roles easily too now by adding a MySQL database using Add-ons).
- It takes seconds rather than minutes to scale up and out as well as changing tier.
- 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.
- You can get memory dumps via a REST API via Kudu.
With all that in mind, this is what I see as the advantages of / situations you would use Web Roles (a lot of those also apply to Virtual Machines, but that is outside the scope of this post):
- If you need to create an application that has non standard HTTP ports open (or frankly ports open for non-HTTP traffic) you can’t use Web Sites.
- You can’t RDP into the server for debugging or other purposes when using Web Sites.
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 free/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.(edit: VM isolation will be the same for standard tier, see next point about network isolation)
- You can use Windows Azure Virtual Networks to get network isolation of your Web Roles, but this can’t be used with Web Sites
- 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; also, Azure Web Farm has the ability to support execution of console applications packaged with your web application providing the same kind of benefit).
- 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 can mount a NTFS filesystem stored in blob storage using Azure Drive
- 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 tier Web Sites, but I haven’t confirmed.edit: the fact you can have A Record support means this can be achieved with Web Sites too. You can automatically scale your web site using Web Roles.You can perform much more complex auto-scaling with Web Roles – the slider-based auto-scaling in the portal is much more comprehensive and allows CPU and Azure Storage Queue based scaling (as opposed to just CPU based scaling) and if you want even more complex auto-scaling you can use the Autoscaling Application Block (aka WASABi)
- 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 instanceshas a maximum of 6 shared or 10 reservedstandard 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 and shared instances make up for this) or Extra Large / A6 / A7 (if you need extreme vertical scale – but you probably only need this for intense Worker Role processing rather than for web sites [unless you are doing something very wrong/weird with your web application ]).
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.edit: SSL for custom domain names in Azure Web Sites has been released, but it comes at a cost, whereas you can install SSL to your Web Role for free.
- If you want securely managed Security Certificates for any other purpose than SSL 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 websites and shared instances having a limit of 100 websites ( reservedstandard instances have 10GB of space and a 500 website limit [I wonder if this is an IIS limit otherwise why would it be there since you have a complete VM(s) at your disposal?]). With Accelerator for Web RolesAzure Web Farm 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
- You can create linked resources, which may (I can’t verify or find any information to back this up) provide the same effect – you can do this for Azure SQL Databases and storage accounts:
- 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 variables and connection strings 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
- If you want to use the Content Delivery Network against your web site rather than a static Storage Account then you need a Cloud Service and can’t use Web Sites.
Windows Azure Web Roles has an SLA (99.95%), but Web Sites has no SLA.Web Sites has a 99.9% SLA whereas Web Roles has a 99.95% SLA.
- Web Roles that are stopped are not charged so if you only need your site functioning for part of the day you could stop the roles when it’s not needed and have a significant cost saving.
- Web Roles are charged by the minute now – I can’t work out if Web Sites are the same or not though, but I assume so since the pricing page talks about converting the usage to Compute hour equivalents.
- If you want to use GDI+ or report viewer then that is not currently supported in Web Sites (but does work on Web Roles) – it is in the long term plan to add support and you can keep track of progress via the MSDN forums
- The regions that you can deploy Web Sites to are currently restricted
while this feature is in preview, but there are probably plans to roll out wider (see point 3 in the link)(edit: it’s available in all regions except South East Asia – I can’t find any reason why it’s not available in that region).
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), but it does mean that you have to always deploy all the websites at the same time and keep them all in the same Visual Studio solution.
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.
If you need enormous scale,
SSL, the South East Asia n or West US data centre s, a non-standard configuration (of IIS, ports, diagnostics, security certs or start up scripts), RDP, network isolation, 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, but otherwise Web Sites is a great option!
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 (in a previous job) 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 Azure Web Farm
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. 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! See update on my opinion of the future of Web Roles vs Web Sites.
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)
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.
Update (25 May 2013)
Updated to add a note about CDN support as pointed out by Teo below.
Update (17 July 2013)
Overhaul of the post to get it up to date with recent changes to Web Sites and Web Roles as well as a general tidy up and making it more friendly (e.g. added diagram, new intro and tl;dr section and moved around some of the points that were in the wrong section).
Update (8 September 2013)
Added information about GDI+/Report Viewer as pointed out by Travis below.