Reference Architecture: Web Application Hosting in Azure
The objective of this article is to describe a high-level solution architecture for a green-field application or to migrate an existing application on Azure Public Cloud using PaaS first approach. The solution takes advantage of various azure managed services such as Azure Application Gateway (Layer 7 load-balancer), App Service, App Service Plan, Blob Storage, Azure SQL Database, Virtual networks, etc. It also encompasses design decisions, best practices, database migration strategy, and automated CI/CD pipelines. The proposed solution is highly manageable, secure, scalable, efficient, elastic, highly available, fault-tolerant, and recoverable.
Architecture Overview:
The following diagram depicts the various components that are being used to deploy a .NET application in Azure Public Cloud. Besides this, the solution can be extended for any other programming language (.NET Core, Node.js, Java, Python, or PHP) of your choice.
Resource Group — All the resources should be provisioned in a single resource group (RG) for a specific environment. However, as a best practice, a separate resource group must be provisioned for each environment (Dev/Test/Stage/Prod). In addition, an independent resource group must be created to keep the terraform remote state file separately & securely.
Application Gateway — Application Gateway is a layer-7 application load balancer that should be deployed in a separate Virtual Network inside a dedicated Subnet. The CIDR address for the subnet could be /28 or /29 as recommended by Microsoft. This will provide 11 or 3 usable IP addresses respectively. As HTTPS will be used for any incoming traffic via App Gateway, a certificate (PFX) must be installed on the app gateway. Before a client sends a request to an application gateway, it resolves the domain name of the application gateway by using a Domain Name System (DNS) server. The Azure DNS returns the IP address (frontend IP address) to the client, which must be configured properly. In addition, WAF (Web App Firewall) would be enabled to avoid any malicious attacks such as SQL injection, cross-site scripting, etc. The various web apps/Rest APIs would be configured as different backend pools and if required, path-based routing can also be set-up in the App Gateway. It supports high-availability scenarios, ensures that the newest instances are also spread across availability zones to offer zonal failure resiliency, and also supports scalability by adding multiple instances of the same gateway to share the load.
App Service Plan — One of the vital design decisions is to create a single App Service Plan for multiple apps so that they can scale well. Both the applications (app1 and app2) as shown in the above architecture should be deployed in one App Service Plan.
Azure App Service — Azure App Service is a fully managed platform (PaaS) to quickly build, deploy and scale web apps & REST APIs in different programming languages — NET, .NET Core, Node.js, Java, Python, or PHP, in containers — without managing infrastructure. It offers auto-scaling (both scale-up & scale-out) and high availability, supports both Windows and Linux, and enables automated deployments from GitHub, Azure DevOps server. It increases the developer’s productivity by supporting integration with different IDEs like Visual Studio Code and Visual Studio. We should use private service endpoints for the Azure Web Apps to allow only application gateway located in a virtual network (VNet) to securely access the apps over Private Link.
Azure SQL Database — There are various approaches to provision MS SQL server in Azure such as Azure SQL Database, Elastic Pools, Azure SQL Managed Instance or SQL Server on Azure VMs. Depending on the use-case, we can select the right database. We have provisioned “Azure SQL Database (vCore model)” in a separate private subnet to keep the database isolated. The communication to a database is restricted only to the app tier via VNet Service Endpoints for additional security.
Azure BLOB Storage — Two separate storage accounts have been provisioned in 2 different resource groups as shown in the architecture diagram. One to keep the database backups, log files, and the other to store terraform remote state files separately and securely. Database auditing logs will also be written in the storage account. Blob storage offers 3 types of resources — the storage account, a container in the storage account, and a blob (actual files) in the container.
VNet Service End Points — The traffic using VNet Service endpoints flows over Microsoft backbone, thus providing another layer of isolation from the Public Internet. These service endpoints would be used while accessing Azure SQL Database or Storage accounts from the App services.
Azure Monitor — Azure monitor is a Cloud Monitoring tool that maximizes the availability and performance of the applications by delivering a comprehensive solution for collecting, analyzing, and acting on telemetry from Cloud environments. It will be used for monitoring different metrics such as CPU, Disk Usage, Network, etc.
Automated CI/CD Pipelines:
The workflow for automated CI/CD pipeline to provision infrastructure and deploy an application is as shown:
· Jenkins or Azure DevOps Server can be used as a build server to provision the infrastructure and build/release pipelines in Azure Public cloud subscriptions.
· The terraform pipeline will be executed seldom during the provisioning of the various resources or if any change in configurations is required.
· The best practice is to create separate repositories to store terraform (*.tf files) and application code (.NET, .NET Core, Java, PHP, etc.).
· Fortify, SonarQube should be integrated into CI/CD pipeline for static & security code analysis so that all the vulnerabilities can be removed/taken-care of before-hand.
Database Migration Strategy:
There are numerous options to transfer data to Azure SQL database from on-premise SQL DB including Data Migration Assistant (DMA), Azure Database Migration Service (DMS), AzCopy tool, etc. However, a few organizations do not allow hybrid connectivity or open specific ports (1443 for MS SQL) for transferring data from on-premise servers to the Azure Public Cloud. In such situations, AzCopy (command-line tool) can be leveraged to move data into and out of Azure storage. It works on ports 80 and 443.
Conclusion:
This solution has been designed with various PaaS offerings from Azure so that apps can be built quickly, efficiently, and cost-effectively. The development team can primarily focus on the business logic without worrying about the high-availability, resiliency, and scalability of the platform. Most of these managed services guarantee SLAs for more than 99.95 % (App Gateway, App Service) or even 99.99 % for Azure SQL Database. The reference architecture talks about the deployment in a single region; however, it can be easily extended for multi-region by using Azure Front Door service and other components for higher redundancy.
In the next blog, I will share the detailed in-depth functioning for each component and elaborate the step-by-step guide to provision these managed services using terraform with sample code.
Appreciate your feedback and inputs.
