Modelos de servicio en la nube comparados: IaaS, PaaS, CaaS, FaaS, BaaS, mBaaS y SaaS

El espectro de modelos de servicio en la nube es una escalera — IaaS, CaaS, PaaS, FaaS, BaaS, mBaaS, SaaS — ordenada según cuánto opera el proveedor por ti. Cada “aaS” responde la misma pregunta con una línea distinta: tú construyes por encima de esta línea; nosotros operamos por debajo. La mayoría de las guías se detiene en el trío clásico que la definición del NIST formalizó — IaaS, PaaS, SaaS — y se salta los peldaños donde los productos modernos realmente viven. Esta guía cubre los siete, define cada uno con precisión y luego compara los pares que la gente de verdad confunde. Elige el peldaño y habrás elegido en qué se le va la vida a tu equipo.

Puntos clave

Qué significa “lanzar el backend” en cada peldaño

# La misma tarea — tener un backend sirviendo solicitudes — peldaño por peldaño
# IaaS — recibes máquinas:
$ ssh admin@vm-01              # luego: instalar, configurar, parchear, escalar, monitorear…
# CaaS — recibes orquestación:
$ docker push registry/api:v1  # tus contenedores; su scheduler, redes y escalado
# PaaS — recibes una plataforma:
$ git push platform main       # tu código de app; sus servidores, runtime y escalado
# FaaS — recibes un runtime por evento:
$ deploy functions/api.js      # tus funciones; se ejecutan bajo demanda, escalan a cero
# BaaS / mBaaS — recibes el backend mismo:
#   nada que desplegar — auth, base de datos y APIs ya están corriendo
# SaaS — recibes el producto terminado:
#   nada que construir — inicia sesión y úsalo

El peldaño BaaS merece prueba, porque “nada que desplegar” suena a marketing. Guardar un pedido en un backend de producción — schema, API, control de acceso y escalado del lado del proveedor — es una sola llamada del cliente:

// JavaScript / Node.js — Back4app JS SDK
const order = new Parse.Object('Order');
order.set('total', 129.9);
order.set('status', 'paid');
await order.save(); // schema, API, auth, scaling: all the rungs below you

// Flutter / Dart — Back4app Flutter SDK
final order = ParseObject('Order')
  ..set('total', 129.9)
  ..set('status', 'paid');
await order.save(); // schema, API, auth, scaling handled below you

// iOS / Swift — Back4app Swift SDK
var order = Order()
order.total = 129.9
order.status = "paid"
order.save { result in
  if case .success = result {
    print("saved — the platform ran every layer underneath")
  }
}

// Android / Kotlin — Back4app Android SDK
val order = ParseObject("Order").apply {
  put("total", 129.9)
  put("status", "paid")
}
order.saveInBackground { e ->
  if (e == null) Log.d("Order", "saved — platform ran every layer underneath")
}

Los siete modelos en una sola escalera

La definición de cloud computing del NIST formalizó los tres peldaños clásicos en 2011 — IaaS (“aprovisionar procesamiento, almacenamiento, redes”), PaaS (“desplegar aplicaciones creadas por el consumidor con herramientas soportadas por el proveedor”), SaaS (“usar las aplicaciones del proveedor”) — antes de que CaaS, FaaS y BaaS existieran como categorías. Los peldaños nuevos encajan en los huecos que el NIST dejó: CaaS entre IaaS y PaaS, FaaS y BaaS entre PaaS y SaaS — todavía programables, pero con una porción cada vez menor del programa siendo tuya.

Quién gestiona qué: la matriz de responsabilidades

Todo el tema en una tabla. Lee una columna de arriba abajo para ver qué deja un modelo en tu plato:

Dos cosas que la matriz hace visibles y la prosa suele esconder: la fila de abajo nunca se transfiere — tus datos y tus prácticas de identidad son tuyos en todos los peldaños, incluso en SaaS — y el nombre de cada modelo es simplemente la capa más alta donde empieza “Proveedor”.

¿Qué es IaaS (Infrastructure-as-a-Service)?

IaaS alquila infraestructura virtualizada — máquinas, almacenamiento en bloque, redes — por hora. Todo lo que está por encima del hipervisor es tuyo: sistema operativo, parches, runtime, lógica de escalado y el pager de las 3 a.m. Es el peldaño de máximo control y máxima superficie operativa, cubierto a fondo en la entrada de IaaS.

Cómo se ve el día dos es la prueba honesta del peldaño. En IaaS, el día dos son ventanas de parcheo del SO, upgrades de kernel, alarmas de disco lleno, auditorías de grupos de seguridad, planificación de capacidad y construir el monitoreo que todo peldaño superior incluye gratis. Nada de eso es tu producto. El peldaño se gana el puesto en exactamente tres situaciones: hardware o runtimes que ninguna plataforma ofrece, regímenes de cumplimiento que exigen control de la infraestructura, y una escala sostenida tan grande que el precio unitario bruto vence a los márgenes gestionados después de sumar el equipo que lo opera — una vara mucho más alta de lo que la mayoría de los equipos asume.

¿Qué es CaaS (Containers-as-a-Service)?

CaaS alquila la capa que la mayoría de las guías se salta: empaquetas servicios como contenedores — cualquier lenguaje, cualquier stack — y el proveedor opera el scheduler, la red entre servicios y la maquinaria de escalado, típicamente Kubernetes o un equivalente. Se ubica deliberadamente entre IaaS y PaaS: más abstracto que las máquinas, menos opinado que una plataforma. Eso lo convierte en el hogar natural de los microservicios y de los parques políglotas que chocarían con las convenciones de un PaaS.

La sutileza que separa a CaaS de un tutorial de Kubernetes hospedado: lo que se transfiere es el control plane — schedulers, etcd, API servers, salud de los nodos — mientras que todo lo expresado en imágenes y manifiestos sigue siendo tuyo: higiene de imágenes base, resource requests, liveness probes, estrategia de deployment, topología de servicios. Eso es una disciplina real, y es precisamente por eso que el peldaño existe como oferta propia: equipos que necesitan esa expresividad pero no tienen apetito por operar la maquinaria de abajo. El contenedor mismo es la historia de portabilidad — la misma imagen corre en cualquier orquestador conforme, lo que mantiene a CaaS entre los peldaños de menor lock-in de la escalera.

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

PaaS alquila una plataforma de aplicaciones gestionada: tú haces push del código, el proveedor pone el runtime, el escalado y el sistema operativo debajo. El trato es convención a cambio de ceremonia — lenguajes soportados e idiomas de la plataforma a cambio de deploy con git push. Lo crítico que PaaS no elimina: tú sigues escribiendo y poseyendo toda la aplicación de backend — auth, endpoints, validación, todo — una distinción que la entrada PaaS vs. BaaS disecciona.

El contrato PaaS moldeó una generación de buenos hábitos — apps twelve-factor, configuración en el entorno, procesos stateless, logs como streams — porque la plataforma impone lo que antes era solo un consejo. Su frontera es igual de instructiva: la plataforma ejecuta tu aplicación pero no sabe nada de lo que hay dentro, así que cada preocupación de backend — sesiones, permisos, migraciones, rate limits — sigue siendo código que tú escribes, pruebas y parcheas. Esa es la señal de que estás en el peldaño equivocado: si la mayor parte de tu código hospedado en PaaS reimplementa usuarios, CRUD y subida de archivos, estás construyendo a mano el peldaño de arriba.

¿Qué es FaaS (Functions-as-a-Service)?

FaaS alquila cómputo por evento: despliegas funciones individuales, el proveedor ejecuta cada invocación bajo demanda y escala a cero entre una y otra. Es la expresión más pura del cómputo serverless — nada corre, y nada factura, hasta que algo sucede. Los costos son arquitectónicos: cold starts, límites de ejecución y una ausencia de estado que empuja toda la persistencia a otro lado. Cómo se comparan las funciones con operar tu propia flota de servicios es la pregunta de funciones vs. microservicios.

La ausencia de estado es la restricción estructural: una función puede ser destruida después de cualquier invocación, así que todo lo durable — sesiones, archivos, colas, datos — debe vivir en servicios alrededor de la función. Llevada a su conclusión, esa restricción ensambla silenciosamente un BaaS: funciones para la lógica, servicios gestionados para todo lo que tiene estado. Por eso los dos peldaños convergieron en la práctica, y por eso existen runtimes open-source (Knative, OpenFaaS) para equipos que quieren el modelo por evento sobre su propia orquestación. El precio sigue la misma lógica con forma de evento — gratis cuando está ocioso es imbatible para tráfico con picos y castiga la carga constante, la inversión que toda factura de FaaS acaba enseñando.

¿Qué es BaaS (Backend-as-a-Service)?

BaaS alquila el backend mismo. La base de datos, la autenticación, el almacenamiento de archivos, las APIs generadas automáticamente y las notificaciones push llegan preconstruidos y gestionados, consumidos desde SDKs de cliente — para las funcionalidades estándar no hay código del lado del servidor que escribir, como demuestra el ejemplo de código de arriba. La lógica custom corre en cloud functions embebidas, y por eso las plataformas BaaS maduras contienen el peldaño FaaS en lugar de competir con él. La versión construir-vs-comprar de esta decisión tiene su propia entrada, y la cuestión del lock-in — la debilidad honesta del peldaño — depende de si la plataforma es open source o propietaria.

Lo que BaaS elimina es infraestructura y boilerplate, no ingeniería: tu modelo de datos, tus reglas de seguridad y tu lógica de negocio siguen siendo decisiones que ninguna plataforma toma por ti. La economía del peldaño es la más filosa de la escalera — minutos hasta un backend funcionando, costo inicial casi cero — y también lo es su riesgo estructural: en una plataforma propietaria, el schema de datos, la auth y las funciones viven en formato del proveedor, lo que hace de BaaS el lock-in más fuerte de los peldaños programables. La variante open-source disuelve exactamente eso: cuando la misma plataforma se puede auto-hospedar, irse significa mudarse, no reescribir. La era de la IA también amplió la audiencia del peldaño — los frontends generados necesitan backends reales rápido, y uno preconstruido y con permisos es la forma que encaja.

¿Qué es mBaaS (Mobile Backend-as-a-Service)?

mBaaS es donde empezó la categoría BaaS: un backend preconstruido dirigido específicamente a apps móviles, con notificaciones push, SDKs conscientes del dispositivo y sincronización offline como funcionalidades de primera clase y no como añadidos. Cuando las single-page apps web también se volvieron client-first, el modelo se generalizó y la m se cayó en silencio — hoy toda plataforma seria sirve web y móvil desde el mismo backend. Cuándo la distinción todavía importa — y cuándo es solo residuo histórico — es el tema de la entrada mBaaS vs. BaaS.

La m todavía se gana su letra en tres lugares. Las notificaciones push no son una llamada de API sino una relación con los gateways de plataforma (APNs, FCM) — registro de tokens, targeting de dispositivos, semántica de entrega — que una plataforma de grado mBaaS gestiona de punta a punta. La sincronización offline-first significa que el SDK es una máquina de estados, no un envoltorio HTTP delgado: persistencia local, escrituras en cola, manejo de conflictos cuando vuelve la conectividad. Y el estado por dispositivo (installations, canales, segmentos) es un modelo de datos que las apps web simplemente no tienen. Si esos tres párrafos describen tu producto, la herencia móvil de tu plataforma importa; si no, BaaS y mBaaS son la misma compra.

¿Qué es SaaS (Software-as-a-Service)?

SaaS alquila software terminado — inicia sesión y úsalo. Es el único peldaño de la escalera que consumes en lugar de construir encima, y por eso compararlo con los demás es un cambio de categoría: los primeros seis modelos responden “¿cuánto del stack de mi producto opero yo?”; SaaS responde “¿debería esto existir siquiera como producto mío?”. Tu CRM, tu correo y tu analytics son SaaS. En el momento en que una herramienta necesita tu lógica custom dentro, te caíste del peldaño SaaS y necesitas uno más abajo.

SaaS importa en esta comparación sobre todo como frontera: define cómo se ve “totalmente gestionado” cuando no queda nada por programar, que es la dirección hacia la que todos los demás peldaños llevan dos décadas subiendo. También fija el techo del pitch de los peldaños de construcción — cuanto más se acerca un BaaS a “el backend de tu producto se siente SaaS desde el día uno”, más se concentra la ingeniería restante en exactamente la parte que te diferencia. La dependencia es el precio: hoja de ruta, precios y portabilidad de datos quedan del lado del vendor, con tus datos y tu política de acceso como las únicas filas que nunca dejan de ser tuyas.

Cómo creció la escalera

El patrón a lo largo de dos décadas es unidireccional: cada modelo nuevo abstrae la capa que el anterior todavía exponía, y cada generación de equipos empieza más arriba que la anterior. Que mBaaS llegara antes que el BaaS general es la mejor trivia de la escalera — la restricción móvil (sin equipo de servidor, ciclos de release de app store) forzó primero la abstracción más alta, y el resto de la industria la alcanzó después.

La pizza, extendida a siete peldaños

La analogía clásica para enseñar esto (acuñada por el arquitecto de software Albert Barron en 2014) mapea el trío a la cena: on-prem es cocinar en casa, IaaS es la pizza para hornear, PaaS es el delivery, SaaS es salir a cenar. Los peldaños nuevos la extienden con naturalidad. CaaS es alquilar una cocina comercial con moldes estandarizados — tus recetas, empacadas a tu manera, cocinadas en su equipo. FaaS es pagar por porción — no existe pizza hasta que tienes hambre, y nunca pagas por una mesa vacía. BaaS es el kit de comida con todo prehecho salvo tu toque personal — masa, salsa y horno resueltos; tú pones el topping que hace que el restaurante sea tuyo. Y mBaaS es ese mismo kit en tamaño food truck: la restricción (móvil) moldeó el kit primero, y todos los demás lo adoptaron después.

IaaS vs. CaaS vs. PaaS vs. FaaS vs. BaaS vs. SaaS, comparados

Los pares que la gente realmente compara

IaaS vs. PaaS — “¿queremos operar máquinas o solo enviar una app?”. Elige IaaS solo cuando el control es el requisito; si no, PaaS borra la carga del-SO-hacia-arriba para la misma aplicación.

IaaS vs. CaaS — la misma pregunta una capa más arriba: ¿operar tu propia orquestación sobre máquinas alquiladas, o alquilar también la orquestación? A menos que operar el control plane sea tu especialidad, CaaS.

CaaS vs. PaaS — la unidad que entregas: contenedores (cualquier stack, tu empaquetado, control a nivel de orquestación) vs. código de aplicación (sus runtimes, sus convenciones, menos ceremonia). Los microservicios y los parques políglotas se inclinan por CaaS; una app estándar, por PaaS.

CaaS vs. FaaS — persistencia vs. eventos. Los servicios de larga vida con tráfico entre servicios pertenecen a contenedores; el trabajo esporádico con forma de evento pertenece a funciones que escalan a cero. La mayoría de los sistemas reales corre ambos.

PaaS vs. BaaS — la confusión más profunda de la escalera, con una entrada completa: PaaS hospeda el backend que todavía tienes que escribir; BaaS elimina ese paso para las funcionalidades estándar. Escribir el backend, o tenerlo.

FaaS vs. BaaS — alcance de la tercerización, diseccionado en BaaS vs. Serverless: FaaS terceriza el runtime del código que escribes; BaaS terceriza el backend para que la mayor parte de ese código nunca exista. Las plataformas BaaS maduras embeben FaaS, así que en la práctica los peldaños se combinan.

BaaS vs. mBaaS — historia vs. presente: el mismo peldaño, con origen mobile-first. Si tu producto vive del push, del offline y del estado por dispositivo, la m todavía describe tus requisitos; las plataformas convergieron de todos modos.

SaaS vs. todos los demás — el cambio de categoría: cada otro modelo es algo sobre lo que construyes; SaaS es algo sobre lo que no construyes nada. Si una carga puede ser SaaS, ese es casi siempre el peldaño suficiente más barato — solo que deja de ser tu software.

Dónde encaja “serverless”

Serverless no es un octavo peldaño — es el paraguas sobre los dos peldaños programables más altos. La definición canónica cubre tanto FaaS (tu código, ejecutado bajo demanda) como BaaS (servicios de backend preconstruidos): en ambos, nadie en tu equipo gestiona un servidor, la capacidad escala automáticamente y el costo sigue al uso. Cuando alguien dice “nos fuimos serverless”, la pregunta de escalera es qué peldaño: funciones que escribieron, un backend que no escribieron o — lo más común — la combinación.

Casos de uso comunes

• IaaS: migraciones lift-and-shift, runtimes y hardware especializados, regímenes de cumplimiento que exigen control de la infraestructura.
• CaaS: flotas de microservicios, sistemas políglotas, equipos que quieren orquestación de grado Kubernetes sin operar el control plane.
• PaaS: aplicaciones web y APIs custom donde la lógica de backend es el producto, operadas por equipos que quieren deploy sin operaciones de servidor.
• FaaS: handlers de webhooks, jobs agendados, pipelines de imágenes y datos — trabajo orientado a eventos sin un backend completo alrededor.
• BaaS: backends de app completos con necesidades estándar — usuarios, datos, archivos, notificaciones — especialmente para equipos frontend-first.
• mBaaS: lo mismo, mobile-first — productos construidos sobre push, sincronización offline y estado por dispositivo.
• SaaS: todo lo que tu empresa usa pero no construye — el peldaño que consumes en lugar de arquitectar encima.

¿Qué peldaño deberías elegir? Matriz de decisión

Dos reglas honestas se apilan encima: elige por defecto el peldaño más alto que encaje (cada paso hacia abajo recontrata trabajo operativo) y reevalúa por carga de trabajo — las empresas viven en varios peldaños a la vez, por diseño.

Limitaciones y trade-offs

• IaaS: el precio unitario te halaga; la nómina de operaciones para parchear, escalar y asegurar es la factura real.
• CaaS: tercerizaste el control plane, no la complejidad — imágenes, manifiestos, service meshes y pipelines de deployment siguen siendo una disciplina de ingeniería.
• PaaS: sigues poseyendo una aplicación entera — cada upgrade de dependencias y cada bug de auth incluidos — más las convenciones con forma de plataforma.
• FaaS: cold starts, límites de ejecución y un precio por invocación que se vuelve hostil bajo carga alta sostenida.
• BaaS / mBaaS: un techo de personalización para requisitos muy fuera del estándar, y el lock-in más fuerte de la escalera cuando es propietario — la razón por la que importan las plataformas basadas en open source: mantienen la salida real.
• SaaS: dependencia total — hoja de ruta, precios y portabilidad de datos viven en las decisiones de otro.
• Todos: la línea de responsabilidad compartida se mueve, pero nunca pasa por encima de tus datos, tu política de acceso y tu criterio.

La escalera as-a-service 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. Ocupa el peldaño BaaS — completo como mBaaS, con push y SDKs móviles de primera clase — y se cubre deliberadamente en ambas direcciones. Hacia arriba: el backend estándar viene preconstruido, así que el día uno se siente SaaS-inmediato para tu propio producto. Hacia abajo: las funciones, triggers y jobs agendados de Cloud Code te dan el peldaño FaaS dentro de la plataforma, y la misma empresa documenta el peldaño CaaS para cargas que necesitan contenedores. Y como el stack es open source, el peor modo de falla de la escalera — el lock-in en la cima — viene con un camino de bajada documentado: auto-hospedar el mismo backend en cualquier peldaño inferior, sin reescritura.