When it comes to migrating apps to Azure, one of the common asks I see is - hey I got a static web app with some .NET based WCF/REST services as a backend using SQL databases. How can I deploy the App in Azure and design it to be multi-region & highly- available?
In this article, I will document a few simple patterns - this is a working document, I aim to add scripts in future so you can deploy these with one click.
Pattern 1:
All PaaS pattern, the design aims to keep the cost low and considers Active-Active type setup.
Service Summary
- Azure Front Door (AFD): [Resource Type: Global]
- Acts as single-entry point for API and Static Site
- Additional Capabilities CDN + WAF + SSL offloading + Edge Acceleration
- You can implement IP based whitelisting if required - API Management: [Resource Type: Regional]
- You can apply Policy-based restriction to allow incoming Traffic from AFD (see here)
- When making calls to backend APIs on Web App it can inject certificate, that Web Apps enforce and can verify (see here)
- Allows throttling, caching etc. - Web App and App Service Plan: [Resource Type: Regional]
- Hosts APIs (WCF and REST)
- Some changes might be required e.g., adding logic for Certificate-based access
- Web Apps are integrated into VNET using VNET integrations, to help you connect to private endpoints in VNET and on-prem resources
- You can use alternatively use Hybrid connection to connect to on prem resources (see here) - Static Site: [Resource Type: Regional]
- You can use Azure Static Site (In-Preview) or Blob based Static site (with RA-GRS) - SQL DB: [Resource Type: Regional]
- Azure SQL DB with Geo-Replication is straight forward option to allow DBs to work
- Depending on number of SQL DBs required and usage patterns you can consider Elastic pool option to save costs - Key Vault: [Resource Type: Regional]
- To store secrets, it has built-in DR, in the case of regional outage secondary region acts as a read-only endpoint, hence only one instance - App Configuration: [Resource Type: Regional]
- Not shown in Architecture but can be considered if required to externalise configurations
Pattern 2:
If you wish to containerise and run the application into Kubernetes then here is a simple pattern for the same, the design aims to keep the cost low and considers Active-Active type setup.
Service Summary
- Azure Front Door (AFD): [Resource Type: Global]
- Acts as single-entry point for API and Static Site
- Additional Capabilities CDN + SSL offloading + Edge Acceleration
- You can implement IP based whitelisting if required - API Management: [Resource Type: Regional]
- You can apply Policy-based restriction to allow incoming Traffic from AFD (see here)
- When making calls to backend APIs on Web App it can inject certificate, that Web Apps enforce and can verify (see here)
- Allows throttling, caching etc. - App Gateway: [Resource Type: Regional]
- As an ingress controller, also used for SSL offloading and WAF for API and static site - AKS Cluster: [Resource Type: Regional]
- Hosts WCF/REST into Windows Container and Static Site into Linux
- Deployed as Zone Redundant running Linux and Windows Node Pool
- APIs running on the .NET framework will run into Windows Node Pool
- Injected inside your VNET so you can get private IP for services (if required) - SQL DB: [Resource Type: Regional]
- Azure SQL DB with Geo-Replication is straight forward option to allow DBs to work
- Depending on number of SQL DBs required and usage patterns you can consider Elastic pool option to save costs - Key Vault: [Resource Type: Regional]
- To store secrets, it has built-in DR, in the case of regional outage secondary region acts as a read-only endpoint, hence only one instance - App Configuration: [Resource Type: Regional]
- Not shown in Architecture but can be considered if required to externalise configurations - Azure Container Registry (ACR): [Resource Type: Regional]
- Highly-available Container registry Geo-Replicated.
Please note this is work in progress, leave a comment on what you would like to see in this article.
