Azure / Intermediate: managed services and governance / Lesson 7

App Service and Functions execution contracts

Design a managed web path and an event-driven path with explicit state, scaling, identity, and deployment assumptions. Avoid treating serverless or managed hosting as a complete application architecture.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Compare request hosting with trigger-driven execution.
Explain plan, runtime, and deployment constraints.
Model duplicate-event handling offline.

A hosting service has an execution contract

Azure App Service hosts supported web applications and APIs within a managed platform and plan model. Azure Functions executes code through supported triggers and bindings under a chosen hosting option. Neither name establishes the required runtime version, network access, execution limits, startup behavior, or regional support. Choose from the workload’s interaction: a synchronous API may need a bounded response, while document processing can acknowledge receipt and finish asynchronously. Keep the client’s accepted-request response distinct from successful business completion. A function triggered by an event still needs a failure and retry policy rather than assuming every invocation succeeds once.

Shared plan capacity and application state matter

An App Service plan and its applications have a resource and scaling relationship that must be understood before adding apps or instances. Co-hosting can couple capacity and operational decisions. Functions hosting options likewise differ in scaling, runtime, networking, and execution constraints, so avoid universal timeout or cold-start claims. The JSON model separates a public HTTP API from an upload-event processor and records durable-state ownership. It is not an App Service or Functions deployment definition. Verify actual plan features, identities, connection limits, and supported runtime lifecycle before proposing a future implementation.

json A managed execution plan with explicit completion meaning

{
  "model": "execution-contract-only",
  "components": [
    {
      "name": "catalog-api",
      "candidate": "Azure App Service",
      "completion": "synchronous-bounded-response"
    },
    {
      "name": "document-processor",
      "candidate": "Azure Functions",
      "completion": "eventual-result-with-operation-id"
    }
  ],
  "durable_state": "external-authoritative-store"
}

Expected output

accepted upload and completed document are different outcomes

The model does not create plans, bindings, applications, or accounts. Service-specific features are unresolved design inputs.

An event identity must survive a retry

A handler can complete its effect and fail before the surrounding delivery process records success. Depending on trigger and delivery semantics, another attempt can then occur. Use a stable operation or event identity and coordinate a durable receipt with the intended local effect. The offline array below counts each synthetic upload identity once and reports one duplicate. This is not durable or shared idempotency and cannot prevent duplicate external payments or mail. A real design needs appropriate storage constraints, transaction boundaries, and a provider protocol for remote effects. State these limits before treating the model as a production pattern.

python Offline duplicate-identity accounting

events = ["upload-1", "upload-1", "upload-2"]
seen = set()
for event_id in events:
    seen.add(event_id)
print(len(seen), len(events) - len(seen))

Expected output

2 1

Two identities and one repeat are observed in memory. No Functions runtime, event source, or persistent receipt is exercised.

A deployment boundary includes configuration and data

Code rollout, configuration, managed identity, secrets, connections, and data schema must remain compatible during change. Deployment slots can help particular App Service workflows where supported, but swapping code is not automatically a database rollback or universal identity/configuration swap. Check each setting’s slot behavior and application startup assumptions. Function code and bindings also need compatibility with in-flight events and queued payloads. Do not regenerate secrets or change identity permissions casually as part of a release. A health response should reflect the intended readiness contract, while independent user and background completion signals verify the actual task.

Test completion and recovery rather than service labels

A review should cover valid input, rejected input, dependency failure, retry, duplicate identity, configuration mismatch, and a new instance starting without local state. Measure request and background outcomes separately. Managed identity access, private connectivity, observability, and retention are still design responsibilities. This course runs no App Service deployment, function host, trigger, SDK, account inspection, or cloud command. Its JSON and arithmetic examples expose contracts only. A future authorized test must verify the chosen runtime and hosting behavior under controlled conditions before any availability, latency, or cost claim is made.

Common errors and fixes

An HTTP acceptance response is called completed processing

Why it happens: Request acknowledgement and business completion are conflated.
How to fix it: Expose a stable operation identity and explicit completion state.
Prevent it next time: Observe failed and delayed background work separately.

A retry generates a new deduplication identity

Why it happens: Attempt identity replaces durable operation identity.
How to fix it: Preserve the original business identity across attempts.
Prevent it next time: Test failure after the effect but before acknowledgement.

A slot swap is assumed to roll back all state

Why it happens: Code deployment and data/configuration lifecycle are mixed.
How to fix it: Plan schema and configuration compatibility explicitly.
Prevent it next time: Verify the supported slot behavior for each relevant setting.

Check your understanding

1. Why should an event processor not store its only completion record in instance memory?

Show worked solution

The instance can restart or another instance can receive the retry, losing that memory. Use a stable operation identity and a durable design that joins the receipt and local effect appropriately. Remote effects need their own protocol; the local set in the example is an explanation, not a shared guarantee.

2. Does choosing Functions establish a fixed timeout or startup delay?