Runtime Selection as a Responsibility Decision
Goal
Open runtime selection with a decision frame based on responsibility, workload shape, and team capability.
The Short Version
The right runtime leaves the team owning the controls the workload needs and no more platform work than it can operate well.
Runtime choices move responsibility for hosts, operating systems, schedulers, scaling, patching, deployment, and availability. 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 responsibility ladder from virtual machines through managed platforms, containers, orchestrators, and functions.
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
| Decision dimension | Question to make explicit |
|---|---|
| Compatibility | Which operating system, runtime, network, or hardware constraints are real? |
| Unit | Is deployment a machine, application, container, function, or batch job? |
| Scaling | What triggers scale, and how quickly must capacity appear? |
| State | Can instances be replaced, and where does durable state live? |
| Operations | Which platform work can the team reliably own? |
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
Runtime choices move responsibility for hosts, operating systems, schedulers, scaling, patching, deployment, and availability
Runtime choices move responsibility for hosts, operating systems, schedulers, scaling, patching, deployment, and availability. 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.
Workload shape includes process lifetime, state, network needs, startup sensitivity, concurrency, scheduling, and hardware requirements
Workload shape includes process lifetime, state, network needs, startup sensitivity, concurrency, scheduling, and hardware requirements. 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.
Team skills, platform maturity, observability, security, delivery model, and cost behavior are architectural constraints
Team skills, platform maturity, observability, security, delivery model, and cost behavior are architectural constraints. 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
Classify a legacy web application, event-driven image processor, scheduled reconciliation job, and latency-sensitive API before choosing runtimes.
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
Selecting a runtime because the team wants to learn it. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Optimizing only for portability while ignoring operations. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Assuming more managed always means less architecture work. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
If Someone Asks You
What questions should you ask before choosing a cloud runtime?
A clear answer is:
The right runtime leaves the team owning the controls the workload needs and no more platform work than it can operate well.
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
The right runtime leaves the team owning the controls the workload needs and no more platform work than it can operate well.
Questions to Check Your Understanding
Which responsibilities shift between runtime models?
What aspects of workload shape influence selection?
Why is team operating capability a design constraint?
Further Study
Kubernetes Concepts - Use this authoritative source to deepen the section's provider-neutral control and decision model.