Alguns dias atrás um amigo meu mostrou um vídeo chamado "Não Use Docker Compose em Produção! Eis o Porquê" do Erick Wendel que o YouTube recomendou. Eu uso Docker Compose em produção a mais de QUATRO ANOS, hospedando algumas aplicações que possuem mais de dois milhões de acessos mensalmente, e achei que o vídeo foca em coisas que são balelas com uma pitada de fearmongering (fomentador de medo), parecendo que o objetivo do vídeo foi apenas para vender cursos sobre Kubernetes.

No vídeo é recomendado usar Kubernetes, e bem, eu já usei usei k3s, e as vantagens que você ganha rodando k3s nas suas máquinas são pequenas comparadas com a dor de cabeça que você tem de manter o k3s na máquina. Já gastei horas tentando debugar problemas em minhas aplicações sendo que, no final, era problema no k3s. Exemplos incluem Diferenças entre o kubectl do k3s e o Kubernetes upstream e que, se você fizer bind de um serviço na porta 10010, você não conseguirá mais dar attach em serviços hospedados no k3s, e essa porta não é documentada em nenhum lugar.

Usar Kubernetes gerenciado pela AWS/GCP/Azure te tira essas dores de cabeça, mas você vai recomendar AWS/GCP/Azure para uma pessoa que está começando no ramo de empreendedorismo? Ela vai gastar muito mais dinheiro com empresas cloud ao invés de comprar uma VPS/máquina dedicada em uma hospedagem como a OVHcloud ou Hetzner! Para iniciantes, é melhor usar Compose e a pessoa descobrir o que ela precisava para a aplicação dela ao longo do tempo, e não colocar Kubernetes direto e ela ter um monte de coisa que, para ela, é desnecessária e pode até atrapalhar a aplicação dela.

Usar Kubernetes é MUITO mais complicado, e overkill, do que usar apenas o Compose ou o Swarm. Configurar um serviço no Kubernetes é extremamente mais complicado do que um serviço no Compose, e você adiciona um mental overhead gigantesco para quem quer hospedar uma simples aplicação na internet.

Kubernetes também é complicado para tipos de aplicação que precisam ter um local para ler e escrever dados, como banco de dados ou servidores de jogos como Minecraft. Como você vai colocar para o serviço sempre rodar em um servidor em específico? E onde vai escrever os dados? Ah, e o tal de "ele roda duas aplicações ao mesmo tempo" isso dai não vai dar problema nessas aplicações? Com o Compose você não tem esse mental overhead pois é só colocar um bind de volume e vida que segue.

Eu já usei o Swarm no passado, e até escrevi um tutorial sobre ele. O Swarm é bom e é mais simples que o Kubernetes, mas atualmente não uso pois as minhas aplicações não possuem vantagem de ter auto escalonamento ou replicação. Quando a aplicação precisa de replicação, eu faço ela manualmente e uso scripts em bash para automaticamente atualizar as replicações. Isso sim é algo que o Kubernetes e o Swarm fazem e que eu substituo a feature com algo que eu fiz manualmente, mas tenho certeza que o meu script em bash foi mais simples de implementar na minha máquina que o Kubernetes. :gessy_smol:

Sobre o vídeo:

• 02:08 Health Checks é uma funcionalidade que tem no Compose, auto restart é uma funcionalidade que tem no Compose e, se você preferir, nem precisa usar o do Compose, é só colocar um serviço do systemd que inicia o container sozinho.
• 05:51 Se a sua aplicação está tendo um pico de CPU ou memória, isso é problema na aplicação e o certo é corrigir a aplicação. Usar um orquestrador para reiniciar é apenas uma solução temporária. E se você realmente quiser implementar isso em um serviço do Docker Compose, você também consegue.
• 06:11 Isso não tem nada a ver com Compose ou orquestradores, isso é algo que você tem que configurar sozinho usando algum serviço de monitoramento, como Prometheus.
• 07:40 Nem todo mundo quer gerenciar recursos de forma automaticamente, só ver os vários casos de gente choramingando que perdeu dinheiro pois a AWS/GCP/Azure/etc auto escalonou o serviço dela de uma forma inviável para a pessoa. Como também nem todo mundo tem máquinas suficientes para aproveitar de auto escalonamento. Não adianta você ter auto escalonamento se você só tem uma VPS humilde de 1GBs de RAM.
• 07:55 Sim, é assim que o Compose funciona, mas você mesmo pode implementar blue-green deploys manualmente se quiser, só ter um proxy na frente da aplicação (nginx, por exemplo) e trocar para o novo deploy. E blue-green deploy não é tão necessário assim, especialmente se você tem uma empresa pequena com poucos recursos (uma VPS pequena, por exemplo), usar blue-green deploy seria inviável, pois fazer blue-green deploy igual como o Kubernetes faz significa que você teria que ter recursos suficientes para ter 2x instâncias rodando ao mesmo tempo. Como também nem todas as aplicações funcionam bem com um esquema de blue-green deploy sem precisar ter modificações consideráveis no código. Eu já dei exemplo sobre banco de dados e servidores de jogos antes, mas vai outro exemplo: Se você tem um bot para o Discord, você não vai querer duas instâncias dele rodando ao mesmo tempo, pois significa que por um tempo teria duas versões do bot rodando, conectadas na mesma shard, ou seja, ele estaria recebendo os mesmos eventos nas duas instâncias.

Não tem tantos pontos a comentar no vídeo pois a maior parte do tempo do vídeo é passado falando sobre curso, ou falando sobre sponsors, ou falando sobre coisas que não são relevantes a serem comentadas neste comentário.

No final, se você já usa Docker Compose, você já sabe de todas essas desvantagens que o Compose tem.

---

---