Windows Azure: Web Roles vs. Websites

Windows Azure has many different devices for publishing and consuming content.  Two of those which are often confused are web roles and web sites.  The two are very similar and share some common strengths, but given specific conditions one may fit your need better than the other.  For example, web roles and web sites will both support auto scaling, database support, blob storage access,  ASP.NET, NodeJS, Python and PHP.   Here is a brief overview of specific uses for each.

Web sites:

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

Web sites on Windows Azure operate very similar to those run by other web hosting companies but with added Azure benefits.  You can access the site you created via FTP or Git which means changes you make to the code are updated instantaneously upon submission.  If you need to use any of the templates that are provided  by Windows Azure then web sites are the way to go.  Azure has a slew of templates that you can install, configure and update from the gallery.  Everything that you are familiar with in traditional web sites applies to Windows Azure web sites.
Web roles are where the power of the Windows Azure platform begin to shine.  Here are some of my favorite advantages of the web role cloud service.

Web role:

A Web role is a cloud service.  Cloud services are really where Platform as a Service ideology really begins to work for you.  Web roles allow developers much more control over the environment.  They are created within virtual machines and allow developers direct access to IIS (or web server of their choosing).  Because web roles run in virtual machines they also give you the flexibility that virtual machines give you, without having to manage the virtual environment.  What does that mean?  With a virtual environment you have to stay up to date on patches for the operating system and web server along with any other maintenance the machine will need.  With a web role that is not necessary.  While you still have remote access the to virtual machine your web role is running on, you do not need to manage it.  The virtual environments and patches are managed by Azure.
Web roles can also be attached to one or many worker roles.  Think of a worker role as a console application that will run a computationally heavy process that may take a considerable amount of time.  These types of processes are not for immediate user consumption but to be calculated and stored for future access.  For example, generating recommendations for users in a way similar to Netflix or Amazon is computationally expensive.  To do that within a GUI front end like a web site or web role is not practical.  Unlike a web site, a web role can call a worker role to run a background process.  This worker role can run on a different virtual machine so as not to ruin the performance of your web role.  In addition you can set up Windows Azure Virtual Network so the web and worker roles are on the same subnet.  This allows the two to talk directly to one another on the inside of firewalls instead of having to venture out of the firewall and routed through the internet.
There are many more advantages to using Web Roles over Websites but the last few I want to touch of briefly are multiple staging environments, Content Delivery Network (CDN) connectivity, support for unsupported platforms, and running scripts with elevated privileges.  Websites do not support CDN’s and can’t run scripts that require administrative permissions.  So if a CDN is something your website requires or if you are migrating to Azure and have a few legacy cgi scripts that require admin rights websites will not work for you.
From a development standpoint multiple staging environments is a big win for web roles.  When a cloud service is set up, a staging and production environment are created for you.  There is no longer the fear of having working code in your test environment and crashing your production environment.  The environments are identical in Azure.  If it works in staging it will work in production.
Web Roles and Websites also scale out differently.  Websites only need to worry about scaling up your site in order to keep up with demand.  In a Web role the scaling is similar but what if your web application needs two worker roles for each web role to handle all of the computation.  Scaling with Web roles can facilitate this type of configuration.
I have just pointed out a few of the practical differences between websites and web roles.  Websites are perfectly suitable for publishing content fast, accessing databases and processing records.  They are great for content management systems and you can even use them for e-commerce .  If the cloud service you build will need multiple virtual machines in addition to a virtual network where information will be passed inside the firewall or any significant back end, then a web role / worker role setup is most likely for you.  It provides you the flexibility you need without having to manage the infrastructure you are creating.