Ainda não use Kubernetes

Startups em estágio inicial não devem adotar Kubernetes precipitadamente.
Na maioria dos casos, ainda é cedo demais.

Para equipes pequenas (1 a 10 pessoas), é melhor usar um serviço de contêiner serverless.
(AWS ECS - Fargate, GCP Google Cloud Run)

[sungwoo]

O k8s já não é uma questão de gostar ou não; não virou uma questão de sobrevivência?
Mesmo sem conhecer AWS, acho que chegamos a uma situação em que é preciso conhecer k8s.

[bravomylife]

Discordo dessa opinião.

Acredito que a única desvantagem do k8s é justamente a curva de aprendizado.

Mesmo que a equipe tenha só umas 5 pessoas, no começo vai ser difícil, mas quando o nível de conhecimento sobre k8s passa de certo ponto, é impossível voltar atrás. O ganho de produtividade que isso traz é incomparável.

ci/cd, gitops, deploy canário etc. podem ser feitos sem k8s, mas fazer tudo isso junto em cima do k8s é mais fácil de entender e mais simples de gerenciar.

Como alguém que já viveu essa transição na prática, dizer que ainda é cedo me faz lembrar da época on-premise, quando as pessoas hesitavam em adotar a AWS Cloud por acharem algo estranho e pouco familiar.

[pppqqq]

Não é uma questão genérica do tipo “foque no negócio”; só acho difícil concordar com decisões que acabam prendendo você a alguma tecnologia específica.
Se fosse um texto defendendo o uso ativo de PaaS como beanstalk/app engine/heroku, eu concordaria plenamente, mas hoje em dia praticamente não há vantagens em uma equipe pequena escolher ECS/cloud run/docker swarm. Talvez fosse diferente 4 ou 5 anos atrás.

[jjpark78]

Do ponto de vista dos custos, o serverless é de longe mais vantajoso.

[tribela]

Eu também concordo. Na maioria dos casos, docker-swarm ou mesmo docker-compose já são mais do que suficientes.

[kbumsik]

Essa é uma opinião que também apareceu bastante nos comentários do Hacker News..... [1]
Fica um pouco confuso porque o texto parte do pressuposto de que "Kubernetes é difícil".

Hoje em dia, o ecossistema do Kubernetes evoluiu bastante, então, a menos que você instale Kubernetes diretamente on-premises, ele não é tão difícil assim.
Além disso, na operação do Kubernetes você consegue decidir até certo ponto o nível de complexidade por conta própria, e montar uma configuração básica não é algo tão complicado. Claro que depois, quando você começa a acoplar vários add-ons, aí naturalmente fica mais difícil.
Também já tem muita gente que, como eu, teve contato com ambientes de deploy começando por EKS ainda no início da carreira.

Falando de forma bem direta: eu realmente não entendo por que configurar um Deployment e um Ingress básicos no k8s (claro, com o banco de dados em um serviço gerenciado à parte) seria particularmente mais difícil do que configurar diretamente o AWS ECS Fargate, como o texto menciona.
Nos dois casos, você precisa configurar VPC, cluster, CDN e load balancer do mesmo jeito... e nos comentários também há muitos relatos dizendo que o ECS foi ainda mais incômodo.

[1] https://news.ycombinator.com/item?id=31795160

[colus001]

Concordo. Não acho que a configuração básica seja tão difícil, nem que a dificuldade de manutenção seja particularmente alta. Na nuvem, seja passando uma configuração complexa para algum outro setup ou para uma configuração em YAML do Kubernetes, sinceramente não sei dizer o que seria exatamente melhor.

[sixmen]

Na nossa empresa, quando o número de desenvolvedores passou de 100, sentimos essa necessidade e estamos fazendo a migração de ECS -> EKS, mas às vezes também bate um certo arrependimento.

Você disse que "na operação de Kubernetes é possível decidir, até certo ponto, o nível de complexidade por conta própria", mas, para quem não conhece muito bem, existe esse lado de pensar que tudo o que se comenta no ecossistema de Kubernetes deve ser necessário, e acabar colocando tudo.

Você disse que a necessidade de configurar load balancer continua a mesma, mas eu acho que existe uma diferença entre precisar conhecer só o ALB e precisar conhecer ALB + Ingress.

Assim como MSA não é necessária em escala pequena, Kubernetes exige mais coisas para aprender do que parece, então acho correto dizer que, em um porte em que "é preciso focar na aplicação", ele realmente é overkill.

Por outro lado, se alguém já tiver montado muito bem o ambiente de Kubernetes, implantar aplicações por cima dele até parece ter menos efeito de lock-in, já que tudo acaba sendo definido em uma forma mais independente de cloud.

[kbumsik]

Pelo que você disse, realmente parece que existem aspectos assim. Acho que acabei considerando como óbvias demais as coisas que aprendi usando Kubernetes.
E também reconheço que, como hoje em dia saem addons demais no ecossistema do Kubernetes, existe mesmo uma dificuldade na hora de decidir o que vale a pena adotar.

Como eu não tenho experiência de migração, tipo de ECS -> EKS... queria saber se, além de algo como efeito de lock-in, houve algum ponto em que as coisas melhoraram depois da transição.

[kbumsik]

Ah, só como referência, estou falando com base na minha experiência com EKS. É bem diferente de instalar k8s diretamente on-premise e operar você mesmo o etcd e o Control Plane, haha.

Do ponto de vista de quem começou já com k8s, lendo o texto eu acabei pensando o contrário: será que realmente vale a pena gastar tempo estudando ECS...?
De todo modo, acho que não precisa necessariamente definir isso de forma tão oficial; talvez o mais certo seja usar primeiro o que a equipe considerar mais confortável.

[525hm]

Concordo com a ideia de começar sem k8s.

[mrchypark]

Concordo muito.

Não apenas em empresas com 10 pessoas, mas também sou contrário à adoção de k8s em empresas de porte razoável.

Acho que isso só faz sentido quando o lock-in com o provedor de nuvem chega a um nível crítico, ou quando a infraestrutura on-premise também é usada em conjunto.

[jujumilk3]

Eu achava que havia, em certa medida, uma tendência de seguir por inércia as stacks tecnológicas de empresas de porte enterprise.
Por coincidência, um texto que organizou isso por escrito apareceu no Hacker News, então estou compartilhando.