El caso
El Black Friday llegó antes de tiempo. Y cada servidor necesitaba un sistema entero.
En la víspera del Black Friday, Isaac necesitaba más instancias del sistema de pedidos. Levantó VMs nuevas, instaló el sistema en cada una y configuró el balanceador a mano. Cuando pasó el pico, todavía había máquinas encendidas sin ningún uso.
Los contenedores de la tienda ya estaban listos. Lo que faltaba era una forma de ejecutarlos sin cuidar cada servidor.
Este post parte de Fundamentos de la nube, de Modelos de servicio en la nube y de Contenedores: aislamiento sin máquina virtual.
El problema
Escalar contenedores sobre VMs es trabajo manual
Un contenedor resuelve el empaquetado, pero no decide dónde correr, cuántas copias mantener ni qué hacer cuando una copia falla. Si la tienda corre una VM por instancia, cada escala es un pedido nuevo, una instalación y una configuración.
Sin una capa para eso, el equipo pasa más tiempo administrando servidores que mejorando la tienda.
La solución
Servicios de contenedores
Un servicio de contenedores (Containers as a Service, o CaaS) queda entre la VM y la plataforma: tú entregas la imagen y la configuración, y el proveedor se encarga del servidor. Hay dos formas principales.
- Contenedores sin servidor (serverless containers): no eliges ni ves el servidor. El proveedor crea el entorno para cada contenedor y cobra por el tiempo de CPU y de memoria usado. Algunos escalan hasta cero cuando no hay tráfico.
- Orquestación gestionada: defines cuántas copias quieres, y un plano de control (Kubernetes) distribuye, reinicia y escala los contenedores sobre un conjunto de nodos.
Cada proveedor tiene sus nombres: Cloud Run en Google Cloud, AWS Fargate en AWS, Azure Container Apps en Azure y OCI Container Instances en Oracle Cloud.
Sin servidor
Entregas la imagen y recibes una URL. Sin máquina que elegir y sin sistema operativo que actualizar.
En la tienda: la API de pedidos arranca en segundos cuando llegan clientes, y desaparece cuando se van.
Orquestación
Kubernetes mantiene el número de copias que definiste y reemplaza las que fallan.
En la tienda: si una copia del sistema de pedidos cae, otra arranca sin que Isaac haga nada.
Escala automática
El número de copias acompaña la carga, hacia arriba y hacia abajo.
En la tienda: el Black Friday recibe copias extra, y se devuelven después del pico.
Cobro por uso
Pagas por los recursos que los contenedores consumen mientras corren.
En la tienda: las copias ociosas no generan el costo de una máquina parada.
No los confundas
Contenedores × servicios gestionados
Servicio de contenedores sin servidor
“¿Solo quiero entregar el contenedor y recibir una URL, sin administrar nada?”
- Ejemplo
- La API de pedidos de la tienda, que escala con el tráfico.
- Foco
- Menos administración. Tú controlas la imagen y la configuración.
Orquestación (Kubernetes)
“¿Necesito muchos servicios, con reglas complejas de red y de despliegue?”
- Ejemplo
- Diez servicios de la tienda, cada uno con sus réplicas y sus reglas de comunicación.
- Foco
- Más control y más complejidad. Defines la configuración de cada pieza.
Por debajo
Orquestación con Kubernetes
Kubernetes es el sistema de orquestación más usado. Describes el estado deseado, por ejemplo "tres copias de la API de pedidos, con 512 MB cada una", y él hace lo necesario para llegar ahí: elige en qué nodo corre cada copia, reinicia las que fallan y cambia las versiones poco a poco.
Los proveedores ofrecen el plano de control gestionado: Google Kubernetes Engine (GKE) en Google Cloud, Amazon EKS en AWS, Azure Kubernetes Service (AKS) en Azure y Oracle Kubernetes Engine (OKE) en Oracle Cloud. Aun así, hay que entender las piezas: copias, servicios, configuraciones y reglas de red.
Imágenes
Registro de imágenes
Toda imagen que se usa en la nube se guarda en un registro. El servidor (o el servicio) descarga la imagen de allí cuando necesita iniciar un contenedor. Cada proveedor tiene el suyo: Artifact Registry en Google Cloud, Amazon ECR en AWS, Azure Container Registry en Azure y OCI Container Registry en Oracle Cloud.
Quien controla el registro controla lo que puede correr en producción. Por eso, el acceso al registro sigue las mismas reglas de identidad y de permisos que el resto de la nube, como vimos en Seguridad y responsabilidad compartida en la nube.
En la práctica
Elegir el camino
| Situación | Elección |
|---|---|
| Una API que escala con el tráfico, sin equipo de infraestructura | Servicio de contenedores sin servidor |
| Muchos servicios que se comunican, con reglas de red propias | Orquestación gestionada |
| Carga constante y previsible, con control total de las máquinas | VMs, con contenedores dentro si hace falta |
| Una imagen que tiene que estar disponible en varias regiones | Registro con replicación entre regiones |
Términos clave
Seis términos para recordar
Toca la tarjeta para ver la definición.
Prueba rápida
Tres preguntas, estilo examen
01
El equipo quiere ejecutar una API en contenedores, sin administrar servidores ni Kubernetes. ¿Qué opción cumple eso?
02
¿Dónde se guardan las imágenes que la tienda usa en producción?
03
Un servicio de contenedores tiene muchas instancias en el Black Friday y pocas el resto del año. ¿Qué característica reduce el costo fuera del pico?
Los contenedores en la nube quitan al equipo la parte más repetitiva: elegir servidores, instalar sistemas y reaccionar a cada pico. Lo que queda es decidir el tamaño de las copias, el límite de escala y quién puede publicar imágenes. Para la tienda, eso significa levantar la API para el Black Friday sin una tarde de configuración, y liberar los recursos cuando pasa el pico.