Fundamentos de la computación en la nube
Plataforma como servicio (PaaS)
El modelo de servicio que te quita el sistema operativo y el runtime de encima, así que subes código y la plataforma lo corre, con AWS Elastic Beanstalk, Heroku y Google App Engine como los productos que lo entregan.
- Definir Plataforma como Servicio (PaaS) según el marco del NIST
- Identificar qué capas se mueven del cliente al proveedor entre IaaS y PaaS
- Contrastar el despliegue de la misma aplicación por IaaS y por PaaS
- Explicar el límite entre PaaS y el modelo serverless que cubre este curso más adelante
Qué pasa si nunca quisiste tocar el sistema operativo
La lección anterior te dejó dueño de una instancia EC2: parchando su sistema operativo, instalando un runtime, configurando un firewall. Ahora imagina a un desarrollador solo con una app web que tiene que entregar el viernes y cero interés en nada de eso. No quiere elegir una AMI, dimensionar un balanceador de carga ni leer un changelog de parches. Quiere entregar código y verlo correr. Plataforma como Servicio es el modelo construido exactamente para ese traspaso.
La definición del NIST, en la práctica
El NIST define PaaS como la capacidad de "desplegar en la infraestructura de nube aplicaciones creadas o adquiridas por el consumidor, hechas con lenguajes de programación, bibliotecas, servicios y herramientas soportadas por el proveedor". El consumidor no administra la infraestructura subyacente, incluyendo red, servidores, sistemas operativos o almacenamiento, pero sí controla la aplicación desplegada y, con frecuencia, la configuración del entorno que la aloja.
Lee esto contra la definición de IaaS de la lección anterior y el cambio es preciso: el sistema operativo, que era tuyo en IaaS, ahora pertenece al proveedor. Lo que te queda es la aplicación misma y los ajustes alrededor de cómo corre.
Quién administra qué, actualizado
| Capa | IaaS | PaaS |
|---|---|---|
| Redes, servidores, virtualización | Proveedor | Proveedor |
| Sistema operativo | Tú | Proveedor |
| Runtime y middleware | Tú | Proveedor |
| Código de la aplicación | Tú | Tú |
| Datos | Tú | Tú |
Todo el cambio está en una sola fila: el sistema operativo y el runtime cruzan la línea de "tú" a "proveedor". Esa es toda la diferencia entre los 2 modelos, y merece más atención de la que sugiere una sola fila, porque es exactamente la línea que prueba un escenario de examen.
Productos reales que entregan PaaS
- AWS Elastic Beanstalk: empaqueta instancias EC2, un balanceador de carga y auto-escalado detrás de un solo despliegue, construido sobre el IaaS de AWS por debajo, pero nunca tocas esas piezas directamente
- Heroku: corres
git push heroku main, y Heroku detecta tu lenguaje, instala dependencias y despliega, sin configuración de servidor para frameworks estándar - Google App Engine y Azure App Service: el mismo trato, subes código, la plataforma lo corre
Ejemplo trabajado: la misma app, 2 caminos
Desplegar una pequeña app web en Ruby vía EC2 significa lanzar una instancia, instalar Ruby y sus dependencias, configurar un servidor web, conectar un balanceador de carga, y montar un grupo de auto-escalado, varios pasos separados, cada uno tuyo de hacer bien y mantener parchado. Desplegar la misma app vía Heroku significa correr git push heroku main. Heroku lee el código, reconoce que necesita un runtime de Ruby, lo construye, y empieza a servir tráfico, todo desde ese único comando.
Eso no es una versión más chica del mismo trabajo. Es un trabajo distinto: dejaste de administrar infraestructura y empezaste a administrar solo tu aplicación.
El error de concepto: PaaS no es "cero decisiones de infraestructura"
Es tentador asumir que PaaS elimina por completo pensar en infraestructura. No es así. Sigues eligiendo un tamaño de dyno o instancia, sigues configurando variables de entorno, y sigues pagando por la capacidad que tienes asignada atienda tráfico o no en ese momento: un dyno de Heroku que aprovisionas sigue corriendo, y facturando, hasta que tú mismo lo reduces. Un modelo que solo cobra por el instante en que tu código realmente se ejecuta es otra idea distinta, cómputo serverless, y este curso la cubre más adelante en el tema de Arquitecturas Modernas en la Nube. PaaS reduce tu trabajo de infraestructura. No lo elimina.
El límite que viene: PaaS contra SaaS
PaaS todavía te pide escribir la aplicación. Esa es exactamente la línea que la siguiente lección borra por completo.
Dónde te deja esto
PaaS cambia parte del control que te daba IaaS por velocidad: dejas de administrar servidores y empiezas a entregar código directo a una plataforma que lo corre. La siguiente lección cubre qué pasa cuando ni siquiera el código es tuyo de escribir.