Kubernetes gerenciado na Cloud ou serviços de containers? E quando é idiotice migrar de um para o outro?

Existe uma diferença enorme entre simplificar uma arquitetura e simplesmente trocar uma tecnologia por outra. Kubernetes gerenciado não é barato nem simples, mas quando já está produtivo, maduro e integrado ao ecossistema da empresa, a história é totalmente outra. Nesse cenário, migrar para outro serviço de containers não é apertar um botão e a mágica acontece, você está criando um novo projeto, com novos custos, riscos e limitações. Isso tudo enquanto o antigo ainda está vivo e você dobrando seus custos com infraestrutura. E antes de chamar isso de modernização, talvez valha fazer uma pergunta incômoda: qual problema estamos realmente tentando resolver?

1. A provocação

“Precisamos sair do Kubernetes porque Kubernetes é complexo.”

Essa pedrada vindo ainda nesse cenário:

1. A empresa possui um cluster Kubernetes gerenciado, como Azure AKS ou Amazon EKS.
2. A plataforma já está em produção.
3. Times já utilizam Kubernetes diariamente.
4. CI/CD, observabilidade, segurança, autoscaling, secrets, ingress, service mesh e integrações já estão estabelecidos.

E então de repente surge a proposta abençoada:

“Vamos migrar tudo para um serviço de containers gerenciado. Vai ser muito mais simples.”

Mais simples para quem? E a que custo?

Primeiro de tudo, container não é Kubernetes

Antes de discutir EKS, AKS, GKE, ECS ou Container Apps, vale separar duas coisas que frequentemente aparecem como se fossem equivalentes, mas não são.

Container é uma forma de empacotar e executar uma aplicação. Kubernetes é uma plataforma para orquestrar containers.

Um container resolve principalmente o problema de como executar a aplicação de forma isolada e reproduzível. Ele empacota a aplicação, suas dependências e configurações necessárias para execução.

Mas, em produção, rapidamente aparecem outras perguntas:

• Onde esse container vai rodar?
• Quem reinicia se ele morre?
• Como escalar de 2 para 50 instâncias?
• Como distribuir tráfego entre as instâncias?
• Como fazer rollout sem derrubar a aplicação?
• Como descobrir serviços uns aos outros?
• Como lidar com configuração e secrets?
• Como distribuir workloads entre máquinas?
• Como fazer scheduling?
• Como controlar recursos?
• Como observar e operar tudo isso?

É justamente aí que entra um orquestrador.

Container, Kubernetes, Cloud

A relação conceitual é mais ou menos esta:

O EKS, AKS e GKE não são “tipos diferentes de container”.

Eles são serviços gerenciados que entregam Kubernetes.

A Cloud assume uma parte relevante da operação da plataforma, principalmente a infraestrutura de controle e componentes gerenciados, mas a aplicação continua interagindo com uma plataforma baseada nos conceitos e APIs do Kubernetes.

Você continua pensando em coisas como:

Pod, Deployment, Service, Ingress, ConfigMap, Secret, HPA, Namespace, RBAC, Node, Scheduling e etc.

Ou seja, existe uma abstração importante, mas o modelo operacional continua sendo Kubernetes.

E quando tiramos Kubernetes da equação?

É aqui que algumas comparações começam a ficar perigosas.

Serviços como Amazon ECS, Azure Container Apps, Azure App Service e AWS App Runner também permitem executar aplicações baseadas em containers, mas eles não são simplesmente “Kubernetes mais fácil”.

Eles adotam outro modelo de abstração.

A diferença não é simplesmente “Kubernetes é complicado e Container Apps é simples.”

A diferença é onde a plataforma coloca as abstrações e quem fica responsável por determinadas decisões.

No Kubernetes, você recebe uma plataforma extremamente flexível e extensível. Essa flexibilidade traz poder, mas também traz decisões operacionais.

Em um serviço mais opinativo, muitas dessas decisões já vêm pré-definidas ou são escondidas pela plataforma e isso pode ser exatamente o que você quer.

Mas também significa que você abre mão de algumas possibilidades de controle e passa a operar dentro das regras daquela plataforma.

2. O ponto que costuma passar despercebido

Quando alguém fala:

“Vamos tirar o Kubernetes porque ele é complexo.”

A pergunta seguinte deveria ser:

“Qual complexidade estamos removendo e qual complexidade estamos aceitando no lugar?”

Porque a aplicação continua existindo, os containers continuam existindo, a comunicação entre a rede interna e externa continua existindo, os deployments continuam existindo, a observabilidade continua existindo, a segurança continua existindo, a escalabilidade continua existindo.

Acho que já deu para entender, né ? O que muda é quem implementa, quem abstrai e quem opera essas responsabilidades.

Por isso, migrar de Kubernetes para uma plataforma mais gerenciada pode ser uma excelente decisão arquitetural mas não deveria ser justificado simplesmente como um“Container é mais simples que Kubernetes.”

Container não substitui Kubernetes, Container é o workload e Kubernetes é uma plataforma de orquestração. E um serviço como Container Apps é uma outra forma de oferecer uma plataforma para executar workloads.

Entao a provocação que fica é justamente essa:

“Tirar Kubernetes do caminho não significa necessariamente eliminar complexidade. Muitas vezes significa apenas mover a complexidade para outro lugar.”

E, dependendo do problema que você está tentando resolver, mover essa complexidade pode ser exatamente a decisão certa.

MAS quando o Kubernetes já está rodando em produção, a discussão muda bastante.

Você não está mais escolhendo simplesmente “onde rodar um container”. Já existe uma plataforma construída ao redor dele, com deployments, autoscaling, ingress, observabilidade, secrets, service discovery, pipelines, políticas de segurança e processos operacionais. Migrar para Container Apps ou outro serviço gerenciado significa substituir parte desse modelo, e não apenas trocar a infraestrutura por uma opção mais simples.

Nesse cenário, a pergunta não deveria ser “Kubernetes é mais complexo?”, porque provavelmente essa complexidade já foi absorvida pela organização. A pergunta passa a ser se o benefício de uma plataforma mais opinativa compensa o custo de migrar workloads, pipelines, observabilidade, segurança, integrações e conhecimento operacional já construído. Um cluster Kubernetes produtivo representa também investimento arquitetural e conhecimento acumulado, que não desaparece porque outra plataforma possui uma experiência de desenvolvimento mais simples.

Por isso, comparar EKS/AKS/GKE diretamente com Container Apps pode gerar uma falsa sensação de simplificação. Você pode reduzir a quantidade de Kubernetes que precisa operar, mas terá que adaptar a aplicação ao modelo da nova plataforma e aceitar suas limitações, abstrações e formas de operação. A complexidade não necessariamente desaparece, ela muda de lugar, e pior. Enquanto ela não muda completamente de lugar ela está gerando o triplo de complexidade.

No fim, migrar de um Kubernetes produtivo para um serviço mais opinativo pode ser uma ótima decisão, mas precisa existir uma razão arquitetural clara para isso. Se o problema é o custo ou a complexidade operacional do Kubernetes, talvez a solução seja reduzir essa complexidade dentro do próprio Kubernetes antes de jogar fora uma plataforma que já funciona.

A pergunta que deveria vir antes de se quer sugerir a migração

Antes de discutir tecnologia, a pergunta deveria ser: “Qual problema estamos tentando resolver?”

A lógica deveria ser simples: uma migração precisa resolver um problema mensurável.

Se o cluster custa caro, precisamos medir quanto custa e por quê. Se a operação é complexa, precisamos identificar quais componentes geram essa complexidade. Se o problema é baixa utilização, precisamos avaliar se o workload realmente se beneficia de scale-to-zero. Caso contrário, existe um risco clássico em arquitetura: confundir uma tecnologia mais simples com uma solução melhor para o problema existente.

No caso de um Kubernetes produtivo que já funciona, a pergunta não é simplesmente “o que é mais fácil de operar?”. Acaba sendo:

“O ganho dessa simplificação é suficiente para justificar o custo, o risco e as limitações da migração?”

3. O custo invisível do “é só migrar os containers”

Aqui está talvez o maior erro conceitual de uma migração desse tipo: confundir container com aplicação. Ter uma imagem Docker não significa que a aplicação é apenas aquela imagem. Em um Kubernetes produtivo, o container normalmente está cercado por uma quantidade enorme de recursos e integrações que fazem parte do funcionamento da aplicação.

Por isso, dizer “temos Docker, então basta colocar a imagem no novo serviço” é uma simplificação perigosa. A pergunta real não é apenas se o destino consegue executar o container, mas quanto do ambiente que envolve esse container existe no destino e quanto precisará ser redesenhado.

Replatforming sem mudança de negócio

Existe ainda uma questão maior. Uma migração de plataforma não necessariamente cria valor para o negócio.

Se depois de meses de trabalho continuamos entregando o mesmo produto, para os mesmos clientes, com as mesmas funcionalidades, precisamos questionar qual foi o retorno da migração.

Enquanto o negócio permanece praticamente igual, podem ter mudado arquitetura, IaC, pipelines, observabilidade, networking, segurança, troubleshooting, documentação, treinamento e modelo operacional.

É perfeitamente possível gastar seis meses migrando a plataforma para terminar com uma conclusão pouco confortável:

“Passamos seis meses migrando a plataforma para continuar rodando exatamente os mesmos containers.”

E aí chegamos no paradoxo:

Talvez a nova plataforma realmente seja mais simples. Mas isso precisa ser demonstrado no contexto do ambiente existente, e não apenas olhando para a experiência de criar um novo container. Apergunta que deveria acompanhar toda a decisão é:

“Nós realmente removemos complexidade ou apenas trocamos o tipo de complexidade?”

Porque migrar um container pode ser simples.

Migrar tudo o que existe ao redor dele é outra história.

4. Kubernetes tem uma vantagem que frequentemente é ignorada: o padrão

Uma das maiores vantagens do Kubernetes aparece justamente quando pensamos além da Cloud atual: ele já é um padrão de mercado. Um Deployment continua sendo um Deployment, um Service continua sendo um Service e um container continua sendo um contâiner, independentemente de estar rodando em EKS, AKS, GKE ou em Kubernetes próprio. Isso cria uma camada comum entre a aplicação e o provedor de Cloud.

Isso não significa que uma aplicação em EKS possa ser simplesmente copiada para AKS sem nenhuma adaptação. Rede, IAM, storage, load balancers e integrações com serviços nativos da Cloud ainda precisam ser tratados. Mas existe uma diferença importante: a camada de orquestração permanece familiar. O conhecimento de Kubernetes, os manifests, as ferramentas e boa parte do modelo operacional continuam válidos.

É justamente essa padronização que cria uma possibilidade estratégica importante: arquiteturas celulares. A empresa pode pensar em cada célula como uma unidade relativamente autônoma, com a mesma plataforma Kubernetes sendo utilizada em diferentes Clouds, regiões ou ambientes. A Cloud passa a fornecer infraestrutura e serviços complementares, enquanto Kubernetes funciona como uma camada comum de execução. Então Kubernetes é realmente complexo, mas pelo menos sua complexidade é padronizada.

Tombando a AWS para Azure: estamos migrando de Cloud ou abandonando Kubernetes?

Imagine uma organização que hoje possui:

E decidimos migrar para Azure:

Tirando toda a camada de Segurança/RBAC, Redes, esteira CI/CD (que já haveria mesmo rodando em serviços de containers gerenciados), o Core do Cluster permance o mesmo, com seus Helms e Add-ons também compatíveis. Agora imagina o trampo de tombar um AWS ECS para um Container Apps.

Multi-cloud: onde a teoria encontra a realidade

Com Kubernetes, existe uma camada comum:

A célula pode mudar de Cloud mantendo grande parte do modelo da aplicação e da plataforma. E detalhe: com ferramentas como o ArgoCD conseguimos de maneira muito fácil concilhar dois Clusteres e gerenciar o estados de nossos Objetos, seja ele EKS, AKS, GKP ou até mesmo clusteres mais sofisticados em OpenShift

Agora compare com uma estratégia baseada em serviços proprietários:

Não existe uma abstração equivalente perfeita entre os dois lados. Deployment, networking, autoscaling, IAM, service discovery, observabilidade, integrações, IaC e operação passam a seguir modelos diferentes.

Isso não torna ECS ou Container Apps escolhas ruins. Para uma única Cloud, eles podem ser exatamente a escolha mais simples e adequada. O problema aparece quando a organização descobre, anos depois, que a simplicidade obtida na adoção inicial criou uma dependência maior na hora de mudar de provedor.

Essa é uma das razões pelas quais Kubernetes pode fazer sentido como camada de padronização em uma arquitetura celular: cada célula pode estar próxima da infraestrutura e dos serviços da Cloud onde roda, mas mantém uma interface de execução comum.

Multi-cloud com Kubernetes pode ser uma estratégia. Multi-cloud com dois serviços proprietários de containers pode virar dois produtos diferentes fingindo ser a mesma plataforma.

E talvez essa seja uma das maiores vantagens de Kubernetes que não aparecem quando olhamos apenas para o custo de operar um cluster: o valor de um padrão também está na liberdade que ele preserva para o futuro.

5. Quando sair do Kubernetes faz sentido e quando começa a parecer uma péssima ideia

O objetivo deste artigo não é transformar Kubernetes em religião. Existem cenários em que sair do Kubernetes é uma excelente decisão arquitetural. Se temos uma API stateless extremamente simples, pouco volume, baixa necessidade de customização, workloads event-driven ou jobs pontuais, e realmente precisamos de scale-to-zero e de um modelo mais serverless, manter um cluster inteiro pode significar pagar complexidade por uma capacidade que praticamente não utilizamos.

A própria proposta de serviços como Container Apps parte justamente dessa premissa: quando a aplicação não precisa acessar diretamente as APIs do Kubernetes nem utilizar seus recursos avançados, uma plataforma mais opinativa pode entregar o resultado com muito menos responsabilidade operacional.

Se você usa 10% do Kubernetes, talvez esteja pagando complexidade por 100% da plataforma.

O problema começa quando essa lógica é aplicada a um Kubernetes produtivo que já funciona bem. Se o cluster possui custo controlado, operação madura, observabilidade consolidada, dezenas de workloads, operadores, CRDs, GitOps, estratégias avançadas de deployment, service mesh ou outras integrações profundas com o ecossistema, a conta muda completamente. E se ainda existe uma estratégia de multi-cloud, trocar Kubernetes por uma plataforma altamente proprietária pode transformar uma migração de Cloud em uma migração de plataforma inteira.

É por isso que “managed services é melhor” também é uma simplificação. Managed Services não significa automaticamente mais barato, mais portátil, mais flexível ou melhor para qualquer workload. Significa principalmente que a Cloud assumiu uma parcela maior das responsabilidades operacionais. Você troca controle por responsabilidade reduzida, e isso pode ser excelente, desde que seja exatamente o trade-off que o workload precisa.

E aqui aparece um custo que frequentemente fica fora do business case: o ecossistema que foi construído ao redor do Kubernetes. Quantas ferramentas, automações, pipelines, conhecimentos, dashboards, políticas, integrações e abstrações foram construídos durante cinco anos e precisarão ser substituídos em seis meses?

Por isso, antes de discutir “Kubernetes ou Container Apps?”, a discussão correta deveria começar pelo workload: qual é o SLA, qual é o perfil de escala, quanto Kubernetes realmente utilizamos, qual é o custo atual, qual é o custo de migração, qual será o custo futuro, qual nível de lock-in é aceitável, qual é o impacto operacional e qual é o risco da mudança.

A provocação, portanto, não é “nunca saia do Kubernetes”. É justamente o contrário: saia quando existir uma razão concreta para sair.

Se a migração reduz custo, elimina complexidade real, habilita um modelo de escala que o workload precisa ou libera o time de responsabilidades que não geram valor, ótimo.

Mas se o cluster já é produtivo, barato o suficiente, maduro, automatizado, utilizado de forma relevante e ainda oferece uma camada importante de padronização e portabilidade, migrar apenas porque “a outra opção parece mais simples” pode ser uma das formas mais caras de criar simplicidade.

Uma matriz que ajuda a decidir quando usar um ou outro: