En la lección anterior dibujaste el plano completo de Contoso Airlines y la tabla de decisiones que lo sostiene. Queda la pregunta incómoda: ¿está bien? Cualquiera puede defender su propia arquitectura —siempre hay un motivo para lo que uno mismo decidió—, y por eso las organizaciones necesitan un lenguaje común, ajeno al orgullo de quien diseñó cada pieza, para discutir si una plataforma se sostiene.

Ese lenguaje es el Azure Well-Architected Framework: cinco pilares, un conjunto de principios de diseño por pilar y, sobre todo, un método para encontrar la deuda arquitectónica antes de que estalle. No es una certificación ni una lista de servicios obligatorios: es un conjunto de preguntas que cualquiera puede hacer a cualquier arquitectura, incluida la suya.

Esta lección recorre los cinco pilares auditando la plataforma de Contoso pilar por pilar —qué cumple, qué no cumple y qué se decidió conscientemente no hacer—, se detiene en lo que el marco tiene de más valioso, que son los compromisos entre pilares, convierte la revisión en un proceso con participantes, frecuencia y plan de acción, y termina con una lista de comprobación que puedes llevarte a tu propio trabajo mañana mismo.

Aviso de nomenclatura: en este curso «WAF» ha significado hasta ahora firewall de aplicaciones web (wafcontosoglobal). El Well-Architected Framework comparte siglas por accidente. Para evitar confusiones, en esta lección se le llama siempre Well-Architected o «el marco».

1. Qué es el marco y para qué sirve de verdad
2. Los cinco pilares de un vistazo
3. Fiabilidad
4. Seguridad
5. Optimización de costes
6. Excelencia operativa
7. Eficiencia del rendimiento
8. Los compromisos entre pilares
9. La revisión Well-Architected como proceso
10. Herramientas: la evaluación oficial y Azure Advisor
11. Guías para cargas de trabajo específicas
12. El marco en el día a día
13. Lista de comprobación de arquitectura
14. Errores Comunes y Consejos
15. Ejercicios
16. Conclusión

El Well-Architected Framework es una guía de Microsoft que estructura el diseño y la revisión de cargas de trabajo —no de suscripciones enteras, sino de sistemas concretos con dueño y usuarios— alrededor de cinco pilares. Cada pilar aporta principios de diseño, listas de comprobación, recomendaciones y compromisos conocidos.

Sus tres utilidades reales, por orden de importancia:

1. Lenguaje común. Cuando alguien dice «esto es deuda de fiabilidad» en lugar de «esto está mal hecho», la conversación deja de ser personal. El marco convierte opiniones en categorías.
2. Detección temprana. Las preguntas del marco encuentran la ausencia de plan de reversión, la copia nunca restaurada o el secreto sin rotación antes de que un incidente los descubra a las tres de la madrugada.
3. Explicitar los compromisos. Ningún sistema puntúa alto en los cinco pilares a la vez. El marco obliga a decir en voz alta qué se está sacrificando y a cambio de qué.

Y dos cosas que no es, y conviene saberlo antes de empezar: no es una lista de requisitos que haya que cumplir al 100 % —una plataforma que cumpliera todo sería carísima e inmanejable—, y no sustituye al criterio: el marco pregunta, la respuesta la pone el contexto de negocio.

Principios de diseño: diseñar para el fallo asumiendo que todo componente caerá; definir objetivos medibles de disponibilidad, RPO y RTO acordados con negocio; añadir redundancia en la capa correcta; usar reintentos, tiempos de espera y cortacircuitos; simplificar, porque cada dependencia añade probabilidad de fallo; y probar la recuperación, porque una copia no restaurada no es una copia.

Principios de diseño: confianza cero —no confiar en la red, verificar siempre—; mínimo privilegio; defensa en profundidad; cifrado en tránsito y en reposo; ninguna credencial en el código; segmentación; y detección con capacidad de respuesta.

Principios de diseño: adecuar el gasto al valor de negocio; modelar y prever el coste antes de construir; medir con un indicador unitario; optimizar antes de comprometerse; y hacer del coste una responsabilidad compartida, no una auditoría anual.

Principios de diseño: infraestructura como código; automatizar todo lo repetitivo; despliegues pequeños, frecuentes y reversibles; observabilidad de extremo a extremo; documentación viva; y cultura sin culpa con análisis posterior a los incidentes.

Principios de diseño: escalar horizontalmente antes que verticalmente; medir antes de optimizar; elegir el modelo de datos por el patrón de acceso; usar caché donde el dato lo tolera; procesar de forma asíncrona lo que no necesita respuesta inmediata; y pruebas de carga que reproduzcan el pico previsto.

Aquí está el verdadero valor del marco. Ninguna decisión mejora los cinco pilares a la vez; casi todas mejoran uno y empeoran otro, y el trabajo del arquitecto es elegir cuál, no fingir que no ocurre.

Regla práctica que conviene memorizar: un compromiso solo es legítimo si está escrito, tiene dueño y tiene fecha de revisión. Lo que no está escrito no es un compromiso, es un descuido con buena prensa.

Una revisión no es una reunión de dos horas donde alguien enseña un diagrama. Es un proceso con participantes, guion y salida.

Cómo se puntúa, sin caer en la trampa del número: la evaluación oficial produce una puntuación por pilar, útil como línea base para comparar contigo mismo dentro de seis meses, e inútil como objetivo. Perseguir el 100 % lleva a aplicar recomendaciones que no proceden —exactamente el mismo error que perseguir la puntuación de Advisor en el módulo 8—.

El resultado de la revisión de Contoso, priorizado por riesgo por unidad de esfuerzo:

Obsérvese lo que no está en la lista: multirregión activo-activo, pruebas de caos y registro inalterable. No porque no importen, sino porque su relación coste-beneficio, en este contexto y este trimestre, es peor que la de las cinco anteriores. Una revisión que produce veinte acciones no produce ninguna.

La evaluación Well-Architected es un cuestionario guiado que recorre los pilares, permite marcar preguntas como no aplicables y genera un informe con recomendaciones y enlaces a documentación. Es autoevaluación: su calidad depende por completo de la honestidad de quien responde, así que conviene hacerla en grupo y no en solitario.

Se complementan exactamente en su punto ciego: Advisor nunca dirá «no tienes plan de reversión» y la evaluación nunca dirá «esta máquina lleva catorce días al 3 %». Ambas comparten los cinco pilares como taxonomía, lo que permite volcar las recomendaciones de Advisor directamente en el pilar correspondiente de la revisión.

Además de los cinco pilares genéricos, el marco publica guías especializadas que aplican los mismos principios a un tipo concreto de carga. Merece la pena conocer que existen y consultarlas cuando toque:

La guía de misión crítica es especialmente instructiva aunque no la necesites: leerla enseña cuánto cuesta de verdad el «cero paradas» y, casi siempre, convence de que 99,9 % con RTO de 4 h era la decisión correcta.

Un marco que solo se usa una vez al año es un ritual. La forma de que sirva es partirlo en dos puntos de contacto pequeños:

• En la revisión de diseño, antes de construir: cinco preguntas, una por pilar, respondidas en una página. ¿Qué pasa si esto falla? ¿Quién puede acceder y con qué credencial? ¿Cuánto costará al mes? ¿Cómo se despliega y cómo se revierte? ¿Qué carga soporta y cómo escala?
• En la solicitud de incorporación de cambios, como plantilla de una sola línea por pilar. No es burocracia si cabe en la plantilla del repositorio y se responde en un minuto.

Para llevarse y usar en cualquier proyecto, no solo en este curso.

Fiabilidad: ¿hay RPO y RTO escritos y acordados con negocio? ¿Qué componente es un punto único de fallo? ¿Qué dependencia síncrona podría hacerse asíncrona? ¿Hay reintentos con retroceso y tiempos de espera? ¿Se ha restaurado alguna copia este semestre? ¿Está probado el plan de recuperación?

Seguridad: ¿hay alguna credencial fuera de un almacén de secretos? ¿Alguien tiene propietario permanente? ¿Hay algún dato accesible desde internet? ¿MFA es obligatorio para todos? ¿Se revisan los accesos periódicamente? ¿Se cifra en tránsito y en reposo? ¿Hay detección activa y alguien que la mire?

Coste: ¿existe presupuesto con alerta? ¿Está todo etiquetado con dueño y centro de coste? ¿Cuál es el coste unitario y hacia dónde va? ¿Qué recursos llevan un mes sin uso? ¿Se optimizó antes de comprometerse? ¿Están escritos los recortes rechazados?

Excelencia operativa: ¿se puede recrear el entorno desde código? ¿Se despliega sin intervención manual? ¿Cuánto se tarda en revertir? ¿Qué alerta habría detectado el último incidente? ¿Está la arquitectura documentada y actualizada?

Eficiencia del rendimiento: ¿cuál es el objetivo de latencia y se mide? ¿Escala automáticamente y se ha probado con el pico? ¿El modelo de datos corresponde al patrón de acceso? ¿Qué se puede cachear sin arriesgar corrección? ¿Qué se puede hacer asíncrono?

• Tratar el marco como una lista de obligaciones. Cumplirlo todo es carísimo; el marco pregunta, el negocio responde.
• Perseguir la puntuación. La puntuación sirve para compararse con uno mismo, no para presumir ni para fijar objetivos.
• Revisar toda la nube a la vez. Se revisa una carga de trabajo; una revisión de «todo» no produce acciones concretas.
• Hacer la evaluación en solitario. El sesgo de quien diseñó el sistema anula el resultado; hace falta alguien que pregunte «¿y si esto cae?».
• No incluir a negocio ni a finanzas. Sin ellos no se pueden decidir compromisos, y toda la revisión queda en teoría.
• Salir con veinte acciones. Cinco con dueño y fecha valen más que veinte en una hoja de cálculo.
• No registrar lo que se decide no hacer. Es la información que más se echa de menos un año después.
• Consejo: haz la primera revisión antes de construir, cuando cambiar de idea es gratis.
• Consejo: guarda el informe de cada revisión en el repositorio, con fecha. La comparación entre dos revisiones enseña más que cualquiera de las dos.
• Consejo: cuando alguien proponga algo que mejore un pilar, pregunta siempre en voz alta qué pilar empeora. Si la respuesta es «ninguno», falta análisis.

Ejercicio 1. Toma tres decisiones concretas de la plataforma de Contoso —el WAF en modo prevención, la réplica fg-contoso-reservas y el apagado nocturno de los entornos de desarrollo— y analiza cada una como compromiso: qué pilar mejora, qué pilar empeora, cómo se cuantifica cada lado y en qué condiciones de negocio la decisión debería invertirse.

Ejercicio 2. Eres responsable de una plataforma de comercio electrónico con 20.000 pedidos al mes, una sola región, App Service, SQL Database y despliegues manuales desde el portal los viernes. No hay copias probadas, los secretos están en la configuración de la aplicación y no hay presupuesto de coste. Realiza una revisión Well-Architected abreviada: identifica el estado de cada pilar y produce cinco acciones priorizadas con dueño y plazo, justificando por qué esas cinco y no otras.

Ejercicio 3. La dirección de Contoso pide subir la disponibilidad objetivo del 99,9 % al 99,99 % «porque suena mejor». Prepara la respuesta técnica: qué implica realmente esa diferencia en minutos de parada, qué cambios de arquitectura exigiría, qué coste aproximado tendría, qué pilares empeorarían y qué preguntas devolverías a negocio antes de aceptar el compromiso.

Solución 1: WAF en modo prevención. Mejora seguridad —bloquea inyección, secuencias de comandos entre sitios y automatismos antes de llegar a la región—; empeora rendimiento —unos milisegundos por petición, irrelevantes frente a los 400 ms de objetivo— y, sobre todo, disponibilidad percibida por falsos positivos: una regla demasiado estricta bloquea a clientes legítimos, que es un riesgo mucho mayor que la latencia. Se cuantifica con la latencia añadida en Application Insights y con el número de peticiones bloqueadas legítimas. Debería invertirse —pasar a solo detección— únicamente si se demostrara que bloquea tráfico real de forma recurrente y el ajuste de reglas no lo resuelve; nunca por rendimiento. Réplica fg-contoso-reservas. Mejora fiabilidad —RTO de 4 h en vez de días y protección ante fallo regional—; empeora coste en ≈1.180 €/mes. La cuantificación del otro lado es la clave: hay que estimar el coste de una parada de un día en temporada alta, que con ingresos por reservas es muy superior. Se invertiría si el negocio aceptara por escrito un RTO de días, o si el volumen cayera tanto que la parada costara menos que la réplica. Apagado nocturno de -dev. Mejora coste; empeora disponibilidad y, de rebote, agilidad —alguien que quiera trabajar de madrugada se encuentra el entorno parado— y fiabilidad del propio runbook, que mal filtrado podría apagar producción. Se cuantifica con horas ahorradas por el precio hora y con incidencias reportadas por el equipo. Se invertiría si hubiera equipo en otra zona horaria o pipelines nocturnos que necesitaran el entorno: entonces el ahorro se busca en dimensionamiento, no en apagado.

Solución 2: estado por pilar. Fiabilidad: crítico —copias no probadas equivale a no tener copias; región única sin plan de recuperación; sin RPO/RTO escritos—. Seguridad: crítico —secretos en configuración de aplicación, accesibles a cualquiera con permiso de lectura del recurso—. Excelencia operativa: malo —despliegue manual, en viernes, sin reversión ni trazabilidad de qué versión hay en producción—. Coste: desconocido, que a estos efectos es malo —sin presupuesto no hay alerta de anomalía—. Rendimiento: sin datos —no se menciona medición, así que probablemente no la haya—. Cinco acciones priorizadas: (1) Restaurar una copia en un entorno aparte esta semana —dueño operación, 5 días—: es la acción de menor esfuerzo y mayor reducción de riesgo catastrófico, y además revela si las copias existen de verdad. (2) Sacar los secretos a Key Vault con identidad administrada —desarrollo, 2 semanas—: elimina la exposición más probable y más barata de explotar. (3) Pipeline de despliegue con ranura y reversión, y prohibición de desplegar en viernes —desarrollo y operación, 3 semanas—: convierte cada despliegue de evento de riesgo en rutina. (4) Presupuesto con alerta y etiquetado mínimo de dueño y entorno —finanzas con operación, 1 semana—: coste bajísimo, y sin él no se detecta ni un error ni un abuso. (5) Objetivos de disponibilidad y latencia escritos, con Application Insights midiéndolos —producto y desarrollo, 1 mes—: sin objetivo no hay forma de saber si algo va mal. Por qué estas y no otras: las cinco atacan riesgos con consecuencia catastrófica y coste de mitigación bajo; multirregión, autoescalado fino o revisiones de acceso automatizadas tienen mejor apariencia pero peor relación riesgo-esfuerzo mientras las copias sigan sin probarse.

Solución 3: en minutos, 99,9 % permite unos 43 minutos de parada al mes; 99,99 %, unos 4,3 minutos. La diferencia no es «un nueve más»: es que ninguna intervención humana cabe dentro del presupuesto de parada, así que todo debe ser automático. Cambios necesarios: conmutación automática de base de datos con pruebas continuas, activo-activo en al menos dos regiones con el tráfico ya repartido —no en frío—, eliminación de todo punto único incluido el propio despliegue, despliegues progresivos con reversión automática por métrica, pruebas de caos periódicas, y guardia 24×7 con capacidad de respuesta en minutos. Coste aproximado: al menos duplicar la plataforma de producción más el coste operativo del equipo, del orden de 25.000-30.000 €/mes adicionales, frente a los 12.550 € actuales. Pilares que empeoran: coste, obviamente, y excelencia operativa a corto plazo, porque la complejidad multirregión introduce clases de incidente nuevas —incoherencia de datos, división de cerebro, despliegues desincronizados— que hoy no existen; también empeora la agilidad, ya que cada cambio debe validarse en dos regiones. Preguntas a devolver a negocio: ¿cuánto cuesta realmente un minuto de parada, medido en reservas perdidas y no solo estimado? ¿Cuántos minutos de parada hemos tenido en los últimos doce meses, y cuántos habrían sido evitables con 99,99 %? ¿Hay algún contrato, cliente corporativo o requisito regulatorio que exija ese nivel, o es una preferencia? ¿Está la dirección dispuesta a financiar un equipo de guardia continuo, que es el coste que no aparece en la factura de Azure? Y una observación honesta: si en el último año la mayor parte de la indisponibilidad vino de errores de despliegue y no de fallos de infraestructura, invertir en despliegue progresivo y reversión automática compra más disponibilidad real que duplicar regiones, y cuesta una fracción.

Ya sabes qué es el Azure Well-Architected Framework y para qué sirve de verdad: no como lista de obligaciones ni como certificación, sino como lenguaje común que despersonaliza la discusión sobre arquitecturas, como mecanismo de detección temprana de la deuda que aún no ha estallado y, sobre todo, como forma de hacer explícitos los compromisos que de otro modo se toman sin que nadie los mencione.

Conoces los cinco pilares con sus principios de diseño —fiabilidad, seguridad, optimización de costes, excelencia operativa y eficiencia del rendimiento— y has visto la plataforma de Contoso auditada pilar por pilar, con la distinción que hace útil una auditoría: lo que cumple, lo que no cumple —revisiones de acceso, cortacircuitos, pruebas de caos, presupuestos de error, registro inalterable— y lo que se decidió conscientemente no hacer, que no es lo mismo que un olvido.

Tienes los compromisos entre pilares con casos vividos y cuantificados: el WAF que añade milisegundos y falsos positivos, la réplica que cuesta 1.180 € al mes, el apagado que ahorra a costa de disponibilidad, la directiva que bloqueó un despliegue un viernes; con la regla que los hace legítimos —escritos, con dueño y con fecha de revisión—. Sabes ejecutar la revisión como proceso: una carga de trabajo, participantes de arquitectura, desarrollo, operación, seguridad y finanzas, cadencia semestral, y una salida que es un plan de cinco acciones priorizadas, no una puntuación; conoces la evaluación oficial y su complementariedad exacta con Azure Advisor, las guías especializadas para AKS, IA, SaaS y misión crítica, cómo llevar el marco al día a día con cinco preguntas en la revisión de diseño y una plantilla en la solicitud de cambios, y te llevas una lista de comprobación por pilar aplicable a cualquier plataforma.

El marco te dice cómo debería estar hecha una arquitectura. La lección siguiente aborda la otra mitad del oficio: cómo se hacen mal. El catálogo honesto de los errores que se repiten en todas las organizaciones —de coste, de seguridad, de arquitectura, de operación, de gobierno y de datos—, con su síntoma, lo que cuesta arreglarlos tarde, cómo se previenen, y los cuatro que el equipo de Contoso sí cometió durante este curso.