Since Microsoft released their Windows Azure Platform several years ago, they’ve received a lot of feedback that deployment of hosted websites and applications took too long. Users also pointed out that the platform was a little out of the reach of the hobbyist who just wanted to try things out. These folks just wanted to run a website and quickly iterate changes to that site as they wrote their code.
In response, Microsoft have decided to encourage people who just want to try out the platform, and hobbyists who wish to play with the technology, by creating the 90 Day Free Trial. They have also announced a new high-density website hosting feature that can go a long way in helping out small shops and hobbyists by improving the deployment speed, and allowing fast iterations for simple websites
Windows Azure Websites
Up until June of this year, Windows Azure had only one way of hosting a web application: their Hosted Services offering, now known as Cloud Services. When you performed a new deployment, the platform would identify a physical server with enough resources based on your configuration, create a virtual machine from scratch, attach a separate VHD that had your code copied to it, boot the machine, and finally configure load balancers, switches and DNS so that your application would come online. This process could take about five to twelve minutes to complete, and sometimes longer. When you consider all those things that are going on behind the scenes I think the wait is quite reasonable given that some enterprise shops have to wait days or weeks to get a new machine configured for them. The point here is that, for Cloud Services, the container that your application or solution runs in is a virtual machine.
In June, Microsoft provided a way to deploy websites faster by introducing Windows Azure Websites (WAWS). WAWS is a high density hosting option which uses an Application Pool Process (W3WP.exe) as the container in which your site runs. A computer process is much faster to start up than a full virtual machine: Therefore deployments and start up times for WAWS are a great deal quicker than Cloud Services. Since these processes are so fast to start up, any idle sites can be shut down (have their process stopped) to save resources, and then started back up when requests come in. By bringing sites up and down, a higher number of sites can then be distributed across a smaller number of machines. This is why it is termed ‘high density hosting’. You can host not only .NET based websites, but also sites running PHP, Node.js and older ASP.
One Website, Please
You can create and deploy a Windows Azure Website in just a few minutes. You can even select an open source application such as DasBlog or Joomla to get a jump start on your website if you like. You first need to have a Windows Azure Account by taking advantage of that Free Trial I mentioned or, if you have a MSDN subscription, you can use your Azure Benefits for MSDN. Once you have a Windows Azure account you can follow the instructions on some of the tutorials provided by Microsoft to get a website deployed. There are several great tutorials out there on getting started so I wanted to focus more on what is happening behind the scenes to make all this work.
Once you have a new, shiny website created in Windows Azure Websites, the site itself isn’t running until a request comes in. That means that, even though you can see the website in the portal that says “running”, it is not yet actually deployed to a machine in the Windows Azure datacenters. The site is registered with the Windows Azure platform and will be deployed once a request comes in. This is known as a “cold request” because the site is not deployed yet.
During a cold request, someone asks for something hosted on your website (an image, the home page, etc.). When the request comes in, it is first passed to the Windows Azure Load Balancer which sees that it is destined for a Windows Azure Website property rather than one of the Cloud Services. The request passes on to a set of servers running the IIS Application Request Routing module (I’ve nicknamed these the pirate servers since they run “ARR”). These ARR servers then look to see if they know where this website is running. Since the site hasn’t actually been started yet, the ARR servers won’t find the site and will look up the site in the Runtime Database that contains metadata for all registered websites in Windows Azure. With the information garnered from the Runtime DB, the platform then looks at the virtual resources available and selects a machine to deploy the site to.
Up to this point, the content for the website has not been deployed anywhere; so where does it live until it gets deployed? When you upload your content, it is placed into Windows Azure BLOB Storage. In fact, Microsoft has created an abstraction layer over the top of Windows Azure BLOB Storage so that it looks as if the content is available via a standard network share. Your websites share a combined total of 1GB of storage for their content on this share, unless you opt for paying for reserved instances which I’ll touch on later. This BLOB storage is kept under a storage account owned by Microsoft and is not under your own storage accounts. This is one of the reasons why you only get 1GB of storage for all your websites; you aren’t directly paying for the content storage on a website.
Once the platform realizes that the website that is being requested isn’t deployed yet it uses Dynamic Windows Process Activation Service (DWAS) on a virtual machine running IIS to create a W3WP.exe process instance. This is essentially an application pool under IIS. IIS is then pointed to the code on the abstracted network share for your website. Once the W3WP.exe process is created and started, the original request is passed in so that your site can respond to that request as normal. This whole series of events, ranging from the time the request hits Windows Azure to the time your site receives the request, should take only a few seconds. If your website takes a lot of time to warm up, whilst it perhaps works on filling caches or making a lot of database calls, that work will start after your website receives that request, so it pays to keep your start up time low if at all possible.
As long as the website is actually deployed and running, then any subsequent requests to the site will pass into ARR servers and be forwarded immediately to the virtual machine running the website. These types of requests are called “hot requests” and the overhead of the routing should be negligible.
I’m Bored, Can I Take a Break?
As I mentioned earlier, one of the reasons that WAWS is considered ‘high density hosting’ is because they can get a lot of sites running across a relatively smaller number of virtual machines. This is made possible because at any one time, not all of the sites are actually up and running at the same time: Some are idle. When a site goes idle for a period of time (i.e., it is not getting any requests or doing any work) the W3Wp.exe process that is running the site is shut down. The next request coming into this site would then be a cold request and the site would get started back up, very likely on a different machine.
The idle timeout period can fluctuate quite a bit. Currently the timeout period starts at around 20 minutes, but then it can be as short as 5 minutes. Now, you might be thinking, “Whoa! My site might be taken down even after only 5 minutes of idle time?” Yes, that is a pretty short amount of time; however, the reason the idle time fluctuates is to deal with resource management that comes along with being hosted in a shared system.
Party at My Server!
The web servers running WAWS are in a shared system, with each virtual server running many different W3WP.exe processes. Being part of a shared system means that each website is taking up some amount of memory and utilizing some portion of the CPU. The advantage is that resources can be very efficiently used to host a large number of these websites per virtual machine, but that is as long as everyone plays nice. In a shared system there is always the “noisy neighbor” issue to think about. This is where one of the other tenants on the server decides to get really obnoxious, eating up a lot of memory or hogging the CPU (like your apartment neighbors deciding to have a big block party, but not inviting you). This type of behavior can have significant impact on the other websites running on the server, which is why Microsoft has put several mitigating tactics in place to deal with this.
I’ve already mentioned the idle timeout which causes sites to be shut down if they do not see requests for some time. While it might seem counter-intuitive as to why shutting down non-busy sites helps combat noisy neighbors, it actually is a benefit to those sites that are not as busy. The idle site is torn down, thereby freeing up more resources in the form of memory and CPU on the server; however, more importantly to the site that was just shut down, the next request will be bring it back up on another machine which should not be as busy. Effectively this helps move your site away from the partiers.
The next tactic for dealing with noisy tenants is to apply quotas. Microsoft has quite a few of these for WAWS when running in the shared system. There are memory and CPU quotas that are used to keep a site from hogging too much of the machine’s finite resources. For example, the CPU quota has two thresholds: how much CPU you can use in a given day and how much of that CPU usage can be used within a five-minute period. For the free option of WAWS, the CPU quota is an hour per day and 2.5 minutes within a five minute period. This doesn’t mean that your site can only be up for an hour per day. What it really means is that, over a 24 hour period, your site can use 1 hour of CPU time in total (in theory your site would respond to requests very quickly and utilize only seconds of CPU time for each request). The second CPU threshold is to keep a site from hogging the CPU for that allowable hour by doing something CPU-intensive such as calculating Pi to the millionth digit. Sure, the thread would be switched out while this was going on and other sites would get to execute but it would certainly affect the other sites on the server.
There are other quotas as well, such as the amount of outbound traffic (your website output to users) and how much of the storage space quota I mentioned that you are taking up for your website content. Some of these quotas apply regardless of the options you choose when managing your site, and others change, or simply are removed if you choose a different plan as I’ll discuss next.
Options, Options, Options
Remember that it is not just poorly written code that might push you up against these quotas. Just by having a popular website it could cause you to hit the limit of the quotas. Once you hit a quota your site could stop responding to requests, and users will be redirected to a page indicating that the site has exceeded the quotas. Obviously this isn’t something you want to have happen for your production level sites and it is also why Microsoft offers three hosting models for WAWS: Free Shared, Paid Shared and Reserved.
The Free Shared Model is the answer for those hobbyists who want to just try some code out or test a proof of concept. As well as the quotas I’ve already mentioned, the Free Shared Model is also constrained in that you cannot have customized domain names for your website. Each subscription can have up to 10 of these Free Shared websites.
The Paid Shared Model is still hosted within the shared system, but the thresholds on the quotas have been increased. This is a good model for perhaps running a personal website, or even a business site that doesn’t see an inordinate amount of traffic. For example, in the Paid Shared model your CPU usage quota is 4 hours per day, but is still constrained to the 2.5 minutes for every 5 minute period. In the Paid Shared Model, you can also set up a custom domain name to point to your website rather than being stuck with mysite.azurewebsites.net. The announced price for the Paid Shared model after the preview period is two cents ($0.02) per hour.
If you don’t want to run under the shared system at all, you can elect to move to the Reserved Model, which allows you to select a Virtual Machine size and get your own virtual machine. This option removes any need for the memory and CPU quotas since you are the only tenant on the machine. It also increases your storage quota to 10 GB for all of your websites, but it will cost about the same as running a full virtual machine under Cloud Services once the WAWS service is generally available: This is currently twelve cents ($0.12) per hour per CPU core that you select to run the reserved instance on. The advantage of this option is that you can actually run up to 100 websites on this reserved instance, meaning that even though you are paying more you are able to co-locate many websites on a server that is dedicated to you.
It is important to note that currently if you elect to have a reserved instance ALL of your websites on that subscription will be moved to this reserved instance. This means that if you wish to have some websites running in the shared system and some running under reserved you’ll need to divide these websites across Azure Subscriptions for now.
One of the main advantages of Cloud computing is being able to scale capacity both up and down so as to meet demand. WAWS is no exception. If you elect to run your websites in the shared system, then you’ll be able to scale to have up to 3 instances of your application. This means that up to three W3WP.exe processes are running your website spread across different virtual machines in the shared system. This helps provide better throughput and better availability for your site.
If you have chosen the Paid Shared model for hosting, then you’ll be charged for each instance of a website that you are running, even if the site has gone idle. This is because the platform has to reserve capacity in order to bring the site online any time a request comes in. If you have elected the reserved model then you are charged per instance per core you’ve selected. For example, if you select a Medium-sized virtual machine to run your sites on, which is 2 cores, and you scale up to two instances then you’ll be charged for 4 total cores.
Some Things to Keep In Mind
The WAWS feature is currently in preview, which means that while you can certainly use it, Microsoft doesn’t yet provide production level support for the feature. You can find support through the online forums until the feature goes to General Availability. Like any preview or Beta feature, it will be at your own risk to use this for your production sites. Also, being a preview, there are some facets or features that aren’t quite available yet. For example, SSL is not currently supported, though Microsoft has stated this is on the road map.
WAWS supports several ways to deploy your websites: TFS (via the online TFS Preview service), GIT, FTP, Web Deploy via Visual Studio and a package upload from the Azure Management portal. As you can see there are many ways for you to get your website deployed, so pick out the one that best fits into your deployment process.
The WAWS feature isn’t the only hosting option for Windows Azure and it is not a good fit for every solution. WAWS is a platform as a service (PAAS) offering that provides you simply with a place to put your code. The network infrastructure, operating system and everything else it taken care of for you; however, this level of abstraction means that you are giving up some control. For example, you can’t install assemblies into the GAC or install additional software on the machines running your websites. More complex solutions that require additional control over their infrastructure, need greater scaling capability and/or have many more moving parts than a website, would more likely be best hosted using Cloud Services or new Windows Azure Virtual Machine option, but these are beyond the scope of this article.