Predictions for the Next Decade of Container Technology
Seven reasoned, falsifiable predictions for where containers, Wasm, microVMs, confidential computing, supply-chain rules, AI scheduling and platform engineering land by 2036 — each with the signal that would prove it wrong.
Published on • November 15, 2026
AI Assistant
Predictions are only worth writing down if you also write down what would prove them wrong. When Solomon Hykes tweeted in 2019 that WASM+WASI would have made Docker unnecessary, he spent the next five years correcting people who read it as a container obituary — his own summary is that it “will never happen,” that WebAssembly “has a very different shape,” and that replacing containers ultimately means replacing Linux. That is the standard of care this list aims for: seven claims about the next decade of container technology, each with the reasoning behind it and a concrete, checkable signal that would falsify it. Rationale grounded in the expert split documented in InfoWorld’s Can Wasm replace containers? (Nov 2024), plus everything else in this series.
1. Wasm becomes a first-class workload — not a container replacement
The claim. By 2036, WebAssembly components run alongside containers as a scheduled workload class, exactly the way VMs and containers coexist today. Nobody “migrates off containers” for stateful, long-running, socket-heavy services; the workloads that move are edge functions, request handlers, plugins and policy engines.
Why. The arguments on both sides have been stable for years. Containers beat Wasm for anything long-running, stateful or thread-hungry (Matt Butcher: “I don’t foresee Wasm challenging that space in the next decade”), and Wasm beats containers where the sandbox is the feature — kilobyte artifacts, microsecond starts, no ambient authority. Cloudflare’s Workers platform is the tell: a “post-container” platform that quietly runs containers underneath for GPUs, headless browsers and builds. Layers accumulate; they rarely evict.
Falsifiable signal. Supports: a major cloud ships a generally available Wasm RuntimeClass in default node images, and container runtimes (containerd, CRI-O, Podman, Docker) treat Wasm shims as first-class, tested paths. Refutes: the flagship CNCF Wasm runtimes and component toolchains are archived or merged back into niche status while the pattern stays browser-only.
2. MicroVMs become the default sandbox for anything multi-tenant; unikernels stay niche
The claim. Serverless platforms, hosted sandboxes and multi-tenant PaaS default to hardware-or-kernel-isolated per-tenant execution — Firecracker-style microVMs, Kata Containers, gVisor — without customers asking. Unikernels remain a specialist tool for a handful of appliances and research systems.
Why. The security economics of “one kernel for all your customers” stopped being acceptable around the time the container escape became a board-level discussion. MicroVM startup times have collapsed to the point where the isolation premium is a rounding error on request latency, and the operational model (snapshot, resume, pause) fits serverless perfectly. Unikernels still require recompiling the world and lack the library ecosystems that made containers trivially adoptable.
Falsifiable signal. Supports: at least two major providers launch per-tenant microVM sandboxes as a default, unrequested feature of their app-hosting products. Refutes: a dominant platform demonstrates that strong kernel-level isolation (user namespaces + seccomp + Landlock alone) satisfies auditors at scale, and microVM-per-tenant becomes the exception on cost grounds.
3. Confidential computing stops being a premium tier
The claim. Memory encryption (AMD SEV-SNP, Intel TDX) and remote attestation become default-on options in mainstream cloud compute, with Kubernetes-native attestation flowing into admission control — a pod can require “this node’s firmware and kernel are measured” the way it today requires a node label.
Why. Regulated workloads already treat it as mandatory, and the marginal hardware cost keeps falling as the silicon matures. Confidential Containers and the Kata-based stack have already proven the container-plus-VM packaging; what is missing is the boring part — defaults, docs and APIs — which is precisely how every “premium” infrastructure feature has historically become standard.
Falsifiable signal. Supports: memory-encryption-by-default is the advertised baseline for general-purpose VM SKUs at two of the top three clouds, and an in-tree Kubernetes API surfaces node attestation. Refutes: attestation stays a bespoke integration with per-vendor SDKs five years from now.
4. Software supply-chain mandates become procurement law, not best practice
The claim. Signed artifacts, SBOMs and provenance attestations shift from “nice to have” to “cannot buy without” — driven by regulation (the EU Cyber Resilience Act’s obligations land in late 2027) and by enterprise procurement copying it. Registries increasingly refuse to serve unsigned content by default.
Why. The tooling already exists — sigstore/cosign, SLSA levels, in-toto attestations, OCI’s referrers API for attaching them to images (see the OCI artifacts piece in this series). What converts tooling into norms is a rule with an enforcement date. Every prior wave (TLS everywhere, PCI-DSS, SOC-2) followed the same arc: voluntary for three years, checkbox for ten.
Falsifiable signal. Supports: a hyperscaler marketplace or a national procurement framework requires SLSA-provenance and signed images as a listing condition. Refutes: mandates are watered down to “SBOM on request,” and unsigned pushes remain frictionless through 2030.
5. AI workloads rewrite the scheduler’s job description
The claim. GPU/accelerator fleets become the dominant driver of Kubernetes scheduling design: Dynamic Resource Allocation (DRA) replaces device-plugin plumbing, gang scheduling and topology-aware placement become defaults rather than add-ons, and power draw becomes a schedulable dimension — inference replicas get placed and capped against a power budget the way CPU requests work today.
Why. The economics are unambiguous: a GPU node’s power and memory dominate its cost, so consolidation, packing and preemption decisions that were theoretical for CPU workloads become the whole game. Training jobs need gang scheduling because a partially-scheduled gang is wasted money; inference needs fast, warm placement because cold starts are user-visible. Scheduling research follows the money.
Falsifiable signal. Supports: energy/power metrics appear as first-class scheduling inputs in-tree, and DRA is the documented default path for accelerators in the Kubernetes docs. Refutes: accelerator scheduling remains dominated by out-of-tree operators with bespoke CRDs and manual placement.
6. Edge density forces a smaller, flatter control plane
The claim. Fleets of thousands of edge sites — factories, stores, vehicles, 5G cells — run managed Kubernetes with extremely lean data planes (k3s-class agents, read-only filesystems, automatic repair), and much of the compute at the far edge is Wasm precisely because a containerd-plus-image pipeline is too heavy for the box.
Why. The constraint that dominates edge is not CPU but operations: nobody is ssh-ing into a rack in a port city. Lightweight distributions plus GitOps plus aggressive scale-to-zero is the only staffing model that works. Wasm’s kilobyte footprint and instant start solve the same bandwidth problem images do — pushing a 40 MB image over a satellite link every deploy is the actual bottleneck.
Falsifiable signal. Supports: managed offerings advertise fleets of 10,000+ nodes under one control plane as a standard tier, and edge-specific Wasm runtimes ship in production device fleets at volume. Refutes: edge consolidates onto small numbers of regional datacenters, and the “thousands of tiny clusters” pattern never escapes the demo.
7. Platform engineering becomes the default org shape — and the platform team’s API is the roadmap
The claim. By the early 2030s, “we have a platform team” is as unremarkable as “we have a CI system.” The interesting container question stops being which runtime and starts being which golden path: internal developer platforms publish self-service environments, and the cluster itself becomes an implementation detail behind an IDP.
Why. The cloud-native toolchain won, and the cost of that victory is optionality fatigue — the average team cannot be expert in runtimes, schedulers, networking, ingress, autoscaling and supply chain at once. Every abstraction layer in this list (RuntimeClass, DRA, carbon-aware scheduling) adds knobs; platform teams are how organizations absorb knobs without spreading them across every squad. The evidence is already organizational: platform roles, platform scorecards and platform-as-product language are now standard in large engineering orgs.
Falsifiable signal. Supports: platform engineering appears as a named function with SLAs and a roadmap in most large-org engineering surveys, and CNCF-style platform definitions are adopted as reference standards. Refutes: platform teams get dissolved back into per-team SRE duties as tooling consolidates to a handful of hyperscaler-managed services.
How to hold me to this
Two meta-predictions, both checkable: convergence beats disruption — in 2036 the container image format, the OCI registry and the CRI contract are still the load-bearing interfaces, with the churn happening above and below them. And every “killer” technology ends up as a layer — VMs did not kill bare metal, containers did not kill VMs, and Wasm will not kill containers; the pattern is too consistent to bet against.
If predictions 1–3 all fail while 4–7 hold, the correct read is that the operational and organizational layers moved while the execution layer ossified — a perfectly coherent decade, and the one I would bet on second.