Containers: por que venceram

Um container empacota uma aplicação com tudo de que ela precisa para rodar — bibliotecas, dependências, arquivos — e a executa isolada do resto da máquina. A diferença essencial em relação a uma máquina virtual é que o container compartilha o kernel do sistema hospedeiro, em vez de trazer um sistema operacional próprio.

Dois problemas motivaram os containers.

O primeiro é o desperdício das máquinas virtuais, que a lição anterior descreveu: vinte aplicações não precisam de vinte sistemas operacionais.

O segundo é mais antigo e mais irritante: "na minha máquina funciona". A aplicação roda no computador do desenvolvedor com uma versão de biblioteca e falha no servidor com outra. Ou dois projetos na mesma máquina exigem versões incompatíveis da mesma dependência.

O container resolve empacotando o ambiente junto com a aplicação. O que roda no seu computador é bit a bit o que roda em produção. Não é "configurado igual" — é a mesma coisa.

Máquina virtual é uma casa pré-fabricada completa, com fundação e instalações próprias. Container é um contêiner de navio: padronizado por fora, arrumado por dentro como você quiser, e aproveitando a estrutura do navio em vez de trazer um casco próprio.

A analogia é boa também no ponto fraco: os contêineres compartilham o casco. Se o navio afundar, afundam todos — assim como uma falha no kernel afeta todos os containers da máquina.

Container virou o formato padrão de publicar aplicação. Integração contínua constrói uma imagem e a mesma imagem vai para teste e produção, o que elimina a diferença de ambiente. Kubernetes orquestra containers. E localmente, subir um banco de dados para desenvolver passou a ser um comando em vez de uma instalação — que depois some sem deixar rastro.