Início do Bloco C (DevOps). Foco: você consegue conversar sobre containers e orquestração sem virar especialista. Em específico, sabe quando k8s é justificado, quando é overengineering, e quais alternativas modernas resolvem 80% dos casos com 20% da complexidade.
Pré-requisito: Semana 4 (Cloud) ajuda mas não é obrigatória. Tempo estimado: 3-4 horas de leitura + 1 hora de exercício hands-on. Output prático: você avalia proposta de "vamos pra k8s" do cliente e propõe alternativa quando faz sentido.
Por que essa semana importa
Containers (Docker) e orquestração (Kubernetes) são o vocabulário básico de TI moderna. Em qualquer reunião sobre deploy, escalabilidade, multi-environment, infraestrutura, esses termos aparecem.
Cliente que diz:
"Rodamos em k8s on-prem com 3 clusters, usando Helm charts e Argo CD pra deploy contínuo, com Istio fazendo service mesh"
...está te dizendo 6 conceitos em uma frase, todos importantes pra entender. Sem repertório, você assenta e escuta. Com repertório, você faz perguntas que mostram que entende a stack.
Mais importante: 60% das empresas que adotaram Kubernetes nos últimos 5 anos NÃO PRECISAVAM. K8s é poderoso mas tem custo de operação alto. Saber identificar over-engineering te diferencia de vendedores e consultores que recomendam k8s pra tudo.
Bônus: agentes do Team Studio podem rodar em containers (boa prática). Saber implantar isso na infra do cliente é vantagem comercial.
1. O modelo mental: por que container existe
Antes de container, deployment era doloroso por razões específicas:
1.1 O problema do "funciona na minha máquina"
Dev escreve código no Windows com Node 18, MongoDB 5.0, PYTHON 3.10. Deploya em servidor Linux com Node 14 (porque OPS não atualizou), MongoDB 4.2, Python 3.8.
Resultado: deploy quebra com erros bizarros. Dev gasta 3 dias debugando ambiente em vez de produzir código.
1.2 Soluções pré-container
VMs (máquinas virtuais): cada app numa VM completa com OS próprio. Funcionava mas pesado: GB de RAM por VM, lento pra subir, caro.
Vagrant: VM padronizada pra dev. Resolvia "funciona na minha máquina" parcialmente.
Chef/Puppet/Ansible: configuração programática de servidores. Útil mas exige muito setup.
1.3 Containers entram em cena (Docker 2013)
Container empacota app + dependências + bibliotecas necessárias num "pacote leve" que roda IGUAL em qualquer lugar com Docker.
Vs VM: - VM tem OS completo (Linux com kernel próprio) - Container compartilha kernel do host, só empacota o resto - VM pesa GBs, demora minutos pra subir - Container pesa MBs, demora SEGUNDOS pra subir
Resultado: dev empacota app no container, container roda igual em laptop, staging, produção. "Funciona na minha máquina" → "funciona ONDE TIVER Docker".
1.4 Containers viraram unidade básica de software moderno
Hoje: - 95% das stacks modernas usam containers - Praticamente todo provedor cloud suporta containers natively - Times de dev contratam expectativa de saber Docker - CI/CD assume containers - Kubernetes virou padrão de orquestração
Aprender Docker hoje é equivalente a aprender HTTP em 2000. Vocabulário básico de desenvolvedor moderno.
2. Docker em 30 minutos
2.1 Conceitos fundamentais
Image (imagem): "molde" do que vai virar container. Definida por Dockerfile, salva no disco ou em registry.
Pense: imagem = receita. Container = bolo pronto.
Container: instância em execução de uma imagem. Pode ter vários containers rodando da mesma imagem.
Registry: lugar onde imagens vivem (Docker Hub, AWS ECR, GitHub Container Registry, Google GCR).
Dockerfile: arquivo texto que descreve como construir uma imagem.
2.2 Anatomia de Dockerfile
# Base: começa de uma imagem existente
FROM node:20-alpine
# Define diretório de trabalho dentro do container
WORKDIR /app
# Copia arquivos de dependência
COPY package*.json ./
# Instala dependências
RUN npm ci --only=production
# Copia código da aplicação
COPY . .
# Define porta que o container escuta
EXPOSE 3000
# Comando pra iniciar
CMD ["node", "server.js"]
Cada linha cria uma layer (camada). Layers são cacheadas: se package.json não mudou, próximo build pula npm ci. Isso acelera build absurdamente.
2.3 Comandos básicos
# Construir imagem
docker build -t minha-app:1.0 .
# Rodar container
docker run -p 3000:3000 minha-app:1.0
# Listar containers rodando
docker ps
# Parar container
docker stop <id>
# Ver logs
docker logs <id> --follow
# Executar comando dentro de container rodando
docker exec -it <id> sh
# Subir pra registry
docker push registry.com/minha-app:1.0
Em reunião, você vai escutar docker build, docker push, docker pull, docker run. Reconhecer cada um é suficiente.
2.4 Docker Compose - multi-container local
Aplicação real tem múltiplos containers: app + banco + cache + worker. Docker Compose define todos em um arquivo YAML:
version: '3.8'
services:
app:
build: .
ports:
- "3000:3000"
depends_on:
- postgres
- redis
postgres:
image: postgres:16
environment:
POSTGRES_PASSWORD: secret
volumes:
- pgdata:/var/lib/postgresql/data
redis:
image: redis:7-alpine
volumes:
pgdata:
Comando: docker compose up e todos sobem juntos.
Compose é PARA AMBIENTE LOCAL (dev). Pra produção, Kubernetes ou alternativas. Mas em time pequeno, Compose pode rodar produção também (é o que fazemos no TM).
2.5 Multi-stage builds - imagens menores
Truque importante pra produção: separar build de runtime em estágios diferentes.
# Stage 1: build (com tools pesadas)
FROM node:20-alpine AS build
WORKDIR /app
COPY . .
RUN npm install && npm run build
# Stage 2: runtime (só o necessário)
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
Imagem final tem só nginx + arquivos buildados, sem Node, sem npm. Menor, mais rápida, mais segura (menos atacável).
Pergunta de reunião:
"Vocês usam multi-stage builds? Qual tamanho médio das imagens em produção?"
Imagens > 1GB pra app web é sinal de Dockerfile mal otimizado.
3. Kubernetes - quando vale, quando é overkill
Kubernetes (k8s) é orquestrador de containers em escala. Roda dezenas/centenas de containers, faz auto-healing, scaling, networking, secrets, deploys complexos.
Foi criado pelo Google (baseado em Borg, sistema interno deles). Open-sourced em 2014. Virou padrão de indústria por volta de 2018.
3.1 Quando k8s VALE
- Múltiplos serviços (microserviços com 5+ componentes)
- Escala variável (precisa de autoscaling sério, multi-AZ)
- Time de plataforma dedicado (3+ pessoas que sabem k8s bem)
- Compliance/segurança rigorosa (k8s oferece RBAC, network policies, secrets management built-in)
- Multi-tenancy (vários clientes com isolamento forte)
3.2 Quando k8s é OVERKILL
- Monolito ou poucos serviços (3-4 serviços): docker compose ou PaaS resolvem
- Time pequeno sem expertise: você vai gastar 40% do tempo operando k8s em vez de produzindo
- Tráfego previsível e estável: autoscaling de k8s não compensa complexidade
- Startup pré-PMF: complexidade não justifica antes de produto vencer
3.3 Conceitos essenciais (vocabulário pra reunião)
Pod: menor unidade. 1 ou poucos containers + storage + IP. Geralmente 1 pod = 1 app.
Deployment: define quantos pods da mesma app devem existir. Faz rolling update automaticamente.
Service: endereço estável pra acessar pods (que podem subir/cair). Tipo "load balancer interno".
Ingress: roteia tráfego externo pros services (basicamente "nginx as a service" dentro do k8s).
ConfigMap / Secret: configuração e credenciais externalizadas (não hardcoded no código).
Namespace: isolamento lógico dentro do cluster (separar prod, staging, dev no mesmo cluster).
Helm chart: "pacote" pra deployar app complexa no k8s. Comparável a apt-get package pro Linux.
Operator: aplicação inteligente que opera outra aplicação no k8s (ex: Postgres Operator gerencia clusters Postgres).
3.4 Sabores de Kubernetes
Self-managed (você roda k8s do zero): - kubeadm: setup manual - k3s: k8s leve, bom pra edge/desenvolvimento - OpenShift (Red Hat): k8s + plataforma enterprise - Doloroso de manter; só faz sentido pra empresa com 50+ engenheiros de infra
Managed (cloud provider gerencia control plane): - AWS EKS: Elastic Kubernetes Service - GCP GKE: Google Kubernetes Engine - Azure AKS: Azure Kubernetes Service - Você só cuida dos worker nodes e apps. Recomendado.
Distribuídos serverless: - GCP Autopilot: GKE sem você nem ver nodes - AWS Fargate: containers serverless - Azure Container Apps: managed totalmente
3.5 Custo real de k8s
Cluster k8s "pequeno" em cloud managed: - Control plane: US$ 0-72/mês (AWS cobra, GCP grátis) - 3 nodes pequenos (t3.medium): ~US$ 100/mês - Storage, network: ~US$ 30/mês - Load balancers: US$ 20/mês cada - Subtotal: ~US$ 200-400/mês mínimo
Mais grave: custo HUMANO. K8s exige profissionais qualificados. Salário de DevOps/SRE com k8s no Brasil: R$ 12k-25k/mês.
Empresa pequena gastando R$ 30k/mês pra economizar R$ 5k em infra é prejuízo claro.
Pergunta de reunião:
"Quantos serviços rodam no k8s de vocês? Quantas pessoas operam? Já avaliaram alternativas mais simples?"
Resposta revela maturidade da decisão.
4. Alternativas modernas - onde rodar containers SEM k8s
Se você não precisa do k8s, o que usar? Vários produtos modernos resolvem 80% dos casos com 20% da complexidade:
4.1 Plataformas serverless de container
AWS Fargate: roda containers sem gerenciar VMs. Você define memória, CPU, e Fargate executa. ~30-50% mais caro que EC2 mas zero ops.
Google Cloud Run: serverless de container puro. Auto-scale do zero a milhares de instâncias em segundos. Cobra POR REQUEST (não por hora).
Azure Container Apps: similar ao Cloud Run, integrado com ecossistema Microsoft.
Quando usar: APIs, workers, jobs assíncronos. Não pra apps stateful complexas.
4.2 PaaS modernas
Fly.io: deploya container em 30+ regiões globais com 1 comando. Banco distribuído integrado (Postgres). Excelente pra Edge computing barato.
Railway: PaaS muito polida pra time pequeno. Sobe app, banco, cache em minutos. Mais cara que Fly.io.
Render: alternativa a Heroku. PaaS clean, free tier generoso.
Vercel: dominante pra frontend (Next.js, React). Edge functions modernas.
Heroku: clássico, ainda funciona mas perdeu mercado pra alternativas mais modernas.
Quando usar: produto early-stage, time pequeno, prioriza velocidade sobre custo.
4.3 Container-as-a-Service simples
AWS App Runner: deploya app diretamente de um repo Git. Sem configuração.
Digital Ocean App Platform: similar, mais simples.
Quando usar: startup que quer "subir e esquecer".
4.4 Como escolher
| Caso | Recomendação |
|---|---|
| MVP/startup pré-PMF | Fly.io ou Railway |
| Time pequeno, app web simples | Cloud Run ou App Runner |
| Time pequeno, app multi-serviço | Docker Compose em VPS + Caddy |
| Time médio, escala média | Fargate ou ECS |
| Empresa grande, microserviços complexos | EKS/GKE/AKS (k8s managed) |
| Empresa enterprise, on-prem | OpenShift |
Team Studio hoje roda no caminho "Docker Compose em VPS + Caddy" pra Mission Control. Funciona pra escala atual.
5. Onde Team Studio entra na infra do cliente
Quando você for vender Team Studio pra empresa que tem stack moderna, vão perguntar como você quer rodar. 4 opções:
5.1 Na infra do cliente (mais comum em B2B grande)
Cliente roda Team Studio dentro do k8s/cloud dele. Você entrega um deployment Helm chart ou similar.
Pros: dado nunca sai da infra do cliente (compliance), custo de infra é do cliente, integração natural. Cons: você precisa entregar artifact instalável (chart, container, manifest), operar remotamente é mais difícil.
5.2 No seu cloud, dado fica na infra do cliente
Team Studio roda no seu cloud (AWS/GCP), agentes acessam dados do cliente via API.
Pros: você controla operação, atualiza sem pedir permissão. Cons: cliente pode resistir ("dados saem da nossa rede"), mais latência.
5.3 SaaS multi-tenant (modelo Team Studio default)
Você roda um sistema, vários clientes compartilham infra com isolamento lógico.
Pros: mais barato, mais simples de operar, melhor margem. Cons: cliente exigente vai pedir "single-tenant", você tem que ter resposta pronta.
5.4 Híbrido
Parte na sua infra (LLM calls), parte na infra do cliente (acesso a dados sensíveis).
Pros: equilibra controle vs compliance. Cons: mais complexo de operar.
Pergunta de reunião:
"Vocês exigem que aplicações rodem dentro da VPC de vocês ou aceitam SaaS externo? Quais são as restrições de compliance?"
Resposta define qual modelo Team Studio propõe.
6. Cinco perguntas que destravam reunião sobre containers/k8s
6.1 "Qual orquestrador de containers vocês usam? E por quê?"
Por que importa: cliente que escolheu k8s sem justificativa clara é caso a investigar (over-engineering provável).
6.2 "Quantos serviços rodam? Quantos pods? Qual o cluster size?"
Por que importa: 5 serviços rodando em k8s de 100 nodes = absurdo. 100 serviços em 5 nodes = sub-provisionado. Números revelam saúde.
6.3 "Como fazem deploy? GitOps, CI/CD direto, manual?"
Por que importa: revela maturidade. Manual = caótico. GitOps (Argo CD, Flux) = maduro.
6.4 "Tem service mesh (Istio, Linkerd) ou ingress simples?"
Por que importa: service mesh tá pra k8s como CDN tá pra cloud. Empresa grande tem. Empresa pequena que tem geralmente não precisa.
6.5 "Qual a estratégia pra secrets management dentro do k8s?"
Por que importa: secrets do k8s padrão são FRACOS (base64 encoded, não encrypted). Empresa madura usa Vault, AWS Secrets Manager, ou Sealed Secrets.
7. Exercício prático
Cenário: startup B2B SaaS com 2 anos. 5 devs full-stack. ARR R$ 8M/ano. Hospedam tudo em AWS. CTO compartilha:
"Estamos com Vercel + Supabase pra produto, mas o time tá querendo mover pra Kubernetes 'pra ter mais controle'. Estamos olhando AWS EKS. Vale a pena?"
Pratique: 1. Liste 5 perguntas pra decidir SE vale (não como fazer) 2. Identifique 3 sinais de que NÃO vale a migração 3. Identifique 3 sinais de que VALE 4. Esboce alternativa intermediária se k8s não fizer sentido
(Sugestões no fim.)
8. Material extra
Leitura essencial: - "Docker Deep Dive" (Nigel Poulton) - livro curto, 200 páginas, MELHOR intro a Docker - "Kubernetes Up & Running" (Brendan Burns et al) - referência clássica - Blog Honeycomb (https://www.honeycomb.io/blog) - engenharia de plataforma com pé no chão - "Choose Boring Technology" (Dan McKinley) - artigo seminal sobre evitar overengineering
Vídeos: - "Docker Crash Course" (TechWorld with Nana, ~1h) - referência popular - "Why I'm switching FROM Kubernetes" - várias palestras de CTOs explicando como saíram
Hands-on (4 horas): - Instale Docker Desktop - Crie Dockerfile pra app Node.js simples - Faça build, rode local - Use docker compose pra subir app + Postgres - Brincadeira opcional: instale k3s (k8s leve) em laptop e deploya app lá
9. Sugestões pro exercício prático (veja só depois de tentar)
5 perguntas pra decidir:
- "Qual problema o atual setup (Vercel + Supabase) está te causando? Quais funcionalidades específicas você precisa que não tem hoje?"
- "Quem no time tem experiência operando k8s em produção? Quantas horas/semana esperam dedicar a operações?"
- "Qual o volume de tráfego atual? Quantos usuários simultâneos no pico? Vercel/Supabase tão limitando?"
- "Você consegue listar 3 coisas concretas que k8s vai destravar que hoje não consegue fazer?"
- "Qual o orçamento mental pra investir em ops nos próximos 6 meses? Em horas e em dinheiro?"
3 sinais de que NÃO vale:
- Time de 5 devs full-stack sem DevOps dedicado: vão gastar 30-40% do tempo operando k8s. Em troca de marginalmente mais "controle".
- Justificativa vaga ("mais controle"): sem problema específico identificado, k8s vai criar novos problemas, não resolver os existentes.
- ARR R$ 8M com 5 devs: você precisa CRESCER PRODUTO, não infra. Cada hora gasta operando k8s é hora não construindo feature.
3 sinais de que VALE (se tivessem):
- Time tem 1+ pessoa com 3+ anos de k8s em produção
- Já passou de ~100 deploys por dia (Vercel não escala bem aqui)
- Cliente enterprise grande exigiu rodar on-prem (compliance)
Alternativa intermediária:
Migrar produto pra AWS Fargate ou Cloud Run, mantendo Supabase pro banco. Ganha: - Container deployment (vs Vercel buildpacks) - Mais controle de runtime (versões específicas, libs OS) - Mas evita complexidade de k8s - Time pequeno consegue operar
Custo: similar a k8s simples. Complexidade: muito menor.
10. Próxima semana
A Semana 7 fecha o Bloco C (DevOps) com CI/CD, observability e deploys: pipeline do commit até produção (lint, build, test, security, deploy), estratégias de deploy (recreate, blue-green, rolling, canary), feature flags, 3 pilares de observability (logs, métricas, traces) com ferramentas como Prometheus, Grafana, Datadog e OpenTelemetry, 4 golden signals do Google SRE, alerting SLO-based. Inclui plano 3 meses pra sair de 1 deploy/semana pra 10 deploys/dia.