Roteiro de deploy na nuvem

Kubernetes não é a resposta certa para todo time. Ele resolve problemas reais em escala — mas traz uma complexidade operacional e um custo significativos, capazes de afundar um time pequeno ou uma startup antes mesmo de ela lançar sua primeira funcionalidade. Esta aula mapeia o panorama de deploy e oferece um roteiro de decisão: dado o tamanho do seu time, a quantidade de serviços e a sua maturidade operacional, qual é a escolha de infraestrutura certa agora, e como você evolui para o próximo nível?

A aula anterior, Modelos de serviço, deu o vocabulário (IaaS, PaaS, CaaS, DBaaS). Esta aula o transforma em plataformas concretas, preços e um caminho de migração para a loja: gateway, account, order, Postgres.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

1. O espectro da infraestrutura gerenciada

Os provedores de nuvem foram, aos poucos, abstraindo as preocupações de infraestrutura. O trade-off é sempre o mesmo: quanto mais a plataforma gerencia, menos controle você tem e menos carga operacional você carrega. O diagrama vai da opção mais gerenciada, à esquerda, até a de mais controle (e mais trabalho), à direita:

flowchart LR
    subgraph dx ["Caminho da experiência do desenvolvedor"]
        railway["Railway / Render<br/>(git push → URL)"] -->|"mais controle, mais ops"| fly["Fly.io<br/>(Dockerfile, regiões)"]
        fly -->|"mais controle, mais ops"| lightsail["Lightsail<br/>(VM simples ou containers)"]
    end
    subgraph aws ["Caminho nativo da AWS"]
        express["ECS Express Mode<br/>(imagem → URL HTTPS)"] -->|"mais controle, mais ops"| ecs["ECS Fargate<br/>(task definitions, sem nós)"]
        ecs -->|"mais controle, mais ops"| eks["EKS<br/>(Kubernetes completo)"]
        eks -->|"mais controle, mais ops"| vm["VMs EC2<br/>(você opera tudo)"]
    end

A seção 5 estima o custo mensal de cada uma para o mesmo workload.

2. Roteiro de decisão por tamanho de time

flowchart TD
    A{"Precisa rodar na AWS?<br/>(créditos, compliance)"}
    A -->|Não| B{"Usuários espalhados por<br/>vários continentes?"}
    B -->|Não| C["Railway / Render<br/>(git push → URL)"]
    B -->|Sim| D["Fly.io<br/>(máquinas multirregião)"]
    A -->|Sim| E{"Uma VM ou poucos<br/>containers bastam?"}
    E -->|Sim| F["Lightsail<br/>(preço mensal fixo)"]
    E -->|Não| G["ECS Express Mode<br/>(Fargate + ALB)"]

flowchart TD
    A{"Há um engenheiro de ops /<br/>plataforma dedicado?"}
    B["ECS Fargate + ALB + RDS<br/>(containers serverless, sem nós)"]
    C["EKS (managed node groups)<br/>ou ECS com mais controle"]

    A -->|Não| B
    A -->|Sim| C

3. As plataformas em detalhe

AWS Lightsail Containers

O Lightsail embrulha containers em uma abstração que lembra o Heroku: envie uma imagem, defina variáveis de ambiente, escolha um tamanho de nó (power) e uma quantidade de nós (scale) e receba um endpoint HTTPS público. Não há VPCs, security groups nem políticas IAM para configurar, e o preço mensal é fixo por nó⁴.

$ aws lightsail create-container-service --service-name my-api \
    --power small --scale 1
$ aws lightsail create-container-service-deployment \
    --service-name my-api \
    --containers '{"my-api":{"image":"my-registry/my-api:latest","ports":{"8080":"HTTP"}}}' \
    --public-endpoint '{"containerName":"my-api","containerPort":8080}'

A imagem precisa vir de um registry público (por exemplo, o Docker Hub) ou ser enviada ao registry do próprio serviço com aws lightsail push-container-image; o Lightsail passa então a se referir a ela como :my-api.<label>.<version>.

Amazon ECS Express Mode (sucessor do App Runner)

O ECS Express Mode (lançado em novembro de 2025³) mantém a simplicidade do App Runner — "entra uma imagem, sai uma URL HTTPS" —, mas tudo o que ele cria é um recurso ECS comum na sua própria conta. Com uma única chamada, você fornece uma imagem de container e duas roles IAM; o ECS provisiona um serviço Fargate, um Application Load Balancer com HTTPS, auto scaling, security groups e uma URL padrão². Não há cobrança extra pelo Express Mode — você paga pelas tasks Fargate, pelo balanceador de carga e pelos demais recursos subjacentes.

aws ecs create-express-gateway-service \
    --service-name order-service \
    --execution-role-arn arn:aws:iam::123456789012:role/ecsTaskExecutionRole \
    --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRoleForExpressServices \
    --primary-container '{
        "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/order:1.0",
        "containerPort": 8080,
        "environment": [{"name": "SPRING_PROFILES_ACTIVE", "value": "prod"}]
    }' \
    --health-check-path "/actuator/health" \
    --scaling-target '{"minTaskCount":1,"maxTaskCount":4}'

• Só imagem. Ao contrário do App Runner, o Express Mode não faz build a partir do código-fonte: seu CI precisa construir a imagem e enviá-la ao ECR — exatamente o que o pipeline Jenkins do Hands-on 4 faz.
• Balanceador de carga compartilhado. Vários serviços Express (até 25) podem compartilhar um ALB, com roteamento baseado em regras mantendo-os isolados³ — útil para a loja, que tem vários serviços pequenos.
• Sem beco sem saída. Como o ALB, os target groups e as task definitions ficam visíveis na sua conta, "se formar" para o ECS Fargate completo significa editar esses recursos, não migrar.

Railway

O Railway oferece a experiência de desenvolvedor mais simples do ecossistema: conecte um repositório do GitHub, e o Railway detecta a linguagem e o framework, faz o build e o deploy automaticamente. A cobrança é por uso (por vCPU e GB de memória efetivamente usados, por segundo), além de uma pequena taxa mensal de plano que conta como crédito de uso⁶.

O que o Railway oferece de fábrica:

• HTTPS automático com domínios personalizados
• Postgres, Redis e MongoDB integrados como serviços add-on
• Deploy a cada push — sem precisar de pipeline de CI/CD no início
• Rede privada entre os serviços do mesmo projeto (<service>.railway.internal), de modo que só o gateway precisa de um domínio público
• Dashboard com logs, métricas e gerenciamento de variáveis de ambiente

Fly.io

O Fly.io roda containers como VMs leves (Machines) em servidores em regiões ao redor do mundo, perto dos seus usuários. Um arquivo de configuração fly.toml define a aplicação; fly deploy faz o build e o deploy⁷.

app = "my-order-service"
primary_region = "gru"  # São Paulo

[build]
  dockerfile = "Dockerfile"

[http_service]
  internal_port = 8080
  force_https = true

[env]
  SPRING_PROFILES_ACTIVE = "prod"

Ponto forte: o Fly.io coloca seus containers em regiões próximas dos seus usuários. Um usuário em São Paulo alcança gru em poucos milissegundos, contra mais de 100 ms de ida e volta até uma região US East. Adicionar regiões é um único comando — fly scale count 3 --region gru,iad,lhr — e o roteamento Anycast do Fly envia cada usuário para a Machine mais próxima. Apps da mesma organização conversam por uma rede privada (<app>.internal).

Ponto fraco: serviços com estado são mais complexos do que na AWS. O Fly Postgres clássico é uma app que você mesmo opera (backups, failover, upgrades); o mais recente Managed Postgres elimina esse trabalho, mas começa em um preço fixo maior que o processamento de uma app pequena⁷. Não há free tier para novas organizações, apenas um curto período de teste.

4. Alternativas de Kubernetes para orquestração

Se você quer os recursos do Kubernetes, mas não o custo nem a complexidade do EKS, vale conhecer estas distribuições. Todas expõem a mesma API do Kubernetes, então os manifestos do Hands-on 5 rodam sem alterações:

Minikube — Roda o Kubernetes upstream em uma VM ou container no seu laptop, com um único nó por padrão e add-ons (ingress, dashboard, metrics-server). É o ambiente do Hands-on 5 e do exercício de MiniKube — feito para aprendizado e desenvolvimento local, não para produção.

K3s — Kubernetes leve e certificado pela CNCF (um único binário com menos de 100 MB), criado originalmente pela Rancher, hoje SUSE⁸. Implementa a mesma API do Kubernetes upstream, usa SQLite em vez de etcd por padrão em um único servidor (etcd embutido para HA) e já vem com o Traefik como ingress. Ideal para deploys on-premises, dispositivos de borda e pequenos clusters de produção em uma ou poucas VMs.

K0s — Kubernetes "zero-friction" da Mirantis. Um único binário sem dependências no host além do kernel; ele empacota e gerencia seus próprios componentes de control plane (etcd, ou kine com SQLite/MySQL/Postgres). Escolha comum para produção on-premises quando se prefere uma distribuição mínima e sem customizações.

Kind (Kubernetes in Docker) — Roda cada nó do Kubernetes como um container Docker. Criado para testar o próprio Kubernetes, hoje é a escolha padrão para testes de integração em CI e para validar manifestos antes de enviá-los a um cluster real.

5. Comparação de custos

Quanto custa rodar os três microsserviços da loja (gateway, account, order) mais um pequeno banco Postgres em cada plataforma? A tabela e o gráfico abaixo são gerados a partir de um único modelo de custos: uma lista de preços unitários e, para cada plataforma, uma configuração low (baixa) e outra high (alta) montadas a partir desses preços. Mude um preço no código e os dois se atualizam juntos.

Lendo a estimativa: para onde vai o dinheiro

Olhe para as colunas de premissas (assumes) em vez dos totais. Nesta escala, a conta é dominada por custos fixos que existem mesmo com tráfego zero:

O processamento de três pequenos serviços Spring Boot costuma ser a menor linha. É por isso que uma plataforma com taxa fixa de control plane perde com três serviços e ganha com cinquenta: o custo fixo é dividido entre mais workloads. É também por isso que "um cluster EKS por ambiente" (dev, staging, prod) triplica a parte fixa da conta.

6. Exemplo: a loja em cada estágio

Os mesmos quatro componentes, implantados nas três plataformas do caminho de migração abaixo:

O código da aplicação não muda entre as três colunas: o estilo 12-factor (configuração em variáveis de ambiente, serviços stateless, estado no Postgres) é o que faz de cada migração um exercício de deploy, e não uma reescrita.

7. Caminho de migração

flowchart TD
    start(["Ideia / Protótipo"])
    r["Railway / Fly.io<br/>(Dia 1 — lançar rápido)"]
    ex["ECS Express Mode<br/>(Mês 3 — nativo da AWS, stateless)"]
    ecs["ECS Fargate, controle total<br/>(Ano 1 — produção)"]
    eks["AWS EKS<br/>(Ano 2+ — escala, time cresce)"]

    start --> r
    r -->|"Precisa de serviços AWS<br/>ou compliance"| ex
    ex -->|"Precisa de sidecars, serviços<br/>privados, controle fino"| ecs
    ecs -->|"Vários times, 50+ serviços,<br/>GitOps obrigatório"| eks

    style r fill:#4CAF50,color:#fff
    style ex fill:#FF9800,color:#fff
    style ecs fill:#FF5722,color:#fff
    style eks fill:#F44336,color:#fff

Observe que o passo do Express Mode para o ECS Fargate "completo" nem é uma migração: o Express Mode é ECS, então você simplesmente passa a editar as task definitions, as regras do balanceador de carga e a rede que ele criou.

Pontos-chave

• Kubernetes não é o padrão: escolha a plataforma por tamanho do time, quantidade de serviços e maturidade operacional.
• Há dois caminhos: experiência do desenvolvedor (Railway/Render → Fly.io → Lightsail) e nativo da AWS (ECS Express Mode → ECS Fargate → EKS → EC2 puro), cada um trocando simplicidade por controle.
• Em pequena escala, custos fixos (control plane do EKS ~US$ 73, ALB ~US$ 30, NAT ~US$ 33) dominam a conta; apresente toda estimativa com região, data e dimensionamento.
• Times pequenos: Railway, Render, Fly.io, Lightsail ou ECS Express Mode. Times médios: ECS Fargate. Times grandes: EKS com Karpenter/Auto Mode, ArgoCD, o Load Balancer Controller e o External Secrets.
• K3s, K0s, Kind e Minikube dão a API do Kubernetes sem o EKS — e entregam a você a operação do control plane.
• Migre por problema concreto, mantenha a aplicação portável e nunca suponha que um produto gerenciado vai existir para sempre (App Runner).

Conexões

• Modelos de serviço — o vocabulário IaaS / PaaS / CaaS usado aqui.
• Containerização — as imagens que todas as plataformas desta aula implantam.
• Hands-on 4 — DevOps — o pipeline que faz o build e envia as imagens.
• Hands-on 5 — Orquestração e o exercício de MiniKube — a API do Kubernetes que EKS, K3s e Kind expõem.
• Confiabilidade — o que você perde quando a loja inteira roda em uma única VM.
• Projeto: AWS, EKS e Custos e PaaS.