Azure Reference Architecture Guide - Key Features

  • App Service for APIs

  • Publish APIs to Azure App Services

  • Application Insights

  • Create Azure SQL server

  • Create Azure SQL Databases

  • Create Azure Cosmos DB

  • Create Azure Redis Cache

  • Storage Account

  • SendGrid

  • Azure Key Vault

  • Virtual Machine

  • Azure CDN

  • API Management

  • Application Gateway

  • Setup Azure AD

  • RBAC setup

  • Lock Resource Groups

  • Pricing Calculator

  • Auto scaling

  • Auto scaling using ARM template

  • Disaster recovery

  • Azure Backup

  • Site Recovery Vault

  • Configure certificates

Lab-04: Azure High Level Architecture (HLD)


Lab scenario

You've received Application High Level Application architecture and application requirements and you need to present Azure High Level Architecture. In this Lab we will create HLD of Azure blueprint as per the Application requirements.

Objective

In this Lab we will discuss on following topics:

  • Azure Blueprint
  • Azure services used in the Architecture

References:

PowerPoint Slides

PowerPoint slides userd in the Video.

Basic-Azure-Architecture Basic-Azure-Architecture

Recommendations

Your specific requirements might differ from the generic architecture shown here. Use the recommendations in this section as a starting point.

Architecture

The architecture has the following components:

Azure API Management.

API Management is a managed service for publishing catalogs of HTTP APIs, to promote reuse and discoverability. API Management consists of two related components:

  • API gateway. The API gateway accepts HTTP calls and routes them to the backend.

    The API gateway helps to decouple front-end clients from the back end. For example, it can rewrite URLs, or transform requests before they reach the backend. It also handles many cross-cutting concerns such as authentication, cross-origin resource sharing (CORS) support, and response caching etc...

  • Developer portal. Each instance of Azure API Management provides access to a developer portal. This portal gives your developers access to documentation and code samples for calling the APIs. You can also test APIs in the developer portal.

Backend systems.

This application needs Azure SQL server for RDBMS and costmos DB for no SQL for managing application data securely.

Azure Active Directory

(Azure AD). Use Azure AD to authenticate clients that call the API gateway. Azure AD supports the OpenID Connect (OIDC) protocol. Clients obtain an access token from Azure AD, and API Gateway validates the token to authorize the request. When using the Standard or Premium tier of API Management, Azure AD can also secure access to the developer portal.

Region

To minimize network latency, create all the application resources in the same region. In general, choose the region that's closest to your users (or closest to your backend services).

The resource group also has a region. This region specifies where to store deployment metadata and where to execute the deployment template. To improve availability during deployment, put the resource group and resources in the same region.

Scalability considerations

we should consider the scalability at each service level, each service will have the different scalability options.

The App Services supports auto scalling to meet demand.

Availability considerations

Backups

For App Services, we recommend a configuration-as-code approach to backing up and restoring. Because App Services are serverless, you can quickly recreate them from Azure Resource Manager templates. Save the templates in source control, integrate the templates with your continuous integration/continuous deployment (CI/CD) process. In a disaster recovery event, deploy the template to a new region.

Regularly back up your API Management configuration. Store your backup files in a location or Azure region that differs from the region where the service is deployed. Based on your RTO, choose a disaster recovery strategy:

  • In a disaster recovery event, provision a new API Management instance, restore the backup to the new instance, and repoint the DNS records.

  • Keep a passive instance of the API Management service in another Azure region. Regularly restore backups to that instance, to keep it in sync with the active service. To restore the service during a disaster recovery event, you need only repoint the DNS records. This approach incurs additional cost because you pay for the passive instance, but reduces the time to recover.

DevOps considerations

Create separate resource groups for production, development, and test environments. Separate resource groups make it easier to manage deployments, delete test deployments, and assign access rights.

When you assign resources to resource groups, consider these factors:

  • Lifecycle. In general, put resources that have the same lifecycle in the same resource group.

  • Access. To apply access policies to the resources in a group, you can use Azure role-based access control (Azure RBAC).

  • Billing. You can view rollup costs for the resource group.

  • Pricing tier for API Management. Use the Developer tier for development and test environments. To minimize costs during preproduction, deploy a replica of your production environment, run your tests, and then shut down.

Deployment

Use Azure Resource Manager templates to deploy the Azure resources, follow the infrastructure as Code (IaC) Process. Templates make it easier to automate deployments using Azure DevOps Services, or other CI/CD solutions.

Staging

Consider staging your workloads, which means deploying to various stages and running validations at each stage before moving on to the next one; that way you can push updates to your production environments in a highly controlled way and minimize unanticipated deployment issues. Blue-green deployment and Canary releases are recommended deployment strategies for updating live production environments. Also consider having a good rollback strategy for when a deployment fails; for example you could automatically redeploy an earlier, successful deployment from your deployment history.

Workload isolation

Think of isolate the deployment units /components in own separate Resource Manager templates for ex: put API Management and any individual App Services or logic apps in their own separate Resource Manager templates. By using separate templates, you can store the resources in source control systems. You can deploy the templates together or individually as part of a CI/CD process.

Versions

Each time you change a App services or logic app's configuration or deploy an update through a Resource Manager template, Azure keeps a copy of that version and keeps all versions that have a run history. You can use these versions to track historical changes or promote a version as the logic app's current configuration. For example, you can roll back a logic app to a previous version.

API Management supports two distinct but complementary versioning concepts:

  • Versions allow API consumers to choose an API version based on their needs, for example, v1, v2, beta, or production.

  • Revisions allow API administrators to make non-breaking changes in an API and deploy those changes, along with a change log to inform API consumers about the changes.

You can make a revision in a development environment and deploy that change in other environments by using Resource Manager templates. For more information, see Publish multiple versions of your API

You can also use revisions to test an API before making the changes current and accessible to users. However, this method isn't recommended for load testing or integration testing. Use separate test or preproduction environments instead.

Diagnostics and monitoring

Use Azure Monitor for operational monitoring in both API Management and App Services or Logic Apps. Azure Monitor provides information based on the metrics configured for each service and is enabled by default. For more information, see:

  • Monitor published APIs
  • Monitor status, set up diagnostics logging, and turn on alerts for Azure Logic Apps

Each service also has these options:

  • For deeper analysis and dashboarding, send App Services logs to Azure Log Analytics.

  • For DevOps monitoring, configure Azure Application Insights for API Management.

API Management supports the Power BI solution template for custom API analytics. You can use this solution template for creating your own analytics solution. For business users, Power BI makes reports available.

Security considerations

Although this list doesn't completely describe all security best practices, here are some security considerations that apply specifically to this architecture:

  • The Azure API Management service has a fixed public IP address. Restrict access for calling Logic Apps endpoints to only the IP address of API Management. For more information, see Restrict inbound IP addresses.

  • To make sure users have appropriate access levels, use Azure role-based access control (Azure RBAC).

  • Secure public API endpoints in API Management by using OAuth or OpenID Connect. To secure public API endpoints, configure an identity provider, and add a JSON Web Token (JWT) validation policy. For more information, see Protect an API by using OAuth 2.0 with Azure Active Directory and API Management.

  • Connect to back-end services from API Management by using mutual certificates.

  • Enforce HTTPS on the API Management APIs.

Storing secrets

Never check passwords, access keys, or connection strings into source control. If these values are required, secure and deploy these values by using the appropriate techniques.

If a App Services or logic app requires any sensitive values that you can't create within a connection string or connector, store those values in ``Azure Key Vault` and reference them from a Resource Manager template. Use deployment template parameters and parameter files for each environment. For more information, see Secure parameters and inputs within a workflow.

API Management manages secrets by using objects called named values or properties. These objects securely store values that you can access through API Management policies. For more information, see How to use Named Values in Azure API Management policies.

Cost considerations

In general, use the Azure pricing calculator to estimate costs. Here are some other considerations.

An error has occurred. This application may no longer respond until reloaded. Reload 🗙