Functions, Serverless Runtimes, and Batch

Goal

Explain execution models shaped by events, short-lived work, schedules, parallelism, and managed scaling.

The Short Version

Functions and batch are chosen by execution shape and coordination needs, not simply by whether servers are hidden.

Functions fit bounded event handlers with managed scaling, but execution limits, cold starts, concurrency, and event semantics matter. The important architecture move is to make the boundary explicit before selecting a cloud feature. A feature can automate a decision, but it cannot decide the organization's risk tolerance, ownership model, or acceptable failure behavior.

Use this section as a decision tool. Name the actor or producer, the protected or affected resource, the contract between them, the conditions under which the action is allowed, and the evidence that will show whether the design worked.

Mental Model

Use a decision flow from trigger and duration through concurrency, resource shape, state, coordination, and latency sensitivity.

flowchart LR
    N1["Workload shape"] --> N2["Responsibility boundary"] --> N3["Runtime model"] --> N4["Deployment and scaling"] --> N5["Operations"]

Read the diagram from left to right, then review it from right to left. The forward pass explains how work succeeds. The reverse pass asks whether an operator can trace an outcome back to its initiating identity, input, policy, route, or contract.

Architecture Decisions

The answers should be recorded with the workload design. If the answer is merely "the platform default," the team has discovered an assumption, not completed an architecture decision.

Core Ideas

Functions fit bounded event handlers with managed scaling, but execution limits, cold starts, concurrency, and event semantics matter

Functions fit bounded event handlers with managed scaling, but execution limits, cold starts, concurrency, and event semantics matter. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.

Serverless container or application runtimes support longer-lived services while retaining managed infrastructure characteristics

Serverless container or application runtimes support longer-lived services while retaining managed infrastructure characteristics. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.

Batch fits queued, scheduled, parallel, resource-intensive, or high-performance jobs needing explicit job lifecycle and capacity choices

Batch fits queued, scheduled, parallel, resource-intensive, or high-performance jobs needing explicit job lifecycle and capacity choices. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.

Provider Lenses

AWS offers responsibility boundaries through EC2, managed application platforms, ECS or EKS, Fargate, Lambda, and batch services. Azure offers Virtual Machines, App Service, Container Apps or AKS, Functions, and batch services. Product names matter only after workload shape, control needs, scaling behavior, and operating maturity are explicit.

Provider lenses are useful for implementation planning, but they should come after the provider-neutral decision. This keeps the reasoning portable and makes differences in defaults, scope, and operational responsibility easier to detect.

Example: Applying the Decision

Compare thumbnail generation, nightly financial reconciliation, a public API, and a large parallel simulation.

Keep an incompatible legacy component on virtual machines initially, place a conventional web API on a managed application or container platform, use functions for short event-driven tasks, and introduce Kubernetes only when its shared orchestration capabilities justify operating the platform.

A review should finish with named owners, a testable success path, expected failure modes, and observable evidence. That is more useful than a diagram that only proves the components can connect.

Common Mistakes

• Breaking a workflow into functions without designing state and idempotency. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.

• Ignoring startup latency, concurrency quotas, downstream capacity, or runaway cost. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.

• Using an always-on service for naturally queued batch work without evaluating job execution. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.

If Someone Asks You

How do you choose among functions, serverless services, and batch?

A clear answer is:

Functions and batch are chosen by execution shape and coordination needs, not simply by whether servers are hidden.

I would then show the decision path, the responsibility boundary, and the evidence used to review it. That explanation connects the technical mechanism to its architecture purpose.

What You Should Remember

Functions and batch are chosen by execution shape and coordination needs, not simply by whether servers are hidden.

Questions to Check Your Understanding

1. Which workload traits fit a function?

2. Why must downstream capacity influence serverless scaling?

3. What does a batch platform manage that a simple scheduled process does not?