Una aplicación cloud-native no es simplemente una aplicación que se ejecuta en la nube: es una aplicación diseñada para aprovechar la nube, es decir, pensada desde el principio para escalar horizontalmente, tolerar fallos, desplegarse de forma frecuente y automatizada, y ejecutarse en entornos dinámicos (contenedores, orquestadores, plataformas gestionadas). Para lograrlo, la comunidad ha consolidado una serie de patrones y principios probados que evitan reinventar la rueda y los errores típicos. Esta lección recoge los más importantes: la metodología de los 12 factores, los patrones de contenedores sidecar y ambassador, el patrón de migración strangler fig, el auto-escalado y la configuración externalizada. Dominarlos te permite diseñar sistemas resilientes, portables y operables, que son justo las cualidades que la nube premia.

1. La metodología de los 12 factores (resumen).
2. Patrón Sidecar.
3. Patrón Ambassador.
4. Patrón Strangler Fig (estrangulador).
5. Auto-escalado (horizontal y vertical).
6. Configuración externalizada.
7. Errores comunes y consejos.
8. Ejercicios y soluciones.

The Twelve-Factor App es un conjunto de buenas prácticas para construir aplicaciones SaaS portables y escalables. Aquí un resumen agrupado:

Los tres que más impacto tienen en arquitectura cloud-native: (3) configuración en el entorno (lo veremos en detalle), (6) procesos sin estado (permite escalar y reemplazar instancias libremente) y (9) desechabilidad (las instancias deben poder morir y nacer sin drama, base de la resiliencia y el auto-escalado).

El patrón sidecar (literalmente, el "sidecar" de una motocicleta) consiste en desplegar un contenedor auxiliar junto al contenedor principal de la aplicación, en el mismo Pod, compartiendo ciclo de vida, red y volúmenes. El sidecar añade funcionalidad transversal (logging, proxy, seguridad, sincronización) sin modificar la aplicación principal.

Explicación: el Pod tiene dos contenedores. aplicacion escribe sus logs en /var/log/app. El sidecar log-shipper (Fluent Bit) lee de ese mismo volumen compartido (emptyDir) y los envía a un sistema central. La aplicación no sabe nada de cómo se exportan sus logs: esa responsabilidad transversal vive en el sidecar. Es la base de las service meshes como Istio, donde un sidecar proxy gestiona toda la comunicación de red.

El patrón ambassador (embajador) es un tipo especial de sidecar que actúa como proxy de salida: la aplicación habla con el embajador como si fuera el servicio remoto, y el embajador se encarga de los detalles de la conexión externa (reintentos, circuit breaker, cifrado TLS, sharding, monitorización). Así, la aplicación se simplifica y la lógica de red se centraliza.

Explicación del diagrama: la aplicación se conecta siempre a localhost (al embajador), ignorando dónde está realmente el servicio remoto. El embajador resuelve la conexión real, añade reintentos, cifrado y enrutamiento. Diferencia clave con el sidecar genérico: el sidecar suele añadir funciones que acompañan a la app (logging, métricas); el ambassador se especializa en gestionar las conexiones salientes hacia servicios externos.

El patrón strangler fig (higuera estranguladora, por la planta que envuelve y reemplaza al árbol que la sostiene) es la estrategia recomendada para migrar un sistema monolítico legado a microservicios de forma incremental, sin reescribirlo todo de golpe (lo que sería arriesgadísimo). La idea: colocas un proxy/enrutador delante del monolito y vas redirigiendo funcionalidades, una a una, hacia nuevos servicios, hasta que el monolito queda vacío y se retira.

Explicación: el router recibe todo el tráfico. La funcionalidad de "pagos" ya se ha extraído a un microservicio nuevo, así que el router envía /pagos al microservicio y todo lo demás sigue yendo al monolito. Con el tiempo, más rutas migran al lado nuevo hasta vaciar el monolito. Ventaja: migras con riesgo controlado, pudiendo revertir cada paso, y entregas valor de forma continua en lugar de en una arriesgada migración "big bang".

El auto-escalado ajusta automáticamente la capacidad según la demanda. Hay dos dimensiones:

En Kubernetes, el Horizontal Pod Autoscaler (HPA) ajusta el número de Pods según métricas:

Explicación: el HPA vigila el Deployment miapp-deployment. Mantiene entre 2 y 10 réplicas y su objetivo es que el uso medio de CPU ronde el 70%. Si la CPU sube por encima, crea más Pods; si baja, los reduce (sin bajar de 2). Para que esto funcione, la aplicación debe ser sin estado (factor 6 y 9 de los 12 factores): cualquier réplica debe poder atender cualquier petición.

El factor 3 de los 12 factores dice: la configuración no va en el código. Las credenciales, URLs y parámetros que cambian entre entornos (desarrollo, pruebas, producción) deben inyectarse desde fuera, normalmente como variables de entorno o ficheros montados. Así, la misma imagen inmutable se promociona entre entornos cambiando solo la configuración, y no hay secretos hardcodeados en el repositorio.

En Kubernetes esto se hace con ConfigMap (configuración no sensible) y Secret (datos sensibles):

Explicación: el ConfigMap guarda parámetros no sensibles (LOG_LEVEL, feature flags). En el Deployment, envFrom.configMapRef inyecta todas sus claves como variables de entorno del contenedor. La contraseña de base de datos se obtiene de un Secret mediante secretKeyRef, de modo que no aparece en texto plano en el manifiesto de despliegue. La imagen miapp:1.0 no cambia entre entornos; solo cambian el ConfigMap y el Secret. Recuerda que los Secret de Kubernetes están solo codificados en base64 por defecto: para datos verdaderamente sensibles, conviene un gestor de secretos dedicado y validar el enfoque con el equipo de seguridad.

• Guardar estado en la instancia. Sesiones o ficheros en memoria local rompen el escalado horizontal: usa almacenamiento externo (BD, caché, almacenamiento de objetos). Es el factor 6.
• Configuración hardcodeada o secretos en el repositorio. Externaliza siempre la configuración. Un secreto subido a Git es un incidente de seguridad.
• Migración big bang. Reescribir un monolito de cero suele acabar mal. Usa el patrón strangler para migrar de forma incremental y reversible.
• Auto-escalar una app con estado. Si la app no es stateless, añadir réplicas no resuelve la carga y puede corromper datos.
• Abusar de sidecars. Cada sidecar consume recursos en el Pod; añádelos cuando aporten valor transversal claro, no por moda.
• No diseñar para la desechabilidad. Implementa apagado elegante (atender el SIGTERM, cerrar conexiones) para que el escalado y los despliegues no corten peticiones a medias.

1. ¿Por qué el principio "procesos sin estado" (factor 6) es un requisito previo para que el auto-escalado horizontal funcione bien?
2. Tu equipo debe modernizar un gran monolito de seguros sin poder parar el servicio. Describe cómo aplicarías el patrón strangler fig en los primeros pasos.
3. Diferencia con un ejemplo el patrón sidecar del patrón ambassador.

1. Porque al escalar horizontalmente el tráfico se reparte entre muchas réplicas intercambiables, y cualquier petición puede caer en cualquier réplica. Si una réplica guardara estado local (la sesión del usuario, datos en memoria), las siguientes peticiones del mismo usuario podrían ir a otra réplica que no tiene ese estado, provocando errores. Con procesos sin estado, todas las réplicas son equivalentes y se pueden añadir, quitar o reemplazar libremente.
2. Pasos iniciales: (1) colocar un router/fachada delante del monolito que reciba todo el tráfico sin cambiar el comportamiento; (2) elegir una funcionalidad acotada y de bajo riesgo (por ejemplo, consulta de un catálogo) y extraerla a un nuevo servicio; (3) configurar el router para que esa ruta vaya al servicio nuevo y el resto siga en el monolito; (4) verificar, medir y, si todo va bien, repetir con la siguiente funcionalidad. Cada paso es reversible.
3. Sidecar: contenedor auxiliar que acompaña a la app aportando una función transversal; ejemplo, un log-shipper que recoge y envía los logs de la aplicación. Ambassador: sidecar especializado que actúa de proxy de salida hacia servicios externos; ejemplo, un proxy al que la app se conecta por localhost y que gestiona reintentos y TLS contra una base de datos remota.

Has recorrido los patrones que definen una arquitectura cloud-native: la disciplina de los 12 factores (sin estado, configuración externa, desechabilidad), los sidecars y ambassadors para añadir capacidades sin tocar la app, el strangler fig para migrar monolitos con seguridad, el auto-escalado para adaptarse a la demanda y la configuración externalizada con ConfigMaps y Secrets. Todos comparten un objetivo: aplicaciones resilientes, portables y operables. En la última lección del módulo veremos cómo crear y gestionar toda esta infraestructura de forma reproducible y versionada con la Infraestructura como Código (IaC).