¿Qué es PaaS (Platform as a Service)?

PaaS es un modelo de nube donde el proveedor opera la plataforma sobre la que despliegas tu código, pero tú sigues escribiendo y manteniendo la aplicación. En términos llanos: alquilas la plataforma, pero la app sigue siendo tuya. La definición del NIST traza la línea con precisión — el proveedor controla servidores, sistemas operativos y runtimes; tú controlas la aplicación desplegada y sus datos.

Puntos clave

Cómo se ve usar un PaaS

La experiencia PaaS por excelencia es desplegar con un comando y sin configurar infraestructura:

# El flujo PaaS típico: push del código, la plataforma hace el resto
$ git push platform main
-----> Runtime detected: Node.js
-----> Installing dependencies, building release
-----> Launching web process (2 instances)
       https://my-api.example.app deployed

Lo que ese comando despliega, eso sí, sigue siendo una aplicación de servidor completa que tú escribiste — routing, validación, cableado de base de datos, manejo de auth:

// server.js — en un PaaS, todo esto sigue siendo tuyo de escribir y mantener
import express from 'express';
const app = express();

app.get('/tasks', async (req, res) => {
  const user = await authenticate(req);            // esto lo construiste tú
  const tasks = await db.query(                    // y esto
    'SELECT * FROM tasks WHERE owner = $1 AND done = false',
    [user.id]
  );
  res.json(tasks);                                 // y esto
});

app.listen(process.env.PORT);

Ese es el trato esencial de PaaS: la infraestructura desaparece, pero la aplicación de backend — y cada parche de seguridad, upgrade de dependencias y endpoint dentro de ella — sigue siendo tu base de código.

La escalera de abstracción

Cada modelo de servicio en la nube responde una pregunta: ¿cuánto alquilas y cuánto sigues operando tú?

El reparto de responsabilidades, capa por capa:

Existen variantes especializadas de PaaS para trabajos más estrechos — plataformas de integración, móviles, de base de datos, de comunicaciones — pero todas están en el mismo peldaño: un lugar gestionado para ejecutar o conectar el software que construyes.

PaaS vs. BaaS: la diferencia práctica

BaaS es el peldaño siguiente, y la diferencia se ve en lo que no escribes. El endpoint de la lista de tareas de arriba — chequeo de auth, query, respuesta — se reemplaza en un BaaS por una llamada directa del SDK desde cualquier cliente, con el control de acceso aplicado por la 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

Los modelos son primos, no sinónimos. Una app PaaS corre de forma continua sobre capacidad que tú configuras; el cómputo serverless se materializa por evento, factura por invocación y escala a cero — al precio de cold starts y límites de ejecución. En la práctica la línea se difumina: las plataformas modernas atornillan funciones serverless al hosting estilo PaaS, y una arquitectura serverless puede servir una API entera que un PaaS habría hospedado como una sola app. La decisión depende de la forma del tráfico: la carga constante favorece un proceso PaaS siempre encendido; la carga con picos o mucho reposo favorece el cómputo por invocación.

Casos de uso comunes

• APIs y servicios web custom. Un backend con lógica demasiado específica para funcionalidades preconstruidas — motores de precios, marketplaces, herramientas internas — desplegado sin poseer servidores.
• Estandarizar muchos deployments. Los equipos que operan decenas de servicios adoptan un PaaS para que todos compilen, desplieguen, logueen y escalen igual.
• Migrar desde servidores autogestionados. Las aplicaciones de servidor existentes (especialmente las twelve-factor) se mueven a un PaaS casi sin cambios — el mismo código, sin más parcheo de SO.
• Donde BaaS reemplaza a PaaS: backends de app estándar. Si el backend es usuarios + datos + archivos + notificaciones, las funcionalidades preconstruidas eliminan la capa de aplicación que el PaaS hospedaría — el caso común en productos móviles y web.
• Híbrido: núcleo custom estilo PaaS, BaaS para el resto. Algunos equipos mantienen un servicio custom en una plataforma mientras la gestión de usuarios, las APIs de datos y el almacenamiento vienen de un BaaS al lado.

¿Deberías elegir PaaS o BaaS? Matriz de decisión

Si la mayoría de los requisitos son estándar pero unos pocos son custom, eso no es razón para elegir PaaS — un BaaS con un runtime de funciones embebido cubre ambos lados con menos código que poseer.

Limitaciones y trade-offs

• Sigues poseyendo una aplicación. Upgrades de framework, parches de seguridad en dependencias, bugs de auth — un PaaS hospeda tu backend; no lo mantiene. Este es el costo que BaaS elimina y PaaS no.
• Vendor lock-in. Las apps escritas contra servicios y formatos de deploy específicos de la plataforma son costosas de mover. Mitigaciones: apégate a estándares abiertos, usa contenedores, prefiere plataformas construidas sobre open source — la misma cautela de vendor lock-in aplica a lo largo de toda la escalera.
• Costo con carga sostenida. La conveniencia gestionada lleva un margen; las cargas grandes y constantes acaban siendo más baratas en peldaños inferiores de la escalera — al precio de recontratar la carga de operaciones.
• Menos control. Sin acceso al SO, tuning de red limitado y versiones de runtime al calendario del proveedor. Los regímenes de cumplimiento que exigen control de infraestructura pueden descartar el modelo.
• Dependencia del proveedor. Las caídas, los cambios de precio y las deprecaciones llegan en el calendario del proveedor, no en el tuyo. Evalúa su historial como parte de la arquitectura.

PaaS vs. BaaS en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Eso lo coloca un peldaño por encima de PaaS: cada app arranca con el backend completo ya aprovisionado. El hueco de lógica custom que de otro modo te arrastraría de vuelta a un PaaS lo cubre Cloud Code — funciones serverless, triggers y jobs agendados. Y como el stack es open source, la objeción del lock-in se invierte: el mismo backend puede auto-hospedarse en cualquier infraestructura, así que bajar la escalera más adelante sigue siendo posible sin reescritura.