CH08-01: Web Application Architecture Mental Model

Goal

Part 2 explained how to choose Azure services by the job they perform. This chapter puts those choices together in a familiar pattern: a web application that users reach, application code handles, data services support, and a team must operate safely.

The goal of this section is to give you a map for the rest of the chapter. A web architecture is not only the place where web code runs. It is the complete path from a user request to the application runtime, data dependency, security control, deployment process, monitoring signal, and cost owner.

The durable idea is:

A web application architecture is the complete path from user request to application runtime, data dependency, security control, and operating feedback.

The Short Version

A web application architecture starts with a request path.

Someone opens a browser, calls an API, uploads a document, signs in, or refreshes a page. That action becomes traffic. The architecture decides how that traffic enters Azure, how it is protected, where the application code runs, which data it can reach, how secrets are handled, how failures are detected, how releases are made safely, and who pays attention when something changes.

The tempting first question is:

Should this run on App Service, Container Apps, AKS, a virtual machine, or static storage?

That question matters, but it is too early by itself. Azure App Service is managed hosting for web applications and APIs. Azure Container Apps runs containerized applications without asking the team to manage Kubernetes directly. Azure Kubernetes Service, or AKS, runs workloads on managed Kubernetes when the team needs Kubernetes control. Azure Blob Storage can host static website content when the site is mostly files such as HTML, CSS, JavaScript, images, and documents. Each option can be useful. None of them replaces the need to design the full request path.

A stronger architecture question is:

What responsibility does each layer of the web application need to carry?

Once those responsibilities are clear, the service choices become easier to explain.

The Request-Path Model

Think of a web application as a path with operating controls around it:

flowchart LR
    U["Users<br/><small>Browsers, mobile apps, partners</small>"]
    E["Entry & protection<br/><small>DNS, TLS, routing, WAF</small>"]
    R["Web/API runtime<br/><small>App code, containers, static content</small>"]
    D["Data dependencies<br/><small>Databases, storage, caches</small>"]
    O["Operations<br/><small>Logs, metrics, alerts, releases, cost</small>"]

    U --> E --> R --> D
    R --> O
    D --> O

This diagram is intentionally simple. It is not saying every web application has exactly one edge service, one runtime, and one database. It is giving you a way to build the larger architecture in steps.

First, draw the request path. Then add protection. Then add data access. Then add deployment, monitoring, scaling, and cost. If you try to draw every service at once, the diagram becomes a product poster. If you build the diagram layer by layer, each Azure service earns its place.

The Main Responsibility Layers

Most production web applications need the same broad responsibilities, even when the final Azure services differ.

Do not worry about memorizing every name in this table. The chapter will focus on the jobs behind the names. The important habit is to ask what responsibility is missing before asking which service looks most familiar.

Hosting Is Only One Layer

The hosting layer is important because it shapes deployment, scaling, runtime control, and operations. But a hosting decision does not complete the architecture.

Suppose a team says, "We will use App Service." That answers where the web app runs. It does not answer:

• Should users enter through a global edge, a regional gateway, or only an internal network?

• Where is TLS terminated?

• Does the application need WAF protection?

• Can the runtime reach the database through public networking, or should it use private access?

• How are secrets, certificates, and connection information stored?

• What happens during deployment?

• Which logs, metrics, and traces prove the application is healthy?

• Which team owns alerts and cost review?

The same is true if the team chooses Container Apps, AKS, virtual machines, or static storage. The compute choice is one part of a larger operating path.

When the Runtime Choice Changes

Here is a simple way to think about common web hosting directions before the later sections add detail:

This is not a final decision tree. It is a first filter. A static site may still need an API. An App Service app may still need private endpoints. A Container Apps design may still need a gateway. An AKS platform may still need strong governance, monitoring, and cost ownership.

Example: A Customer Portal

Imagine a company building a customer portal. Users sign in, view subscriptions, upload documents, and manage orders.

A rough first diagram might look like this:

Users
  -> Public HTTPS entry
  -> Web portal
  -> Account API
  -> Azure SQL for subscription data
  -> Blob Storage for uploaded documents
  -> Logs, alerts, release controls, cost owners

Now the architecture starts to become a set of decisions:

• The public entry may need Azure Front Door if users are global and the team wants edge routing, health-based failover, and WAF at the edge.

• The web portal may run on App Service if it is a conventional web application with a managed hosting model.

• The account API may also run on App Service, or it may run on Container Apps if the team packages APIs as containers and wants revision-based deployment.

• Uploaded documents may live in Blob Storage because object storage is a better fit than a relational database for files.

• Subscription records may live in Azure SQL Database because they are structured relational data.

• Key Vault and managed identities can reduce the need for stored secrets.

• Private endpoints and private DNS can keep data access off public network paths where the requirements call for it.

• Azure Monitor and Application Insights can show request failures, dependency latency, exceptions, and user-impacting incidents.

Notice what happened. The architecture did not start with a catalog. It started with the path a request follows and the responsibilities that surround that path.

Common Mistakes

• Choosing App Service, Container Apps, AKS, or virtual machines before understanding the request path.

• Treating WAF, private endpoints, Key Vault, monitoring, and cost controls as optional extras instead of architecture responsibilities.

• Drawing a happy-path diagram that omits deployment, failure, ownership, and support decisions.

• Using AKS because containers are involved, even when the team does not need Kubernetes control.

• Hosting static content on a full application runtime when static storage or a static web hosting option would be simpler.

• Assuming a managed service removes the need to design identity, networking, observability, and operations.

If Someone Asks You

What is the simplest way to think about Azure web application architecture?

A good answer is:

Start with the request path. A web application architecture decides how users enter, how traffic is protected and routed, where the web or API runtime runs, how it reaches data, how secrets and private access are handled, and how the team deploys, monitors, scales, recovers, and controls cost. Hosting is important, but it is only one layer of the design.

What You Should Remember

Start with the request path, then assign each layer a clear responsibility.

Questions to Check Your Understanding

1. What are the main layers in a web application request path?

2. Why is hosting only one part of the architecture?

3. When might a web workload fit App Service, Container Apps, AKS, or static storage?

4. Which operating concerns should appear before production?