Migração de Aplicações Legadas para Microsserviços na AWS

Eduardo Souza | CEO Dominit

Um relatório recorrente entre equipes de TI é sempre a mesma queixa: um deploy que devia levar minutos leva um dia inteiro de coordenação, porque uma mudança pequena num módulo de faturamento obriga a testar e reimplantar o sistema inteiro. Esse é o sintoma mais comum de um monólito legado que passou do ponto de retorno — e é também o motivo pelo qual "migrar para microsserviços" virou item recorrente em roadmap de modernização. O problema é que boa parte dessas iniciativas fracassa não pela tecnologia, mas pela ordem errada de decisões: escolher o runtime antes de entender os limites do domínio, ou tentar reescrever tudo de uma vez em vez de estrangular o monólito aos poucos. Este guia cobre o caminho técnico real — de quando vale a pena decompor até qual serviço da AWS roda cada pedaço da nova arquitetura, com os trade-offs que normalmente ficam de fora do discurso de vendas de microsserviços.

Por Que Decompor um Monólito Legado — e Quando Não Vale a Pena

Um monólito não é, por si só, um problema arquitetural. Muitas aplicações monolíticas rodam de forma estável por anos, e reescrever algo que funciona só para seguir uma tendência é o tipo de decisão que consome orçamento sem resolver a dor real do negócio. O sinal de que vale a pena decompor não é "o sistema é velho" — é a combinação de sintomas operacionais: deploys que exigem coordenar múltiplas equipes porque tudo está no mesmo pacote de implantação, um único componente com problema de performance ou confiabilidade que derruba módulos que não têm nada a ver com ele, e times que não conseguem escalar de forma independente porque a base de código inteira escala junto, mesmo que só uma parte precise.

A AWS Prescriptive Guidance recomenda avaliar candidatos à decomposição olhando primeiro para esses sintomas — problemas de confiabilidade ou performance, e componentes fortemente acoplados dentro de uma arquitetura monolítica — antes de decidir que microsserviços é o caminho. Vale a mesma lógica para o porte da empresa: uma companhia de 30 funcionários com um sistema interno usado por uma dúzia de pessoas raramente ganha algo decompondo esse sistema em oito serviços independentes — a complexidade operacional adicional (mais pipelines, mais observabilidade, mais superfícies de rede) supera o ganho. O cálculo muda quando a aplicação atende centenas de usuários simultâneos, tem módulos com padrões de carga muito diferentes entre si (um catálogo de produtos e um motor de recomendação, por exemplo), ou quando o gargalo real é organizacional: equipes que não conseguem trabalhar em paralelo porque dependem umas das outras para publicar qualquer mudança.

Estratégias de Decomposição: do Strangler Fig ao Domain-Driven Design

Depois de confirmar que a decomposição faz sentido, a pergunta seguinte é como fazer a transição sem parar o negócio por meses. Duas abordagens sustentam praticamente toda migração bem-sucedida.

Strangler Fig. O nome vem da figueira estranguladora, que cresce ao redor de uma árvore hospedeira até substituí-la por completo. Aplicado a software, o padrão consiste em criar a nova arquitetura em paralelo ao monólito e migrar funcionalidades incrementalmente, redirecionando tráfego aos poucos para os novos serviços até que o sistema antigo possa ser desligado com segurança. A AWS descreve o processo em três etapas — transformar, ao criar componentes modernizados portando ou reescrevendo trechos do monólito em paralelo ao sistema legado; rotear, direcionando o tráfego correspondente para o novo componente; e eliminar, retirando a funcionalidade antiga do monólito conforme o tráfego migra definitivamente. A vantagem central é o risco distribuído: em vez de uma migração "big bang" — arriscada justamente pelo tamanho e complexidade do monólito —, cada fatia migrada pode ser validada em produção antes da próxima.

Decomposição por domínio (Domain-Driven Design). Enquanto o Strangler Fig resolve o "como migrar sem parar", o DDD resolve o "onde cortar". A ideia é identificar bounded contexts — fronteiras de domínio de negócio com vocabulário e regras próprias (pedidos, pagamentos, catálogo, logística) — e transformar cada um em candidato a serviço independente. Cortar pela tecnologia (por exemplo, "todo código de banco de dados vira um serviço") tende a gerar microsserviços fortemente acoplados entre si, porque a fronteira não reflete uma fronteira de negócio real. Um padrão complementar de transição, o branch by abstraction, permite introduzir a nova implementação atrás de uma interface abstrata enquanto o código antigo ainda está em uso, trocando a implementação sem quebrar quem consome o serviço.

Na prática, as duas estratégias se combinam: o DDD decide as fronteiras (o que vira um serviço), e o Strangler Fig decide o ritmo (como migrar cada fronteira sem downtime).

Containers como Runtime Padrão: Amazon ECS, EKS e Fargate

Depois de decidir as fronteiras dos serviços, a decisão técnica seguinte é onde rodar cada um. Para a maioria dos microsserviços com estado de longa duração ou processos contínuos, containers em orquestração gerenciada é o ponto de partida mais comum na AWS — e existem três combinações relevantes.

O Amazon ECS (Elastic Container Service) é o orquestrador de containers proprietário da AWS: totalmente gerenciado, integrado nativamente a IAM, CloudWatch e Elastic Load Balancing, sem a complexidade de operar um control plane Kubernetes. É a opção mais simples para equipes que não têm (ou não querem ter) expertise em Kubernetes internamente.

O Amazon EKS (Elastic Kubernetes Service) entrega Kubernetes gerenciado — a AWS opera o control plane, mas a aplicação continua rodando sobre a API padrão do Kubernetes, com acesso ao ecossistema de ferramentas, operators e ao ecossistema de terceiros que já existe para essa plataforma. Faz sentido quando a equipe já opera Kubernetes em outro lugar (on-premises ou em outro provedor), quando existe dependência real de ferramentas do ecossistema CNCF, ou quando a portabilidade multi-cloud é um requisito explícito do negócio — não apenas uma preferência. Detalhamos esse cenário com mais profundidade no guia avançado de Amazon EKS.

Tanto ECS quanto EKS podem rodar sobre duas camadas de capacidade diferentes: instâncias Amazon EC2, onde a equipe escolhe o tipo de instância e gerencia a capacidade, ou AWS Fargate, um mecanismo de computação serverless que elimina o provisionamento e o patching de servidor — você define CPU e memória por task e a AWS cuida do resto. Fargate custa mais por unidade de computação do que EC2 gerenciado manualmente, mas remove uma classe inteira de trabalho operacional (dimensionamento de cluster, patching de SO, isolamento de workload por segurança), o que costuma compensar para equipes pequenas ou para serviços com padrão de tráfego imprevisível.

Um detalhe que vale registrar: o AWS App Runner, historicamente citado como alternativa mais simples para publicar containers direto de um repositório de código ou imagem, deixou de aceitar novos clientes — quem já usa continua operando normalmente, mas não é mais uma opção viável para uma migração que está começando agora. Vale considerar isso ao planejar, já que é comum encontrar esse serviço recomendado em conteúdo mais antigo.

Em todos os casos, as imagens de container circulam pelo Amazon ECR (Elastic Container Registry), que além de armazenar as imagens de forma privada e integrada a IAM, faz scanning de vulnerabilidades a cada push e aplica políticas de ciclo de vida para não acumular imagens obsoletas indefinidamente.

Runtime Serverless: Quando Lambda Substitui Containers

Nem todo microsserviço precisa de um processo rodando o tempo todo. Para serviços orientados a evento, com carga esporádica ou fortemente variável, ou para funções pequenas e bem isoladas dentro do domínio decomposto, o modelo serverless costuma custar menos e eliminar completamente o trabalho de gerenciar cluster — a infraestrutura escala por unidade de consumo, com cobrança pelo uso real e alta disponibilidade embutida por padrão, segundo o whitepaper da AWS sobre implementação de microsserviços.

Esse caminho já foi coberto em profundidade no artigo sobre arquitetura serverless na AWS com Lambda, Step Functions e API Gateway — vale tratá-lo como uma opção de runtime dentro da mesma decomposição de domínio, e não como um caminho concorrente ao de containers. É comum, inclusive, que a mesma arquitetura de microsserviços combine os dois: serviços de domínio central rodando em ECS ou EKS, e funções auxiliares — processamento assíncrono, integrações pontuais, orquestração de fluxo com Step Functions — rodando em Lambda. A escolha certa depende do padrão de carga e da complexidade de cada serviço individual, não de uma preferência arquitetural única para o sistema inteiro.

Comunicação Entre Serviços: API Gateway e Descoberta de Serviço

Decompor o monólito troca chamadas de função dentro do mesmo processo por chamadas de rede entre processos distintos — e essa mudança introduz uma classe inteira de problema que não existia antes: latência de rede, falhas parciais, e a necessidade de cada serviço saber onde encontrar o outro.

O Amazon API Gateway funciona como a porta de entrada única para os microsserviços expostos externamente — suporta APIs REST, HTTP e WebSocket, lida com autenticação (políticas IAM, autorizadores Lambda, pools de usuários do Cognito), limitação de taxa, versionamento e deployments canário para publicar mudanças com segurança. Para comunicação entre serviços internos, a decisão típica é entre chamadas síncronas via HTTP (mais simples de depurar, mas cria acoplamento temporal — o chamador espera a resposta) e comunicação assíncrona via filas e tópicos (Amazon SQS e SNS), que desacopla o tempo de vida dos serviços e tolera melhor picos de carga, ao custo de uma consistência que passa a ser eventual em vez de imediata.

Service discovery — como um serviço encontra o endereço de rede atual de outro, já que containers e funções sobem e descem o tempo todo — é resolvido nativamente pelo AWS Cloud Map em conjunto com ECS e EKS, ou pelo próprio DNS interno do Kubernetes quando o runtime é EKS. Para arquiteturas maiores, um service mesh (como o AWS App Mesh, citado no próprio material da AWS sobre microsserviços) centraliza políticas de roteamento, retry e circuit breaking fora do código de cada serviço — mas é uma camada de complexidade adicional que só compensa a partir de um número relevante de serviços se comunicando entre si.

CI/CD e Observabilidade para uma Arquitetura de Microsserviços

Um monólito tem um pipeline de build e deploy. Uma arquitetura de dez microsserviços, se não for bem planejada, pode acabar com dez pipelines desalinhados — e esse é um dos jeitos mais comuns de uma migração perder o controle silenciosamente. O caminho mais sustentável é um pipeline padronizado e reutilizável por serviço, cada um publicando de forma independente, sem exigir coordenação manual entre times a cada release. Cobrimos esse desenho em detalhe no artigo sobre CI/CD avançado na AWS com CodePipeline, CodeBuild e estratégias de deploy blue-green/canary, que se aplica diretamente a esse cenário — cada microsserviço decomposto ganha seu próprio pipeline, com deploy incremental e rollback automatizado em caso de erro.

Observabilidade é onde a decomposição cobra o preço mais alto se for negligenciada. Um erro que atravessa cinco serviços é ordens de magnitude mais difícil de depurar do que uma stack trace única de um monólito, porque a causa raiz pode estar em qualquer ponto da cadeia de chamadas. Rastreamento distribuído — não apenas logs e métricas isolados por serviço — deixa de ser opcional a partir do momento em que existe mais de um serviço em produção; tratamos esse tema com profundidade no guia de observabilidade na AWS com CloudWatch e X-Ray. Um erro comum nessa fase é publicar os primeiros microsserviços sem tracing distribuído "porque dá para adicionar depois" — na prática, depois é sempre mais caro, porque exige instrumentar retroativamente serviços já em produção sob pressão de um incidente real.

ECS vs. EKS vs. Fargate vs. Lambda Como Runtime de Microsserviço

Não existe runtime "melhor" de forma absoluta — a escolha depende do que a equipe já sabe operar, do padrão de carga de cada serviço e de quanto controle sobre a infraestrutura subjacente realmente é necessário.

Critério	Amazon ECS	Amazon EKS	AWS Fargate (camada de capacidade)	AWS Lambda
Modelo operacional	Orquestrador proprietário AWS, totalmente gerenciado	Kubernetes gerenciado, API padrão do ecossistema CNCF	Serverless — sem gestão de servidor ou cluster	Serverless — sem gestão de servidor, orientado a evento
Curva de aprendizado	Baixa para quem já usa serviços AWS	Alta — exige conhecimento de Kubernetes	Baixa, combinado com ECS ou EKS	Baixa para funções pequenas e bem isoladas
Melhor para	Equipes sem expertise prévia em Kubernetes, integração nativa com AWS	Portabilidade multi-cloud, dependência do ecossistema CNCF, times já operando K8s	Cargas variáveis, equipes pequenas, times que querem eliminar gestão de servidor	Serviços orientados a evento, carga esporádica, funções auxiliares de curta duração
Controle de infraestrutura	Médio	Alto (via configuração do cluster)	Baixo (por design)	Muito baixo (por design)
Modelo de custo	Pago pela capacidade EC2 subjacente, ou por Fargate	Cobrança por cluster + capacidade EC2 ou Fargate	Por vCPU/memória consumidos, cobrança por segundo	Por invocação + tempo de execução

Custos e Métricas de uma Migração para Microsserviços

Migrar para microsserviços raramente reduz o custo de infraestrutura no primeiro momento — na verdade, é comum o custo total subir durante a transição, porque o monólito e os novos serviços rodam em paralelo enquanto a migração incremental do Strangler Fig avança. O retorno real aparece em métricas de velocidade e resiliência, não só na fatura da AWS: frequência de deploy por serviço, tempo médio de recuperação depois de um incidente (MTTR), e o "blast radius" de uma falha — quantos usuários e funcionalidades um único componente com problema consegue afetar.

Do lado estritamente financeiro, os itens que mais pesam numa arquitetura de microsserviços recém-decomposta são: múltiplos load balancers ou listeners por serviço, tráfego de rede entre serviços que antes era uma chamada de função local e agora atravessa a rede (e pode cruzar zonas de disponibilidade, o que tem custo), e a sobreposição temporária de infraestrutura do monólito antigo com a dos novos serviços durante a transição. É por isso que acompanhar custo de perto durante a migração — não só depois que ela termina — é parte do trabalho, tema que aprofundamos no guia de FinOps na AWS. Um erro recorrente é comparar o custo de infraestrutura pré e pós-migração isoladamente, sem contabilizar o ganho (ou a ausência de ganho) em velocidade de entrega — que é, na maioria dos casos, o motivo real de decompor.

Casos de Uso por Porte de Empresa

Para empresas entre 30 e 150 funcionários, a decomposição raramente compensa como projeto de uma vez só — o caminho mais realista costuma ser extrair um ou dois módulos específicos com dor real (o que já concentra a maior parte do sofrimento operacional) via Strangler Fig, mantendo o restante do monólito intacto até que exista motivo concreto para seguir. Nesse porte, Fargate ou Lambda tendem a fazer mais sentido do que EKS — o overhead de operar Kubernetes raramente se paga sem uma equipe dedicada de plataforma.

Para empresas entre 150 e 400 funcionários, com múltiplas equipes de desenvolvimento trabalhando na mesma base de código, o cálculo muda: a dor de coordenação entre times já justifica uma decomposição mais ampla, e a diferença entre ECS e EKS passa a depender mais da bagagem técnica interna do que do porte em si.

Para empresas acima de 400 funcionários, com times de plataforma dedicados, EKS entra como opção real com mais frequência — especialmente quando existe operação híbrida ou multi-cloud, ou dependência de ferramentas específicas do ecossistema Kubernetes que não têm equivalente direto no ECS.

Riscos e Armadilhas Comuns na Migração

O erro mais caro em migrações de microsserviços não é técnico — é decompor por camada técnica (todo o código de banco de dados vira um "serviço de dados", toda a lógica de UI vira outro) em vez de por domínio de negócio, o que produz serviços que continuam fortemente acoplados entre si e exigem deploy coordenado, replicando o problema original do monólito com uma camada extra de complexidade de rede por cima.

Outro risco recorrente é o "monólito distribuído": múltiplos serviços que, na prática, compartilham o mesmo banco de dados. Isso elimina o principal benefício de isolamento da decomposição — uma mudança de schema num serviço ainda quebra os outros — enquanto mantém todo o custo operacional extra de ter múltiplos serviços implantados separadamente. Cada microsserviço decomposto de verdade precisa ser dono dos próprios dados, mesmo que isso signifique duplicar informação entre serviços via eventos, em vez de compartilhar uma tabela.

Por fim, subestimar a complexidade de dados distribuídos costuma ser o ponto que mais atrasa cronogramas: transações que antes eram atômicas dentro de um único banco de dados relacional agora precisam de padrões como Saga ou consistência eventual entre serviços, e essa mudança de modelo mental raramente é trivial para uma equipe acostumada a décadas de transação ACID local.

Perguntas Frequentes sobre Microsserviços na AWS

Qual é a diferença entre decompor um monólito e simplesmente containerizar ele?

Containerizar um monólito — empacotar a aplicação inteira em uma imagem Docker e rodá-la em ECS ou EKS — resolve problemas de portabilidade e padronização de ambiente, mas não resolve o acoplamento interno do código. É um passo válido e frequentemente o primeiro de uma migração, mas não é, por si só, uma arquitetura de microsserviços.

É obrigatório usar Kubernetes (EKS) para ter microsserviços na AWS?

Não. Amazon ECS orquestra containers sem exigir conhecimento de Kubernetes, e AWS Lambda elimina até a necessidade de gerenciar containers para boa parte dos serviços. EKS só se justifica quando existe uma razão concreta — portabilidade multi-cloud, dependência do ecossistema CNCF ou expertise já consolidada na equipe.

Quanto tempo leva uma migração de monólito legado para microsserviços?

Varia enormemente com o tamanho do monólito e o número de domínios de negócio envolvidos, mas seguindo o Strangler Fig — que é incremental por natureza — o primeiro serviço extraído costuma sair em semanas, não meses, porque o objetivo inicial é validar o padrão de migração num escopo pequeno antes de replicá-lo.

Como migrar o servidor legado para a AWS antes de começar a decomposição?

Quando a aplicação ainda roda on-premises ou em outro provedor, o primeiro passo costuma ser um rehost via AWS Application Migration Service (MGN), que replica servidores físicos ou virtuais para a AWS com janelas de corte de minutos. Depois desse "lift and shift" inicial, a aplicação já está na nuvem e pronta para começar a decomposição — sem misturar os dois riscos (migração de provedor e reescrita de arquitetura) no mesmo projeto.

Microsserviços sempre reduzem custo de infraestrutura?

Não necessariamente, e raramente no curto prazo. O ganho real costuma estar em velocidade de entrega, resiliência e escalabilidade independente por serviço — o custo de infraestrutura pode até subir durante a transição, quando monólito e novos serviços coexistem.

Preciso de um service mesh desde o primeiro microsserviço?

Não. Um service mesh como o AWS App Mesh resolve problemas de roteamento, retry e observabilidade de rede que só ficam relevantes a partir de um número razoável de serviços se comunicando entre si. Introduzir essa camada cedo demais adiciona complexidade operacional sem um problema real para resolver ainda.

Serverless (Lambda) e containers (ECS/EKS) podem conviver na mesma arquitetura de microsserviços?

Sim, e é comum que convivam. Serviços de domínio central com processamento contínuo costumam rodar melhor em containers, enquanto funções orientadas a evento, integrações pontuais e processamento assíncrono se encaixam bem em Lambda — a decisão é por serviço, não uma escolha única para o sistema inteiro.

Microsserviços na AWS Como Consequência de uma Decomposição Bem Feita, Não Como Ponto de Partida

A pergunta que realmente decide o sucesso de uma migração para microsserviços não é "ECS ou EKS" nem "containers ou serverless" — é se a decomposição respeitou as fronteiras reais do domínio de negócio, e se a transição foi conduzida de forma incremental o suficiente para não colocar a operação em risco no meio do caminho. O runtime é a decisão mais visível, mas é também a mais fácil de reverter; errar a fronteira do serviço ou pular a validação incremental do Strangler Fig custa muito mais caro para corrigir depois.

Empresas que tratam essa migração como um projeto técnico isolado da estratégia de negócio tendem a produzir sistemas mais distribuídos, mas não necessariamente mais simples de operar. As que partem dos sintomas reais — onde o deploy trava, onde a escala é desigual, onde as equipes esbarram umas nas outras — e usam a AWS como conjunto de peças para resolver esses sintomas específicos são as que colhem o ganho que a promessa dos microsserviços sempre fez.