Introducing Azure Web Apps

In this post, I will explain what Azure Web Apps are and what they offer to businesses that require an enterprise-class facility for line-of-business web-based applications running in the cloud.
 

 

Familiar Territory

You have probably already learned a great deal about the concepts of Azure Web Apps without even realizing it. You have probably worked with Web Apps in the past.
Most IT pros have done one or both of the following:

• Set up IIS on Windows Server or a web server, such as nginx, on Linux.
• Set up a website, costing a few dollars per month, running with a hosting company that takes care of the virtual machines for you.

Web Apps are a service provided by the Azure Service Fabric, enabling you to run a website or application without worrying about the virtual machines. Underneath the Service Fabric are a collection of Hyper-V virtual machines that the Service Fabric and Azure manage. This is its responsibility to give you a highly available, self-healing service on which your web app runs.

This abstraction frees you of most responsibilities:

• Deploying virtual machines
• Patching
• Running IIS

Instead, you focus all your efforts on:

• Architecting the application
• Coding the application

If you have used a web hosting service before, then the concept will be familiar:

• You request and are given capacity to host a web application.
• The website is written and you upload your code.
• The desired DNS domain name is associated with your site.
• You test the site and you go live.

Not once will you log into a virtual machine. You do everything through an easy-to-use portal. In the case of Azure, that portal is the Azure Portal but other than that, the commonalities come to an end. That several-dollars-per-month hosting plan is fine for a brochure site with a small amount of traffic but Azure offers much more.

Scaling Up/Out

Beneath the Service Fabric, one or more virtual machines host your web app. This virtual machine or set of load-balanced machines is a member of a service plan. The service plan determines the pricing of your solution:

• Service level agreement (SLA)
• The spec of an individual virtual machine (RAM and processors)
• How many of these virtual machines can host a web app
• Scalability and features supported, such as auto-scaling (number of virtual machines), backups, and SSL certificates

One can manually manage the number of virtual machines in a service plan that host a website. This can lead to idle periods where unneeded machines are running and accruing charges. Autoscale allows Azure to dynamically determine the correct number of virtual machines to power up to run your site. More traffic (and profitability) requires more machines. Less traffic (and profitability) leads to fewer machines being used. We can let Azure solve the “Ticketmaster Problem”.

Windows and Linux

When you deploy a web app, it can be based on abstracted Windows Server or Linux virtual machines. You can also craft new apps based on more than just .NET:

• js
• PHP
• Java
• Python
• Static HTML

Security

There are numerous security options available to you with Azure Web Apps. You can obviously secure transactions on a site using a TLS (the replacement for SSL) certificate. You can even purchase certificates through Azure, making it easy to secure your sites.
You also have the option to enable authentication to prevent unwanted access to corporate or public-facing applications using solutions such as:

• Azure AD, optionally with multi-factor authentication
• Active Directory
• Microsoft Account
• Facebook
• Google
• Twitter

 

 
I have configured Azure AD and Google authentication. The mechanism was a little fiddly. Within a few minutes, I did get it up and running using Microsoft’s documentation.

Cross-Region Support

A trait of Azure is that you can deploy services in any of the normal regions around the world. For example, a business that is selling to Irish emigrants might set up a site in East US, UK South, West Europe and Australia Southeast.
Each of those regions could be shared out using a single URL and by aggregating them under the abstraction of an Azure Traffic Manager profile. This profile, configured for performance, would redirect a client to the “closest” (by latency) web host. For example, a browser in New Zealand should be redirected to the web host in the Azure Australia Southeast region.

 
We can also use Traffic Manager for disaster recovery. Instead of just deploying to East US, I could deploy my application to East US and West US. I could abstract those two sites under another Traffic Manger profile. I would have two options:

• Enable failover mode so that only one site is actively receiving traffic at a time.
• Use load balancing so that I spread the traffic across the two regions. This makes use of the services that are running and that I am paying for.

Continuous Delivery

A good developer stores their code in a managed solution, such as GutHub, and manages the release of code in a structured manner. Azure Web Apps fully support this concept, enabling you to upload your code to your web hosts in many ways:

• FTP
• OneDrive or Dropbox sync
• GitHub
• Local Git repository
• BitBucket
• Visual Studio Team Services

Deployment Slots

Developers typically want 3 deployments:

• Development
• Test
• Production

Azure Web Apps support this concept using Deployment Slots. Instead of you deploying 3 copies of a web app, you deploy 2 additional deployment slots. Production is there by default. Each deployment slot creates a new Web App in the existing service plan and on the existing virtual machines.
You can make use of these deployment slots in two ways:

• Swap: You can test a new version of the site in a test slot. When you have a stable version that is signed off, you can warm up the test deployment slot. Then, you swap it with the production slot. Immediately, any client browsing the site is hitting the new version of the code.
• Staged deployment: You can introduce new code to a small defined percentage of browsers as a pilot release. Most people will hit the older deployment slot but some will hit the new deployment slot. This approach allows you to validate code under production stress but without affecting all clients.

A question I had about this was how to handle connection strings to dev, test, and production databases. Application settings, such as a connection string, can be made sticky with a deployment slot. When you swap a web app from test to production, it will switch to the production database. The old production deployment slot will switch to the test database.

Performance

It can take many milliseconds for a browser to download each byte of a webpage. The further a website is from a client, the slower the website appears to be, the less satisfied the client will be with the site. I am sure that Microsoft would love global companies to run large web farms in every single Azure region but there is another option.
The Content Delivery Network (CDN) feature can be used to cache website content in data centers around the world. This makes one or a few central websites much more effective and appear to be faster. The web servers receive less traffic (still the same number of hits) and are under less pressure. They are focusing more on transactions than serving static content. That static content is instead serviced by the CDN. You can use Microsoft’s CDN but alliances have been formed with other CDN companies such as Akamai.

Backup

Your web app and the database content will have value. You can backup these assets to an Azure storage account (blob storage) using an automated task.

Database Connections

Most web apps will require database connectivity. There are several options to choose from:

• Database-as-a-Service: Azure’s data services offer numerous database options including Azure SQL, Document DB, Cosmos DB, MySQL, and more. Much like with Web Apps, you can run databases without ever deploying a virtual machine or installing the database software.
• Azure VNet connection: A web app can connect to a database running in an Azure virtual machine by using the point-to-site VPN capabilities of a gateway running in the VNet of the virtual machine.
• On-premises database: It is possible to create a hybrid connection to an on-premises database. You can leverage the scale and performance of Azure for the web app, while controlling the sovereignty and compliance of the database.

Background Processing

Azure Web Apps have had the ability to run background tasks (programs or scripts) using Web Jobs for years. This is a process where the task can run in the same service plan (virtual machines) as the website. Microsoft normally recommends to isolate the web jobs into its own virtual machine for performance and scaling reasons.
In recent months, Microsoft has been encouraging a server-less alternative to Web Jobs called Functions. A program or script can be written and ran on demand or based on a trigger without the on-going cost of a virtual machine. Instead, functions are charged based on time running.

Summary

If you start to experiment with Web Apps, you will find it pretty easy to get to grips with. The core feature is similar to other web hosting systems but there is so much more to Web Apps. I have realized, and some of my customers have started to realize, that Web Apps are an important part of the “digital transformation” journey. (Could I get a drink, please!) I wonder how many virtual machines in Azure, other clouds, and virtual private server (VPS) hosting plans are used as web servers. How much money could customers save by switching to Web Apps? How much more control would business have? How much more effective would developers and testers be when driving these systems using tools that they know such as Visual Studio, GitHub, and VSTS?