Durante ocho módulos has visto la plataforma de Contoso Airlines por partes. Cada lección presentó una pieza, la justificó y la dejó funcionando: una red aquí, una base de datos allá, un pipeline, una alerta, un presupuesto. Es la única forma de aprender una plataforma —nadie entiende cincuenta servicios a la vez—, pero no es la forma en que la plataforma existe. En producción todo está conectado con todo, y el día que algo falla nadie tiene tiempo de reconstruir mentalmente ocho módulos: hace falta un plano.

Esta lección dibuja ese plano entero y enseña a leerlo. No vuelve a explicar qué es App Service ni cómo funciona Cosmos DB: eso ya lo sabes. Lo que hace es mostrar el conjunto y el criterio: por dónde entra una petición y por dónde sale, qué habla con qué y a través de qué, por qué cada pieza es esa y no otra, cuánto cuesta el resultado, qué tres versiones distintas de esta misma arquitectura tendrían sentido en otros contextos, y qué haría el equipo distinto si empezara hoy con lo que sabe ahora.

Es la lección más importante del módulo, porque leer una arquitectura de conjunto —ver el punto único de fallo, el acoplamiento innecesario, la pieza que sobra— es exactamente lo que separa a quien conoce servicios de quien diseña sistemas.

Recordatorio: todas las cifras en euros son orientativas y ficticias, y los nombres de recursos pertenecen a un caso de estudio inventado. Los precios reales varían por región y cambian con frecuencia.

1. Cómo se lee un plano de arquitectura
2. El plano completo de Contoso Airlines
3. Lectura por zonas
4. El recorrido de una reserva, de extremo a extremo
5. La tabla maestra de decisiones
6. Los números de la plataforma
7. Tres variantes de la misma arquitectura
8. La retrospectiva honesta: qué haríamos distinto hoy
9. Arquitecturas de referencia y el Azure Architecture Center
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Un diagrama de arquitectura útil no es un inventario de iconos: es un mapa de flujos y fronteras. Se lee siempre en el mismo orden, y merece la pena interiorizarlo porque sirve para cualquier plataforma, no solo para esta:

1. ¿Por dónde entra el tráfico? Todo lo que viene de internet tiene un único punto de entrada legítimo. Si hay dos, uno de ellos es un agujero.
2. ¿Dónde están las fronteras de confianza? El borde público, la red privada, la subred de datos. Cada cruce de frontera es un control: WAF, firewall, NSG, punto de conexión privado.
3. ¿Qué es síncrono y qué es asíncrono? Una flecha continua significa que si el destino cae, el origen falla. Una flecha por cola o evento significa que si el destino cae, el trabajo espera. Es la distinción que más determina la resiliencia real.
4. ¿Dónde vive el estado? El cómputo se puede recrear en minutos; los datos no. Todo lo que guarda estado necesita copia, réplica y plan de recuperación.
5. ¿Quién observa el conjunto? La plataforma de operación no participa en el flujo, pero lo cruza entero.
6. ¿Qué impide crear lo que no debe existir? El gobierno no está en el flujo: está por encima, en la jerarquía de suscripciones.

El plano de la sección siguiente está dibujado exactamente en ese orden, de arriba abajo.

Las flechas continuas son flujo de petición o de datos; las discontinuas, dependencias de plano de control: identidad, secretos, telemetría, copias. Es una distinción deliberada: si kv-contoso-pro deja de responder, la aplicación no se cae al instante —los secretos están en caché—, pero si cosmos-contoso-tarifas-pro deja de responder, la búsqueda de vuelos falla en el acto.

Y por encima de todo el dibujo, sin aparecer en él, está la jerarquía de gobierno, que no participa en ningún flujo pero determina qué se puede crear:

Un único punto de entrada: fd-contoso-global. Todo lo demás está cerrado a internet. Front Door termina TLS en el punto de presencia más cercano al pasajero, aplica el WAF wafcontosoglobal antes de que la petición llegue a ninguna aplicación, cachea lo estático y enruta a la región sana. Las aplicaciones solo aceptan tráfico procedente de Front Door, lo que convierte el WAF en obligatorio y no en opcional. Módulo 2 (entrega global) y módulo 4 (WAF).

Cuatro modelos de cómputo conviviendo, y eso no es incoherencia sino adecuación:

Es la zona que hace que la plataforma no se caiga entera cuando algo falla. sb-contoso-pro desacopla la confirmación de la reserva de todo lo que ocurre después: el tema reservas-confirmadas reparte a tarjetas, facturacion y fidelizacion, tres consumidores que no se conocen entre sí y que pueden estar caídos sin impedir una venta. evgt-contoso-reservas-pro propaga eventos discretos, logic-contoso-retrasos-pro orquesta el aviso a pasajeros con conectores en lugar de con código, y evhns-contoso-telemetria-pro absorbe el chorro de telemetría hacia analítica. Módulo 6.

Cinco motores, uno por forma de dato: SQL para transacciones de reserva, Cosmos DB para tarifas de lectura masiva y global, MySQL para el portal de contenidos heredado, PostgreSQL para tripulaciones, y el lago con Synapse para analítica. Todos accesibles solo por punto de conexión privado. Es el estado, y por eso es donde se concentran las copias, las réplicas y el plan de recuperación. Módulo 3 y módulo 7.

log-contoso-pro es un área única en la que confluye todo: aplicaciones, plataforma, seguridad y actividad. Sobre ella se apoyan las alertas, ag-guardia-contoso, los paneles y las consultas KQL. Y por encima, la iniciativa Base de gobernanza de Contoso impide crear un recurso sin etiquetas, fuera de las regiones permitidas, con blobs públicos o sin HTTPS. Módulos 4 y 7.

Este es el flujo que justifica la existencia de toda la plataforma: una pasajera busca un vuelo Barcelona–Palma y termina con su tarjeta de embarque en el correo.

Lo importante del diagrama es dónde termina la respuesta al pasajero: en el paso 13. Todo lo que viene después ocurre por detrás, y esa frontera es la decisión de arquitectura más valiosa de toda la plataforma. Si la generación de tarjetas falla, la venta ya está hecha y el mensaje se reintenta.

Toda arquitectura es una lista de decisiones con su alternativa descartada. Esta es la de Contoso, completa:

La arquitectura de Contoso no es la arquitectura correcta: es la correcta para Contoso. Cambia el contexto y cambia el plano.

Qué se quita en la versión mínima: firewall, bastión, VMSS, AKS, Synapse, segunda región y la mayor parte del gobierno; se conservan MFA, copias, HTTPS obligatorio, secretos fuera del código y etiquetas, porque eso no es lujo, es higiene. Qué se añade en la de gran empresa: segunda región activa con Cosmos DB de escritura múltiple, grupos de conmutación automática, emparejamiento global, equipo de guardia continuo y una factura tres o cuatro veces mayor; se compra latencia baja global y RTO de minutos, y se paga con complejidad operativa, que es el coste que nadie presupuesta. Qué caracteriza a la regulada: la arquitectura apenas cambia de forma, cambia en restricciones —dónde puede estar el dato, quién puede verlo, cuánto tiempo se conserva la evidencia— y en que cada decisión necesita justificación documental. En los tres casos el plano es reconocible: es la misma forma con más o menos piezas.

Ninguna plataforma real sale bien a la primera. Estas son las cosas que Marta, Diego y Nuria harían de otra manera:

• Etiquetar desde el minuto uno, con directiva. Las etiquetas llegaron tarde y hubo que retro-etiquetar decenas de recursos a mano para poder repartir la factura. La directiva hereda-centro-coste debería haber existido antes que el primer grupo de recursos.
• Empezar por la zona de aterrizaje, no por la primera máquina. La jerarquía de grupos de administración y la iniciativa de gobierno se montaron cuando ya había recursos dentro. Es mucho más barato al revés.
• No crear vm-motor-disponibilidad-dev. Nació como prueba rápida y sobrevivió un año sobredimensionada. Hoy sería un contenedor desde el primer día.
• Bicep antes que el portal. Los primeros recursos se crearon a mano y luego hubo que escribirlos en plantillas a posteriori, con las diferencias sutiles que eso arrastra.
• Presupuesto y alerta de coste el mismo día que la primera suscripción. La factura duplicada del primer trimestre se detectó tarde solo porque nadie miraba, y el intento de separar Log Analytics por equipo costó dos semanas deshacerlo.
• Menos servicios distintos. Conviven MySQL y PostgreSQL por razones históricas; si se empezara hoy, sería un solo motor relacional además de SQL.

La conclusión que el equipo escribió en su retrospectiva es la que conviene llevarse: casi todos los errores fueron de orden, no de elección. Las piezas eran las adecuadas; lo que costó dinero fue montarlas en la secuencia equivocada.

No hace falta inventar cada plano desde cero. El Azure Architecture Center publica arquitecturas de referencia revisadas, con diagrama, componentes, consideraciones por pilar del Well-Architected Framework y, en muchos casos, plantillas desplegables:

Cómo usarlas bien: empieza por la referencia, quítale lo que no necesitas y anota por qué. La referencia está diseñada para el caso exigente; copiarla entera en una organización pequeña produce una plataforma cara e inoperable. El valor no está en el dibujo, está en la lista de consideraciones que lo acompaña.

• Confundir un diagrama con documentación. Un plano sin la tabla de decisiones no explica nada: dentro de un año nadie recordará por qué Cosmos y no SQL.
• Dibujar el diagrama una vez. Un plano desactualizado es peor que ninguno, porque induce a error durante un incidente. Vive en contoso-infra, junto a las plantillas.
• Dibujar todo en un único diagrama ilegible. Uno general y varios de detalle: red, flujo de reserva, gobierno. Cada uno responde a una pregunta.
• No distinguir flechas síncronas de asíncronas. Es la información más importante del plano y la que más se omite.
• Copiar una arquitectura de referencia entera. Está pensada para el caso más exigente; adapta y documenta lo que quitas. Y recuerda que más servicios no es mejor arquitectura: cada uno añade coste de operación, no solo factura.
• Consejo: mantén una tabla de decisiones de arquitectura con fecha, alternativa descartada y motivo. Es el documento más valioso de una plataforma y el que nadie escribe.
• Consejo: revisa el plano después de cada incidente, y tenlo a mano en las guardias. Los incidentes enseñan dónde estaba mal dibujado.

Ejercicio 1. Mirando el plano general y el diagrama de secuencia, identifica los tres puntos de fallo más graves de la plataforma de Contoso: para cada uno, qué deja de funcionar exactamente, si el fallo es total o parcial, y qué haría falta para mitigarlo con su coste aproximado. Ordénalos por impacto en el negocio, no por gravedad técnica.

Ejercicio 2. Una cadena hotelera de 40 empleados quiere un portal de reservas con búsqueda, pago y confirmación por correo, con unas 8.000 reservas al mes y presupuesto máximo de 1.200 €/mes. Diseña su arquitectura partiendo del plano de Contoso: qué conservas, qué eliminas y qué sustituyes por una alternativa más barata. Justifica qué tres cosas no eliminarías nunca aunque el presupuesto bajara a 600 €.

Ejercicio 3. Contoso quiere vender en Latinoamérica y el equipo propone activo-activo con Cosmos DB de escritura múltiple. Analiza la propuesta: qué problema resuelve realmente, qué problemas nuevos crea —especialmente con db-reservas—, qué alternativa más barata cubriría el 80 % del beneficio, y qué preguntas de negocio harías antes de decidir.

Solución 1: ordenados por impacto en el negocio. (1) sql-contoso-reservas-pro / db-reservas: es el único punto donde la venta es síncrona e insustituible; si cae, no se puede confirmar ninguna reserva —parada total de ingresos—, aunque la búsqueda siga funcionando porque las tarifas están en Cosmos. Ya está mitigado parcialmente con redundancia de zona y fg-contoso-reservas a North Europe, con RTO de 4 h; reducirlo a minutos exigiría conmutación automática y pruebas frecuentes, con un coste adicional del orden de 1.200-1.500 €/mes. (2) fd-contoso-global: es el único punto de entrada; si falla el perfil o una regla del WAF bloquea tráfico legítimo, la caída es total e instantánea aunque todo lo demás esté sano —el fallo más probable no es de Azure, es una regla mal desplegada, y por eso la mitigación real es barata: modo de detección primero, despliegue por pipeline y capacidad de revertir en minutos—. (3) cosmos-contoso-tarifas-pro: si cae, no hay búsqueda de vuelos, que es el 90 % del tráfico; el fallo es parcial —quien ya tiene un vuelo elegido podría reservar— pero comercialmente devastador; la mitigación es lectura desde una segunda región, relativamente barata, más una caché de tarifas de la ruta popular en el borde. Nota de criterio: el fallo de func-contoso-tarjetas-pro no entra en la lista pese a ser visible para el cliente, porque el mensaje espera en Service Bus y la venta ya está cobrada: exactamente lo que se buscaba al desacoplar.

Solución 2: se conserva la forma, no el tamaño. Conservar: App Service —un plan Standard o Premium v1 pequeño, no Premium v3—, SQL Database sin servidor con pausa automática (8.000 reservas al mes es carga baja y muy irregular), Blob Storage para justificantes, Application Insights, MFA obligatorio, HTTPS obligatorio, copias con retención razonable, etiquetas y un presupuesto con alertas. Eliminar: Front Door y WAF —se sustituye por el dominio propio con certificado gestionado y, si preocupa el abuso, límite de peticiones en la aplicación—, firewall, bastión, VMSS, AKS, Container Apps, Synapse, lago, Event Hubs, segunda región, PIM y la mayor parte de la iniciativa de directivas, que se reduce a tres reglas —regiones permitidas, sin blobs públicos, solo HTTPS—. Sustituir: Service Bus por una cola de Storage o directamente por Event Grid con una Function en consumo, mucho más barato a este volumen; Cosmos DB no aplica —el catálogo cabe en SQL—. Total plausible: 700-900 €/mes, dentro del presupuesto. Las tres cosas que no se eliminan nunca, ni con 600 €: los secretos fuera del código con identidad administrada o Key Vault (una filtración no tiene relación con el tamaño de la empresa), las copias de seguridad probadas (un borrado accidental cierra una empresa pequeña, no la incomoda), y MFA con ningún puerto de administración abierto a internet (el ataque automatizado no distingue entre una pyme y una aerolínea). Son las tres cosas cuyo coste de omisión es catastrófico e independiente del volumen.

Solución 3: qué resuelve realmente: latencia de lectura para usuarios lejanos —una búsqueda desde Bogotá contra West Europe añade cientos de milisegundos— y, secundariamente, tolerancia a la caída de una región. Qué problemas crea: la escritura múltiple en Cosmos obliga a resolver conflictos, algo que un catálogo de tarifas tolera pero que exige una política explícita; y sobre todo db-reservas no acompaña: SQL Database no es de escritura múltiple, así que las reservas seguirían escribiéndose en West Europe y el usuario de Bogotá tendría búsqueda rápida y confirmación lenta, con el riesgo añadido de incoherencia entre lo que ve y lo que puede comprar. Se multiplican además el coste de RU/s, la salida de datos entre regiones, la complejidad de despliegue —dos de todo, en dos pipelines— y la superficie de incidentes. Alternativa que cubre el 80 %: añadir una región de solo lectura a Cosmos DB con lectura desde la región más cercana y consistencia Sesión, mantener la escritura en Europa y apoyarse en Front Door para acercar lo estático y cachear las rutas populares; se gana casi toda la latencia percibida por una fracción del coste y sin conflictos. Preguntas de negocio previas: ¿qué volumen real se espera en Latinoamérica y en qué plazo? ¿Existe requisito legal de residencia del dato en algún país destino? ¿Cuánta pérdida de conversión atribuimos hoy a la latencia, medida y no supuesta? ¿Hay equipo para operar dos regiones activas 24×7? La respuesta a la última suele decidir la discusión.

Ya tienes el plano completo de Contoso Airlines y, más importante, el método para leer cualquier otro: por dónde entra el tráfico, dónde están las fronteras de confianza, qué es síncrono y qué asíncrono, dónde vive el estado, quién observa y qué impide crear lo que no debe existir. Has visto las seis zonas —borde y entrega global, aplicación, integración, datos, operación y gobierno— con sus conexiones reales, y la distinción entre flujo de petición y dependencia de plano de control, que es la que explica por qué unas caídas se notan al instante y otras no se notan en absoluto.

Has recorrido una reserva de extremo a extremo, de la búsqueda a la tarjeta de embarque, atravesando Front Door, el WAF, App Service, la API, Cosmos DB, SQL Database, Service Bus, la función y el almacenamiento, con la frontera clave bien señalada: la respuesta al pasajero termina antes de que empiece el trabajo asíncrono. Y sabes en qué módulo se construyó cada pieza, que es la forma de convertir ocho módulos sueltos en un sistema.

Tienes la tabla maestra de decisiones —cada elección con su alternativa descartada y su motivo—, los números de la plataforma —12.550 €/mes, 0,136 € por reserva, 99,9 %, RPO 15 min y RTO 4 h—, tres variantes de la misma arquitectura para contextos distintos con lo que se quita y lo que se añade en cada una, la retrospectiva honesta con su lección central —casi todos los errores fueron de orden, no de elección— y el Azure Architecture Center como punto de partida para no dibujar desde cero.

Con el plano delante, la pregunta natural es si está bien dibujado. La siguiente lección responde a eso con el marco que Microsoft usa exactamente para ello: el Azure Well-Architected Framework, sus cinco pilares —fiabilidad, seguridad, coste, excelencia operativa y rendimiento—, sus compromisos entre pilares, y una auditoría pilar por pilar de esta misma plataforma que dirá qué cumple, qué no cumple y qué se decidió conscientemente no hacer.