Design Web Applications on Azure App Service

Design Azure App Service Web Apps; design custom web API; secure Web API; design Web Apps for scalability and performance; design for high availability using Azure Web Apps in multiple regions; determine which App service plan to use; design Web Apps for business continuity; determine when to use Azure App Service Environment (ASE); design for API apps; determine when to use API management service; determine when to use Web Apps on Linux; determine when to use a CDN; determine when to use a cache, including Azure Redis cache

Design custom Web API, and secure a Web API

Refer to this post for more information about Web API

Design Web Aps for scalability and performance

I recently created a simple WordPress site using Azure Web App Service. However, that particular website won’t scale nor deliver record-breaking performance because of the fixed, low-specced plan behind it.

As mentioned here, App Service Plans unlock varying features that our Web App can leverage. For example, Basic Service exposes manual scaling with built-in load balancer that aren’t available on Free Service. Alternatively, we need at least Standard Service to have auto-scaling, staging, and other features useful for a production app.

The compute resources available for our Web App increases and gets better as well as the higher the service plan. For example, SSDs are available on Premium Plan, new CPU on Premium Containers Plan, and dedicated networks are available on Isolated Plan. Additionally, we can either scale up or scale out the resources and our Web App.

All that said, review and select the appropriate Service Plan depending on what we are building at the time. For new projects without real-life performance records yet, we can start with the Free Plan. After monitoring the app’s behavior, we can bump up the Service Plan for more features and performance. Conversely, we can also dial down the Service Plan to lower tier if necessary.

At the moment, there’s any official documentation that list out and compares the features of each service plan. However, we can refer to the table below as a guide:

Dev/Test Type

Items

F1

D1

B1

CPU

Shared Infra

Shared Infra

1x core 100 total ACU

Memory

1 GB

1 GB

1.75 GB

Compute
(minutes/day)

60

240

A-series

Storage
(shared by Apps in a Service Plan)

1 GB

1 GB

10 GB

Additional Features

Free

Custom domain

Custom domain / SSL
Scale up to 3 instances (manual)

Production Type

Items

S1

P1v2

P2v2

P3v2

CPU

1x core 100 total ACU

1x core 210 total ACU

2x cores 420 total ACU

4x cores 840 total ACU

Memory

1.75 GB

3.5 GB

7 GB

14 GB

Compute

A-series

Dv2-series

Dv2-series

Dv2-series

Additional Features

Custom domain/SSL
Auto scale up to 10 instances
Staging slots up to 5
Backup up to 10 times daily
Includes Traffic Manager

Custom domain/SSL
Auto scale up to 20 instances
Staging slots up to 20
Backup up to 50 times daily
Includes Traffic Manager

Custom domain/SSL
Auto scale up to 20 instances
Staging slots up to 20
Backup up to 50 times daily
Includes Traffic Manager

Custom domain/SSL
Auto scale up to 20 instances
Staging slots up to 20
Backup up to 50 times daily
Includes Traffic Manager

Design for high availability using Azure Web Apps in multiple regions

We deploy a highly available Web Apps in multiple Azure regions we need to create the following items:

  • Two identical Web Apps
  • Deploy these Apps in two App Service Plan in different regions
  • Create a single endpoint through traffic manager that branches to two endpoints that ends with our Web Apps

Refer to “Scale a web app worldwide with a high-availability architecture.”

Determine which App service plan to use

Refer to this intro about Web Apps. Then, check the previous topics above for more information about this section.

Design Web Apps for business continuity

In my experience, Business Continuity involves more than the technical ingredients of Disaster Recovery. In some cases, Business Continuity might be triggered for non-technical reasons like political rules or instability.

So for this section, let’s refer to Microsoft’s guide about designing for resiliency instead of going through everything about BCDR processes.

Determine when to use Azure App Service Environment (ASE)

As a quick review and an intro for this section, Azure App Service has multi-tenancy at its core. Service plans that run on shared infra actually shares VMs with other customers to run their apps. On the other hand, Production type service plans allocate dedicated VMs to customers but the underlying host and networking components are still shared by several tenants.

In contrast, ASE provides a fully dedicated and isolated environment for customers to run their apps. VPNs can be established to connect on-premise infra to Azure ASE’s virtual network. An ASE is fully exclusive to a customer’s subscription, and can host up to 100 App Service Plans.

Microsoft recommends it for workloads that require:

  • Very high scale (i.e. voting apps, sporting event hubs, entertainment events apps)
  • Isolation and secure network access (i.e. apps that need to securely connect to on-premises resources such as databases)
  • High memory utilization

Here’s a guide how to have a geo-distributed scale app using ASE.

Design for API apps; determine when to use API management service

I’d be honest and admit I’m still learning the ropes of API Apps. I understand that there’s a fine line between API Apps and Web Apps, and that is the familiar and rich metadata exposed by the former so that it can be easily used by other apps.

For example, let’s say we have an application that orchestrates the manufacturing of cars; for easy reference, we’ll call this application “AutoProc-APIapp.” As this scenario suggests, AutoProc-APIapp connects and orchestrate different processes, and has access to different types of information. Now instead of handing the master keys of AutoProc-APIapp to external parties, we can expose an API app to document AutoProc-APIapp and inform external users how to interact AutoProc-APIapp. In other words, this API app will serve as a connector between their application and our internal system.

We can take a cue from designing Web Apps when it comes to architecting Azure API Apps. Check this informative video about building API Apps.

Check this page to find out when to use API Management service.

Determine when to use Web Apps on Linux

When we first select Azure Web App, it defaults to Windows environment. That means the web app will run on a Windows VM with IIS. We have to select Linux as the OS explicitly to start developing Web Apps on Linux with the appropriate Linux-based stack/runtime.

There are two major reasons why we’d want to choose App Service on Linux. First is if we want to code using specific Linux-based platform, and second if we want to port over an existing Linux-based containerized application. Remember, Windows containers runs on Windows OS, Linux containers runs on Linux machine, and never vice versa, at least at the time of writing.

Determine when to use a CDN

Determine when to use a cache, including Azure Redis cache

Caching services, including Azure Redis Cache, boost the performance and scalability of an application by storing frequently accessed data temporarily to another location. That other location may be somewhere closer to the application or faster storage. The more data, and the larger users access these data, the more caching becomes helpful. Caching helps to reduce the latency and contention that comes with handling a large volume of concurrent requests. Here are other use cases for caching:

• Offload a large number of requests
• We can seed the cache with static information like some user data, product info, application forms, etc., even before the application/user requests them
• Avoid repeating computations by storing recent results in the cache

Use Azure Redis Cache

• To create a replicated/HA/cluster/ of caching servers that helps to scale the performance of the data source and serve multiple applications
• Bring the cache closer to the geo-dispersed applications
Hold relatively long-lived cache data

Go back to MCSE 70-535 Unofficial Study Guide Blueprint

By |2018-10-07T12:47:11+00:00October 1st, 2018|Microsoft, Technology|0 Comments

About the Author:

Leave A Comment