Quiz

C — SO convidado, runtime e middleware.

O IaaS entrega a você uma máquina virtual com um SO recém-instalado. Você instala o Java, configura o nginx, aplica os patches do SO e gerencia tudo acima do hypervisor. O PaaS abstrai tudo isso — você envia o código, e a plataforma instala e gerencia o runtime.

C — CaaS.

O CaaS fica entre o IaaS e o PaaS. O cliente fornece uma imagem Docker; a plataforma cuida do agendamento, da rede, da escalabilidade e da saúde dos nós. AWS Fargate e Google Cloud Run são exemplos clássicos — nenhum cluster para gerenciar, mas controle total sobre o que roda dentro do container.

D — Uma função como unidade de deploy, escala até zero, cobrança por invocação + duração.

O PaaS também gerencia o SO e o runtime (A), o CaaS faz o deploy de containers (B), e a multi-tenancy é a marca registrada do SaaS (C). Escalar até zero já não é exclusividade do FaaS — plataformas de containers serverless, como Google Cloud Run e Azure Container Apps, também escalam até zero —, mas a combinação "fazer o deploy de uma função e pagar por invocação e por milissegundo" é o que define o FaaS. Um PaaS clássico mantém pelo menos uma instância rodando e cobra por ela mesmo quando ociosa. O trade-off é a latência de cold start e um tempo máximo de execução (15 min no AWS Lambda).

C — GitHub, Slack, Datadog, Salesforce.

O SaaS fornece software totalmente gerenciado — o cliente gerencia apenas usuários, permissões e dados. GitHub (controle de versão), Slack (mensagens), Datadog (monitoramento) e Salesforce (CRM) são todos SaaS. As outras opções são IaaS (A), PaaS (B) e CaaS (D).

B — PaaS.

O PaaS é o ponto ideal para times que querem entregar rápido sem se tornar engenheiros de infraestrutura. Envie o código, configure as variáveis de ambiente, escale com um controle deslizante. O time mantém controle total sobre a aplicação e os dados, mas nunca mexe em patches do SO, atualizações de runtime ou configuração do balanceador de carga.

C — O provedor gerencia replicação, backups, failover e SO; o cliente gerencia schema e acesso.

Rodar PostgreSQL no EC2 significa que você o instala, configura a replicação por streaming, agenda backups, aplica patches no SO e responde a falhas de hardware. Com AWS RDS ou Cloud SQL, tudo isso é automatizado — você se conecta com um cliente padrão e se concentra nas consultas e na modelagem do schema.

A — IaaS = máximo controle, máxima sobrecarga; SaaS = imediato, controle mínimo.

Esse é o trade-off fundamental da responsabilidade compartilhada. Passar de IaaS para PaaS e depois para SaaS transfere progressivamente a carga operacional para o provedor, ao custo de controle e portabilidade. O modelo certo depende de construir e operar aquilo ser ou não uma competência central do time.

C — Latência baixa e consistente com tráfego alto e constante.

O FaaS sofre com cold starts — a plataforma precisa inicializar uma nova instância da função quando não há nenhuma instância aquecida disponível. Para workloads esporádicos ou em rajadas (webhooks, jobs agendados), isso é aceitável. Para uma API de alto tráfego que exige latência P99 abaixo de 100 ms, um deploy em PaaS ou CaaS sempre aquecido é mais adequado. A provisioned concurrency do Lambda pode manter instâncias aquecidas, mas aí você paga por capacidade ociosa e perde a principal vantagem de custo do FaaS.

D — IaaS.

Quando o workload exige um kernel específico, drivers customizados ou controle de hardware especializado, só o IaaS dá o nível de acesso necessário. O PaaS abstrai o SO; o SaaS não deixa você trazer kernels customizados; o FaaS não expõe hardware de GPU (na maioria das implementações). Plataformas de ML gerenciadas, como o AWS SageMaker, podem fornecer GPUs, mas escolhem o SO e o kernel por você.

C — CaaS com control plane do Kubernetes gerenciado.

GKE e EKS gerenciam o control plane do Kubernetes (API server, scheduler, etcd). No modo clássico, o cliente provisiona e gerencia os worker nodes (ou usa managed node groups); modos como o GKE Autopilot e o EKS Auto Mode também passam o gerenciamento dos nós para o provedor. Em todos os modos, o cliente é responsável por fazer o deploy e configurar os workloads, as network policies, o controle de acesso e por disparar as atualizações de versão do cluster. Isso é CaaS — um degrau acima do IaaS, um degrau abaixo de um PaaS completo.

D — Um SLA de disponibilidade não faz parte da definição.

O NIST define computação em nuvem por cinco características: autoatendimento sob demanda, amplo acesso pela rede, agrupamento de recursos, elasticidade rápida e serviço medido. SLAs são termos contratuais que cada provedor oferece por serviço (e variam muito); um serviço pode ser "nuvem" sem um SLA de 99,99%. Por outro lado, um servidor alugado com contrato de três anos e um SLA forte não é nuvem se você não consegue provisioná-lo por conta própria e pagar pelo uso.

B — De CapEx para OpEx.

Comprar servidores é despesa de capital: um pagamento alto e antecipado por um ativo dimensionado para o pico que você espera. Recursos de nuvem são despesa operacional: você paga pelo que usa e pode parar de pagar quando para de usar. A alternativa D é a pegadinha — o OpEx elimina a aposta inicial, mas não é automaticamente mais barato; um workload rodando em carga máxima 24/7 por anos pode custar mais na nuvem do que em hardware próprio.

C — Do cliente.

A AWS é responsável pela segurança da nuvem: os datacenters, o hardware, o hypervisor e o próprio serviço S3. O cliente é responsável pela segurança na nuvem: quem pode ler os dados, políticas de IAM, bucket policies, configurações de criptografia. Serviços gerenciados transferem camadas operacionais para o provedor, mas decidir quem pode acessar seus dados nunca muda de lado.

C — O banco de dados saiu do IaaS para o DBaaS.

No EC2, o time instala o Postgres, aplica patches no SO, escreve scripts de backup e cuida do failover. Com o RDS, isso tudo vira configurações (retenção de backup, Multi-AZ, janela de manutenção) que a AWS executa. A aplicação continua se conectando com o mesmo formato de URL JDBC e o mesmo driver, e o time continua dono da modelagem do schema, da otimização de consultas e de quem pode se conectar (security groups, usuários do banco de dados).