Docker is everywhere. Every application runs in containers. Every deployment uses Docker. Every team containerizes everything. But here’s the thing: Docker adds a runtime layer between your application and the OS. That layer has overhead. That overhead costs money.

Containers aren’t free. They consume CPU. They consume memory. They consume disk space. They add complexity. They add operational burden.

Most applications don’t need containers. Most applications can run directly on the OS. Most applications don’t need the isolation. Most applications don’t need the portability.

The Runtime Tax

Docker adds a runtime layer. The container runtime. The container daemon. The network bridge. The storage driver. All of this overhead.

A basic Docker setup uses 100-200 MB RAM. Plus CPU for container management. Plus disk I/O for image layers. Plus network overhead for container networking.

Production setups run multiple containers. Each one adds overhead. Each one consumes resources. Each one is another thing to manage.

Native applications don’t have this overhead. They run directly on the OS. They use fewer resources. They’re simpler to manage.

The Image Bloat Problem

Docker images are bloated. Base images include entire operating systems. Alpine Linux: 5 MB. Ubuntu: 70 MB. Debian: 120 MB. But that’s just the base.

Applications add layers. Dependencies. Libraries. Tools. A typical application image: 200-500 MB. Some images: 1-2 GB. That’s a lot of bloat.

Teams build images with everything. Development tools. Debugging tools. Documentation. All of this gets shipped to production. All of this increases image size.

Multi-stage builds help. But they’re complex. Teams skip them. They ship bloated images. They pay for storage. They pay for transfer. They pay for startup time.

Native applications don’t have this bloat. They’re just binaries. They’re small. They’re fast. They don’t need image layers.

The Orchestration Dependency

Docker requires orchestration. Single containers are easy. But production needs orchestration. Kubernetes. Docker Swarm. Nomad. All of this adds complexity.

Teams containerize applications. Then they need orchestration. Then they need service discovery. Then they need load balancing. Then they need monitoring. The complexity explodes.

Native applications don’t need orchestration. They can run as systemd services. They can run as process managers. They’re simpler. They’re easier to manage.

But teams containerize everything. They add orchestration. They add complexity. They add overhead. All because “containers are the standard.”

The “Containerize Everything” Trend

Every application gets containerized. Web apps. APIs. Background jobs. Cron jobs. Everything. But why?

Teams containerize “because everyone does it.” They don’t analyze whether containers add value. They don’t consider alternatives. They just follow the trend.

Containers make sense for some applications. Applications that need isolation. Applications that need portability. Applications that need consistent environments.

But containers don’t make sense for everything. Simple applications don’t need containers. Native applications don’t need containers. System services don’t need containers.

The Portability Illusion

Docker promises portability. “Build once, run anywhere.” But that’s not always true. Different hosts have different kernels. Different storage drivers. Different network configurations.

Containers work best when hosts are similar. But hosts aren’t always similar. Production differs from development. Cloud differs from on-premises. Portability breaks.

Native applications are more portable. They’re just binaries. They run anywhere the OS supports them. No container runtime needed. No image layers. Just the application.

The Isolation Overhead

Docker provides isolation. Namespaces. Cgroups. But that isolation has overhead. CPU overhead. Memory overhead. I/O overhead.

Most applications don’t need this isolation. They can run directly on the OS. They can share resources. They can be simpler.

Virtual machines provide better isolation. But they’re heavier. Containers provide lighter isolation. But they’re still overhead.

If you don’t need isolation, skip containers. Run applications directly. Use fewer resources. Simplify operations.

Who Actually Needs It

Docker makes sense if you have:

  • Applications that need isolation from each other
  • Applications that need consistent environments across hosts
  • Applications that need easy deployment and scaling
  • Teams that want to standardize on containers

Most applications don’t have these requirements. Most applications can run directly on the OS. Most applications don’t need isolation. Most applications don’t need portability.

If you’re running a simple web app, consider running it directly. Use systemd. Use a process manager. Skip containers. It’s simpler. It’s cheaper.

If you’re running multiple applications that need isolation, containers might make sense. But don’t containerize everything. Containerize what needs containers. Skip containers for everything else.