Visão geral

Seu time construiu a loja: um gateway, os serviços account, auth, product e order, um banco Postgres, um cache Redis e o Kafka. Tudo roda bem num notebook com Docker Compose. Agora é preciso rodar em algum lugar de verdade. Você poderia comprar servidores, alugar máquinas virtuais, enviar o código para uma plataforma que o executa por você, ou até dispensar alguns componentes e pagar por um produto que já faz o trabalho. Cada opção traça uma linha diferente entre o que o seu time opera e o que outra empresa opera.

Os modelos de serviço em nuvem definem quanto da pilha o provedor de nuvem gerencia e quanto fica com o cliente. Quanto mais o provedor gerencia, menos controle o cliente tem — e mais rápido ele consegue avançar.

Os três modelos fundamentais definidos pelo NIST¹ são IaaS, PaaS e SaaS. Além deles, surgiram vários modelos especializados — FaaS, CaaS, DBaaS e outros —, cada um recortando uma fatia mais estreita da pilha.

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

O que torna um serviço "nuvem"?

Alugar um servidor num datacenter assinando um contrato de três anos não é computação em nuvem, mesmo que o servidor esteja longe. A NIST SP 800-145¹ define computação em nuvem por cinco características essenciais. Um serviço precisa ter todas elas:

O NIST também define modelos de implantação, que dizem quem compartilha a infraestrutura — e não quanto dela você gerencia:

• Nuvem pública — compartilhada por qualquer cliente pagante (AWS, Google Cloud, Azure).
• Nuvem privada — o mesmo modelo de autoatendimento operado para uma única organização (por exemplo, OpenStack no datacenter da própria empresa).
• Nuvem híbrida — uma combinação, por exemplo, os dados de clientes ficam on-premises enquanto a camada web roda numa nuvem pública.
• Nuvem comunitária — compartilhada por organizações com requisitos em comum (por exemplo, órgãos de governo).

CapEx vs OpEx. Comprar servidores é despesa de capital (CapEx): um pagamento alto adiantado por um ativo que você possui e deprecia ao longo dos anos, dimensionado para o pico que você espera. A nuvem transforma a infraestrutura em despesa operacional (OpEx): você paga mensalmente pelo que usa. O OpEx elimina a aposta inicial, mas não é automaticamente mais barato — um workload que roda em carga máxima 24/7 por anos pode custar mais na nuvem do que em hardware próprio.

A pilha de responsabilidade compartilhada

Todo modelo de serviço em nuvem pode ser mapeado na mesma pilha de seis camadas:

A linha que separa o que o provedor gerencia (verde) do que o cliente gerencia (laranja) sobe à medida que você avança na hierarquia de modelos:

graph TD
  subgraph On-Premises
    direction TB
    A1[Hardware] --> A2[Virtualização]
    A2 --> A3[SO]
    A3 --> A4[Middleware]
    A4 --> A5[Aplicação]
    A5 --> A6[Dados]
    style A1 fill:#ff9999,stroke:#333
    style A2 fill:#ff9999,stroke:#333
    style A3 fill:#ff9999,stroke:#333
    style A4 fill:#ff9999,stroke:#333
    style A5 fill:#ff9999,stroke:#333
    style A6 fill:#ff9999,stroke:#333
  end
  subgraph IaaS
    direction TB
    B1[Hardware] --> B2[Virtualização]
    B2 --> B3[SO]
    B3 --> B4[Middleware]
    B4 --> B5[Aplicação]
    B5 --> B6[Dados]
    style B1 fill:#a8e6cf,stroke:#333
    style B2 fill:#a8e6cf,stroke:#333
    style B3 fill:#ffd3b6,stroke:#333
    style B4 fill:#ffd3b6,stroke:#333
    style B5 fill:#ffd3b6,stroke:#333
    style B6 fill:#ffd3b6,stroke:#333
  end
  subgraph PaaS
    direction TB
    C1[Hardware] --> C2[Virtualização]
    C2 --> C3[SO]
    C3 --> C4[Middleware]
    C4 --> C5[Aplicação]
    C5 --> C6[Dados]
    style C1 fill:#a8e6cf,stroke:#333
    style C2 fill:#a8e6cf,stroke:#333
    style C3 fill:#a8e6cf,stroke:#333
    style C4 fill:#a8e6cf,stroke:#333
    style C5 fill:#ffd3b6,stroke:#333
    style C6 fill:#ffd3b6,stroke:#333
  end
  subgraph SaaS
    direction TB
    D1[Hardware] --> D2[Virtualização]
    D2 --> D3[SO]
    D3 --> D4[Middleware]
    D4 --> D5[Aplicação]
    D5 --> D6[Dados]
    style D1 fill:#a8e6cf,stroke:#333
    style D2 fill:#a8e6cf,stroke:#333
    style D3 fill:#a8e6cf,stroke:#333
    style D4 fill:#a8e6cf,stroke:#333
    style D5 fill:#a8e6cf,stroke:#333
    style D6 fill:#a8e6cf,stroke:#333
  end

Provedor gerencia    Cliente gerencia    Cliente gerencia (on-premises: tudo)

A mesma divisão vale para a segurança. A AWS resume isso como segurança da nuvem (o provedor: datacenters físicos, hypervisor, software dos serviços gerenciados) versus segurança na nuvem (o cliente: dados, gerenciamento de identidade e acesso, regras de rede, configurações de criptografia, o SO no IaaS)². A Microsoft apresenta a mesma tabela para o Azure³. Note que, mesmo no SaaS, o quadrado de dados se refere a operar o armazenamento: decidir quem pode ler os dados é sempre tarefa do cliente.

IaaS — Infraestrutura como Serviço

Você aluga infraestrutura bruta. O provedor fornece computação, armazenamento e rede virtualizados. Você instala o SO, o runtime, o middleware e tudo o que vem acima.

Exemplos: AWS EC2, Google Compute Engine, Azure Virtual Machines, DigitalOcean Droplets.

Quando escolher IaaS:

• Você precisa de controle total no nível do SO (kernel customizado, versão específica de SO)
• Lift-and-shift de workloads on-premises existentes — mover uma aplicação para VMs na nuvem como está, sem redesenhá-la
• Computação de alto desempenho com hardware especializado (instâncias com GPU)
• Conformidade rigorosa que exige controlar a pilha inteira

PaaS — Plataforma como Serviço

Você faz o deploy do código; o provedor o executa. O provedor gerencia o SO, o runtime, o middleware, a escalabilidade e a rede. Você escreve a aplicação e a configura por variáveis de ambiente.

Exemplos: Heroku, AWS Elastic Beanstalk, Google App Engine, Azure App Service, Railway, Render.

Implicação arquitetural: o PaaS favorece o padrão 12-factor app⁴ — processos stateless, configuração por variáveis de ambiente, logs no stdout. A plataforma pode reiniciar ou mover seu processo a qualquer momento, e o sistema de arquivos local é efêmero (apagado a cada reinício); por isso, o estado persistente precisa ficar em serviços gerenciados externos (banco de dados, armazenamento de objetos).

Quando escolher PaaS:

• Construir uma aplicação nova sem experiência em infraestrutura no time
• Prototipagem rápida e MVPs
• Backends de API e microsserviços que não precisam de controle do SO
• Times que querem entregar funcionalidades, não gerenciar servidores

SaaS — Software como Serviço

Você usa o software; o provedor opera tudo. O cliente gerencia apenas usuários, permissões e os dados que insere. Não há infraestrutura nem aplicação para operar.

Exemplos: Google Workspace, Salesforce, Slack, Notion, GitHub, Datadog, PagerDuty.

Multi-tenancy: uma única instância da aplicação atende todos os clientes (tenants), com os dados isolados por tenant ID. Isso gera economia de escala — e é por isso que o SaaS tem o menor tempo até gerar valor.

Quando escolher SaaS:

• Um software pronto já atende a necessidade (CRM, RH, e-mail, monitoramento)
• O time não deveria construir nem operar a ferramenta em si
• A velocidade de adoção importa mais do que a profundidade de customização

Além dos três grandes

Os modelos fundamentais deram origem a variantes especializadas, voltadas para uma parte mais estreita da pilha:

FaaS — Função como Serviço (Serverless)

O extremo do PaaS. Você faz o deploy de funções individuais em vez de aplicações. O provedor gerencia tudo — inclusive escalar até zero quando ocioso — e cobra apenas pelos milissegundos em que a função executa.

Um cold start é o atraso da primeira requisição que chega a uma função sem nenhuma instância aquecida: a plataforma precisa alocar um sandbox, carregar o código e inicializar o runtime. Para uma aplicação Spring Boot, isso pode levar segundos. Os provedores oferecem mitigações — por exemplo, a provisioned concurrency do Lambda mantém instâncias aquecidas —, mas você paga por elas mesmo quando estão ociosas, o que corrói a principal vantagem do FaaS.

Ideal para: workloads orientados a eventos, webhooks, jobs agendados, tarefas esporádicas ou em rajadas. Não é adequado para aplicações de longa duração ou que exigem latência baixa de forma consistente.

CaaS — Container como Serviço

Fica entre IaaS e PaaS. Você fornece imagens Docker; o provedor gerencia o runtime de containers, a orquestração, a rede e a escalabilidade. Você mantém controle total sobre o runtime dentro do container.

Ideal para: times de microsserviços que já usam Docker e querem orquestração gerenciada sem operar o Kubernetes por conta própria.

O Kubernetes gerenciado (Amazon EKS, Google GKE, Azure AKS) também costuma ser classificado como CaaS: o provedor opera o control plane do Kubernetes (API server, scheduler, etcd), e você faz o deploy de containers pela API padrão do Kubernetes, mantida pela CNCF⁶. Quanto dos worker nodes você gerencia depende do modo — os node groups clássicos deixam com você o dimensionamento e as atualizações dos nós, enquanto modos como o GKE Autopilot e o EKS Auto Mode também passam o gerenciamento dos nós para o provedor.

DBaaS — Banco de Dados como Serviço

Um banco de dados gerenciado, em que o provedor cuida de provisionamento, backups, replicação, patches e failover. Você se conecta com um cliente padrão e executa consultas.

Outros modelos especializados

Exemplo: a loja, componente por componente

Sistemas reais misturam modelos de serviço: cada componente vai para onde o seu trade-off é melhor. Esta é uma forma razoável de rodar a loja na AWS — o mesmo formato do projeto da disciplina, que roda os serviços no EKS:

flowchart LR
  client([Cliente]) --> gw["gateway<br/>CaaS: EKS"]
  gw --> acc["account<br/>CaaS: EKS"]
  gw --> ord["order<br/>CaaS: EKS"]
  acc --> db[("Postgres<br/>DBaaS: RDS")]
  ord --> db
  ord --> cache[("Redis<br/>DBaaS: ElastiCache")]
  ord --> kafka["Kafka<br/>gerenciado: Amazon MSK"]
  kafka --> fn["notification<br/>FaaS: Lambda"]
  fn --> mail["e-mail<br/>CPaaS: AWS SES"]

Note que mover um componente para cima (de IaaS para um modelo gerenciado) nunca elimina a coluna de dados e acesso: você continua decidindo quem pode se conectar ao RDS, qual security group alcança o gateway e o que é registrado em log.

Comparação completa

Framework de decisão

flowchart TD
  start([Do que você precisa?]) --> q1{"Precisa de controle total do SO<br/>ou de lift-and-shift?"}
  q1 -->|Sim| iaas["IaaS<br/>EC2, GCE, Azure VM"]
  q1 -->|Não| q2{Vai fazer deploy de containers?}
  q2 -->|Sim| q3{"Quer gerenciar o<br/>Kubernetes por conta própria?"}
  q3 -->|Sim| k8s["CaaS com Kubernetes<br/>EKS, GKE, AKS"]
  q3 -->|Não| caas["CaaS gerenciado<br/>Cloud Run, ECS Fargate"]
  q2 -->|Não| q4{"Workload orientado a eventos /<br/>esporádico?"}
  q4 -->|Sim| faas["FaaS<br/>Lambda, Cloud Functions"]
  q4 -->|Não| q5{"Vai construir uma<br/>aplicação própria?"}
  q5 -->|Sim| paas["PaaS<br/>Heroku, App Engine"]
  q5 -->|Não| saas["SaaS<br/>Use um produto existente"]

Aplique o framework por componente, e não uma vez para o sistema inteiro: no exemplo acima, os serviços ficam em CaaS, a notificação de pedido em FaaS e o monitoramento em SaaS.

Trade-offs e armadilhas

Pontos-chave

• Um serviço é "nuvem" quando tem as cinco características do NIST: autoatendimento sob demanda, amplo acesso pela rede, agrupamento de recursos, elasticidade rápida e serviço medido — e ele transforma CapEx em OpEx.
• Um modelo de serviço define quem gerencia cada camada da pilha de seis camadas; IaaS, PaaS e SaaS sobem a linha, passo a passo.
• CaaS (imagens), FaaS (funções, escala até zero, cold starts) e DBaaS (bancos de dados gerenciados) recortam fatias mais estreitas da pilha.
• Mais gerenciado significa mais velocidade e menos operação, mas menos controle e portabilidade.
• Sistemas reais misturam modelos: escolha por componente — os serviços da loja em CaaS, o Postgres em DBaaS, o monitoramento em SaaS.
• Seus dados, identidades, regras de acesso e configuração são sempre sua responsabilidade.

Conexões

• Containerização — a imagem Docker que as plataformas de CaaS executam.
• Microsserviços — por que a loja é dividida em serviços com deploy independente.
• Roteiro de deploy na nuvem — a próxima aula: plataformas concretas (Railway, Fly.io, Lightsail, ECS, EKS) e seus custos.
• Hands-on 5 — Orquestração — Kubernetes localmente com Minikube, a API que o EKS gerencia para você.
• Projeto: AWS, EKS e Custos e PaaS.

IaaS vs PaaS vs SaaS — visão geral prática dos três modelos fundamentais (em inglês).