O que é PaaS (Platform-as-a-Service)?

PaaS é um modelo de nuvem em que o provedor executa a plataforma onde seu código é implantado, enquanto você ainda escreve e mantém a aplicação. Em bom português: você aluga a plataforma, mas o app continua sendo seu. A definição do NIST traça a linha com precisão — o provedor controla servidores, sistemas operacionais e runtimes; você controla a aplicação implantada e os dados dela.

Principais pontos

Como é usar um PaaS

A experiência que define o PaaS é fazer deploy com um comando e nenhum setup de infraestrutura:

# O fluxo típico de PaaS: faça push do código, a plataforma cuida do resto
$ git push platform main
-----> Runtime detected: Node.js
-----> Installing dependencies, building release
-----> Launching web process (2 instances)
       https://my-api.example.app deployed

O que esse comando implanta, porém, ainda é uma aplicação de servidor completa que você escreveu — roteamento, validação, fiação do banco, tratamento de auth:

// server.js — num PaaS, tudo isto continua sendo seu para escrever e manter
import express from 'express';
const app = express();

app.get('/tasks', async (req, res) => {
  const user = await authenticate(req);            // você construiu isto
  const tasks = await db.query(                    // e isto
    'SELECT * FROM tasks WHERE owner = $1 AND done = false',
    [user.id]
  );
  res.json(tasks);                                 // e isto
});

app.listen(process.env.PORT);

Essa é a troca essencial do PaaS: a infraestrutura desaparece, mas a aplicação de backend — com cada patch de segurança, upgrade de dependência e endpoint dela — continua sendo o seu codebase.

A escada de abstração

Cada modelo de serviço em nuvem responde a uma pergunta: quanto você aluga, e quanto ainda executa?

A divisão de responsabilidade, camada por camada:

Existem sabores especializados de PaaS para trabalhos mais estreitos — plataformas de integração, mobile, banco de dados, comunicação — mas todos ficam no mesmo degrau: um lugar gerenciado para rodar ou conectar o software que você constrói.

PaaS vs. BaaS: a diferença na prática

O BaaS é o degrau seguinte, e a diferença aparece no que você não escreve. O endpoint de lista de tarefas acima — checagem de auth, query, resposta — é substituído num BaaS por uma chamada direta de SDK a partir de qualquer cliente, com o controle de acesso aplicado pela plataforma:

// JavaScript / Node.js — Back4app JS SDK
const query = new Parse.Query('Task');
query.equalTo('done', false);
query.descending('createdAt');
const tasks = await query.find();
console.log(`${tasks.length} open tasks`);

// Flutter / Dart — Back4app Flutter SDK
final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('done', false)
  ..orderByDescending('createdAt');
final response = await query.query();
if (response.success) {
  print('${response.results?.length} open tasks');
}

// iOS / Swift — Back4app Swift SDK
let query = Task.query("done" == false)
  .order([.descending("createdAt")])
query.find { result in
  switch result {
  case .success(let tasks):
    print("\(tasks.count) open tasks")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val query = ParseQuery.getQuery<ParseObject>("Task")
query.whereEqualTo("done", false)
query.orderByDescending("createdAt")
query.findInBackground { tasks, e ->
  if (e == null) {
    Log.d("Tasks", "${tasks.size} open tasks")
  }
}

PaaS vs. serverless

Os modelos são primos, não sinônimos. Um app PaaS roda continuamente em capacidade que você configura; a computação serverless se materializa por evento, cobra por invocação e escala a zero — ao preço de cold starts e limites de execução. Na prática, a linha borra: plataformas modernas anexam funções serverless à hospedagem estilo PaaS, e uma arquitetura serverless pode servir uma API inteira que um PaaS hospedaria como um único app. A decisão depende do formato do tráfego: carga estável favorece o processo sempre ligado do PaaS; carga esporádica ou majoritariamente ociosa favorece a computação por invocação.

Casos de uso comuns

• APIs e serviços web próprios. Um backend com lógica específica demais para funcionalidades prontas — motores de precificação, marketplaces, ferramentas internas — implantado sem ser dono de servidores.
• Padronizar muitos deploys. Times com dezenas de serviços adotam um PaaS para que todo serviço construa, implante, logue e escale do mesmo jeito.
• Migrar de servidores autogeridos. Aplicações de servidor existentes (em especial apps twelve-factor) se mudam para um PaaS quase sem mudanças — o mesmo código, sem mais patching de SO.
• Onde o BaaS substitui o PaaS: backends de app padrão. Se o backend é usuários + dados + arquivos + notificações, funcionalidades prontas eliminam a camada de aplicação que o PaaS hospedaria — o caso comum de produtos mobile e web.
• Híbrido: núcleo custom estilo PaaS, BaaS para o resto. Alguns times mantêm um serviço próprio numa plataforma enquanto gestão de usuários, APIs de dados e storage vêm de um BaaS ao lado.

PaaS ou BaaS? Uma matriz de decisão

Se a maioria dos requisitos é padrão mas alguns são custom, isso não é motivo para escolher PaaS — um BaaS com runtime de funções embutido cobre os dois lados com menos código para manter.

Limitações e trade-offs

• Você ainda mantém uma aplicação. Upgrades de framework, patches de segurança em dependências, bugs de auth — o PaaS hospeda o seu backend; ele não faz a manutenção. Esse é o custo que o BaaS remove e o PaaS não.
• Vendor lock-in. Apps escritos contra serviços e formatos de deploy específicos da plataforma custam caro para mover. Mitigações: fique nos padrões abertos, containerize, prefira plataformas construídas sobre open source — a mesma cautela com lock-in vale escada acima e abaixo.
• Custo em escala sustentada. A conveniência gerenciada carrega uma margem; workloads grandes e estáveis acabam ficando mais baratos nos degraus de baixo — ao preço de recontratar a carga de operações.
• Controle reduzido. Sem acesso ao SO, tuning de rede limitado e versões de runtime no cronograma do provedor. Regimes de compliance que exigem controle da infraestrutura podem descartar o modelo.
• Dependência do provedor. Quedas, mudanças de preço e descontinuações chegam no cronograma do provedor, não no seu. Julgue o histórico do provedor como parte da arquitetura.

PaaS vs. BaaS no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Isso o coloca um degrau acima do PaaS: todo app começa com o backend completo já provisionado. A lacuna de lógica custom que puxaria você de volta a um PaaS é coberta pelo Cloud Code — funções serverless, triggers e jobs agendados. E como a stack é open source, a objeção do lock-in se inverte: o mesmo backend pode ser auto-hospedado em qualquer infraestrutura, então descer a escada mais tarde continua possível, sem reescrita.