3

Pelo menos a discussão não é usar barriga da máquina vs containers.

Já é uma discussão mais elevada, entre usar k8s ou docker-compose.

Tudo tem tradeoffs, vou focar em defender o uso de k8s. Gitops com argocd, serviços self-hosted via helm chart como supabase ou n8n facil de fazer deploy, ingress, secrets.

Já usei barriga de máquina, docker, docker compose, docker swarm, e agora uso k8s.

Uma vps com 4gb de ram da pra rodar um k3s, os devs podem usar k3s local, uma máquina com mais recursos pode ter namespaces e ingress separados para ambiente dev/staging/prod.

Caso precise expandir ou escalar, já tem os manifestos yaml ou helm charts prontos para subir em um EKS ou um cluster próprio de talos.dev por exemplo.

Usar k8s te deixa mais próximo de ser agnóstico da cloud, diminuindo o risco de vendor-lockin.

Meu fluxo pessoal de uso de containers:

  • intellij/vscode/shell
  • docker
  • docker-compose
  • k3s
  • k8s prod
Carregando publicação patrocinada...
1

O argumento do vendor lock-in com manifests prontos é legítimo se você já está nessa jornada de qualquer jeito. Mas esse fluxo só funciona bem pra quem já passou pelo docker swarm e entende o que cada camada resolve. Pra quem vem do compose direto, o k3s ainda custa caro em curva de aprendizado antes de gerar valor.

3

"custa caro em curva de aprendizagem"

No meu caso, é tipo dirigir um carro popular durante a vida toda depois pilotar um carro de luxo, da pra voltar, mas fica o gostinho do luxo por um tempo.

Depois de ficar "fluente" em kubernetes, usar docker puro ou docker compose é como se eu estivesse voltando pra barriga da máquina ao invés de usar containers.

Assim como a W3C define padrões para a web, a CNCF atua como uma fundação neutra que organiza e "aprova" projetos de infraestrutura em nuvem.

https://landscape.cncf.io/

A discussão do uso de docker-compose é para cenário de desenvolvimento, sobre o swarm, tenho péssimas experiências práticas com ele rodando em 4 máquinas em produção, cuidar do deploy automatizado, ingress, batches ou jobs requer muito contorno, as secrets viram arquivos dentro dos container, resolução de nome dos serviços interno era instável.

Sugiro reavaliar o tal "custo de curva de aprendizagem" ainda mais com um monte de LLM para ajudar hoje em dia.

1

A experiência com Swarm faz sentido, esse problema de resolução de nomes e secrets como arquivo é clássico do ecossistema.

Mas o meu ponto sobre custo não é só a curva de aprendizado inicial. É o overhead contínuo depois que você já sabe: monitorar etcd, gerenciar certificados, debugar scheduling, entender por que um pod não subiu. LLM ajuda a aprender mais rápido, mas não opera o cluster por você no domingo de madrugada.

Sobre a analogia do carro de luxo: faz sentido quando você tem a estrada certa. Para um time de 2 devs com 3 serviços, o luxo vira manutenção que ninguém pediu e que ninguém no time tem contexto para resolver rápido.

O landscape CNCF é impressionante e também é parte do problema.