Docker está morto – e é hora de seguir em frente

Vamos cortar o ruído. Docker foi o ícone do DevOps por quase uma década.

Mas as coisas mudaram. Rápido. Se você ainda está tratando o Docker como seu martelo de ouro em 2025, é hora de um choque de realidade.

Este não é um texto de ódio. Esta é uma análise prática de por que o Docker está silenciosamente saindo de cena, e o que as equipes modernas de infra estão fazendo em vez disso.

O que o Docker fez certo

O Docker mudou a forma como pensamos sobre infraestrutura. Em vez de VMs, temos contêineres leves. Portáveis, repetíveis e rápidos (naquela época).

De 2013 a 2018:

• Os desenvolvedores podiam “Dockerizar” um aplicativo e enviá-lo.
• Os pipelines de CI/CD foram simplificados.
• Kubernetes adotou o Docker como seu runtime padrão de contêiner.
• Todo mundo e seu cachorro fez um Dockerfile.

Foi bom. Até que não foi mais.

O que deu errado?

1. O problema do Daemon do Docker

O Docker depende de um único processo de longa duração – o Daemon do Docker. Isso significa:

• É um ponto único de falha.
• Executa como root, o que levanta bandeiras vermelhas para segurança.
• Depurar o daemon? Boa sorte. Você o mata, você mata tudo.

Alternativas como o containerd não precisam desse daemon central. Eles são menores, mais rápidos e não precisam do modo Deus para funcionar.

# Execução tradicional do Docker
docker run nginx

# Com o containerd
ctr run --rm docker.io/library/nginx:latest nginx /bin/sh

2. O pagamento do Docker Desktop

O Docker deu o pior passo em seu ciclo de vida: cobrar dos desenvolvedores pelo Docker Desktop em ambientes empresariais.

• As equipes começaram a procurar alternativas como Podman, Rancher Desktop e Colima.
• Os desenvolvedores não gostam de surpresas em suas ferramentas. Esta foi uma delas.

3. Kubernetes desistiu do Docker

Vamos deixar claro – o Kubernetes não desistiu dos contêineres. Ele abandonou o Docker como runtime.

Em vez disso, mudou para containerd e CRI-O.

Diagrama UML: Ciclo de Vida do Contêiner no Kubernetes (Antes e Depois da Despreciação do Docker)

                +------------------+              +------------------+
                |  kubelet         |              |  kubelet         |
                +--------+---------+              +--------+---------+
                         |                                 |
             +-----------v------------+        +-----------v------------+
             |    Daemon do Docker     |        |    containerd / CRI-O  |
             +-----------+------------+        +-----------+------------+
                         |                                 |
                   +-----v-----+                     +-----v-----+
                   | contêiner |                     | contêiner |
                   +-----------+                     +-----------+

K8s prefere runtimes que implementam o CRI (Interface de Execução de Contêiner) nativamente. O Docker não implementa. Isso adicionou camadas de shim desnecessárias.

4. Podman > Docker (para a maioria dos casos de uso)

Podman é basicamente um substituto direto para o Docker. Mas melhor:

• Sem daemon
• Sem root
• Totalmente compatível com os comandos do Docker

# Docker
docker build -t meu-app .

# Podman (mesmo comando)
podman build -t meu-app .

E a melhor parte? Você pode criar um alias:

alias docker=podman

A maioria dos desenvolvedores nem perceberia a diferença. Exceto pelo fato de que o Podman é mais rápido e mais seguro.

E o que você deve usar em vez disso?

• Para desenvolvimento local, use Podman, Colima ou NerdCTL. Essas ferramentas são leves, rápidas e não requerem o Docker Desktop.
• Para pipelines de CI/CD, use containerd. É mais eficiente, se integra melhor com Kubernetes e não depende de um daemon.
• Para runtime do Kubernetes, prefira CRI-O ou containerd. Ambos são nativos do Kubernetes e não requerem shims extras.
• Para usuários de desktop, ferramentas como Rancher Desktop (se você quiser uma GUI) ou Podman (para quem usa terminal) são excelentes alternativas.

Mas e o DockerHub?

Sim, o DockerHub ainda é relevante para hospedagem de imagens. Você ainda pode usá-lo sem a ferramenta Docker. Ferramentas como skopeo ou ctr podem puxar do DockerHub.

skopeo copy docker://nginx:latest dir:/tmp/nginx

História Real de Migração

Estávamos executando um monte de microserviços usando Docker e Docker Compose para desenvolvimento local. Então encontramos:

• Ambientes de desenvolvimento inconsistentes
• Builds de CI expirando devido a problemas de cache do Docker
• Problemas de licenciamento do Docker Desktop

O que fizemos:

• Substituímos o Docker Compose por podman-compose
• Usamos nerdctl + containerd em CI
• Trocamos para Rancher Desktop para membros da equipe que precisavam de GUI

Resultado?

• Builds de CI foram 30% mais rápidos
• Zero problemas de licenciamento
• Equipe aderiu ao Podman sem atritos

Conclusão

O Docker não está morto. Ele apenas… não é mais essencial.

Como o jQuery – ele resolveu um problema que agora é melhor resolvido por outras ferramentas.

Se você está construindo algo em 2025 e ainda recorre ao Docker, pergunte a si mesmo:

Essa ferramenta está me ajudando, ou estou usando apenas porque sempre usei?