Diseñar una arquitectura cloud native real implica conectar capas de red, seguridad, cómputo y almacenamiento en un solo flujo coherente. Aquí vas a ver, paso a paso, cómo se construye la arquitectura de Platzi Wallet, una aplicación de ejemplo pensada para alta disponibilidad, escalabilidad y seguridad desde el primer request del usuario hasta la base de datos. Es la guía ideal si estás empezando a unir conceptos como zonas de disponibilidad, CDN, WAF, Kubernetes y nube híbrida.

¿Qué capas tiene una arquitectura cloud native?

Una aplicación cloud native bien diseñada se organiza en capas que cumplen funciones específicas. Cada capa resuelve un problema: disponibilidad, conectividad, exposición controlada o seguridad.

Para Platzi Wallet, partimos de una premisa clara: la app debe ser altamente disponible. Por eso usamos dos availability zones (AZ), término que escucharás constantemente en cualquier nube pública [00:54].

¿Qué es una availability zone (AZ)? Es un centro de datos lógicamente independiente dentro de una región del cloud provider. Usar dos o más AZ permite que tu aplicación siga funcionando si una falla.

¿Por qué necesitas una capa de conectividad?

La capa de networking conecta tu nube con el mundo exterior, incluyendo tu on-premise. Aunque tu app haya nacido nativamente en la nube, casi siempre vas a necesitar consumir datos que viven en infraestructura propia de la empresa.

En Platzi Wallet existe una conexión dedicada con el on-premise porque hay datos que solo viven ahí. Esa conexión puede resolverse con dos opciones:

• Una VPN sobre Internet.
• Una conexión dedicada que ofrece el mismo cloud provider.

Esto convierte la arquitectura en nube híbrida: on-premise más nube privada más nube pública trabajando juntos [02:32].

¿Cómo se separan la zona pública y la zona privada?

Dentro de la nube tenemos dos zonas con propósitos opuestos. La zona privada aloja el backend, los contenedores y las funciones que nunca deben ser accesibles desde Internet. La zona pública expone los servicios que sí reciben tráfico directo de los usuarios y luego se comunican hacia adentro.

Esta separación no es opcional, es la base de la seguridad por diseño en cualquier app moderna.

¿Qué servicios viven en la zona pública?

La zona pública es la puerta de entrada. Aquí se resuelve cómo te encuentran los usuarios, cómo aceleras la entrega de contenido y cómo proteges la aplicación antes de que el tráfico toque tu backend.

¿Qué hace el DNS y el CDN en cloud native?

El DNS traduce nombres de dominio a direcciones IP, pero también te permite crear reglas de enrutamiento avanzadas. Por ejemplo, en Platzi Wallet podrías configurar que platziwallet.com apunte a un clúster y pagos.platziwallet.com a otro distinto. Todo se decide a nivel de subdominio [03:55].

El CDN (content delivery network) expone tu servicio de forma global usando edge locations, que son data centers pequeños distribuidos por el mundo. Si estás en Colombia usando Platzi Wallet, el contenido te llegará desde la edge location más cercana, quizá en Bogotá o Lima, mejorando dramáticamente la experiencia.

¿Qué es una edge location? Es un punto de presencia del cloud provider distribuido geográficamente, donde se cachea contenido estático o dinámico para que los usuarios lo reciban con menor latencia.

¿Para qué sirve un Web Application Firewall?

Un WAF (Web Application Firewall) corre en paralelo al CDN y agrega reglas de seguridad a nivel de aplicación. Junto con un certificado de seguridad, protege contra los ataques más comunes:

• Denegación de servicio (DoS).
• SQL injection.
• Ataques de scripting.

La regla es simple: siempre que despliegues una aplicación, debe tener un WAF delante. Es tu seguridad en la capa siete [05:36].

¿Cómo se conecta el frontend con el backend?

Después del CDN y el WAF, el tráfico legítimo entra al API Gateway, que recibe las peticiones REST y las enruta hacia un application load balancer. Ese balanceador distribuye la carga entre las instancias del backend, aprovechando precisamente la configuración Multi-AZ que definimos al inicio.

Detrás del balanceador corre el corazón de la app: un clúster de Kubernetes, uno de los proyectos estrella de la Cloud Native Computing Foundation.

¿Qué microservicios corren dentro de Kubernetes?

En el clúster de Platzi Wallet conviven microservicios independientes, cada uno con su propia responsabilidad:

• Pagos.
• Cobros.
• Recargas.
• Pago de servicios como Netflix.
• Login y biometría.

Estos microservicios necesitan persistencia, y ahí entra la capa de almacenamiento, que puede ser por objetos, por bloques o por archivos según el caso de uso.

¿Cómo se automatiza el despliegue del backend?

Para mover código a producción de forma segura y repetible, usamos un pipeline de CI/CD con Argo CD y empaquetamos los servicios con Helm charts. Esto te permite versionar la infraestructura como código y automatizar el despliegue de cada contenedor [07:08].

¿Qué son los Helm charts? Son plantillas reutilizables que definen cómo desplegar una aplicación en Kubernetes, incluyendo configuraciones, dependencias y variables de entorno.

¿Cómo empezar a pensar tu propia arquitectura cloud native?

La arquitectura de Platzi Wallet une zona pública, zona privada, zona de conectividad, DNS, CDN, WAF, API Gateway, Kubernetes y almacenamiento, todo sostenido sobre dos AZ y una conexión híbrida. Cada pieza resuelve un problema concreto, y juntas habilitan que la aplicación sea resiliente, segura y rápida.

Ahora piensa en tu caso. Si tienes una aplicación en mente, o trabajas en una empresa con sistemas existentes, hazte estas preguntas:

• ¿Cuántas zonas de disponibilidad necesitas, dos o tres?
• ¿Vas a tener conexión híbrida con on-premise o todo vivirá en la nube?
• ¿Usarás Kubernetes, otro orquestador o funciones serverless?

De ahora en adelante, piensa cloud native desde el primer diagrama. ¿Qué capa de esta arquitectura te genera más dudas? Cuéntamelo en los comentarios.