Azure App Service
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.
So, what is Azure App Service? To understand what it is, it is useful to know how it came into existence. In 2012, Microsoft added Azure Web Sites to its Azure services portfolio. This service was created specifically for people that wanted to run web applications in Azure. This service was very popular but missed specific features for other developers that were creating mobile applications and APIs. So Mobile Services was added for the mobile app developers. And after that both services were renamed to Web Apps and Mobile Apps.
As developers requested even more specific features, Microsoft added API Apps (for running APIs) and Logic Apps (for running workflows) to the service offering. As all these services were related, Microsoft added them into one big family of services, called Azure App Service. Later, in 2016, Function Apps were added to App Service. Also, Logic Apps were removed from the App Service family, as Microsoft rebranded Logic Apps to be the go-to service for doing integration and workflow tasks (think BizTalk) in Azure.
Azure App Service is meant to be a single product, that has capabilities for whatever you need, mobile, web or api. But in practice, it is a family of several services, that each bring something unique to the table.
Currently, the Azure App Service platform contains these services:
- Web Apps
- For running web and api applications in Azure
- Mobile Apps
- For running the backend for mobile applications in Azure
- Function Apps
- For running small blocks of code in Azure that can be triggered by outside sources, like a message on a queue
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.
App Service runs on an App Service Plan
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.
Azure Service fabric keeps your App Service running. For instance, when you have a Web App that is running a website, Service Fabric makes sure that it runs on a VM, in a Microsoft datacenter. And if that VM fails, or if the underlying hardware fails, Service Fabric moves the Web App to another VM and/or physical server, so that it continues to run. Service Fabric also takes care of scaling for you. When you scale your Web App, by, for instance scaling it out over multiple instances, Service Fabric replicates your Web App over multiple VMs and keeps those running. This is the magic of Azure and this is what makes it so easy for you to run something like a Web App. Service Fabric takes care of all of this. You don’t have to worry about it. You just deploy a Web App and it runs and keeps running.
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.
An App Service Plan is the logical abstraction that represents one or more VMs that your App Service runs on. It is a representation of compute resources, like CPU, memory and disk space. This is the unit that you pay for when you use App Service. You pay for the App Service Plan, not for the actual App Service apps that you run in it. And the nice thing about App Service Plans is that you can run as many App Service apps in there as you want. You could, for instance, run 10 Web Apps in the same App Service Plan. Obviously, if you run 10 applications in one App Service plan, they all share the same compute resources. So, you have to keep in mind that all of these applications can run within the limits of the CPU, memory and disk space of your App Service Plan.
The amount of App Service apps that you can run in an App Service Plan is bound by the pricing tier, but still, this can save you a lot of money. The pricing tier represents the amount of resources that your App Service Plan has, so basically, how large the VMs that it represents are. An example of a pricing tier is the Standard 1 (S1) pricing tier, which, at the moment of this writing, offers 1 CPU core and 1.75 GB of RAM and 50 GB of storage. The S1 pricing tier also allows you to add an unlimited amount of App Service apps to your App Service plan, where the shared tier allows you to run 100 apps in your 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.
Deployment slots – testing in production
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.
Authentication / Authorization
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.
Azure Monitor Application Insights
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 form 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.
Scale up (App Service plan)
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.
Scale out (App Service plan)
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.
MySQL In App
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.
Change App Service Plan
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.
Advanced Tools (Kudu)
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.
App Service Editor
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.
Sometimes, you need more functionality than App Service can provide out-of-the-box. In these cases, you can install extensions in your App Service. There are lots of extensions, like monitoring solutions from New Relic and Stackify and even the Application Insights extension from Microsoft. There are also extensions for to enable the Python runtime and runtimes for other programming languages.
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.
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:
- Application logging
- This contains trace information you write from your application
- You can indicate the logging level: Error, Warning, Information or Verbose
- Web server logging
- Information of the webserver itself
- Detailed error messages
- Detailed information about exceptions in your App Service
- Failed request tracing
- Specific information about requests to your App Service that fail
The log stream feature can be used to, you guessed it, stream the diagnostic logs to the screen. This enables you to see the logs as they happen.
Those were a lot of shared features
We’ve just covered all the feature that each App Service type shares. There are a lot of them. The next posts in this series will focus on individual App Service types and their unique features.