Fundamentos de la computación en la nube
IaaS vs. PaaS vs. SaaS
El reparto completo de responsabilidad en los 3 modelos de servicio lado a lado, las señales de palabras clave que identifican a cada uno en un escenario, y la trampa clásica que atrapa a quien asume que subir en la pila siempre es una mejora.
- Comparar el reparto completo de responsabilidad entre IaaS, PaaS y SaaS, capa por capa
- Aplicar señales de palabras clave para identificar el modelo de servicio correcto en un escenario
- Explicar por qué subir en la pila cambia control por comodidad, en vez de simplemente mejorar
- Evaluar un escenario contra sus restricciones para elegir el modelo de servicio que encaja
Nombrarlos es fácil. Distinguirlos es la habilidad real
Ya puedes definir IaaS, PaaS y SaaS por separado. Eso, por sí solo, no es una habilidad útil: casi nadie te presenta un servicio y te pregunta "¿qué es esto?" de forma aislada. Lo que realmente se prueba, en un examen y en el trabajo, es un escenario con restricciones, un equipo, una fecha límite, un requisito de cumplimiento, y la pregunta de cuál de los 3 modelos encaja. Ahí es donde esta lección invierte su esfuerzo.
La pila completa, lado a lado
| Capa | IaaS | PaaS | SaaS |
|---|---|---|---|
| Redes, servidores, virtualización | Proveedor | Proveedor | Proveedor |
| Sistema operativo | Tú | Proveedor | Proveedor |
| Runtime y middleware | Tú | Proveedor | Proveedor |
| Código de la aplicación | Tú | Tú | Proveedor |
| Datos y tu propia configuración | Tú | Tú | Tú |
Lee la tabla por columna en vez de por fila y el patrón es evidente: cada paso de IaaS a SaaS mueve exactamente una capa más de "tú" a "proveedor". Los datos y tu propia configuración son la única fila que nunca se mueve, sin importar qué modelo elijas.
La trampa: esto es un tradeoff, no un ranking
Es tentador leer esa tabla de izquierda a derecha y concluir que SaaS es simplemente el mejor modelo, porque el proveedor hace más trabajo. Esa conclusión está mal, y es exactamente la trampa que arma una pregunta de examen. Lo que SaaS gana en comodidad, lo gasta en control. No puedes instalar una biblioteca personalizada en los servidores de Gmail, correr tu propio código en la infraestructura de Salesforce, ni elegir una versión distinta de kernel para Microsoft 365. IaaS te devuelve todo ese control, a cambio de que tú administres el sistema operativo, el runtime y la aplicación. Ningún extremo de la tabla es "mejor". Cada uno encaja con un conjunto distinto de restricciones.
Señales de palabras clave para escenarios
Los escenarios de examen casi nunca dicen "IaaS" o "PaaS" directamente. Describen una restricción, y la restricción apunta al modelo.
| El escenario dice... | Apunta a |
|---|---|
| "Control total del sistema operativo", "versión específica del kernel", "acceso root" | IaaS |
| "Solo despliega el código", "sin administrar servidores", "enfócate en la aplicación" | PaaS |
| "Sin instalación", "úsalo tal cual sale de la caja", "sin desarrolladores en el equipo" | SaaS |
Ejemplo trabajado: 2 escenarios, 2 respuestas
Un equipo de ventas de 12 personas necesita un CRM funcionando la próxima semana y no tiene desarrolladores para construir uno. Nada en este escenario menciona código, infraestructura, ni personalización más allá de la configuración. Esa ausencia es la señal: es un escenario SaaS, y una herramienta como Salesforce es el encaje, no algo que el equipo construya desde cero.
Ahora cambia la restricción. Una empresa fintech opera bajo una regulación que la obliga a controlar el nivel exacto de parche del sistema operativo en cada servidor, hasta la versión del kernel, y a aplicar los parches de seguridad en su propio calendario en vez del de un proveedor. PaaS y SaaS le quitan al cliente el sistema operativo de las manos, justo el control que esta regulación exige. Ese único requisito descarta ambos, y deja a IaaS como el único modelo que encaja.
La misma pregunta de fondo en los 2 casos: qué tan arriba de la pila exige llegar este escenario. La respuesta del equipo de ventas es "para nada". La respuesta de la fintech es "hasta el kernel".
La conexión con la responsabilidad compartida
Este mismo reparto capa por capa es la base del modelo de responsabilidad compartida, cubierto por completo en el dominio de Seguridad y Confiabilidad de este curso. Lo que aprendiste aquí, qué capa te pertenece a ti y cuál al proveedor, es exactamente la pregunta que ese modelo responde para la seguridad en específico. No estás aprendiendo una idea nueva ahí. Estás aplicando esta misma a una pregunta nueva.
Dónde te deja esto
Una sola pregunta separa a estos 3 modelos en cualquier escenario: qué tan arriba de la pila exige llegar la situación. El acceso root y el control del kernel te jalan hacia IaaS. Un enfoque en entregar código sin administrar servidores te jala hacia PaaS. La falta de instalación y de desarrolladores propios te jala hacia SaaS. El siguiente tema de este dominio deja atrás los modelos de servicio y pasa a los bloques con los que se construye cualquiera de ellos: regiones, cómputo, almacenamiento, bases de datos y redes.