General Information
The Azure App Service is also referred to as a Web App or Function App and is a fully managed service on which developers can run their code. It is a serverless environment that includes scalable DTU, a combination of CPU, memory and storage. Various development languages and frameworks are supported such as ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, or Python (and Go). More and more development languages are being added to this and you can follow the developments on the Microsoft website.
The App Service runs within an App Service plan that manages scaling. For professional websites, there are two Pricing Tiers: Standard and Premium. For developer and testing purposes, there are the Free and Basic Pricing Tiers. In general, we recommend setting up Acceptance and Production environments on an equal footing.
With the Scaling option, a Webapp is an excellent option to scale to the cheapest Tier outside testing times in order to save costs. When scaling, your application should be adapted for this to avoid long startup times. The App Service plan runs with an ‘Application Request Routing Affinity host’ that enables this scaling and cookie handling. This internal router handles all traffic between the Webapps during deployments, swapping deployment slots, and scaling. There are two types of scaling:
- Vertical: Scale up / scale down ▲▼: If more CPU and Memory is needed then we Scale “UP”. The Webapp capacity (DTU) is doubled per scaling, but the number of hosts remains the same. Note the hosting costs are doubled per scale (indication: 100,200,400,800,1600 etc).
- Horizontal: Scale out / scale in ◄►: If your website gets a lot of visitors, we scale “OUT”. Your site can handle a maximum of “n” number of browser requests. The web app is expanded with an extra host(s) to handle more user sessions (request per minute), for example. This can be done for up to 30 hosts simultaneously depending on the chosen App Service plan. Please note the hosting costs are doubled according to the number of Hosts (indication: 1=100.2=200.3=300.4=400.5=500 etc).
It is therefore important to always look at how many browser requests your pages create. Hereby, developments such as HTTP/3 are helpful to look at. In addition, it is also important to log your loading times of the entire site. You can then determine whether the site has become faster or heavier since the previous releases.
Deployment options
Code deployment is best done via special automation accounts that install the code integrated on the Web App via Azure DevOps pipelines. You store the code in a Git repository and link it to the infrastructure with deployment scripts.
It is also possible to manually install code to the web apps over ftp. Yet that’s more of an option for troubleshooting and viewing logs.
On the Web App page in the Azure portal, you will find the following buttons:
Given sufficient permission rights, these allow you to stop, start and restart the Web App. Be aware, that when the Web App is stopped, the Azure costs continue to run. So, it is not like a VM that has no more costs through stopping or deallocating. The Publishing profile contains all data to deploy data via FTP to the Webapp or Function App.
Configuration
A Webapp generally has a connection to a Database in the Backend. The configuration and connection string are in the Configuration page of the WebApp. Changes to these properties will trigger a restart of the Website. A connection string is required to link the Webapp to the database. For security reasons, it is advisable to store the password in the Azure Keyvault and to create a reference in the connection string. When changing the password in the Keyvault, the website will not be restarted. You give the App Service permissions to the Keyvault and not a user (e.g. Developer). In the case of privacy sensitive information, this is the most secure option. To read about the setup of this, please refer to either the manual page about the Key Vault in the ‘Managed Azure’ folder on this site, or / and the official Azure documentation here.
Custom domains
The Webapp receives a default domain name from Azure. Optionally, Azure also offers the possibility to host your own domain name on the Web App with managed SSL certificates. This means that the certificates are automatically renewed free of charge. This is included with the web app and replaces the purchase of a Certificate and periodic renewal. For this, a CNAME and TXT record must be created in the DNS. True can help you create and validate this record and install the SSL Binding on the custom domain.
Follow these steps to add a DNS record in the Azure Portal:
- Open the Azure portal and navigate to the ‘App Services’, select the respective Web App
- In the Settings menu, select ‘Custom domains’
- Select ‘Add custom domain’
- Select ‘All other domain services’ (if you don’t host DNS with Azure)
- Enter the domain name
Automatically generated DNS records will then appear that you can create (or have created) at your DNS provider. Indicate that you want to set the TTL to 599 seconds (=10 minutes – 1 second). After this has been completed, you can add the Custom domains as described above.
Troubleshooting in the Azure Portal
Logging
A Web App or Function App creates an event log and, depending on the configuration, application logs. You can link the logging to different types of Application loggers. Azure native is App Insights that allows you to write multiple resources to provide diagnostic insight into your application, database, web server and workflows. Application Insights also offers real-time logging if the developer has enabled this in the application, you can then filter your SQL, website and transactions in real time. The logs are normally written to disc, but a Web App is not a large storage environment, so keep in mind that you rotate the logging monthly or weekly. You can find more information under the manual page ‘Azure – Resource logs’, or / and the official Azure documentation here.
Kudu interface
Under Development Tools, you will find the Advanced Tools containing the Kudu Interface with which you have a Prompt interface with the underlying OS (Powershell/Command/SSH). Via the Prompt you can open, edit, upload and download all files, such as the Configs, inis, Application logs and Event logs. See more about the Kudu interface here.
Under Monitoring, you will find a number of powerful diagnostic tools including the Log stream interface. This allows you to see real time logging passing by.