Por qué importa la arquitectura: costo del cambio, calidad, riesgo y fallos reales

Las decisiones que salen caras si se toman mal

La Sección 1.1 definió la arquitectura como el conjunto de estructuras y decisiones significativas que dan forma a un sistema, con la significancia medida por el costo del cambio. Esta sección plantea la continuación práctica: ¿y qué? ¿Por qué debería importarle la arquitectura a un equipo, a un propietario del producto o a un director financiero, y no simplemente las funcionalidades?

La respuesta breve es que la arquitectura decide, más que cualquier otro factor técnico, cómo será el sistema: lo rápido, lo fiable, lo seguro y lo barato de operar que será, y sobre todo lo fácil que será cambiarlo. Las funcionalidades son lo que hace un sistema. La arquitectura determina lo bien que lo hace y lo que costará hacer algo distinto el año que viene. Muchos grandes fallos de software y muchos éxitos costosos se remontan a un puñado de decisiones estructurales.

La arquitectura determina los atributos de calidad

Un atributo de calidad es una propiedad medible de lo bien que un sistema hace su trabajo: rendimiento, disponibilidad, seguridad, modificabilidad, escalabilidad, usabilidad, eficiencia de costos y otras. El Capítulo 2 las define con precisión. Lo fundamental aquí es que la mayoría de los atributos de calidad son emergentes: surgen de cómo se organizan las partes y de cómo interactúan, no de ningún fragmento de código concreto.

Piensa en la disponibilidad. Si el proceso de pago de una tienda en línea debe hacer cinco llamadas síncronas seguidas a servicios que están disponibles cada uno el 99.9% del tiempo, la cadena en su conjunto no puede estar disponible más de aproximadamente el 99.5%, por bien escrito que esté cada servicio, porque las probabilidades se multiplican. Añadir una cola para que algunos de esos pasos ocurran más tarde, o guardar resultados en caché para que algunas llamadas no sean necesarias, cambia la aritmética. Ninguno de los dos cambios es visible dentro de una sola función; ambos son arquitectónicos. El rendimiento, la seguridad y el costo se comportan de la misma manera. Una página de inicio de sesión segura no hace seguro un sistema si un servicio interno sin autenticación es accesible desde internet.

La funcionalidad, en cambio, suele ser en gran medida independiente de la estructura. Puedes implementar las mismas funcionalidades de una app bancaria como una sola unidad desplegable o como cincuenta servicios; los usuarios ven los mismos botones. Lo que cambia es todo lo demás: lo rápido que se puede lanzar una corrección, qué ocurre cuando falla una parte, cuántos ingenieros puede absorber el sistema y cómo es la factura de la nube.

Costo y velocidad del cambio

La mayor parte del costo de un sistema de éxito se produce después de su primer lanzamiento, a medida que se modifica para atender nuevas necesidades. Por eso la estructura importa sobre todo porque determina lo costoso que será cada cambio futuro. En un sistema bien estructurado, un cambio en las normas fiscales afecta a un módulo. En uno enmarañado, afecta a veinte, y cada uno necesita pruebas y coordinación.

La hipótesis de la resistencia del diseño (design stamina hypothesis) de Martin Fowler (2007) recoge este efecto. Un equipo que presta poca atención a la estructura interna suele entregar más rápido al principio. Con el tiempo, la maraña acumulada frena cada cambio, y un equipo que invirtió en estructura lo adelanta. Fowler lo llama hipótesis porque es difícil de medir con rigor, y sugiere que el punto de cruce suele llegar en semanas más que en meses. La ralentización es el interés de la deuda técnica, que trata la Sección 1.7.

Riesgo, equipos, comunicación y estimación

Riesgo. La arquitectura es donde la mayoría de los riesgos técnicos quedan contenidos o se amplifican. Un diseño con un punto único de fallo, una integración sin probar entre partes construidas de forma independiente o una tecnología no probada en su núcleo conlleva un riesgo que ninguna cantidad de programación cuidadosa elimina. Gran parte del trabajo arquitectónico es gestión de riesgos: identificar qué podría salir muy mal y dar forma a la estructura para que no pueda ocurrir o, si ocurre, cause un daño limitado.

Repartir el trabajo entre equipos. Melvin Conway observó en 1968 que las organizaciones que diseñan sistemas tienden a producir diseños que reflejan sus propias estructuras de comunicación. Hoy se llama ley de Conway, y funciona en ambas direcciones. Un sistema cuyas partes tienen límites claros e interfaces estrechas permite que varios equipos trabajen en paralelo con poca coordinación. Un sistema en el que todo depende de todo obliga a cada equipo a estar en cada reunión. Por eso la arquitectura y el diseño de la organización están entrelazados, como explica la sección del Capítulo 3 sobre la ley de Conway.

Comunicación. Una arquitectura da a las personas un vocabulario compartido y un mapa compartido. Los nuevos ingenieros aprenden el sistema más rápido, los gerentes de producto entienden por qué algunas solicitudes son baratas y otras caras, y el personal de operaciones sabe qué depende de qué durante un incidente.

Estimación y planificación. La descomposición en partes conocidas hace posible la estimación: un cambio puede rastrearse hasta los componentes que toca, y cada uno puede estimarlo el equipo que lo conoce. Sin una estructura clara, las estimaciones son conjeturas, porque nadie puede decir con seguridad hasta dónde se propagará un cambio.

Caso práctico: Knight Capital, 1 de agosto de 2012

Knight Capital era uno de los mayores creadores de mercado de la renta variable estadounidense. Según la orden de la Comisión de Bolsa y Valores de Estados Unidos (SEC) del 16 de octubre de 2013, en los primeros 45 minutos de negociación del 1 de agosto de 2012 el enrutador automatizado de órdenes de Knight (llamado SMARS) envió al mercado millones de órdenes no deseadas mientras procesaba 212 pequeñas órdenes minoristas. Recibió más de 4 millones de ejecuciones en 154 valores, por más de 397 millones de acciones, y se quedó con grandes posiciones no deseadas. Knight perdió más de 460 millones de USD, necesitó una inversión externa de emergencia en cuestión de días, y más tarde la SEC le impuso una multa de 12 millones de USD por infringir las normas de acceso al mercado.

La orden de la SEC describe el mecanismo. Años antes, Knight había dejado de usar una antigua función llamada Power Peg, pero su código seguía en el enrutador y aún podía activarse: era código muerto que no estaba muerto. En 2012, Knight escribió código nuevo para un nuevo programa de la NYSE, el Retail Liquidity Program, y ese código nuevo reutilizó un flag que antes activaba Power Peg. El código nuevo se desplegó manualmente en los ocho servidores del enrutador. Un técnico no lo copió en uno de ellos, ningún segundo técnico revisó el despliegue, y Knight no tenía ningún procedimiento escrito que exigiera esa revisión. Cuando se activó el flag, siete servidores ejecutaron el código nuevo; el octavo interpretó el flag como "ejecutar Power Peg" y envió órdenes sin reconocer que ya se habían ejecutado. Antes de la apertura del mercado se enviaron correos electrónicos automáticos que avisaban de un problema, pero nadie actuó en consecuencia.

Sería injusto llamarlo simplemente un bug de programación, e igual de injusto llamarlo un error puramente de operaciones. Las lecciones arquitectónicas tienen que ver con la estructura y la desplegabilidad: funcionalidad obsoleta que seguía siendo accesible en un sistema en producción; un mismo flag con dos significados en distintas versiones del código; un proceso de despliegue sin verificación automática de que todos los servidores ejecutaban la misma versión; y, como subrayó la SEC, controles inadecuados para limitar el daño una vez que algo salía mal. Cada una es una decisión sobre cómo se construye y se lanza el sistema, no sobre una sola línea de código.

Caso práctico: el lanzamiento de HealthCare.gov, octubre de 2013

HealthCare.gov, el mercado federal de seguros médicos de Estados Unidos, abrió las inscripciones el 1 de octubre de 2013. Muchas personas no pudieron crear cuentas ni completar solicitudes, y el sitio sufrió caídas durante semanas. La Oficina de Rendición de Cuentas del Gobierno de Estados Unidos (GAO) y la Oficina del Inspector General (OIG) del Departamento de Salud y Servicios Humanos investigaron después, y sus conclusiones son la mejor fuente sobre lo que salió mal.

El informe de la GAO de julio de 2014 (GAO-14-694) concluyó que los Centros de Servicios de Medicare y Medicaid (CMS) adjudicaron contratos antes de que se fijaran requisitos clave, que los requisitos no dejaron de cambiar, que la supervisión fue débil y que los CMS lanzaron el sistema sin verificar que cumpliera sus requisitos de rendimiento. Las obligaciones del contrato principal del mercado pasaron de 56 millones de USD a más de 209 millones de USD entre 2011 y principios de 2014. Un segundo informe de la GAO, de marzo de 2015 (GAO-15-238), concluyó que los sistemas no se habían probado por completo antes del lanzamiento, y que entre los problemas del lanzamiento figuraban una planificación de capacidad inadecuada, errores de programación del software y funciones previstas que no se habían implementado. El estudio de caso de la OIG de 2016 señaló como causas centrales la ausencia de un liderazgo claro y la mala coordinación entre el trabajo normativo y el técnico. Tras un intenso trabajo correctivo, el sitio pudo atender una alta demanda de los consumidores en unos dos meses.

La historia de HealthCare.gov trata sobre todo de la gestión del programa, pero su lección arquitectónica es directa. El mercado lo construyeron varios contratistas como partes separadas que tenían que funcionar juntas, entre ellas un nodo central de datos (data hub) que se conectaba con otras agencias federales, y nadie verificó de extremo a extremo, con una carga realista, que el conjunto ensamblado cumpliera sus objetivos de capacidad y rendimiento. Los atributos de calidad como la capacidad son propiedades del sistema completo, así que solo puede garantizarlos alguien que sea responsable de la estructura de todo el sistema y lo pruebe como un todo.

Caso práctico: Prime Video y la arquitectura como adecuación, no como moda

En marzo de 2023, un ingeniero del equipo de análisis de calidad de video de Amazon Prime Video publicó una entrada en el blog Prime Video Tech sobre un servicio que monitoriza las transmisiones de video en busca de defectos de calidad. La primera versión se había construido con componentes serverless distribuidos: AWS Step Functions orquestaba los pasos y las funciones de AWS Lambda hacían el trabajo, y los fotogramas de video intermedios pasaban de un paso a otro a través del almacenamiento de Amazon S3. El equipo informó de que este diseño chocó con un límite de escalado rígido en torno al 5% de la carga esperada y habría sido demasiado caro a plena escala, en gran parte por los cargos de orquestación por paso y las numerosas solicitudes al almacenamiento.

El equipo trasladó los pasos de conversión de medios y de detección de defectos a un único proceso que se ejecutaba en contenedores en Amazon ECS, pasando los fotogramas en memoria en lugar de a través del almacenamiento, y escaló ejecutando más copias de ese proceso. La entrada informó de que los costos de infraestructura cayeron más del 90% y de que el servicio podía escalar aún más. La entrada se compartió ampliamente como "Amazon abandona los microservicios", algo que no decía: el cambio afectaba a un servicio, y el autor señaló que los microservicios y los componentes serverless sí funcionan a gran escala, pero que la elección entre ellos y un monolito debe hacerse caso por caso.

La lección no es que los monolitos superen a serverless. Es que la arquitectura es cuestión de adecuación. El diseño serverless fue rápido de construir y adecuado para una carga de trabajo temprana y más pequeña. Cuando la característica definitoria de la carga de trabajo (volúmenes muy altos de datos pasados entre pasos por cada segundo de cada transmisión) pasó a ser dominante, una estructura que movía esos datos por la red muchas veces dejó de encajar, y otra estructura encajaba mejor. Un buen arquitecto se pregunta qué necesitan la carga de trabajo, el equipo y el presupuesto, no qué está de moda.