Docker unifies runtimes with images
Scott Johnston, CEO of Docker, on growing from $11M to $135M ARR in 2 years
The key point is that Docker is trying to own the developer workflow above the runtime, not just Linux containers. A microservice is simply one small piece of an app that can be built, shipped, and run on its own. Docker started by packaging those pieces as Linux containers, then extended that packaging model to Windows containers and Lambda container images, and treated Wasm as another target that fits the same build, image, and local testing flow.
-
In practice, these runtimes solve the same developer job. Package code with its runtime assumptions, run it consistently, and plug it into a larger app. The difference is where it executes. Linux and Windows containers run as OS level workloads, Lambda runs as an event triggered function on AWS, and Wasm runs inside a lightweight Wasm runtime.
-
Docker’s strategic angle is to keep the familiar unit of work as the image. AWS Lambda accepts OCI and Docker image formats for functions, and Docker Desktop added Wasm support so developers could run Wasm workloads alongside regular containers. That makes Docker the common toolchain even as the execution model changes underneath.
-
The comparison is not perfect, because Wasm is not just a smaller container. It is a different runtime with tighter isolation and less OS baggage, which can make startup faster and distribution lighter. But for a developer building a small network service, it still looks like another way to package and ship one service in a multi service system.
Going forward, the market is likely to split by workload rather than pick one winner. Heavier services will keep using containers, short lived event driven code will keep using Lambda, and some edge and lightweight services will move to Wasm. The company that keeps one build and packaging workflow across all three gets the best chance to stay embedded in everyday development.