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.
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:
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:
Instead, you focus all your efforts on:
If you have used a web hosting service before, then the concept will be familiar:
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.
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:
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”.
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:
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:
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.
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:
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:
Developers typically want 3 deployments:
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:
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.
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.
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.
Most web apps will require database connectivity. There are several options to choose from:
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.
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?