Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Standalone conceptOperating modelChapter III · Operations · Building block 16 of 17

Serverless

Infrastructure operations consume team effort even when functions run only on events.

By Michael Meierhoff · Meierhoff Systems

  1. EventEvent: An event starts a bounded execution.
  2. ResponsibilityResponsibility: The platform operates infrastructure and runtime.
  3. LimitLimit: Runtime, concurrency, and dependencies still need design.

Context

Why this is important

Design operation on managed infrastructure with explicit limits.

Design operation on managed infrastructure with explicit limits.

Shop example · Mapping

Serverless: inspect the decision

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. A hypothetical extension to the example shop sends an event to a serverless invoice function after order acceptance. The function creates the document and stores it in its own storage area; the existing shared shop database and its seven modules remain unchanged. A burst of orders can trigger concurrent starts, so the team limits concurrency and checks broker retries, idempotency, execution budget, and cost per invoice.

This is how you read the picture

  1. Event Event
  2. Responsibility Responsibility
  3. Limit Limit
Serverless: inspect the decision
ConceptMeaningReview question
EventAn event starts a bounded execution.What triggers the invoice function?
ResponsibilityThe platform operates infrastructure and runtime.Which runtime limit belongs in the design?
LimitRuntime, concurrency, and dependencies still need design.Which measurements test operational fit?
Architekturverantwortung bleibt bestehen: Laufzeitgrenzen, Kaltstarts, Parallelität, Berechtigungen, Beobachtbarkeit und Kosten bestimmen die Eignung. Serverless kann Funktionen und Datenbanken umfassen; es bedeutet weder serverfreie Ausführung noch automatisch ereignisbasierte Gestaltung. Use the questions in the second column to test this scenario.

Benefits & limitations

Helps if:

  • Design operation on managed infrastructure with explicit limits.
  • Check event sources, runtime limits, and billing under load.

Boundaries

  • Provider limits and execution costs shift operational effort.
  • Cold starts, maximum execution time, and provider coupling must fit the interaction and operating model.

In practice

  1. Diagram the path from order event to invoice and determine how the trigger handles retries, duplicate delivery, and event schema changes.
  2. Test a function exceeding its runtime limit and an unavailable storage target; check idempotency, retry behavior, and how failures map to the order.
  3. Estimate costs for normal and peak load, including invocations, runtime, and storage access, and compare them with a continuously operated alternative.
Read the detailed explanation

Serverless describes a cloud operating model in which a provider manages infrastructure and runtime and supplies capacity largely on demand. Teams configure functions, event sources, and services instead of operating server instances.

Architecture responsibilities remain: runtime limits, cold starts, concurrency, permissions, observability, and cost determine fit. Serverless can include functions and databases; it means neither execution without servers nor an automatically event-driven design.

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. A hypothetical extension to the example shop sends an event to a serverless invoice function after order acceptance. The function creates the document and stores it in its own storage area; the existing shared shop database and its seven modules remain unchanged. A burst of orders can trigger concurrent starts, so the team limits concurrency and checks broker retries, idempotency, execution budget, and cost per invoice. serverless and skalierung help compare this decision with adjacent concerns.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    What triggers the invoice function?

    View the solution with justification

    An order event invokes the managed function.

  2. ApplyingTransferred to a new situation

    Which runtime limit belongs in the design?

    View the solution with justification

    Maximum execution time together with retry and idempotency behavior.

  3. EvaluateWeighing an alternative

    Which measurements test operational fit?

    View the solution with justification

    Cold-start latency, execution time, event failures, and cost per invocation.

Explore further

These building blocks continue the thoughts of this page.

OperationsDeployment & rolloutContext and comparisonOpening OperationsScalingConceptual connectionOpening

References

Continue on the learning path

Next in Runtime & operations: Recovery.

17 Building blocks

Continue withRecovery