Fundamentos da computação em nuvem
Plataforma como serviço (PaaS)
O modelo de serviço que tira o sistema operacional e o runtime do seu colo, então você envia código e a plataforma o executa, com AWS Elastic Beanstalk, Heroku e Google App Engine como os produtos que o entregam.
- Definir Plataforma como Serviço (PaaS) segundo o framework do NIST
- Identificar quais camadas passam do cliente para o provedor entre IaaS e PaaS
- Contrastar a implantação da mesma aplicação via IaaS e via PaaS
- Explicar a fronteira entre PaaS e o modelo serverless coberto mais adiante neste curso
E se você nunca quisesse tocar no sistema operacional?
A lição anterior terminou com você dono de uma instância EC2: aplicando patches no sistema operacional dela, instalando um runtime, configurando um firewall. Agora imagine um desenvolvedor sozinho, com uma aplicação web para lançar até sexta-feira e zero interesse em qualquer uma dessas tarefas. Ele não quer escolher uma AMI, dimensionar um load balancer nem ler um changelog de patch. Ele quer entregar código e ver rodando. Plataforma como Serviço é o modelo construído exatamente para essa troca.
A definição do NIST, na prática
O NIST define PaaS como a capacidade de "implantar na infraestrutura de nuvem aplicações criadas ou adquiridas pelo consumidor, criadas usando linguagens de programação, bibliotecas, serviços e ferramentas suportadas pelo provedor". O consumidor não gerencia a infraestrutura subjacente, incluindo rede, servidores, sistemas operacionais ou armazenamento, mas controla a aplicação implantada e, muitas vezes, as configurações do ambiente que a hospeda.
Leia isso ao lado da definição de IaaS da lição anterior e a mudança fica precisa: o sistema operacional, que era seu na IaaS, agora pertence ao provedor. O que resta para você é a própria aplicação e as configurações ao redor de como ela roda.
Quem gerencia o quê, atualizado
| Camada | IaaS | PaaS |
|---|---|---|
| Rede, servidores, virtualização | Provedor | Provedor |
| Sistema operacional | Você | Provedor |
| Runtime e middleware | Você | Provedor |
| Código da aplicação | Você | Você |
| Dados | Você | Você |
A mudança inteira está em uma linha: o sistema operacional e o runtime cruzam de "você" para "provedor". Essa é toda a diferença entre os 2 modelos, e ela merece mais atenção do que uma única linha sugere, porque é exatamente a fronteira que um cenário de prova testa.
Produtos reais que entregam PaaS
- AWS Elastic Beanstalk: empacota instâncias EC2, um load balancer e auto scaling atrás de uma única implantação, ainda construído sobre a IaaS da AWS por baixo, mas você nunca toca nessas peças diretamente
- Heroku: você roda
git push heroku main, e o Heroku detecta a linguagem, instala as dependências e implanta, sem nenhuma configuração de servidor para frameworks padrão - Google App Engine e Azure App Service: a mesma troca, você envia o código, a plataforma o executa
Exemplo prático: a mesma aplicação, de 2 jeitos
Implantar uma pequena aplicação web em Ruby pela EC2 significa lançar uma instância, instalar o Ruby e suas dependências, configurar um servidor web, conectar um load balancer e montar um grupo de auto scaling, vários passos separados, cada um seu para acertar e manter com patches em dia. Implantar a mesma aplicação pelo Heroku significa rodar git push heroku main. O Heroku lê o código, reconhece que precisa de um runtime Ruby, faz o build e começa a atender tráfego, tudo a partir desse único comando.
Isso não é uma versão menor do mesmo trabalho. É um trabalho diferente: você parou de gerenciar infraestrutura e passou a gerenciar só a sua aplicação.
O erro comum: PaaS não é "zero decisões de infraestrutura"
É tentador assumir que a PaaS elimina completamente o pensamento sobre infraestrutura. Não elimina. Você ainda escolhe um tamanho de dyno ou instância, ainda define variáveis de ambiente e ainda paga pela capacidade que alocou, esteja ela atendendo tráfego agora ou não: um dyno do Heroku que você provisiona continua rodando, e cobrando, até você mesmo reduzi-lo. Um modelo que só cobra pelo instante em que seu código realmente executa é outra ideia, computação serverless, e este curso cobre isso mais adiante, no tema Arquiteturas Modernas de Nuvem. A PaaS reduz sua tarefa de infraestrutura. Não a apaga.
A fronteira à frente: PaaS contra SaaS
A PaaS ainda pede que você escreva a aplicação. Essa é a linha que a próxima lição apaga por completo.
Onde isso deixa você
A PaaS troca parte do controle que a IaaS te dava por velocidade: você para de gerenciar servidores e passa a enviar código direto para uma plataforma que o executa. A próxima lição cobre o que acontece quando nem o código é mais seu para escrever.