Fundamentos da computação em nuvem
IaaS vs. PaaS vs. SaaS
O reparto completo de responsabilidade nos 3 modelos de serviço lado a lado, as pistas de palavras-chave que identificam cada um em um cenário, e a armadilha clássica que pega quem assume que subir na pilha é sempre um upgrade.
- Comparar o reparto completo de responsabilidade entre IaaS, PaaS e SaaS, camada por camada
- Aplicar pistas de palavras-chave para identificar o modelo de serviço correto em um cenário
- Explicar por que subir na pilha troca controle por conveniência, em vez de simplesmente melhorar
- Avaliar um cenário contra suas restrições para escolher o modelo de serviço que encaixa
Nomear é fácil. Diferenciar é a habilidade de verdade
Agora você consegue definir IaaS, PaaS e SaaS individualmente. Isso, sozinho, não é uma habilidade muito útil: quase ninguém te entrega um serviço e pergunta "o que é isso?" isolado. O que realmente é testado, em uma prova e no trabalho, é um cenário com restrições, um time, um prazo, uma exigência de compliance, e a pergunta de qual dos 3 modelos encaixa nele. É aí que esta lição concentra o esforço.
A pilha completa, lado a lado
| Camada | IaaS | PaaS | SaaS |
|---|---|---|---|
| Rede, servidores, virtualização | Provedor | Provedor | Provedor |
| Sistema operacional | Você | Provedor | Provedor |
| Runtime e middleware | Você | Provedor | Provedor |
| Código da aplicação | Você | Você | Provedor |
| Dados e a sua própria configuração | Você | Você | Você |
Leia a tabela por coluna, em vez de por linha, e o padrão fica óbvio: cada passo de IaaS para SaaS move exatamente mais uma camada de "você" para "provedor". Dados e a sua própria configuração são a única linha que nunca se move, não importa qual modelo você escolha.
A armadilha: isso é um tradeoff, não um ranking
É tentador ler essa tabela da esquerda para a direita e concluir que a SaaS é simplesmente o melhor modelo, já que o provedor faz mais trabalho. Essa conclusão está errada, e é exatamente a armadilha que uma questão de prova costuma montar. O que a SaaS ganha em conveniência, ela gasta em controle. Você não consegue instalar uma biblioteca personalizada nos servidores do Gmail, rodar o próprio código na infraestrutura do Salesforce ou escolher outra versão de kernel para o Microsoft 365. A IaaS devolve todo esse controle, ao custo de você mesmo cuidar do sistema operacional, do runtime e da aplicação. Nenhuma ponta da tabela é "melhor". Cada uma encaixa em um conjunto diferente de restrições.
Pistas de palavras-chave para cenários
Cenários de prova raramente dizem "IaaS" ou "PaaS" diretamente. Eles descrevem uma restrição, e a restrição aponta para o modelo.
| O cenário diz... | Aponta para |
|---|---|
| "Controle total do sistema operacional", "versão específica do kernel", "acesso root" | IaaS |
| "Só implantar o código", "sem gerenciar servidor", "foco na aplicação" | PaaS |
| "Sem instalação", "usar pronto, direto da caixa", "sem desenvolvedores na equipe" | SaaS |
Exemplo prático: 2 cenários, 2 respostas
Um time de vendas de 12 pessoas precisa de um CRM funcionando até a próxima semana e não tem nenhum desenvolvedor na equipe para construir um. Nada nesse cenário menciona código, infraestrutura ou personalização além de configuração. Essa ausência é a pista: é um cenário de SaaS, e uma ferramenta como o Salesforce é o encaixe, não algo que um time constrói do zero.
Agora mude a restrição. Uma fintech opera sob uma regulamentação que a obriga a controlar o nível exato de patch do sistema operacional rodando em cada servidor, até a versão do kernel, e a aplicar patches de segurança no próprio cronograma, e não no do fornecedor. PaaS e SaaS tiram o sistema operacional das mãos do cliente, exatamente o controle que essa regulamentação exige. Essa única exigência descarta os 2, e deixa a IaaS como o único modelo que encaixa.
Mesma pergunta de fundo nos 2 casos: até onde na pilha esse cenário exige que você chegue. A resposta do time de vendas é "nem um pouco". A resposta da fintech é "até o kernel".
A conexão com a responsabilidade compartilhada
Esse mesmo reparto camada por camada é a base do modelo de responsabilidade compartilhada, coberto por completo no domínio de Segurança e Confiabilidade deste curso. O que você está aprendendo aqui, qual camada é sua e qual é do provedor, é exatamente a pergunta que aquele modelo responde especificamente para segurança. Você não vai aprender uma ideia nova lá. Vai aplicar esta mesma a uma nova pergunta.
Onde isso deixa você
Uma pergunta separa esses 3 modelos em qualquer cenário: até onde na pilha a situação exige que o provedor vá. Acesso root e controle de kernel puxam para IaaS. Um foco em enviar código sem gerenciar servidor puxa para PaaS. Nenhuma instalação e nenhum desenvolvedor interno puxam para SaaS. O próximo tema deste domínio deixa os modelos de serviço para trás e passa para os blocos de construção que cada um deles roda por cima: regiões, computação, armazenamento, bancos de dados e rede.