CH08-05: Scaling, Deployment, Observability, and Cost

Goal

By this point in the chapter, the web application has a request path, an entry layer, a runtime, and data dependencies. That still does not make it production-ready.

A production web architecture must describe how the system scales, how changes are released, how health is measured, how failures are handled, who responds, and how cost stays visible. These are not finishing touches. They are part of the architecture.

The durable idea is:

A web architecture is not ready until scaling, deployment, observability, reliability, ownership, and cost have been designed.

The Short Version

An application diagram shows what connects to what. An operating model shows what happens when traffic spikes, a deployment breaks, a dependency slows down, an alert fires, or the monthly bill changes.

For web applications, production design should answer:

What should scale, and which signals drive scaling?
How are deployments made safely?
How does the system decide whether a backend is healthy?
Which logs, metrics, and traces matter?
Which alerts require action, and who owns them?
What are the main cost drivers?
What is the rollback or recovery plan?

Azure gives teams many platform features for these concerns, but the features need decisions around them. Turning on monitoring is not the same as knowing what to monitor. Enabling autoscale is not the same as knowing whether the application can handle scale-out safely.

Operations Around the Request Path

Think of operations as an overlay around the application path:

flowchart TB
    U["Users"] --> E["Entry & WAF"] --> R["Web/API runtime"] --> D["Data dependencies"]

    S["Scaling<br/><small>Rules, limits, load tests</small>"] --> R
    DEP["Deployment safety<br/><small>Slots, revisions, rollback</small>"] --> R
    H["Health<br/><small>Probes, checks, dependency status</small>"] --> E
    OBS["Observability<br/><small>Logs, metrics, traces, alerts</small>"] --> R
    OBS --> D
    C["Cost<br/><small>Budgets, tags, owners</small>"] --> E
    C --> R
    C --> D

This overlay should appear in architecture conversations before production. If a design cannot explain how it changes, fails, reports problems, and spends money, it is not finished.

Scaling Decisions

Scaling starts with demand, but demand can show up in different ways.

Common scaling signals include:

Signal	What It May Indicate	Design Concern
Request count	More users or API calls.	Can the runtime add instances quickly enough?
CPU or memory	The application process is under pressure.	Is the bottleneck code, instance size, or dependency latency?
Queue depth or event backlog	Background work is accumulating.	Should workers scale separately from the web front end?
Response time	Users are waiting longer.	Is the issue runtime capacity, database pressure, network path, or external dependency?
Planned event	Traffic will rise because of a campaign, sale, launch, or deadline.	Should capacity be pre-scaled and tested before demand arrives?

Autoscale is useful, but it is not a substitute for load testing. If the application has shared state, slow startup, database connection limits, cache pressure, or downstream throttling, adding more instances may expose new problems instead of solving the old one.

The architecture should also define scale limits. Unlimited scaling can become an outage in the budget. Too little scaling can become an outage for users.

Deployment Safety

Web applications change often. That makes deployment safety a core architecture concern.

App Service deployment slots can help teams deploy a new version beside the current production version, warm it up, test it, and swap traffic when ready. Container Apps revisions can help teams run new versions and control how traffic moves between revisions. Other platforms have their own release patterns, but the responsibility is the same: reduce the blast radius of change.

Safer deployment design usually includes:

A repeatable pipeline.
Environment separation for development, test, and production.
Health checks that represent real application readiness.
A rollback plan that has been tested.
Database migration planning.
Configuration and secret management.
Release ownership and approval rules where needed.

Do not treat "the deployment succeeded" as proof that the application is healthy. A deployment can complete while the application fails at runtime, cannot reach a database, breaks authentication, or returns errors for one important path.

Observability and Incident Ownership

Observability is the ability to understand system behavior from the signals it emits. For a web application, the most useful signals usually include:

Request rate, latency, and failure rate.
Exceptions and dependency failures.
Database and storage latency.
Authentication and authorization failures.
WAF blocks and suspicious traffic.
Runtime CPU, memory, restarts, and scale events.
Deployment events and version changes.
Cost, quota, and capacity signals.

Azure Monitor is the broad Azure platform for metrics, logs, and alerts. Application Insights is commonly used for application performance monitoring, request traces, dependency calls, exceptions, and user-impacting behavior. These tools are useful only when the team decides what matters.

Avoid collecting logs only because logs feel responsible. Logs have cost, retention, privacy, and ownership implications. A noisy alert that nobody owns is not observability. A dashboard that nobody opens during an incident is decoration.

For each important alert, ask:

What user impact does this represent?
Who receives it?
What action should they take?
How urgent is it?
How do we know it is resolved?

Reliability and Health

Web reliability includes more than adding another instance.

Health checks should represent whether the application can serve real traffic. A process that returns "OK" while the database is unavailable may not be healthy enough for routing decisions. At the same time, a health check that depends on every downstream service can cause unnecessary removal from rotation during partial dependency issues.

Design health checks carefully:

Liveness checks answer whether the process is running.
Readiness checks answer whether the instance should receive traffic.
Dependency checks answer whether important services are reachable.

The exact implementation depends on the runtime platform, but the architecture concern is the same. The entry layer, runtime, and operations team need a shared definition of health.

Cost as an Architecture Signal

Web application cost is not only the runtime bill.

Common cost drivers include:

Edge services, WAF policies, routing, and traffic volume.
App Service plans, Container Apps consumption, AKS node pools, or virtual machines.
Azure SQL, Storage, cache, and backup configuration.
Log ingestion, retention, metrics, and tracing volume.
Private endpoints, networking components, and data transfer.
Over-provisioned instances, idle environments, and forgotten test resources.

Cost design should include tags, budgets, alerts, environment ownership, and review habits. Cost surprises are often architecture signals: maybe the logging volume is too high, the scale rules are too aggressive, the database tier is wrong, or non-production environments never shut down.

Example: Product Launch Week

Imagine the education platform is launching a new course bundle. Traffic is expected to triple for one week.

The team should not wait for launch day to see what happens. A production-ready plan might include:

Before launch
  -> Run load tests against realistic user journeys
  -> Review App Service or Container Apps scale settings
  -> Pre-scale where startup time matters
  -> Confirm database connection and performance limits
  -> Freeze risky changes during peak launch windows
  -> Prepare dashboards for requests, latency, errors, dependencies, and WAF events
  -> Assign alert owners and escalation paths
  -> Set cost alerts for edge, runtime, database, and logging growth

During launch
  -> Watch user-impacting metrics
  -> Track deployment and incident changes
  -> Review WAF false positives and suspicious traffic
  -> Compare spend against expected traffic

After launch
  -> Scale back where appropriate
  -> Review incidents, cost, logs, and capacity assumptions

The architecture is stronger because operations were designed before pressure arrived.

Common Mistakes

Treating autoscale as a substitute for load testing.
Deploying directly to production without rollback, health checks, or version visibility.
Collecting logs without alert ownership or cost awareness.
Monitoring only the web runtime while ignoring edge, data, identity, and dependency signals.
Letting non-production environments run at production size without ownership.
Creating dashboards that do not match the questions responders ask during incidents.

If Someone Asks You

What production concerns should be included in an Azure web application architecture?

A good answer is:

Include scaling rules and limits, deployment safety, health checks, rollback planning, logs, metrics, traces, alerts, incident ownership, reliability assumptions, and cost controls. A production web architecture should explain how the application handles traffic growth, changes safely, detects failures, recovers from problems, and keeps spend visible.

What You Should Remember

Production architecture includes how the web app scales, changes, fails, tells you what happened, and spends money.

Questions to Check Your Understanding

What signals might drive web application scaling?
How can deployments be made safer?
Why can observability become a cost decision?
Why should alert ownership be designed before production?