Deployment
Shipping a running service without dropping requests: containers, graceful shutdown, health checks, rolling deploys and migrations that survive two versions at once.
VM, container, managed container, function, PaaS and Kubernetes compared by the engineering problem each one is solving, not by the marketing category.
An image is a frozen filesystem plus an entrypoint; the interesting part is what your process must do once it is PID 1 with no shell around it.
SIGTERM arrives, and the process has one job: stop taking new work, finish or cancel what it holds, release everything, and exit before it is killed.
Replacing instances a few at a time keeps the service up, and guarantees that two versions of your code run against one database at the same time.
Five steps that let a schema change survive a rolling deploy, because for the length of that deploy two versions of your code share one database.
Send a small slice of real traffic to the new version, compare it against the old on the same signals, and only then commit the fleet.
Run two complete environments, cut traffic from one to the other, and cut back if it is wrong — while remembering that the database was never duplicated.
A translation table for the eight things a backend needs from a cloud — with the column that matters most being what the analogy gets wrong.
What the application must do to be a well-behaved workload: honest probes, a termination sequence that races endpoint removal, resource requests that match reality, and no local disk.
A per-invocation execution model that removes supervision and adds cold starts, execution limits and connection pressure — excellent for some workloads and wrong for others.