Introduction to Azure App Service - part 1 (The overview)

Let’s dive in and talk about what Azure App Service is. To provide you with some more context, I’m going to take a step back and talk briefly about what Microsoft Azure is. Don’t worry, I won’t bore you with general cloud information, this is just to create the right context to appreciate what App Service is.

As you know, Microsoft Azure is Microsoft’s public cloud offering, and it is very successful. It was first introduced as a Technical Preview in 2008 at the Microsoft PDC conference (remember those?) under the name Windows Azure. And it offered basic Azure Storage, Cloud Services and Virtual Machines. The idea was that this would be the new server-based Operating System environment in the cloud. The cloud equivalent to Windows Vista as you will (but obviously better than Vista). And in 2009, Microsoft added SQL Azure to its Azure preview, which was revolutionary. Together with Cloud Services, this provided the first-ever Platform-as-a-Service offering that developers could use. Later in 2009, support for PHP and Java was added, signaling the “everybody is welcome in our cloud” approach. Windows Azure became publicly available in 2010 and was renamed to Microsoft Azure in 2014. Currently, Microsoft Azure accounts for most of Microsoft’s revenue and is one of the primary products that Microsoft works on. This is an amazing shift in focus from the pre-cloud era, where Microsoft made most of its money by selling Windows and Office products. 

Because Microsoft’s main priority is delivering value through its cloud services, I always advise my customers to run their applications in Azure. This enables them to focus on creating their application, not on running it. And the easiest way of running an application in Azure is on Azure App Service. 

In this series of posts, we’ll cover all these services in more depth, and we’ll look at how they relate to each other and which ones are best suited for which scenarios. 

All the Azure App Service types run in Azure. And Azure magically makes sure that they keep running and that they can scale up and down. Azure does that by using its Service Fabric. You might have heard of Service Fabric as this is now one of the services that you can use yourself. Service Fabric powers a lot of services in Azure, including App Service.

The VMs that Service Fabric uses, are the actual things that your App Service runs on. And you can choose what type of VM Azure should use to run your App Service. You do this by configuring the App Service Plan.

Because all the services in App Service belong to the same family and share the same technological basis, they share some common features. Here is a list of all the shared features and a brief description of what they are. I don’t mention all of the shared features as some of them aren’t only shared by App Service but are features that all Azure services share. Please note that these shared features will change over time. 

These are deployment features that you can use within all App Service types (some of them might not be available when your run Function Apps in a serverless way).

The deployment slots feature is one of the features that adds a lot of value with little work. A deployment slot is a fully functioning App Service, like a Web App, that runs next to your original Web App. You can use a deployment slot to deploy a new version of your application in and test it. And the beauty of this feature is that you can swap a deployment slot into production with zero downtime. This means that you can deploy the new version of your application to production without having any downtime. We’ll talk more about deployment slots in the post about Web Apps.

When you have one or more deployment slots, you can use them to test in production. You can configure if and how much traffic you want to be routed to each of your deployment slots. For instance, you could route 10% to your staging slot and the rest (90%) to your production Web App. 10% of your users will be sent to the deployment slots and those users get to test your new features.

You can use the deployment center feature to connect a code repository to your Web App and have that code built and deployed whenever it is updated. So the deployment center enables you to implement Continuous Integration (build every time code is checked in) and Continuous Deployment (deploy every time the code was built successfully). 

These are shared settings that you can use within all App Service types (some of them might not be available when your run Function Apps in a serverless way).

The application settings let you configure everything from the .NET Framework version that the App Service runs, to which HTTP version it runs. In here, you can also add application settings as key/value pairs and connectionstrings to other services. 

App Service allows you to easily require users to authenticate before they can use your application. Just flip a switch and choose which identity provider you want to use. You can choose Google, Facebook, Twitter, Microsoft, Azure Active Directory or a custom provider.

You can configure the Azure Monitor Application Insights extension that runs in the Ap Service. This extension collects performance and diagnostics information from the App Service and sends that to the Application Insights instance that you use to monitor and analyze your App. 

The identity feature allows you to assign a Managed Service Identity to the App Service. This is an identity that lives in Azure Active Directory and can be used to authenticate to other services, like Azure Key Vault. Using this, you don’t need to store any credentials in your code or in the configuration of your App Service to authenticate to services like Azure Key Vault. 

You can create backups of everything in your App Service on a regular basis. Backups saves the content, so the application and the settings of your App Service. It can also backup connected services, like an Azure SQL Database that is connected to the App Service with a connection string. These backups are useful for when you want to revert to a previously working version of your App Service.

When you create an App Service, it has a URL that you can access from the internet. By default, this is something like xxxxx.azurewebsites.net. You can couple your custom domain names to the App service, so that you can reach it through your URL. You can also buy a domain and couple it to your App Service, straight from the Azure portal. The domain that you buy there, is actually bought from GoDaddy.com.

You can secure the traffic to your App Service by adding SSL certificates and binding them to domains that are assigned to your App Service. The default App Service URL, xxxxx.azurewebsites.net, is already secured with an SSL certificate. For custom domains, you can use SSL certificates that you’ve bought somewhere. Or you can use an Azure App Service Certificate that you buy through the Azure portal. Azure App Service Certificates are bought from GoDaddy.com.

You can protect your App Service by adding IP restrictions. And you can create hybrid connections to your App Service that connect it to services and data stores that run somewhere else than Azure, for instance in your own datacenter. And you can use virtual networks to securely connect services to your App Service.

When you increase the amount of compute resources that run your App Service, you call that scaling up. You can do that by choosing a higher pricing tier for the App Service Plan. This will provide your App Service with more CPU, memory and disk space. Obviously, you can also scale down to save costs.

Scaling out happens when you increase the number of instances that you run. In App Service, you can scale out with a manual slider, to increase the amount of App Service instances that you run. Or you can scale out automatically, based on a schedule, or on metrics like when the CPU utilization hits 70%. You can also create an automatic scaling method that uses both a schedule and metrics. 

A very interesting feature of App Service is WebJobs. WebJobs is actually a type of service that you can use to run background jobs with. And they can be triggered by a schedule or by an external event, like when a new message arrives on a queue. All that you have to do, is write the code that does something whenever the WebJob runs. This is really powerful. WebJobs are very similar to Azure Functions, which run in Function Apps. In fact, Azure Functions are built on the same technology as WebJobs. Functions are the evolution of WebJobs, but you can still use WebJobs and they might stick around for a while.

If you want to send push notifications to applications, you can use the Push feature in App Service. This enables you to send push notifications to many push notification platforms, like the ones from Apple, Android and Windows, without you having to cod the specific implementations for these platforms. We’ll discuss te Push feature more in the post about Mobile Apps.

An easy way to use a MySQL database with App Service is by using the MySQL In App feature. This basically instantiates a MySQL database in memory with the App Service and you can use it immediately. This is very performant, as the database is as close to the application in the App Service as can be. You cannot use it when you scale out though (increase the number of instances), as the MySQL instance is only available in the memory of the App Service. When you scale, and another instance of your application runs on another VM, the MySQL data will not be available on that machine. 

You can change the App Service Plan that your App Service runs on. This can help when you want to co-locate your App Service Apps in one App Service Plan to save costs. Or to spread App Service Apps over multiple App Service Plans, to increase performance.

These are shared development tools that you can use within all App Service types (some of them might not be available when your run Function Apps in a serverless way).

If you want to quickly create an App Service App to create one that is exactly the same as the original, you can use the clone app feature. This allows you to copy an App Service App and thereby saves you time. Clone app doesn’t clone custom domains and does copy over the content of the App Service, so the application. 

The console allows you to manage your App Service through a console by using commands like mkdir. It allows you to navigate through the filesystem of the App Service that hosts all of the files of your application.

The advanced tools feature takes you to the Kudu environment. This is a management web application, that runs next to your App Service App. In the Kudu environment, you can manage the filesystem, manage App Service extensions, see the processes that are running and more. Most of the features that made the Kudu environment unique in the past, are now elevated to first-class App Service features, like the console feature.

This is an experimental feature. By the time that you read this, the App Service Editor might have a different name or might not exist anymore. If it is still there, you should check it out. The App Service Editor allows you to go to the files in your App Service and edit and save them in an online code editor. You shouldn’t use this for production purposes, as you want your code changes to come from a code repository, like GitHub or Azure DevOps. 

You can start and monitor performance tests, straight from your App Service. This feature uses Azure DevOps in the background to provision resources for a performance test and execute it. Performance tests that you execute with this feature only support simple test scenarios, like hitting a specific URL of your application. You can use Azure DevOps to create and execute more complex performance tests. 

These features used to be unique to API Apps but are now part of the shared features. Every type of App Service can use these features.

The API definition feature lets you configure the location of the Swagger metadata describing your API. This makes it easy for others to discover and consume your API.

CORS stands for Cross Origin Resource Sharing and allows client-side code (most often JavaScript) to interact with your backend, which is the App Service in this case. You can use this to create a whitelist of domain names that have client-side code that can interact with your backend.

There are lots of monitoring strategies for App Service. These features are the built-in options that you can use without using additional services. 

The Metrics feature allows you to explore and monitor metrics, like the CPU time used, or the amount of server errors over a certain period of time. It even allows you to monitor metrics like Gen x Garbage Collections. And it allows you to create alerts for the metrics that you monitor.

Diagnostic logs create logfiles for everything that happens in your App Service. You can store these logs in the file system of the App Service, or somewhere else, like in Azure Blob Storage. There are several types of diagnostic logs that can help you to diagnose your App Service: