Diseñar una arquitectura cloud basada en contenedores cambia las reglas del juego cuando tu aplicación necesita escalar a miles de usuarios. Aquí verás cómo evoluciona la arquitectura de Platzi Wallet hacia un orquestador de contenedores con Kubernetes, y qué retos aparecen cuando entran en juego los microservicios.

Cómo se estructura una arquitectura cloud basada en contenedores

La base sigue siendo la misma: usuarios, una capa de DNS con el dominio (en este caso platziwallet.com), una capa de CDN combinada con un WAF para seguridad, una API Gateway con autenticación y autorización, y un balanceador de aplicaciones [02:00]. Lo que cambia es lo que pasa después del balanceador.

El backend ya no corre en servidores tradicionales ni en serverless puro. Ahora vive dentro de un orquestador de contenedores, y aquí es donde entra Kubernetes, una de las aplicaciones estrella de la Cloud Native Computing Foundation [03:14]. Kubernetes se encarga de coordinar todos los contenedores que ejecutan los microservicios.

¿Qué es Kubernetes en una arquitectura cloud? Es un orquestador de contenedores open source que automatiza el despliegue, escalado y gestión de aplicaciones contenerizadas dentro de un clúster.

Qué microservicios viven dentro del clúster

Dentro de cada servidor del clúster corren contenedores pequeños, cada uno con un microservicio específico. En Platzi Wallet se identifican cinco [04:30]:

• Pagos, para procesar transacciones de salida hacia comercios.
• Cobros, para gestionar solicitudes de pago.
• Saldo, para consultar el dinero disponible.
• Cash in, equivalente a consignación o ingreso de dinero.
• Cash out, equivalente a retiro de dinero.

Cada microservicio se replica en al menos dos zonas de disponibilidad porque la alta disponibilidad no es negociable en este tipo de arquitectura.

Por qué la escalabilidad en contenedores tiene dos dimensiones

Cuando tu servicio de contenedores está basado en servidores y no es serverless, debes pensar el autoescalado en dos niveles distintos al mismo tiempo. Y aquí viene lo interesante.

El primer nivel es la escalabilidad del servidor: si pasas de un usuario a 100 000 usuarios, el clúster debe crear nuevos servidores para soportar la carga [06:20]. El segundo nivel es la escalabilidad por microservicio, que funciona con una lógica completamente distinta.

Cómo funciona la concurrencia distinta entre microservicios

Piensa en este ejemplo concreto: un usuario hace cash in una sola vez por $100, pero con ese dinero realiza 25 pagos a Netflix, Amazon, Xbox y Uber [07:10]. La conclusión es directa: el microservicio de pagos tiene 25 veces más concurrencia que el de cash in en ese flujo.

Eso significa que no puedes escalar todos los microservicios por igual. Cada uno necesita reglas propias según su patrón de uso real.

¿Qué es una estrategia de placement en Kubernetes? Es la regla que define en qué servidor del clúster nace un nuevo contenedor cuando el sistema autoescala, por ejemplo en el servidor con menos RAM disponible o en otra zona de disponibilidad.

Cómo decides dónde nace un nuevo contenedor al escalar

Los cloud providers ofrecen estrategias de placement para determinar dónde se crea cada réplica nueva. Una opción común es lanzar el próximo contenedor en el servidor con menos RAM disponible, para aprovechar al máximo los recursos del clúster [08:40].

Pero esa regla tiene un costo. Si el microservicio de cobros sigue creciendo y siempre nace en el servidor más cargado de la misma zona, terminas con tres réplicas de cobros en una zona de disponibilidad y solo una en la otra. La alta disponibilidad se rompe.

La solución es combinar reglas: una basada en consumo de memoria y otra que fuerce el balanceo entre zonas. Así mantienes el aprovechamiento de recursos sin sacrificar disponibilidad.

Qué cambia con un servicio de contenedores serverless

Existe una alternativa donde el cloud provider se encarga de los servidores por ti. Tú solo te preocupas por el microservicio: cómo escala, cómo se despliega, qué hace [10:30]. No tienes que instalar agentes, ni dimensionar máquinas, ni pelear con el sistema operativo.

Esta opción serverless para contenedores libera el foco hacia lo que realmente aporta valor: el código del microservicio. Si quieres profundizar después en las diferencias técnicas de declaración de servicios, vale la pena, pero el enfoque conceptual es ese.

Qué piezas adicionales debes configurar siempre

Independientemente de si eliges contenedores con servidor o serverless, hay componentes que no puedes saltarte:

• Estrategia de CI/CD para automatizar el despliegue de cada microservicio.
• Repositorio de código con versionamiento de imágenes.
• Pruebas automatizadas sobre la imagen del contenedor antes de promoverla.
• Capa de base de datos y capas de almacenamiento conectadas al clúster.
• Decisión sobre el storage: si usas el del servidor o uno externo y persistente.

¿Qué es CI/CD en arquitecturas con contenedores? Es la práctica de integración y entrega continua que automatiza la construcción, prueba y despliegue de imágenes de contenedor desde el repositorio hasta el clúster de producción.

Ahora te toca a ti pensar tu propia arquitectura: qué orquestador vas a usar, qué microservicios vas a definir, cómo los vas a distribuir entre zonas y cómo vas a montar tu pipeline de CI/CD. Cuéntame en los comentarios qué microservicios identificaste para tu aplicación y qué estrategia de placement te hace más sentido.