El caso
Dos días de pico, once meses de ociosidad. El servidor del Día del Padre quedó parado el resto del año.
La cervecería artesanal de un amigo de Isaac vende casi todo por el sitio. Durante el año, son pocos pedidos por día. En la semana del Día del Padre, el tráfico llega a decenas de veces lo normal, y el sitio se cae la primera noche.
Para no caerse, la cervecería alquiló un servidor grande. Cuesta todo el año, y la mayor parte del tiempo no atiende a nadie.
Este post parte de Modelos de servicio en la nube: IaaS, PaaS, SaaS y FaaS, de Contenedores en la nube y de Compute Engine: máquinas virtuales en Google Cloud. Allí, el servidor todavía era tuyo para administrar. Aquí, la pregunta es quién tiene que estar encendido cuando nadie usa el sitio.
El problema
Pagar la capacidad del pico todo el año
Con una máquina virtual, la capacidad se compra por hora, encendida o no. Para aguantar el pico, la cervecería necesita un servidor que dé abasto en la semana del Día del Padre. El resto del año, ese servidor espera un tráfico que no llega.
- Si el servidor es pequeño, el sitio se cae en el pico, justo cuando más se vende.
- Si el servidor es grande, la factura se mantiene alta la mayor parte del tiempo.
- Si alguien tiene que ajustar la capacidad en cada campaña, el trabajo vuelve al equipo.
La solución
Serverless: pagar por lo que corre
Serverless no significa que no haya servidores. Significa que tú no administras los servidores, y que el proveedor crea y cierra las instancias según la demanda. Una comparación posible: es como alquilar una sala de coworking por hora. No tienes el edificio, no haces mantenimiento y pagas por el tiempo en que la sala es tuya.
Dos comportamientos definen el modelo:
- Escalar a cero: sin solicitudes por un tiempo, el servicio se queda sin instancias.
- Cobro por uso: el costo acompaña lo que se procesó, no la capacidad encendida.
Tres caminos
Cloud Run, App Engine y Cloud Run functions
Cloud Run
Ejecuta cualquier contenedor que responda solicitudes HTTP, en cualquier lenguaje.
En la cervecería: el sitio entero empaquetado en un contenedor, que arranca cuando alguien entra.
App Engine
Plataforma para aplicaciones web, con versiones y división del tráfico entre ellas. La versión estándar escala a cero; la flexible no.
En la cervecería: la versión anterior del sitio sigue activa mientras la nueva recibe el 10% de las visitas.
Cloud Run functions
Una función que se ejecuta cuando ocurre un evento, como un archivo nuevo o un mensaje.
En la cervecería: la función que envía el correo de confirmación cuando un pedido se paga.
No confundas
Cloud Run × Cloud Run functions
Cloud Run
“¿Una aplicación completa, o una función?”
- Ejemplo
- El sitio de la cervecería, con catálogo, carrito y panel de administración, en un solo contenedor.
- Foco
- Cualquier contenedor que atienda solicitudes HTTP. Eliges el lenguaje y las bibliotecas.
Cloud Run functions
“¿Qué evento dispara el código?”
- Ejemplo
- Un pedido pagado: la función se ejecuta, envía el correo y termina.
- Foco
- Una función pequeña, disparada por un evento. Solo escribes el código de la función.
Por debajo
Solicitud, instancia y cobro
Cuando llega la primera solicitud, Cloud Run crea una instancia del contenedor. Una instancia puede atender varias solicitudes al mismo tiempo, y cuando sube el tráfico, el servicio crea más instancias. Cuando el tráfico se acaba, las instancias ociosas se apagan después de un tiempo.
Por defecto, Cloud Run cobra solo mientras procesa solicitudes. Este modelo tiene un costo: cuando el servicio estaba en cero instancias, la primera solicitud puede tardar más, porque hay que crear una instancia. Esa demora se llama arranque en frío (cold start), y es el precio de escalar a cero.
En la práctica
Qué camino para cada parte de la cervecería
| Parte del sistema | Servicio | Por qué |
|---|---|---|
| Sitio de ventas, con picos de campaña | Cloud Run | Contenedor HTTP que escala según el tráfico |
| Función que envía el correo de pedido pagado | Cloud Run functions | Se ejecuta cuando ocurre el evento, y termina |
| Panel interno con pocos accesos por día | App Engine (estándar) | Plataforma simple, que escala a cero |
| Base de datos de los pedidos | Cloud SQL | No es serverless: necesita datos siempre disponibles |
Términos clave
Cinco términos para fijar
Toca la tarjeta para ver la definición.
Prueba rápida
Tres preguntas, estilo examen
01
Una API de pedidos recibe mucho tráfico una hora por día y casi nada de madrugada. ¿Qué característica del serverless ayuda más?
02
Un equipo quiere poner en línea una aplicación en contenedor, en cualquier lenguaje, que atiende solicitudes HTTP. ¿Qué servicio conviene más?
03
¿Qué afirmación sobre serverless es falsa?
La cervecería no necesitaba un servidor para el Día del Padre. Necesitaba un sitio que exista cuando alguien entra y desaparezca cuando nadie entra. Ese es el sentido del serverless, y el próximo paso del recorrido es Kubernetes y GKE, para cuando el contenedor necesita más control sobre la infraestructura.