Containers

Overview Both let you deploy application code without owning physical servers, but they draw the abstraction line in different places. Serverless functions run only in response to events and scale to zero between invocations, while containers package your app with its dependencies into a persistent, always-addressable process you (or an orchestrator) keep running. Comparison Diagram ServerlessContainersInstance per eventrequestsIdle gaps = zero cost, zero running processCluster / hostContainer AContainer BContainer CAlways running, billed continuously Comparison Table Aspect Serverless Containers Deployment unit Single function handler plus its dependencies Full image with OS layers, runtime, and app code Startup trigger Invoked per event (HTTP call, queue message, timer) Started explicitly and left running by an orchestrator Runtime lifetime Ephemeral, seconds to minutes, then torn down Long-lived, runs continuously until stopped or redeployed State handling Stateless between invocations; external store required Can hold in-memory state across requests within its life Scaling behavior Platform scales instance count automatically, including to zero You or an orchestrator (e.g. Kubernetes) define replica counts and rules Resource control No control over OS, runtime patching, or underlying host Full control over base image, OS packages, and runtime version Cost model Pay per invocation and execution time, nothing when idle Pay for allocated capacity whether or not it’s handling traffic Operational overhead No servers, patching, or orchestration to manage You own cluster upkeep, scaling policy, and image maintenance Key Differences Serverless bills per invocation, containers bill for allocated capacity regardless of traffic Containers give you a fixed runtime environment you control; serverless abstracts the OS away entirely Cold starts and short execution limits shape serverless function design; containers have no such ceiling Serverless functions are inherently stateless, while containers can maintain in-process state across requests When to Use Each Serverless ...

Overview Docker packages an application and its dependencies into a portable container image and runs it on a single host, while Kubernetes schedules, scales, and heals many containers across a cluster of machines. They aren’t direct substitutes — Kubernetes typically runs containers built by Docker (or another OCI-compatible tool), sitting one layer above it. Comparison Diagram DockerKubernetesSingle Hostapp Aapp Bapp Cidledocker runmanual, per-hostif host dies, all lostControl PlaneNode 1Node 2Node 3scheduler places podsauto-reschedules on failuredeclarative, cluster-wide Comparison Table Aspect Docker Kubernetes Core purpose Build, package, and run containers from a single image spec Orchestrate and manage many containers across a fleet of machines Unit of work Container, defined by a Dockerfile and run via docker run Pod, a group of one or more containers scheduled together Deployment scope Single host (or manually scripted across hosts) Multi-node cluster with a control plane scheduling workloads Configuration model Imperative CLI commands or docker-compose.yml Declarative YAML manifests reconciled continuously toward desired state Networking & discovery User-defined bridge networks and container name resolution Cluster-wide Services, DNS, and Ingress across nodes Scaling Manual — start more containers or use docker-compose scale Automated via ReplicaSets and Horizontal Pod Autoscaler Failure recovery No built-in restart across host failure; relies on restart policies per host Self-healing — reschedules pods automatically if a node or container fails Rollouts & updates Rebuild image and manually restart containers Rolling updates and rollbacks managed declaratively per Deployment Key Differences Docker operates at the level of a single container; Kubernetes operates at the level of a cluster. Kubernetes doesn’t replace Docker — it typically schedules containers that Docker (or another container runtime) built and runs. Docker’s model is largely imperative, while Kubernetes is fundamentally declarative, continuously reconciling actual state to desired state. Kubernetes adds self-healing and autoscaling that plain Docker has no native concept of. For a single app on one machine, Kubernetes’ control plane overhead is often unjustified complexity. When to Use Each Docker ...

Overview Containers and virtual machines both let you package and isolate workloads, but they virtualize at different layers of the stack: containers share the host OS kernel while VMs emulate entire hardware and run a full guest OS each. That difference drives everything else — startup speed, image size, isolation strength, and how many instances you can pack onto one host. Comparison Diagram VSContainerVMApp+LibsApp+LibsApp+LibsContainer Engine(Docker / containerd)Host OS Kernel (shared)~MBs · starts in msApp+LibsGuest OSApp+LibsGuest OSApp+LibsGuest OSHypervisor(ESXi / KVM / Hyper-V)Physical Hardware~GBs · starts in minutes Comparison Table Aspect Container VM Isolation boundary OS-level, enforced by kernel namespaces and cgroups Hardware-level, enforced by a hypervisor Guest OS None — shares the host kernel Full guest OS instance per VM Startup time Milliseconds to a few seconds Tens of seconds to minutes (full OS boot) Image/footprint size Megabytes Gigabytes Resource overhead Low; near-native performance Higher; hypervisor plus guest OS overhead Portability Highly portable across any host with a compatible kernel and engine Portable via VM image formats but heavier to move and convert Security isolation strength Weaker — shared kernel widens attack surface Stronger — separate kernel per VM Typical density per host Hundreds of instances Tens of instances Key Differences Containers share the host kernel instead of running a separate OS like VMs. VM isolation is enforced by a hypervisor, giving stronger security boundaries than containers. Containers typically boot in milliseconds, while VMs take minutes to boot a full OS. Container images measure in megabytes; VM images measure in gigabytes. A single host can run far higher density of containers than VMs due to lower per-instance overhead. When to Use Each Container ...