Runtime Selection: VMs, Platforms, Containers, and Functions
What This Chapter Is About
Teach runtime selection as matching deployment shape, operational control, scaling behavior, portability, latency, cost, and team capability.
Keep one durable idea in view:
Choose a runtime by deciding which operational responsibilities the workload needs the team to keep.
Sections
How the Chapter Develops
The chapter develops in this order:
Establish responsibility placement as the main runtime decision frame.
Compare virtual machines with managed application platforms.
Separate container packaging from orchestration and explain when Kubernetes earns its cost.
Add functions, serverless execution, and batch for event-shaped or scheduled work.
Finish by assigning different components of a modernizing application to an intentional runtime portfolio.
Together, these sections show that this capability is an architecture responsibility and decision space, not a catalog of provider features.
What You Will Be Able to Do
By the end of this chapter, the reader should be able to:
Compare runtimes by control, operational burden, scaling, deployment, portability, latency, and cost.
Explain why containers do not automatically require Kubernetes.
Recognize workloads that fit functions, managed platforms, virtual machines, or batch execution.
Compose multiple runtime models without creating an unmanageable platform estate.
Key Ideas
More control usually means more operational responsibility.
The deployment unit and execution pattern matter more than fashionable product categories.
Kubernetes is a platform commitment, not only a container scheduler choice.
Serverless shifts infrastructure work but does not remove architecture, security, observability, or cost responsibilities.
A workload may need a small runtime portfolio rather than one universal platform.