IaaS, PaaS y SaaS: diferencias con ejemplos

IaaS ofrece infraestructura virtual, PaaS una plataforma para desplegar aplicaciones y SaaS un producto listo para usar. La diferencia práctica está en qué opera el proveedor y qué conserva el cliente. Datos, accesos, configuración y salida requieren atención en los tres modelos, aunque cambie la carga técnica.

No empiece por las siglas, empiece por la tarea

Una empresa no compra capas por afición. Necesita publicar una tienda, conectar un catálogo, atender clientes o ejecutar un sistema propio. La pregunta útil es cuánto de ese trabajo conviene construir, cuánto conviene delegar y quién responderá cuando falle.

NIST define IaaS, PaaS y SaaS como modelos de servicio distintos. La clasificación ayuda a entender la capacidad entregada. No describe por sí sola cada copia, límite, integración, región o plazo de soporte del producto contratado.

Antes de elegir, anote cuatro cosas:

• qué necesita controlar el equipo;
• qué sabe operar de forma continua;
• qué datos y procesos no puede perder;
• cuánto trabajo aceptará repetir al cambiar de proveedor.

Delegar una capa no elimina la responsabilidad del negocio. Solo cambia el lugar donde hay que revisar contrato, configuración y evidencia.

Ejemplo de IaaS: una tienda que necesita su propio sistema

Imagine una tienda en línea con una aplicación existente, un conector particular y paquetes del sistema que el equipo conoce. IaaS entrega máquinas virtuales, almacenamiento y red. La empresa instala el sistema operativo, la aplicación y sus dependencias.

El proveedor opera centros de datos, hardware, red física y virtualización. El cliente administra el sistema invitado, sus parches, las aplicaciones, los accesos y las reglas de red dentro de su entorno. El modelo oficial de AWS usa esta división para explicar una instancia IaaS.

IaaS encaja cuando el control del sistema operativo resuelve una necesidad real. También sirve para trasladar una aplicación que aún no puede adaptarse a una plataforma más gestionada.

El coste oculto aparece en la operación:

• actualizaciones y endurecimiento del sistema;
• vigilancia de capacidad, registros y fallos;
• copias separadas de la máquina activa;
• restauración en una instancia nueva;
• guardias y escalado de incidentes.

Una máquina encendida no es un servicio operado. Si nadie tiene tiempo para esas tareas, el control comprado se convierte en deuda.

Ejemplo de PaaS: un equipo que quiere desplegar código

Ahora piense en el catálogo de la tienda. El equipo desarrolla una API y necesita publicar cambios con frecuencia, pero no obtiene ventaja por administrar el sistema operativo. Una PaaS ofrece una plataforma compatible para ejecutar ese código.

El proveedor suele encargarse del host, el sistema, la ejecución y parte del escalado. El cliente conserva el código, los datos, las dependencias, los secretos, los permisos y la configuración de la aplicación.

PaaS puede reducir tareas repetitivas y acortar el camino entre un cambio probado y su publicación. No garantiza que la aplicación esté bien diseñada, que el límite de la plataforma sea suficiente o que una base de datos pueda recuperarse.

La dependencia aparece en otros lugares:

• formato de despliegue y proceso de compilación;
• versiones de lenguaje admitidas;
• variables, secretos y permisos;
• base de datos, colas, archivos y eventos gestionados;
• registros, métricas y herramientas de diagnóstico.

La plataforma administra el entorno, no la lógica del negocio. Un error en precios, inventario o permisos sigue siendo problema de la empresa.

Ejemplo de SaaS: un proceso que ya existe como producto

La misma tienda necesita atención al cliente, correo de equipo o gestión documental. Crear esas aplicaciones no diferencia el negocio. SaaS entrega el producto terminado y el proveedor opera la aplicación y su plataforma.

El cliente configura usuarios, roles, datos, flujos, integraciones y reglas de conservación. La matriz oficial de Microsoft mantiene datos, identidades, usuarios y ajustes bajo responsabilidad del cliente incluso en SaaS.

SaaS encaja cuando el proceso puede adaptarse al producto sin desarrollo crítico. La introducción suele ser más directa, pero la salida depende de la calidad de la exportación y de cuánto comportamiento vive dentro de la herramienta.

Pregunte qué ocurre con:

• historial, adjuntos y relaciones entre registros;
• cuentas, grupos y permisos;
• automatizaciones y campos personalizados;
• claves y conexiones con otros sistemas;
• datos retenidos después de terminar el contrato.

Un archivo descargable no siempre reconstruye el proceso. Puede conservar filas y perder relaciones, permisos o automatizaciones.

Elija por situación, no por una clasificación universal

Los modelos no forman una escalera donde SaaS sea siempre el destino final. Cada uno compra un tipo distinto de capacidad. Una empresa puede usar los tres a la vez y cambiar de modelo según la parte del sistema.

La tabla propone un punto de partida, no un veredicto. Una PaaS puede incluir componentes con límites distintos. Un SaaS puede ofrecer extensiones que exigen mantenimiento propio. El contrato concreto manda sobre la etiqueta.

La responsabilidad compartida también existe en SaaS

Los gráficos comerciales suelen colorear cada capa como si una sola organización pudiera asumirla por completo. La práctica es más incómoda: proveedor y cliente realizan partes diferentes de una misma función.

El proveedor puede proteger la infraestructura de identidad. El cliente decide quién recibe una cuenta y cuándo se elimina. El proveedor puede cifrar almacenamiento. El cliente clasifica los datos y decide qué carga. El proveedor puede ofrecer copias. El cliente necesita saber si puede restaurar el proceso completo.

Estas responsabilidades no desaparecen al subir de IaaS a SaaS:

• propiedad y clasificación de los datos;
• altas, bajas y privilegios de usuarios;
• configuración segura de las funciones disponibles;
• protección de dispositivos que acceden al servicio;
• revisión de integraciones y credenciales;
• plan de continuidad y salida.

Pida una asignación escrita para cada tarea crítica. Debe quedar claro quién previene, quién detecta, quién responde y quién restaura. Compartida no significa indefinida.

La portabilidad se prueba con tres paquetes de salida

NIST distingue la portabilidad de datos, servicios y sistemas. Esa separación evita una promesa fácil: tener una imagen de máquina o un contenedor no mueve automáticamente red, identidades, bases de datos y operación.

Paquete de datos

Incluya datos principales, metadatos, relaciones, archivos, historial y reglas de retención. Verifique el formato, el tiempo necesario para extraerlos y el periodo durante el cual siguen disponibles al terminar el contrato.

En SaaS este paquete suele concentrar el riesgo. En PaaS e IaaS también debe contemplar bases gestionadas, discos, objetos, colas y copias.

Paquete de aplicación

Reúna código, dependencias, imágenes, procedimientos de compilación y configuración reproducible. En IaaS, documente extensiones del proveedor dentro de la máquina. En PaaS, identifique llamadas a servicios o funciones exclusivas.

Un contenedor puede aislar parte del código. No incluye por arte de magia la identidad, el almacenamiento, la red ni los servicios externos.

Paquete de operación

Documente dominios, certificados, secretos, permisos, alertas, paneles, turnos y pasos de recuperación. Sin este paquete, una aplicación puede arrancar en otro lugar y seguir sin estar lista para vender.

Haga una prueba limitada. Exporte una muestra, reconstruya un camino funcional y mida los pasos manuales. La portabilidad que nunca se ensaya es una cláusula optimista.

El coste real cambia de forma en cada modelo

IaaS muestra recursos de infraestructura, pero deja fuera de esa cifra muchas horas de sistema, vigilancia y guardia. PaaS cobra capacidad y servicios gestionados mientras reduce parte de esa operación. SaaS concentra más funciones en la suscripción, aunque puede separar usuarios, almacenamiento, módulos y soporte.

Compare estos bloques durante el mismo periodo:

• servicio principal y consumo variable;
• trabajo técnico y atención de incidentes;
• copias, restauración y pruebas;
• complementos, licencias y soporte;
• transferencia de datos y salida;
• impuestos, moneda y medio de pago aplicables.

En España una factura en euros puede simplificar el presupuesto. En México o Argentina, una tarifa denominada en dólares o euros puede variar en moneda local y depender del método de pago. El dólar también es una variable técnica cuando condiciona continuidad y capacidad de compra.

No convierta esa observación en una predicción cambiaria. Registre moneda de cobro, impuestos, comisión del medio de pago y escenario interno de variación. Después mida el coste en su caja, no en la cifra aislada de la página comercial.

Región, soporte y latencia completan la compra

El modelo de servicio no indica por sí mismo dónde se almacenan todos los datos ni desde dónde se presta soporte. Una región seleccionada puede no cubrir copias, registros, metadatos o herramientas externas.

Para una tienda que vende en Madrid, Ciudad de México o Buenos Aires, mida desde usuarios y sistemas reales. La latencia se prueba. El nombre de una región no sustituye una medición del recorrido, ni una prueba de pago, API y panel administrativo.

Al comparar AWS, Microsoft Azure o DigitalOcean, revise el producto concreto. El nombre del proveedor no confirma qué se copia, quién actualiza, en qué moneda se cobra o cuánto trabajo exige la salida.

La decisión correcta deja una tarea clara para mañana

Elija IaaS si necesita control del sistema y puede operarlo. Elija PaaS si el equipo debe concentrarse en código y acepta los límites de una plataforma. Elija SaaS si el proceso es estándar y la exportación cubre lo que el negocio necesita conservar.

Una arquitectura mixta es normal. Lo peligroso no es mezclar modelos, sino dejar una frontera sin dueño. Si el proveedor no la cubre y el equipo tampoco, la tarea aparecerá durante una caída o una migración.