Em 2014, a Netflix completou uma migração de sete anos do datacenter próprio para AWS. O argumento não foi "vai ser mais barato" — foi "queremos ser bons em streaming, não em operar datacenter". A decisão de usar IaaS em vez de co-location foi uma decisão sobre onde concentrar engenharia: na camada de produto ou na camada de infraestrutura física. Essa lógica — onde você quer gastar sua atenção de engenharia — é o coração do raciocínio sobre modelos de cloud.
A confusão comum é tratar IaaS, PaaS, SaaS e FaaS como categorias estanques e pensar em termos de "qual usar". Na prática, a maioria dos sistemas usa todos eles simultaneamente: EC2 (IaaS) para workloads que precisam de controle de rede, RDS (PaaS) para banco de dados, S3 (SaaS-like) para armazenamento de objetos, e Lambda (FaaS) para processamento de eventos. O trade-off não é entre modelos — é entre controle e responsabilidade em cada componente específico.
A pirâmide de abstração
Cada nível de abstração representa uma transferência de responsabilidade operacional para o provider — em troca de perda de controle e, em muitos casos, de vendor lock-in:
| Modelo | Você gerencia | Provider gerencia | Exemplos |
|---|---|---|---|
| On-premises | Hardware, rede, SO, runtime, app | Nada | Datacenter próprio |
| Co-location | Hardware, rede, SO, runtime, app | Energia, resfriamento, prédio | Equinix, Ascenty |
| IaaS | SO, middleware, runtime, app | Hardware, rede física, hipervisor | EC2, GCE, Azure VMs |
| CaaS | Containers, app | Hardware, rede, orquestrador (control plane) | EKS, GKE, AKS |
| PaaS | App, dados | Hardware, SO, runtime, middleware | RDS, Heroku, App Engine, Elastic Beanstalk |
| FaaS | Função (código), dados | Hardware, SO, runtime, escalabilidade, instâncias | Lambda, Cloud Functions, Azure Functions |
| SaaS | Configuração, dados da aplicação | Tudo exceto uso | Salesforce, Gmail, Datadog, GitHub |
CaaS (Containers as a Service) merece menção explícita porque é onde a maioria das arquiteturas modernas vive: você escreve containers, o provider opera o plano de controle do Kubernetes. É o ponto de equilíbrio entre controle operacional (você decide como sua aplicação funciona) e responsabilidade reduzida (o provider garante que o API server está disponível, que etcd replica corretamente, que os nós recebem patches de segurança).
Shared responsibility model
O shared responsibility model (popularizado pela AWS, mas aplicável a qualquer provider) define explicitamente quem é responsável por quê. A falha em entendê-lo é causa direta de incidentes de segurança e operacionais.
Usar RDS não significa que sua base de dados está "segura pelo provider". O provider garante que o hardware não vai falhar silenciosamente e que o SO recebe patches. Você ainda é responsável por: quem pode conectar (security groups, VPC), como dados em repouso são criptografados (KMS keys que você controla), backups automáticos configurados corretamente, e que sua aplicação não tem SQL injection que expõe todos os dados. O shared responsibility não diminui sua responsabilidade com segurança — redistribui onde ela está.
Para IaaS (EC2), você é responsável por:
- Sistema operacional: patches, hardening, AMI rotation
- Configuração de rede: security groups, NACLs, routing
- Identidade: IAM roles e políticas aplicadas à instância
- Dados em repouso: criptografia de EBS volumes
- Software instalado: vulnerabilidades em bibliotecas do SO
Para PaaS (RDS), o provider assume SO e patches, mas você ainda é responsável por:
- Configuração de acesso: quais security groups podem alcançar a porta 5432
- Criptografia com chave própria (Customer Managed Key no KMS)
- Configurações de auditoria: PostgreSQL audit logging habilitado
- Usuários e permissões dentro do banco de dados
- Multi-AZ habilitado se alta disponibilidade é requisito
Vendor lock-in como espectro
Lock-in não é binário. Existe um gradiente de portabilidade que varia com cada serviço que você usa:
Commodity (baixo lock-in): S3-compatible object storage — MinIO, Cloudflare R2, DigitalOcean Spaces todos implementam a API S3. Mudar de provider é substituir URL + credenciais. Outros: VMs básicas, PostgreSQL gerenciado, Kafka gerenciado. Se você usa S3 ou PostgreSQL, está usando uma interface padronizada que múltiplos providers implementam.
Abstração aberta (lock-in médio): Kubernetes gerenciado (EKS/GKE/AKS) — seus manifests YAML funcionam em qualquer cluster Kubernetes. Mas se você usa ALB Ingress Controller específico da AWS ou Google Cloud Endpoints, está usando extensões do provider. Migrar é possível, mas requer reescrever a camada de integração.
Serviços proprietários (alto lock-in): AWS Step Functions, DynamoDB Streams, Google Cloud Spanner, Azure Cosmos DB. Esses serviços não têm equivalente direto em outros providers — substituí-los requer redesign de arquitetura, não apenas mudança de config. O mesmo vale para ferramentas de dados como Kinesis, BigQuery, ou Azure Synapse.
FaaS (lock-in arquitetural): Lambda é o caso mais interessante. O código de uma função individual é portável — é um handler que recebe evento e retorna resultado. O que cria lock-in é o ecossistema ao redor: triggers (SQS, SNS, EventBridge, DynamoDB Streams), permissões (IAM), observabilidade (CloudWatch), e o modelo de precificação que incentiva decomposição extrema em funções. Migrar de Lambda para Cloud Functions não é apenas reescrever código — é reconfigurar toda a arquitetura orientada a eventos.
O custo do lock-in não é o esforço de migrar — é o tempo antes de querer migrar. Uma startup que usa Lambda hoje vai levar anos antes de o lock-in ser limitante. Uma empresa de 10 anos com 500 Lambdas e arquitetura orientada a SQS/EventBridge tem um custo de migração que provavelmente nunca vai justificar a mudança de provider. Avalie lock-in em função do horizonte temporal do seu negócio, não em abstrato.
A análise econômica do managed service
O argumento mais comum contra managed services é o custo: "RDS é três vezes mais caro que rodar PostgreSQL no EC2". Esse cálculo está errado porque não inclui o custo real da operação.
Rodando PostgreSQL em EC2, você paga em tempo de engenharia:
- Setup inicial: instalação, configuração, tuning de performance (pg_hba.conf, shared_buffers, checkpoint settings)
- Backup e restore: script de pg_dump, teste de restore mensal (você testa?), armazenamento no S3
- Alta disponibilidade: replicação streaming com standby, failover automático via Patroni ou Repmgr
- Patches de segurança: OS patches, PostgreSQL minor version upgrades
- Monitoramento: configurar pg_stat_statements, alertas em conexões, locks, slow queries
- On-call: quem vai acordar 3h quando o standby parar de replicar?
RDS Multi-AZ a preço cheio — sem Reserved Instances — é ~3x mais caro que EC2 + armazenamento equivalente. Mas se você tiver uma equipe de 3 engenheiros, um incidente de produção no banco ocorrendo 2x por ano (razoável para PostgreSQL self-managed), e cada incidente custando 4 horas de engenharia sênior... o payback de RDS é em meses.
A equação muda quando a equipe é grande o suficiente para ter DBAs dedicados, o database é de missão crítica onde você quer controle total de configuração, ou os requisitos de compliance exigem que dados nunca saiam de hardware específico.
Quando cada modelo faz sentido
IaaS puro (EC2/GCE/Azure VMs): Workloads que exigem controle de SO (custom kernel modules, specific network configurations), compliance que requer hardware dedicado (instâncias Dedicated Hosts), ou software que não foi containerizado e não vale o esforço. Casos de borda: sistemas legados, workloads HPC com drivers específicos de GPU/FPGA.
CaaS (EKS/GKE/AKS): O default moderno para serviços de backend. Portabilidade de workload garantida (seus manifests funcionam em qualquer K8s), ecossistema rico de ferramentas (Helm, ArgoCD, Prometheus, Istio), e a maioria dos engenheiros sabe trabalhar com Kubernetes. A pergunta não é "usar ou não" — é "managed ou self-managed" (ver conceito 03).
PaaS para dados (RDS, ElasticSearch managed, Redis managed): Quase sempre a escolha certa para equipes sem DBA dedicado. O delta de custo é recuperado em tempo de engenharia na primeira vez que você precisaria operar um failover manual.
FaaS (Lambda): Processamento orientado a eventos onde a carga é irregular e imprevisível. Casos ideais: processamento de imagens disparado por upload no S3, transformação de dados via SQS, webhooks de terceiros. Mau fit: APIs síncronas de baixa latência (cold start), processamento de longa duração (timeout de 15 min no Lambda), workloads com carga constante (provisioned concurrency cancela o benefício econômico). Ver conceito 07.
SaaS: Qualquer capacidade que não é diferenciador de negócio. Email transacional (SendGrid/SES), autenticação (Auth0/Okta), monitoramento (Datadog/New Relic), CI/CD (GitHub Actions). O tempo de engenharia para construir e manter equivalentes próprios raramente compensa — exceto na escala da Netflix ou Google onde o custo de SaaS supera o custo de engenharia interna.
O anti-padrão do "lift and shift"
A migração de datacenter para cloud mais simples é o "lift and shift": pegar as VMs existentes e reproduzi-las na cloud. É a escolha mais rápida para sair do datacenter — e a que menos aproveita cloud.
Lift and shift geralmente resulta em:
- Custo maior que on-premises porque VMs on-demand são caras para cargas constantes
- Nenhum benefício de escalabilidade elástica (você copiou o mesmo over-provisioning)
- Débito técnico de migração real para depois — a migração "rápida" criou anos de trabalho
O valor de cloud não está em rodar as mesmas VMs em datacenter de terceiro. Está em ter acesso a managed services que eliminam trabalho operacional, escalabilidade elástica que elimina over-provisioning estático, e modelo de custo que alinha gasto com uso real. Aproveitar cloud requer redesign, não apenas relocação.
Decisões de engenharia
Prefira CaaS (EKS/GKE/AKS) como default para serviços de backend greenfield — portabilidade de workload via Kubernetes + ecossistema rico de ferramentas. Desça para IaaS apenas quando houver requisito de controle de SO ou hardware específico (GPU, custom kernel). Suba para PaaS para componentes de dados (banco, cache, fila) onde managed service elimina operação custosa. A decisão não é global — cada componente do sistema pode ter um nível diferente. Evite IaaS puro para novos serviços sem razão técnica clara: você está comprando complexidade operacional sem benefício.
Use RDS quando a equipe não tem DBA dedicado, quando o sistema precisa de HA com failover automático sem investimento de setup, ou quando a prioridade é product engineering (não infra). Use PostgreSQL em EC2 quando você precisa de extensões não suportadas pelo RDS (por ex: TimescaleDB full, pg_cron avançado), quando o controle de configuração em nível de OS é necessário, ou quando o custo em escala ($10k+/mês em RDS) justifica investimento em operação. Para a maioria das equipes com menos de 5 engenheiros, RDS tem payback imediato — o primeiro incidente de standby que não faz failover cobre o custo de meses de RDS.
Lambda é economicamente superior para cargas com picos irregulares e longos períodos de inatividade — você paga por invocação, não por instância. Container sempre rodando (ECS/EKS) é superior quando a latência de cold start é inaceitável (APIs síncronas com P99 < 200ms), quando a carga é constante (provisioned concurrency elimina o benefício de custo do Lambda), ou quando o tempo de execução excede 15 minutos. Lambda tem limite de memória (10GB), disco efêmero (10GB), e tempo máximo de execução (15 min) — qualquer workload que excede esses limites requer container. Para processamento assíncrono de eventos com carga variável, Lambda é difícil de superar em custo e simplicidade operacional.
Aceite lock-in quando: o serviço não tem equivalente funcional em outros providers (DynamoDB Streams, Spanner), o horizonte de permanência no provider é > 5 anos, ou a abstração que previne lock-in adiciona complexidade que atrasa entrega. Pague o custo de portabilidade quando: regulatório exige multi-cloud ou on-premises fallback, o negócio tem histórico de mudança de provider, ou o serviço é commodity (S3, PostgreSQL) onde a abstração é trivial. Evite abstração prematura de portabilidade em serviços que você usa há menos de 1 ano — o custo de nunca usar o melhor serviço disponível supera o risco de lock-in hipotético.
Perguntas de entrevista
Como o shared responsibility model muda conforme o nível de abstração sobe de IaaS para PaaS?
Em IaaS (EC2), o provider é responsável pela infraestrutura física: hardware, rede física, hipervisor, e disponibilidade da capacidade. Você é responsável por tudo acima: SO (patches, hardening), middleware, runtime, aplicação, dados, e configuração de rede (security groups, VPC). Se o SO tem uma vulnerabilidade não corrigida, é sua falha operacional — não do provider.
Em PaaS (RDS), o provider assume SO, patches de banco de dados, e disponibilidade da instância gerenciada. Você ainda é responsável por: configuração de acesso (quem pode conectar na porta 5432), criptografia em repouso com suas chaves (CMK no KMS), backup policy, usuários e permissões dentro do banco, e a segurança da aplicação que consome o banco. O erro crítico é assumir que "usar RDS = banco de dados seguro" — o shared responsibility não elimina sua responsabilidade de segurança, ela sobe um nível.
Por que "lift and shift" frequentemente resulta em custo maior na cloud do que on-premises?
Lift and shift copia o modelo mental de on-premises para cloud sem aproveitar as propriedades da cloud. On-premises, você provisiona para o pico de carga porque hardware adicional leva semanas. Você tem VMs permanentemente rodando 24/7, muitas com utilização média de 10–30%. Em cloud com lift and shift, você recria esse padrão: VMs rodando continuamente, over-provisionadas para o pico, sem escalabilidade elástica. VMs on-demand na cloud têm custo por hora — o mesmo padrão de VM grande rodando sempre é mais caro que comprar hardware próprio em 3–5 anos.
O valor econômico da cloud emerge de padrões cloud-native: escalabilidade elástica (pagar apenas pelo pico quando ele acontece), uso de managed services que eliminam staff operacional, e arquiteturas event-driven que pagam por uso real. Lift and shift compra agilidade de deploy (sem datacenter próprio) mas não melhora a economia — frequentemente a piora até que a equipe refatora para cloud-native.
Como fazer a análise econômica correta ao comparar RDS vs PostgreSQL em EC2?
O erro comum é comparar apenas o custo de infraestrutura: "RDS db.r6g.large Multi-AZ custa $X/mês, EC2 r6g.large + EBS custa $Y/mês, Y < X, portanto EC2 é melhor". Essa análise omite o custo real da operação self-managed.
A análise correta inclui: (1) Setup inicial — quantas horas de engenharia sênior para configurar replicação streaming, Patroni para failover automático, backup com teste de restore, monitoramento com alertas corretos? (2) Manutenção recorrente — patches de SO mensais, upgrade de minor versions do PostgreSQL, rotação de AMI; (3) On-call — quantas vezes por ano o banco vai causar incidente fora do horário comercial? Qual o custo hora de um engenheiro sênior de plantão? (4) Oportunidade — horas gastas em operação de banco são horas não gastas em produto. Para a maioria das equipes com menos de 5 engenheiros, o payback do RDS é positivo no primeiro incidente significativo de banco. A análise muda quando a equipe tem DBA dedicado ou quando o custo de RDS em escala excede $5–10k/mês.
O que é CaaS e por que representa o ponto de equilíbrio moderno para serviços de backend?
CaaS (Containers as a Service) é o modelo onde você escreve e opera containers, e o provider opera o plano de controle do orquestrador — em prática, EKS (AWS), GKE (Google), ou AKS (Azure) com Kubernetes. Você ainda decide como sua aplicação funciona (manifests, recursos, scaling policies, networking interno), mas o provider garante que o API server está disponível, que etcd replica corretamente, que os nós recebem patches de segurança do plano de controle, e que o escalonamento de nós funciona.
É o ponto de equilíbrio porque: portabilidade de workload (seus manifests Kubernetes funcionam em qualquer cluster), controle suficiente (você configura rede, RBAC, storage classes, ingress), e responsabilidade reduzida comparado a IaaS (sem operar etcd, sem preocupação com API server HA). O ecossistema ao redor — Helm, ArgoCD, Prometheus, Istio — é padronizado e open source, reduzindo lock-in. A maioria dos engenheiros sênior hoje conhece Kubernetes, tornando CaaS a opção de menor atrito para contratação e operação.
Como avaliar se vendor lock-in em um serviço cloud é risco real ou preocupação prematura?
A pergunta certa não é "existe lock-in?" — é "qual o custo do lock-in dado o meu horizonte temporal e probabilidade de migração?". Custo de lock-in = probabilidade de querer migrar × custo de migração × impacto no negócio durante migração.
Para startups nos primeiros 3 anos: lock-in em serviços proprietários (DynamoDB, Lambda ecosystem) é frequentemente custo zero — a probabilidade de migração é baixa, e usar o melhor serviço disponível acelera o product-market fit. Para empresas enterprise com 5+ anos no mesmo provider: lock-in em serviços de dados (BigQuery, Redshift, Azure Synapse) começa a ser real — migrar petabytes tem custo de egress + reengenharia. Para sistemas com requisito regulatório de multi-cloud ou on-premises fallback: lock-in é custo imediato que precisa ser mitigado por design. A análise prática: use serviços proprietários agressivamente quando são diferenciadores de velocidade; use abstrações (S3-compatible, Kubernetes, PostgreSQL) quando a portabilidade é commodity e a abstração não adiciona complexidade.
Como praticar
-
Auditar os modelos de cloud do seu sistema atual. Liste todos os componentes de infraestrutura do seu sistema (banco, cache, fila, compute, storage, CDN, observabilidade). Para cada um: qual modelo de cloud é usado (IaaS/CaaS/PaaS/FaaS/SaaS)? Quem é responsável por patches, HA, e backups? Há componentes em IaaS que poderiam ser PaaS sem perda de funcionalidade?
Critério: Produzir uma tabela com todos os componentes, modelo atual, responsabilidade de operação por camada, e recomendação de mudança de nível quando aplicável. Identificar pelo menos um componente em IaaS que tem equivalente PaaS maduro com custo operacional menor. -
Calcular o TCO real de um componente self-managed. Escolha um banco de dados ou serviço de mensageria que você opera self-managed. Calcule o custo total de propriedade incluindo: custo de infraestrutura (EC2, EBS, snapshots), horas de engenharia em setup e manutenção no último ano, número e duração de incidentes relacionados, e custo de on-call. Compare com o preço do managed equivalent (RDS, MSK, ElastiCache).
Critério: O TCO self-managed deve incluir horas de engenharia valorizadas a custo real (salário + encargos). O resultado deve mostrar claramente se o managed service tem payback positivo — e em qual horizonte temporal (meses ou anos). -
Mapear o grau de vendor lock-in da stack atual. Para cada serviço cloud que você usa, classifique: (1) commodity — tem equivalente direto em outros providers; (2) abstração aberta — portável com reengenharia moderada; (3) proprietário — requer redesign de arquitetura para migrar. Estime o custo de migração total para o segundo provider mais viável.
Critério: O mapa deve cobrir todos os serviços cloud usados em produção. A estimativa de custo de migração deve separar: custo de egress de dados, horas de reengenharia, e downtime esperado. Concluir se o lock-in atual é aceitável dado o horizonte de negócio. -
Projetar a arquitetura cloud-native de um sistema lift-and-shift hipotético. Tome um sistema legado típico (monolito em VMs, banco relacional em servidor dedicado, cron jobs em servidor fixo). Projete a versão cloud-native usando os modelos corretos para cada componente: CaaS para o monolito containerizado, PaaS para banco, FaaS para cron jobs, SaaS para observabilidade. Documente o que muda e o que permanece igual.
Critério: A proposta deve incluir diagrama de arquitetura antes e depois, justificativa de modelo de cloud para cada componente, e estimativa de custo mensal da versão cloud-native. A versão cloud-native deve demonstrar pelo menos uma melhoria em custo, disponibilidade, ou redução de operação comparado ao lift-and-shift. -
Analisar o shared responsibility model para um incidente real ou hipotético. Escolha um incidente real (seu ou público — como o S3 outage de 2017 ou RDS failover falho) ou crie um cenário hipotético (ex: instância RDS com backup desabilitado é corrompida após falha de disco). Determine: o que o provider era responsável? O que o operador era responsável? Onde o modelo de responsabilidade foi mal-entendido?
Critério: A análise deve citar as seções específicas do shared responsibility model do provider relevante. Deve concluir claramente quem deveria ter feito o quê e quais controles preventivos teriam evitado o impacto — separando o que é competência do provider e o que é competência do operador.
Referências para aprofundar
- docs AWS — Shared Responsibility Model.
- article Netflix Tech Blog — Completing the Netflix Cloud Migration.
- book Cloud Strategy — Gregor Hohpe (O'Reilly, 2020).
- article Why We're Leaving the Cloud — David Heinemeier Hansson (dhh.dk, 2022).
- docs AWS Well-Architected Framework.
- standard NIST Definition of Cloud Computing — SP 800-145.
- article Serverless Architectures — Martin Fowler / Mike Roberts (martinfowler.com).
- book Cloud Native Patterns — Cornelia Davis (Manning, 2019).
- article The CNCF Cloud Native Definition — CNCF.
- article Corey Quinn — Understanding Your AWS Bill — Last Week in AWS.
- article Lock-in and Multi-Cloud — Fowler/ThoughtWorks Technology Radar.
- book Site Reliability Engineering — Google (O'Reilly, 2016).