O que é PaaS? Platform as a Service face a IaaS, SaaS e Kubernetes

A Platform as a Service (PaaS) é um modelo de cloud em que entrega a sua aplicação como código-fonte ou imagem de contentor e o fornecedor a executa. A plataforma faz o build e o deploy da aplicação, escala-a e gere os servidores, os sistemas operativos e as redes subjacentes. A aplicação, a sua configuração e os seus dados continuam a ser da sua responsabilidade.

A definição mais citada vem do National Institute of Standards and Technology dos EUA (NIST SP 800-145). Com uma PaaS, faz deploy das suas próprias aplicações na infraestrutura do fornecedor, mas não gere nem controla a infraestrutura de cloud subjacente, incluindo a rede, os servidores, os sistemas operativos e o armazenamento (no original: «not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage»). Controla, isso sim, as aplicações de que fez deploy e, eventualmente, definições do ambiente de alojamento.

O que uma PaaS assume

A lista exata varia de fornecedor para fornecedor, mas uma PaaS completa cobre a maior parte do seguinte:

• Builds: transforma um repositório Git numa imagem executável, com buildpacks que detetam a sua linguagem ou a partir de um Dockerfile que inclui no repositório.
• Deploys: publica novas versões, muitas vezes a cada push para uma branch, e mantém um histórico do que esteve a correr e quando.
• Escalabilidade: aumentar o número de réplicas ou o tamanho da instância é uma alteração de configuração, não a instalação de um novo servidor.
• TLS e domínios: cada aplicação recebe um hostname, e a plataforma emite e renova os certificados para os seus domínios.
• Logs e métricas: logs de execução e gráficos de CPU e memória, sem ter de manter a sua própria stack de logs.
• Bases de dados geridas: PostgreSQL, MySQL ou uma cache ao lado da aplicação, com réplicas e backups como opção.
• Servidores e sistemas operativos: aplicar patches aos hosts, substituir hardware avariado e manter a rede a funcionar.

O que continua a ser da sua responsabilidade

Uma PaaS elimina o trabalho de infraestrutura, não a responsabilidade pelo seu produto. Continua a ser responsável por:

• O seu código e as respetivas dependências, incluindo atualizar bibliotecas quando é divulgada uma vulnerabilidade.
• Configuração e segredos: variáveis de ambiente, chaves de API e quem na sua equipa as pode ver.
• Os seus dados: o esquema, as migrações, ativar os backups e testar um restauro.
• Dimensionamento e custo: quantas réplicas executa e que plano escolhe, e a fatura que daí resulta.
• Segurança da aplicação: autenticação, validação de entradas e acesso ao dashboard.
• Localização: a região em que a sua aplicação e os respetivos dados são executados.

PaaS vs IaaS vs SaaS vs serverless vs Kubernetes

Os modelos diferem naquilo que entrega e naquilo que mantém. Uma comparação aproximada:

Modelo	O que entrega	O fornecedor gere	O que continua a gerir	Uso típico
IaaS	Máquinas virtuais, discos, redes	Hardware, virtualização, centros de dados	Sistema operativo, runtime, deploys, escalabilidade, patches	Controlo total, software legado ou especial
PaaS	Código-fonte ou uma imagem de contentor	Servidores, SO, builds, deploys, encaminhamento, muitas vezes bases de dados	Aplicação, configuração, dados	Aplicações web, APIs, workers
SaaS	Nada de que fazer deploy	A aplicação inteira	Definições, utilizadores e os seus dados na aplicação	Software empresarial padrão
Serverless (FaaS)	Funções	Execução por evento ou pedido, escalabilidade conforme a procura	Código das funções, cold starts, limites de tempo e de tamanho	Cargas orientadas a eventos, com picos
Kubernetes	Imagens de contentor e manifestos	Como serviço gerido: o control plane	Nós, deployments, ingress, configuração da escalabilidade, CI/CD, logging	Grandes infraestruturas com uma equipa de plataforma

A IaaS fornece máquinas virtuais e deixa o resto consigo. O NIST descreve-a como o fornecimento de «processing, storage, networks, and other fundamental computing resources» (capacidade de processamento, armazenamento, redes e outros recursos informáticos fundamentais) nos quais executa qualquer software, incluindo o sistema operativo.

O SaaS está no extremo oposto: usa a aplicação pronta do fornecedor no browser ou através de uma API e não faz deploy de nada.

O serverless, no sentido de funções, executa o seu código como pequenas funções acionadas por eventos ou pedidos HTTP e fatura de acordo com a procura real. O whitepaper da CNCF sobre serverless observa que a maioria dos runtimes limita o tamanho ou o tempo de execução de cada função, e que o arranque após períodos de inatividade pode ser lento. Uma PaaS, por sua vez, executa normalmente a sua aplicação como um processo sempre ativo.

O Kubernetes é um orquestrador de contentores, e a sua própria documentação afirma que o Kubernetes «is not a traditional, all-inclusive PaaS», ou seja, que não é uma PaaS tradicional e completa. Não faz deploy de código-fonte, não faz o build da sua aplicação e não inclui bases de dados como serviços integrados. Fornece blocos de construção para plataformas. Leia PaaS vs Kubernetes para uma comparação mais longa.

Quando uma PaaS é adequada

• Desenvolve aplicações web, APIs ou workers em segundo plano numa linguagem comum.
• Ninguém na sua equipa tem como função gerir servidores ou clusters, e prefere não contratar alguém para isso por enquanto.
• Quer uma nova versão em produção poucos minutos depois de um merge, com logs e métricas já disponíveis.
• Precisa das bases de dados, do armazenamento e da aplicação no mesmo sítio, numa única fatura.

Quando não é

• Precisa de um kernel personalizado, de hardware especial ou de controlo de baixo nível sobre a rede. Uma máquina virtual ou bare metal é mais adequada.
• O seu software espera acesso root, um sistema init completo ou pacotes instalados com scripts de maintainer. Um Dockerfile pode cobrir parte disto; algum software só funciona bem numa VM.
• Executa cargas de trabalho grandes e estáveis e já tem uma equipa de plataforma. Nesse caso, gerir a sua própria infraestrutura pode compensar.
• O seu código corre alguns segundos por dia em resposta a eventos. Uma plataforma de funções pode sair mais barata.
• Tem um requisito legal ou de conformidade que as regiões ou as certificações do fornecedor não conseguem cumprir.

Como avaliar uma PaaS

Regiões e localização dos dados

Verifique onde são realmente executados a aplicação, a base de dados, os backups e os logs, e se pode escolher isso serviço a serviço. Verifique também onde ficam o control plane e os dados de conta do fornecedor, e em que país a empresa tem sede. Para dados pessoais de pessoas na UE, ambas as perguntas contam.

Serviços incluídos

Veja o que vem com a plataforma e o que exige um terceiro: bases de dados, armazenamento de objetos, e-mail, CDN, logs e métricas, ambientes de pré-visualização. Cada add-on de outro fornecedor é mais um contrato, mais uma fatura e mais um subcontratante ulterior.

Modelo de preços

As plataformas faturam por instância, por segundo de execução, por pedido ou por utilizador (seat), e algumas medem ainda a largura de banda, os minutos de build ou o volume de logs. Estime um mês com os seus números reais, incluindo a base de dados e um segundo ambiente de staging.

Portabilidade

A dependência de fornecedor (lock-in) costuma esconder-se no build e na configuração, não no código. Prefira uma plataforma que crie imagens de contentor padrão a partir de um Dockerfile ou de Cloud Native Buildpacks: o lifecycle dos buildpacks exporta uma imagem OCI, o mesmo formato que as outras plataformas de contentores executam. Mantenha a configuração em variáveis de ambiente e use motores de base de dados padrão cujos dados possa exportar e restaurar noutra plataforma. Assim, sair passa a ser uma migração e não uma reescrita.

Onde se encaixa a Nodion

A Nodion é uma PaaS operada pela Nodion GmbH, com sede em Stuttgart, na Alemanha. Faz deploy a partir do Git com um Dockerfile ou com os Cloud Native Buildpacks próprios da Nodion, ou a partir de uma imagem pré-construída. Cada aplicação tem processos, logs, métricas e domínios, as aplicações Git podem abrir ambientes de pré-visualização, e as bases de dados geridas Postgres, MySQL, Valkey e ClickHouse associam-se no separador Environment da aplicação. Pode escolher a região por serviço, por exemplo EU Central em Frankfurt. Consulte Aplicações para mais detalhes.