This article is entitled Azure App Service design considerations part 1 and is part of an article series.
Check a more recent blog post (Azure App Service Design Considerations Part 2) for additional design considerations which supplement this 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/.
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.
Microsoft Azure App Service is a PaaS service in Azure. The Azure App Service can be used to modernize your Web apps, API apps and mobile apps and can work with various software development frameworks and runtime stacks.
When designing an offer and implementation for migrating a customer’s on-prem application to Azure App Service, a series of considerations need to be taken into account. Usually a technical questionnaire can be shared with the customer and the collected feedback should be matched directly to the design factors in order to make proper design decisions.
Azure App Service design considerations
At a minimum the following design considerations should be made.
- Plan for the target user audience, including number and location of maximum and concurrent users. This affects the sizing of the Azure App Service instance, mainly depending on the concurrent IP connections/sessions.
- Will the app be imported from a code base or will it using a Docker container?
- Plan for a source code versioning mechanism/repository, e.g. Github.
- Plan for the runtime stack of the migrated application(s), e.g. .NET, .NET core, Python, PHP, Ruby, etc.
- Estimated conventional hardware resources (RAM, CPU, disk size and type, IOPS, bandwidth) that the application consumes under normal and stressed conditions. These should be translated into Azure App Service ACU (Azure Compute Units).
- What type of data storage does the application use? This could be a SQL (e.g. MySQL, PostgreSQL) or non-SQL flat database (e.g. CosmosDB). For each associated database, the exact release number (version) and storage space requirements should be defined. Also, does the App Service need an Azure Files mount for SMB-based persistent data storage?
- What Azure App Service networking features will be used for inbound (ingress) and outbound (egress) traffic of the App Service? Azure offers the following network features for inbound traffic: App-assigned address, Access restrictions, Service endpoints, Private endpoints. Also the following features are offered for outbound traffic: Hybrid Connections, Gateway-required virtual network integration, Virtual network integration. VNET integration may or may not require Azure NAT Gateway integration for the App Service subnet, to accommodate for potential SNAT port exhaustion issues.
- Application authentication and authorization mechanisms and identity management (e.g. Windows/Azure AD vs SQL authentication and MFA).
- Does the App require only standard backups or application snapshots as well (premium feature)?
- Are Azure Application Insights (app monitoring) required? Do you need to plan for application code instrumentation via the Azure Application Insights API?
- Does the Azure Web App require strict isolation and security? This will determine if Azure App Service Environment (ASE) will be used or not.
- Will a VPN be needed with private IP address space or will the solution be accessible from the public Internet?
- What are the load balancing requirements? This article should be considered when deciding upon the appropriate L4 vs L7 load balancing service option in Azure.
- What are the high availability and scalability requirements? Does the solution need to be a single-region or a multi-region solution? The appropriate Azure App Service architecture blueprint should be utilized based on this decision, ranging from a basic to a fully scalable multi-region Web App.
- Review the migration checklist at https://azure.microsoft.com/en-us/blog/migration-checklist-when-moving-to-azure-app-service/.
- If you are using the Application Service Environment (ASE) service, consider using the ASE v3 migration tool: https://learn.microsoft.com/en-us/azure/app-service/environment/migrate.
- Ensure that you take all possible App Service limitations or known issues into account before proceeding with your design. Consult the following article for more details: https://stefanos.cloud/azure-service-limits-and-known-issues/.
- Does the app have any special security, privacy, governance or compliance requirements, e.g. HIPAA, PCI DSS compliance, etc?
When planning an on-premise ASP.NET application to Azure App service migration, make use of the pre-migration Powershell audit scripts. This is a generally available service since March 2023, as per: https://azure.microsoft.com/en-us/updates/general-availability-asp-net-web-app-migration-to-azure-app-service-using-powershell-scripts/. For details about the PowerShell migration scripts please refer to ASP. Net web app Migration to Azure App Service using PowerShell Scripts – Microsoft Community Hub or visit Azure App Service migration tools | Microsoft Azure.
Also for .NET application assessment and migration, consult the following tools and procedures:
Microsoft released the Azure App Service Migration Assistant Tool, which is available at https://azure.microsoft.com/en-us/blog/introducing-the-app-service-migration-assistant-for-asp-net-applications/.
Visit the following link to start your App Service migration procedure: https://azure.microsoft.com/en-us/products/app-service/migration-tools/