Azure App Service

Azure App Service design considerations part 2

by

Introduction

In a previous blog post (azure app service design considerations part 1), a high-level inventory of Azure App Service design considerations was provided. In this post entitled Azure App Service design considerations part 2, we provide further design considerations which supplement the first blog post.

Also refer to the following freely downloadable .pdf document which includes a series of tasks and tools to plan for when designing an application migration to the Azure App Service PaaS offering:

https://stefanos.cloud/free-downloads/

Part 3:

While part 1 and part 2 cover the cloud/systems architect design perspective, in this third, and last, part of the Azure App Service design considerations post we cover items which must taken into account from an application developer perspective, when utilizing Azure App Service for migrating their apps or when designing their apps from scratch to be hosted in Azure App Service as Cloud Native apps.

Choosing App Service vs other app hosting solutions in Azure

There are a number of ways to host your application code in Azure. This could be IaaS based (virtual machines) or PaaS-based, e.g. Azure App Service or Azure Kubernetes service (AKS).

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 (provided by Microsoft) 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.

Decision tree for Azure compute services

Besides choosing App Service vs other Compute solutions for your application code, you should normally have to decide upon the proper load balancing and application gateway solution for your application. Review the following resources for guidance:

The “Help me choose” wizard in the Load Balancing services section of the Azure portal should help you make your decision based on your requirements as design factors.

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?
  • Check the limits of all components involved in your solution, including App Service. More details on the Azure service limits can be found at: https://stefanos.cloud/azure-service-and-component-limits/.
  • 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.
  • Does your app support load balancing and ARR affinity? You need to evaluate the operations of your application in load balancing mode by utilizing multiple application nodes and check if you are using ARR affinity cookie (stateless or stateful app). In order for your app to be horizontally scalable in Azure App Service, load balancing must be supported. In a nutshell, if your app is stateful, scaling up would be best, while if your app is stateless, scaling out gives you more flexibility and higher scale potential. A good analysis of application state types (stateful vs stateless) and load balancing support for App Service can be found at: https://learn.microsoft.com/en-us/answers/questions/39015/azure-app-service-arr-affinity-auto-scaling-statef.
  • How many Azure App Service deployment slots do you need per App Service (app)?
  • Carry out planning for the functional and non-functional (security, availability/resiliency, performance, scalability) of your App Service components and the non-App Service components that integrate with App Service. Plan for stress (load) testing tools to stress your solution under load similar that that of the expected production.
  • 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:
    • Visual Studio publishing via publishing profiles and Web Deploy
    • FTPS
    • ZIP package
    • Manual from local git
    • Manual from online git
    • CI/CD with Azure Pipelines
    • CI/CD with third party pipeline service, e.g. Bitbucket
  • 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.
  • Review the “How to diagnose and solve problems in Azure App Service” KB article. This lists all possible issues which can be detected in an Azure App Service deployment. By reverse-analysis, you should take all these factors into consideration when designing your App Service to prevent any issues from occurring. This however can be a very lengthy process and may not always produce the desired results, since some issues may only be manifested and discovered after extensive stress (load) testing for a sufficient period of time. Therefore always ensure that you carry out a proper stress testing methodology, both in terms of application traffic/load and in terms of an adequate time period to be certain that any issues are detected early in the new App Service.
  • Ensure that you employ all recommended Azure App Service Patterns and Features for the Azure Well-Architected Framework five (5) pillars, namely cost optimization, reliability, operational excellence, performance efficiency and security. More details can be found at: https://techcommunity.microsoft.com/t5/fasttrack-for-azure/azure-app-service-patterns-and-features-for-the-azure-well/ba-p/3696156.
Cost Optimization Reliability Operational Excellence Performance Efficiency Security 
Automate deployments and testing with CI/CD   X X  X  X 
Deployment slots X X X   
Scale-up/Scale-out X   X  
Perform Chaos Engineering   X X     
Perform Load Testing  X X X  
Use Managed Identity for Azure Resource access   X X  X
SSL/TLS support     X    X 
App Service Environment  (ASE)    X X 
High availability design  X X  X 
Store credentials and other values in Azure Key Vault    X  X 
Install a web application firewall (WAF) X X   X
Authenticate through Azure Active Directory (AD)          X 
Virtual Network (VNET) integration       X  X X 
Design for scalability     X  X  X 
Reduce response time and connection timeouts with asynchronous programming design patterns    X    X
Optimize with data compression  X  X       
Implement Retry and Circuit Breaker patterns    X    X   
Logging and Monitoring   X  X  XX   X

Sources