Arquitectura Evolutiva en Azure: El Arte de no Sobre-diseñar

Si llevas tiempo en el mundo de la arquitectura Cloud, conoces esa sensación. Estás frente al lienzo en blanco (o un main.tf vacío) y te encuentras en ese punto crítico: la delgada línea entre sentar unas bases sólidas y caer en la trampa del sobre-diseño (over-engineering).

Recientemente, trabajando en la arquitectura base para una Prueba de Concepto (PoC) en Azure, me vi tentado a desplegar todo el arsenal que Microsoft nos ofrece. Sin embargo, recordé una máxima que a veces olvidamos: La arquitectura no es solo tecnología; es contexto y momento.

Hoy quiero compartir cómo he abordado este diseño, diferenciando entre lo que es “innegociable” desde el día 1 y lo que es “evolutivo”.

El Enfoque: Sólido pero Ligero

En los diagramas que acompañan este post, podéis ver el enfoque actual que he implementado. No es la arquitectura final de una multinacional, pero tampoco es un “Hello World” inseguro.

1. Gestión del Estado y Ciclo de Vida (Terraform)

Como se ve en el diagrama de secuencia, he optado por una estrategia de Infraestructura como Código (IaC) en capas. No todo se despliega a la vez.

• Fase de Fundación: Storage Accounts, Networking base.
• Fase de Orquestación: Identidades, Recursos compartidos (ACR, KeyVault).
• Fase de Aplicación: El despliegue “quirúrgico” de los servicios.

Esto evita el temido monolito de Terraform y reduce el radio de explosión si algo falla. Separar el ciclo de vida de la infraestructura del ciclo de vida de la aplicación es vital para mantener la agilidad.

2. Seguridad e Identidad: El Innegociable

Aquí es donde no se puede negociar. En el diagrama de jerarquía de identidades, veréis que he implementado Federación OIDC (OpenID Connect) entre GitHub Actions y Azure.

• ¿El objetivo? Eliminar los secretos rotativos (Client Secrets) que caducan o se filtran.
• Zero-Trust: Reforzamos la seguridad asignando identidades granulares. Cada servicio tiene permiso solo para lo que necesita (ej. AcrPush, Secret User), ni más, ni menos.

3. Lo que NO ves (y por qué es importante)

Si analizas el diagrama de arquitectura completo, notarás ausencias notables.

• ¿Dónde está Azure Front Door?
• ¿Por qué no hay Private Endpoints en cada servicio PaaS?
• ¿Dónde está la suite completa de Defender for Cloud?

Técnicamente, podría implementarlo todo hoy. Pero aplicar todos los patrones Enterprise en una fase de PoC o MVP es el error más común. Frena el desarrollo, dispara la complejidad cognitiva del equipo y aumenta los costes innecesariamente.

Sin embargo, el segundo error más grave es usar la excusa de la “agilidad” para crear deuda técnica permanente (ej. usar Connection Strings en texto plano o un solo Service Principal para todo).

La Lección: Innegociables vs. Evolutivos

La clave del éxito en la arquitectura Cloud moderna está en saber clasificar tus decisiones:

1. Los Innegociables (Día 1): Gestión de identidad robusta (OIDC), segregación de responsabilidades, IaC modular y control de secretos (Key Vault). Si esto falla, los cimientos se rompen.
2. Los Evolutivos (Día 2+): Capas de seguridad perimetral avanzadas (WAF, Front Door), redundancia geográfica o networking privado complejo. Estos llegarán cuando el tráfico y el riesgo de negocio lo justifiquen.

Conclusión

Las buenas arquitecturas no nacen perfectas; nacen preparadas para evolucionar.

Diseñar para el futuro no significa construirlo todo hoy, sino dejar los huecos necesarios para que, cuando llegue el momento de escalar, no tengas que demoler lo que ya has construido.

¿Y vosotros? ¿Dónde ponéis la línea roja entre una buena base y el sobre-diseño en vuestras PoCs? Os leo en los comentarios.