Construyendo Azure que sobrevive al mundo real — con Mike Martin [MVP]

La arquitectura de Azure parece sencilla cuando todo funciona. La verdadera prueba llega cuando fallan las dependencias, las regiones dejan de estar disponibles, el tráfico se dispara, las suposiciones resultan erróneas, los requisitos cambian y alguien acaba haciendo la pregunta incómoda: ¿por qué diseñamos esto así desde el principio?

En este episodio de M365.FM, Mirko Peters conversa con Mike Martin [MVP] sobre cómo es la arquitectura de Azure cuando tiene que sobrevivir a condiciones reales de producción y no solo verse bien en un diagrama.

Mike aporta décadas de experiencia en desarrollo, infraestructura, arquitectura, liderazgo, coaching, formación y Microsoft Azure. Una de sus observaciones más sólidas es que muchos de los problemas a los que se enfrentan hoy los arquitectos no son realmente nuevos. El DNS sigue fallando. Las dependencias de IP siguen importando. Los costes siguen siendo un problema. Las integraciones siguen fallando. Las dependencias siguen desapareciendo en el peor momento posible.

Lo que ha cambiado es el nivel de complejidad que construimos alrededor de esos problemas.

DE VISUAL BASIC A LA ARQUITECTURA MODERNA DE AZURE
Mike repasa casi tres décadas en IT, desde sus inicios como desarrollador de Visual Basic en los años noventa, pasando por sistemas distribuidos, redes, software empresarial e infraestructura, hasta llegar a Azure.

Su observación clave es sencilla: el sector sigue resolviendo muchos de los mismos problemas fundamentales, pero las arquitecturas que los rodean se han vuelto mucho más complejas.

Los sistemas modernos han pasado de las aplicaciones cliente-servidor a arquitecturas distribuidas, plataformas en la nube, contenedores, microservicios, Kubernetes, entornos híbridos y, ahora, desarrollo asistido por IA.

Eso genera posibilidades enormes, pero también un nuevo riesgo: la sobreingeniería.

Mike sostiene que muchos equipos actuales complican innecesariamente problemas sencillos. Una buena arquitectura no consiste a menudo en añadir más tecnología, sino en saber qué no añadir.

¿QUÉ HACE REALMENTE UN ARQUITECTO DE AZURE?
Para Mike, la arquitectura no consiste en elegir el mayor número de servicios de Azure ni en producir un diagrama impresionante.

Se trata de entender qué componentes deben ir juntos, cuáles conviene evitar, cuáles son necesarios y cómo construir algo que siga siendo mantenible, escalable, seguro y resiliente.

La arquitectura incluye mucho más que el cómputo:

• Identidad
• Redes
• Flujos de datos
• Seguridad
• Monitorización
• Integración
• Dependencias
• Escalabilidad
• Operaciones
• Recuperación
• Despliegue
• Coste

Mike también cuestiona la idea de que cloud-native signifique automáticamente Kubernetes o contenedores. Azure ofrece muchos servicios gestionados y nativos que pueden resolver problemas sin introducir una sobrecarga operativa innecesaria.

El papel del arquitecto es comprender la solución completa y elegir la arquitectura más sencilla que aún satisfaga los requisitos reales.

EMPEZAR POR LOS REQUISITOS DE NEGOCIO, NO POR LOS SERVICIOS DE AZURE
Una de las lecciones más importantes de este episodio es simple: no empieces por la tecnología.

Antes de decidir entre Azure Kubernetes Service, App Service, Azure Functions, contenedores, Service Bus u otra plataforma, los equipos deberían entender primero qué tiene que hacer realmente la solución.

Preguntas que conviene plantear:

• ¿Es interna o orientada al cliente?
• ¿Cuántos usuarios dependerán de ella?
• ¿Necesita escalar globalmente?
• ¿Cuánto tiempo puede estar no disponible?
• ¿Cuántos datos puede permitirse perder el negocio?
• ¿Qué requisitos de cumplimiento normativo aplican?
• ¿Qué ocurre si la aplicación desaparece durante varias horas?
• ¿Quién se ve afectado?
• ¿Qué nivel de soporte operativo se necesita?

Estas preguntas conducen directamente a conceptos como los SLA, los SLO, los RTO y los RPO. También determinan si la arquitectura debe ser de una sola región, multirregión, activo-activo, activo-pasivo o algo mucho más sencillo.

RTO Y RPO SIN TECNICISMOS
El RTO y el RPO suelen debatirse como siglas técnicas, pero su significado real es empresarial.

• RTO (Recovery Time Objective): ¿con qué rapidez debe volver a funcionar el sistema tras un fallo?
• RPO (Recovery Point Objective): ¿cuánta pérdida de datos es aceptable?

Un sistema usado para una monitorización no crítica puede tolerar varias horas de caída o de datos perdidos. Un sistema que da soporte a primeros intervinientes, a operaciones financieras, al comercio o a infraestructuras críticas puede requerir una recuperación en minutos.

El punto importante es que estas cifras no deberían inventarlas los arquitectos. Deben derivarse del impacto real que tendría un fallo para el negocio.

Una vez comprendidos esos requisitos, pueden traducirse en decisiones de diseño técnico.

LA RESILIENCIA NO ES LO MISMO QUE ALTA DISPONIBILIDAD
Mike utiliza una analogía sencilla para explicar la diferencia entre disponibilidad y resiliencia.

Un sistema de alta disponibilidad puede tener otro componente preparado para asumir el control cuando el principal falla.

Un sistema resiliente está diseñado para absorber problemas, seguir funcionando, recuperarse con elegancia y volver a la normalidad sin colapsar por completo.

Esa distinción importa. Una aplicación puede estar técnicamente disponible y aun así ofrecer una mala experiencia. Puede ser:

• Lenta
• Limitada por throttling
• Parcialmente no disponible
• Dependiente de un backend que falla
• Afectada por un problema de integración
• Sometida a presión regional

La resiliencia real exige, por tanto, algo más que tiempo de actividad. Requiere una arquitectura capaz de soportar carga, errores de aplicación, fallos parciales, problemas regionales, dependencias rotas, incidentes operativos y recuperación una vez superado el incidente.

AZURE NO HACE RESILIENTE A TU APLICACIÓN AUTOMÁTICAMENTE
Una suposición peligrosa es pensar que, como el propio Azure es altamente disponible, cualquier aplicación que se ejecute en Azure hereda automáticamente esa resiliencia.

No es así. Microsoft proporciona los servicios y las capacidades que hacen posibles las arquitecturas resilientes, pero el cliente sigue necesitando diseñar la resiliencia.

Aquí es donde importan los patrones arquitectónicos:

• Circuit breakers
• Bajo acoplamiento
• Procesamiento asíncrono
• Escalado independiente
• Múltiples zonas de disponibilidad
• Múltiples regiones
• Mecanismos de conmutación por error
• Monitorización
• Infraestructura como código
• Procedimientos de recuperación probados

Microsoft aporta los bloques de construcción. La arquitectura determina si esos bloques crean realmente un sistema resiliente.

POR QUÉ IMPORTA EL DISEÑO ASÍNCRONO
Uno de los ejemplos más claros del episodio procede de sistemas que sufren picos de tráfico previsibles, como los portales tributarios de la administración pública.

Un problema de diseño habitual se produce cuando cada acción depende de una operación síncrona en el backend. El usuario pulsa un botón, el frontend espera al backend, el backend espera a otro servicio, una dependencia se ralentiza y, al final, toda la experiencia de usuario se ve afectada.

Mike explica por qué los sistemas débilmente acoplados suelen ser más resilientes. En lugar de obligar al frontend a esperar cada operación del backend, las aplicaciones pueden colocar el trabajo en colas o en sistemas dirigidos por eventos y permitir que los componentes procesen las tareas de forma independiente.

Esto aporta varias ventajas:

• Los distintos componentes pueden escalar de forma independiente
• Un servicio puede fallar sin derribar toda la plataforma
• Los backends pueden procesar el trabajo de forma asíncrona
• Los picos de tráfico son más fáciles de absorber
• Los componentes de cara al usuario dependen menos de la temporización del backend
• Los fallos son más fáciles de aislar

EL MITO DEL 100 POR CIENTO DE DISPONIBILIDAD
Otro tema importante de la conversación es la obsesión por la disponibilidad del 100 por cien.

Mike es muy claro: el 100 por cien de tiempo de actividad no es un objetivo de arquitectura realista. Una solución suele estar compuesta por varios servicios, cada uno con su propio SLA. Cuando se combinan varias dependencias, la disponibilidad total de la solución es inferior a la de cada componente por separado.