Tipos de Infraestrutura

O eixo central: responsabilidade compartilhada

Toda decisão de infraestrutura é, no fundo, uma resposta à pergunta “qual camada da pilha eu quero deixar de gerenciar?”. A pilha, de baixo para cima, é aproximadamente:

Networking → Storage → Servidores (hardware) → Virtualização → SO → Runtime → Middleware → Dados/Aplicação → Função

Cada modelo move a fronteira do “gerenciado por você” para cima. O trade-off é sempre o mesmo: controle e customização de um lado, velocidade e menor carga operacional do outro.

On-premise

Provedor gerencia: nada (ou apenas o datacenter físico se for colocation).
Você gerencia: hardware, rede, energia, virtualização, SO, patches, runtime, app.
Exemplos: servidores em rack próprio, VMware vSphere on-prem, bare metal.
Quando usar: requisitos regulatórios de soberania de dados, latência ultrabaixa com hardware especializado (GPUs próprias), cargas previsíveis onde a nuvem sai cara no longo prazo, legado que não pode migrar.
Trade-off: controle total e CapEx amortizável, mas você carrega toda a complexidade operacional e não tem elasticidade real.

IaaS (Infrastructure as a Service)

Provedor gerencia: hardware, rede física, virtualização (hypervisor).
Você gerencia: SO, patches, runtime, middleware, aplicação, escalabilidade.
Exemplos: AWS EC2, Google Compute Engine, Azure Virtual Machines.
Quando usar: você precisa de controle sobre o SO e o ambiente (kernel, drivers, agentes de segurança), lift-and-shift de cargas legadas, ou infraestrutura de base sobre a qual construir plataformas próprias.
Trade-off: máxima flexibilidade dentro da nuvem, mas você ainda cuida de patching de SO, hardening e autoscaling.

CaaS (Containers as a Service)

Provedor gerencia: hardware, virtualização, SO host, e frequentemente o plano de controle do orquestrador.
Você gerencia: as imagens de container, definições de deploy, e (dependendo) os nós de execução.
Exemplos: AWS ECS, EKS (Kubernetes gerenciado), Google GKE, Azure AKS, Google Cloud Run.
Quando usar: você empacota a aplicação em containers e quer orquestração, escalabilidade horizontal e portabilidade — o modelo natural para uma arquitetura de Microservices.
Trade-off: ótimo equilíbrio entre controle e abstração; abstrai o SO mas exige que você domine imagens, redes de container e limites de recursos.

PaaS (Platform as a Service)

Provedor gerencia: tudo até o runtime e o middleware; você só entrega o código e os dados.
Você gerencia: o código da aplicação e a configuração/dados.
Exemplos: Heroku, AWS Elastic Beanstalk, Google App Engine, Azure App Service, Railway, Render.
Quando usar: times pequenos que querem foco no produto sem operar infra, protótipos, MVPs, aplicações web CRUD padrão.
Trade-off: velocidade de entrega altíssima, mas menos controle sobre tuning fino, risco de lock-in e custo que escala mal em volume.

FaaS / Serverless (Function as a Service)

Provedor gerencia: tudo, inclusive a alocação e o scale-to-zero; você fornece apenas a função.
Você gerencia: a lógica da função e suas dependências.
Exemplos: AWS Lambda, Google Cloud Functions, Azure Functions, Cloudflare Workers.
Quando usar: cargas intermitentes/bursty, glue code, tarefas disparadas por eventos. É a expressão máxima de arquitetura orientada a eventos: cada evento (upload no S3, mensagem numa fila, chamada HTTP) invoca uma função efêmera.
Trade-off: paga-se apenas pela execução e escala automaticamente a zero, mas há cold starts, limites de tempo de execução, statelessness forçado e dificuldade de debug/observabilidade.

A “Pizza as a Service” — tabela de responsabilidade compartilhada

A analogia clássica: fazer uma pizza (On-premise) vs. jantar fora (Serverless). Cada modelo terceiriza mais camadas.

Camada / Ingrediente	On-premise	IaaS	CaaS	PaaS	FaaS
Rede / Networking	Você	🏭	🏭	🏭	🏭
Armazenamento (Storage)	Você	🏭	🏭	🏭	🏭
Servidores (hardware)	Você	🏭	🏭	🏭	🏭
Virtualização	Você	🏭	🏭	🏭	🏭
Sistema Operacional	Você	Você	🏭	🏭	🏭
Runtime / Container runtime	Você	Você	Você*	🏭	🏭
Middleware / Orquestração	Você	Você	🏭**	🏭	🏭
Aplicação / Função	Você	Você	Você	Você	Você
Dados	Você	Você	Você	Você	Você

🏭 = gerenciado pelo provedor · Você = sua responsabilidade * No CaaS “sem servidor de nós” (Fargate/Cloud Run) o provedor também abstrai os nós. ** No Kubernetes gerenciado, o control plane é do provedor; os worker nodes podem ser seus.

Repare no padrão: a linha “Você” sobe uma camada a cada degrau. On-premise é “Você” em tudo; FaaS é “Você” apenas em Aplicação/Dados.

A escada de abstração (diagrama)

flowchart TB
    subgraph Voce["Menos que você gerencia →"]
    direction TB
    A["On-premise<br/><i>controle total, CapEx</i>"] --> B["IaaS (EC2)<br/><i>você cuida do SO pra cima</i>"]
    B --> C["CaaS (ECS/EKS)<br/><i>você entrega imagens</i>"]
    C --> D["PaaS (Beanstalk/Heroku)<br/><i>você entrega o código</i>"]
    D --> E["FaaS (Lambda)<br/><i>você entrega a função</i>"]
    end
    A -. "mais controle / mais carga operacional" .-> A
    E -. "mais abstração / menos controle" .-> E
    style A fill:#7f1d1d,color:#fff
    style B fill:#9a3412,color:#fff
    style C fill:#854d0e,color:#fff
    style D fill:#166534,color:#fff
    style E fill:#155e75,color:#fff

Anti-padrões e erros comuns

Escolher pela hype, não pelo trade-off. Colocar tudo em Serverless quando a carga é constante e de longa duração — sai mais caro e mais lento que um container.
“Lift-and-shift” ingênuo. Jogar um monólito legado numa EC2 e achar que “está na nuvem”. Sem repensar arquitetura, você pagou nuvem e manteve toda a dor operacional.
Ignorar cold starts em FaaS para APIs de baixa latência com tráfego irregular. Usuários sentem o atraso da primeira invocação.
Estado em serviços stateless. Guardar sessão em memória no PaaS/FaaS: qualquer scale-out ou reciclagem de instância derruba o estado.
Misturar níveis de abstração sem critério. Ter parte em EKS, parte em Lambda, parte em EC2 crua sem uma razão clara multiplica a superfície operacional.
Esquecer que os dados são sempre seus. Nenhum modelo terceiriza a responsabilidade sobre correção, backup e conformidade dos dados.

Relações

Faz parte de DevOps & Infraestrutura e conecta-se ao panorama em Como Tudo se Conecta.
CaaS é a casa natural de Containers - Docker e Docker Compose e do estilo Microservices.
FaaS é a expressão prática de Event-Driven Architecture.
Os serviços concretos de cada modelo aparecem em AWS - Visão Geral dos Serviços.
Provisionar qualquer um destes de forma reprodutível é papel de Terraform.
Sistemas que distribuem carga entre esses modelos tocam em Sistemas Distribuídos.

Perguntas de revisão

Na “pizza as a service”, qual é a única camada que permanece sua responsabilidade em todos os modelos, do On-premise ao FaaS?

Resposta

Os dados (e a aplicação/função). Provedores abstraem hardware, SO, runtime e orquestração, mas correção, backup e conformidade dos dados nunca deixam de ser sua responsabilidade.

Você tem uma API com tráfego muito irregular, cargas curtas e disparadas por uploads de arquivos. Qual modelo é o candidato mais natural e qual é seu principal risco?

Resposta

FaaS / Serverless (ex.: Lambda acionada por evento do S3), por escalar a zero e cobrar só pela execução. O principal risco são os cold starts (latência da primeira invocação) e os limites de tempo de execução/statelessness.

Qual a diferença essencial de responsabilidade entre IaaS e CaaS?

Resposta

No IaaS você ainda gerencia o sistema operacional (patches, hardening). No CaaS o provedor cuida do SO host e frequentemente do orquestrador; você passa a entregar imagens de container e definições de deploy, subindo um degrau na escada de abstração.

Por que “colocar tudo em Serverless” pode ser um anti-padrão para uma carga constante de longa duração?

Resposta

FaaS é otimizado para execuções curtas e intermitentes. Sob carga constante e prolongada, o modelo de cobrança por invocação/tempo fica mais caro que um container reservado, e os limites de duração/cold starts atrapalham. Um CaaS (ECS/EKS) ou até IaaS costuma ser mais econômico e adequado.