In a previous blog post, a high-level inventory of Azure App Service design considerations was provided. In this post, we provide further design considerations which supplement the first blog post.
Azure offers a number of ways to host your application code. The term compute refers to the hosting model for the computing resources that your application runs on. The following flowchart will help you to choose a compute service for your application.If your application consists of multiple workloads, evaluate each workload separately. A complete solution may incorporate two or more compute services. Before moving on with any design and capacity planning, you first needs to determine what is the best compute option for hosting your application code. Choosing the right application code hosting service in Azure can be accelerated by using the below flow chart provided by Microsoft.
Azure App Service design considerations
If Azure App Service is the right choice for your workloads, then you need to take into account the following design considerations:
- Do you require single-tenant hosting and a highly secure environment for your applications? Then consider the Azure App Service Environment (ASE) which comes with more sophisticated security design and dedicated hardware resources at the price of higher costs. If ASE is not required, you can move forward with the Azure App Service plan of your choice.
- Is your application developed in an Azure-supported runtime stack?
- Will you be hosting your application as a code running on a runtime stack or inside a container?
- What are the CPU, RAM, disk size and disk IOPS requirements of your application? This is the main factor which will determine the size of your App Service Plan.
- Does your app have dependencies which may determine the Azure stack to use to host the application? For instance is your app running in a container or running in specific version of the Java or .NET runtime?
- Does your app use specialized frameworks such as Web sockets and SignalR? If this is the case, then maybe some of the Azure components do not provide support for these technologies as in the example of Azure Front Door support for Web sockets and SignalR.
- How many apps will you be hosting? Will you be hosting all App Services (apps) under the same App Service Plan or not?
- What URL paths and host headers do your applications use? Make a list of all custom subdomains and URL paths as well as the TLS certificates which your applications are already making use of. This will have an impact on the configuration of your load balancing solution, either via Azure Application Gateway and WAF or Azure Front Door and WAF.
- If your Web Apps are going to be used as backend pools in a design with Azure Front Door, check the Azure Front Door design considerations blog post for details on how your Azure App Service design is interconnected with the Azure Front Door design.
- Always prefer scaling out/in rather than scaling up/down in Azure App Service. Determine the starting number of App Service instances and if you will need an autoscale policy or not.
- How many Azure App Service deployment slots do you need per App Service (app)?
- What your backup requirements? Backup size and retention window must be determined and this will have an impact on the overall storage account size needed for application backups. Do not include backup space for your database but rather take into account a separate storage space for your databases.
- What are your database connection strings?
- Do you require Azure Key Vault for storing TLS certificates and application credentials or secrets?
- What are the IIS system variables and web.config custom variables in your applications?
- Do you require App service zone-level redundancy? If yes, you need at least three App Service instances and the deployment must be made by using ARM templates from the beginning.
- How are you planning to publish your application code to Azure App Service? The following publishing methods are generally available:
- Do you require region-level redundancy for your App Services? The ideal solution would be to go for real multi-region design with paired regions, which of course comes at a high cost. Alternatively, you can utilize the emergency mode restoration in case of a region failure, which is made feasible by using App Service application snapshots, available in the premium plans.