Monday 8 February 2016

Azure - Web Apps Summary & Cheat Sheet

Over the past month I've been studying towards MCP, Microsoft Azure Developer Specialist certification. I have learned a lot, so I have decided to summarise and visualise the key points.

Features vs Tier

Azure web apps feature vs tier

  • Free - Shared and limited compute, all you get is an Azure URL, some CPU time and access to Kudu to view logs, console, environment information,  processes, web jobs, etc. 
  • Shared  - Shared, limited, but scalable compute, you can even have your own domain name pointing to it.
  • Basic - Dedicated and scalable compute, at this level you are paying per VM and not per web app (more on that later), hence the price jump. This tier is packed with features. 
  • Standard - Dedicated and auto scalable compute with backups and slots for partial traffic routing, quality assurance or seamless upgrades by swapping slots. 
If you are thinking of moving your web apps to the Azure and not sure if it makes sense financially, then you should read Penny Pinching in the Cloud: When do Azure Websites make sense.

What should you know about web apps?

Azure Web Apps Topology

  1. Slots - Standard tier unlocks slot feature. Each web app can have 4 slots and 1 production slot. These non-production slots don’t scale and they tend to reside on the main VM, in our case these slots will remain on WEBVM1. These slots act like production slots and you can have web jobs running inside them. This can be an issue if your application is not designed for multi job processing. To prevent your web job from running just update the config by adding WEBJOBS_STOPPED = 1 to the app settings. Slots are on the same server so don’t do performance testing against them as you will impact performance of the entire VM. If you need to do some performance testing then it would be better to create a new service plan and deploy your web app in to it, this will ensure isolation.
  2. App Service Plan - This is a very powerful feature and it becomes very handy once you go above shared tier. Beyond shared tier you get dedicated compute i.e. your own VM. App service plan = Websites, Features & VM(s) grouping. You pay for a service plan. However when it comes to shared tier you pay per website inside the app service plan. Once you go beyond shared service plan you start paying for VM(s) and not websites. This is important to remember as it can save you a lot of money! So it’s cheaper to pay for 2 websites on a shared service plan (as you not paying for VMs at that point), however it’s much cheaper to pay for 25 websites on a basic service plan as they will be hosted together on a VM.
  3. Dedicated VM - As mentioned above, you don’t get your own VM until you go beyond shared. This means that if you have bunch of websites on a shared tier they could have different IP addresses to each other. Once you upgrade to basic and beyond and if your web apps are inside the same app service plan they will be hosted on a same server and will have the same IP address.
  4. Scalability - When you scale your web app you are scaling the entire app service plan. This means that if you scale you are automatically scaling However you are not scaling any non-production slots. These slots will remain on the main VM, in our case these slots remain active on WEBVM1. To ensure that traffic gets distributed fairly ensure that Application Request Routing is disabled.
  5. Kudu - All web app slots come with Kudu. You can access it via https://{site name} This tool allows you to execute PowerShell, view real time logs, processes, view environment config, etc.
  6. Web Jobs - Every web app comes with a web job. To see the trace logs just go to https://{site name} Web jobs can be written in a lot of languages. They can be scheduled, queue triggered or executed on demand. These web jobs are stored inside the site/wwwroot/app_data/jobs and get executed inside the same application pool as the the main site. So if you are hosting and it's using "application pool 1", well web job for that site will be using exactly the same application pool. Why is this significant? Performance and it seems that something in Azure hits some API that invokes the web job inside the IIS context. Just an interesting observation.

How does slot swap work?

Azure Web App Swap Analysis

"Swap" is not a best name for what actually happens, it should have been called reroute. Why reroute? Because files don't get copied anywhere, config doesn't swap either, all that happens is that host names get changed and specific settings get enforced, that is it. Let's take a closer look:
  1. IIS, App & Diagnostic config - In traditional IIS you could modify virtual directories, error pages, authentication, compression, etc (green box in the picture below) with Azure you can also configure diagnostics. 
  2. Target slot setting override - When you "swap" your config doesn't go anywhere, it stays in the same slot. However there could be a override if you have ticked "Slot setting". Let's say that has an app setting WEBJOBS_STOPPED = 0 and app setting is WEBJOBS_STOPPED = 1. I've ticked "Slot setting", this way this setting will always remain the same in that slot. So when I click "swap" it will take app setting for WEBJOBS_STOPPED and override app setting inside the Why? Because will soon become production and in production slot it must always be WEBJOBS_STOPPED = 0.
  3. Warmup - After the config has been overridden with some slot specific config app gets recycled and some external Azure client invokes the app by calling the root directory e.g., this is done to warm up the app.
  4. Reroute - As soon as the website is warmed up IIS host names are changed at the site bindings level. 
  5. Source slot setting override - Now that we have a new production slot up and running the slot setting override is performed against the new staging site. This means that new staging will be down for few seconds while it's gets settings updated, recycled and it starts ups.
By now you should have learnt that app contents and config doesn't get swapped, it's just the host names that get swapped. If you have ticked "slot setting" it also performs specific config override.

For more detailed analysis of slot swap I throughly recommend reading How to warm up Azure Web App during deployment slot swap.

Bringing it all together 

Azure Billing, Resource and Containers Topology

  1. Azure Subscription - Resource and a billing container. You can create resources inside it that span across different regions.
  2. Resource group - Authorisation, billing and a resource container. You can put resources in to a resource group and give users access to just that resource group. 
  3. Sub resource group - Same as a resource group (see #2). 
  4. Service plan - Needs to be with in a subscription and a region. You can't have a service plan that spans across multi regions or subscriptions. 
  5. Region B - Can be used for disaster recovery and performance. To do this you will need to use Traffic Manager. 
  6. Traffic Manager - Used for traffic distribution, failover and routing users to closer region to reduce latency (performance). 
  7. Internal Load Balancer - Routes traffic to all of the available VMs.