La elegancia de las soluciones

Es muy fácil, cuando se trabaja en TI, concentrarse en soluciones grandes y complejas. Parece que es ahí donde deben estar las buenas soluciones – grandes soluciones, mucho software, todos los últimos dispositivos. Lo que hacemos es apasionante y resulta muy fácil dejarse llevar por la inercia. Es divertido emprender proyectos desafiantes y de gran envergadura. Escuchar lo que están haciendo otros profesionales de TI, cómo resuelven los retos otras empresas y hablar con proveedores que tienen grandes sistemas que vendernos contribuye a la emoción, y es muy fácil perder el sentido del alcance y del objetivo; es tan común ver soluciones grandes y desmesuradas para problemas sencillos que parece que así es, sencillamente, como debe ser la TI.

Pero no tiene por qué ser así. La complejidad es enemiga tanto de la fiabilidad como de la seguridad. Las soluciones innecesariamente complejas aumentan el coste tanto en la adquisición como en la implementación, así como en el mantenimiento, además de ser por lo general más lentas, más frágiles y de poseer una gran superficie de ataque más difícil de comprender y de proteger. Las soluciones sencillas, o más apropiadamente, elegantes, son el mejor enfoque. Esto no significa que todos los diseños vayan a ser sencillos, en absoluto. A menudo se requieren diseños complejos. La TI no es precisamente un campo que carezca de complejidad. De hecho, con frecuencia se cree que el desarrollo de software puede ser la más compleja de todas las empresas humanas, al menos de aquellas que se acometen a cualquier escala. Una instalación típica de TI incluye millones de líneas de código, cientos o miles de protocolos, gran cantidad de sistemas interconectados, capas de configuraciones de software únicas, más ajustes de los que cualquier equipo podría llegar a conocer, y solo entonces añadimos la complejidad de cientos, miles o cientos de miles de seres humanos impredecibles e irracionales que intentan utilizar estos sistemas, cada uno a su manera. La TI es, sin lugar a dudas, compleja.

Lo importante es reconocer que la TI es compleja, que esto no puede evitarse por completo, pero centrarse en diseñar y desarrollar soluciones que sean lo más sencillas, lo más airosas… lo más elegantes posible. Esta idea de diseño proviene, al menos en mi opinión, de la ingeniería de software, donde el código complejo se considera un error y el código sencillo y hermoso, fácil de leer y fácil de entender, se considera un éxito. Uno de los mayores elogios que se le puede conceder a un ingeniero de software es que su código sea considerado elegante. Qué apropiado resulta que se atribuya a Blaise Pascal, en cuyo honor se nombró uno de los lenguajes de programación más populares de las décadas de 1970 y 1980, esta célebre cita (traducida pobremente del francés): “Lamento haber tenido que escribirte una carta tan larga, pero no tuve tiempo de escribirte una corta.”

A menudo resulta mucho más fácil diseñar soluciones complejas y enrevesadas que determinar qué enfoque sencillo bastaría. Ya sea porque tenemos prisa o porque no sabemos por dónde empezar una investigación, la elegancia siempre supone un desafío. La inercia del sector es promover el camino más difícil. A los proveedores les interesa vender más equipos, no solo para conseguir la venta inicial, sino porque saben que con más equipamiento llega más dinero de soporte, y si se vende suficiente equipamiento nuevo y complejo, las necesidades de soporte dejan de aumentar de forma lineal y empiezan a crecer de forma geométrica, ya que se requiere soporte adicional no solo para el equipo o el software en sí, sino también para la configuración y el soporte de las interacciones entre sistemas o de la personalización adicional. Las influencias financieras que hay detrás de la complejidad son enormes, y no se limitan a los proveedores. Los profesionales de TI obtienen mucha seguridad laboral, o la ilusión de ella, gestionando grandes conjuntos de hardware y software que resultan difíciles de transferir sin contratiempos a otro profesional de TI.

A menudo la complejidad se da tan por sentada, se espera tanto, que el proceso de selección de una solución comienza con una gran complejidad como conclusión inevitable, sin ninguna consideración por la posibilidad de que una solución menos compleja pudiera bastar, o incluso ser superior al margen de la cuestión de la complejidad y el coste en sí. En ocasiones la complejidad incluso se vincula por completo a ciertos conceptos hasta tal punto que he llegado a encontrarme con incredulidad ante la idea de que una solución sencilla pudiera superar en precio, rendimiento y fiabilidad a una compleja.

La retórica es fácil, pero ¿cuál es un ejemplo del mundo real? Los mejores ejemplos que veo hoy en día están relacionados en su mayoría con la virtualización, ya sea en lo que respecta al almacenamiento, a una capa de gestión en la nube, al software o simplemente a la virtualización en sí. Veo con bastante frecuencia que una conversación que para una persona trata únicamente de virtualización conlleva la connotación inmediata de requerir almacenamiento por bloques en red y compartido, costoso software de gestión de virtualización, muchos nodos de virtualización redundantes y complejo software de alta disponibilidad – nada de lo cual es intrínseco a la virtualización y la mayor parte de lo cual rara vez tiene como propósito dar soporte a, o realmente atender el interés de, la empresa para la que se implementará. En lugar de partir de los requisitos del negocio, estos conceptos surgen predominantemente de ideas preconcebidas sobre la tecnología. Es sencillo señalar la complejidad y aparentar que se está resolviendo un problema – la complejidad genera una sensación de tranquilidad. Si se reducen muchos argumentos a su esencia, se oirá: “¿Cómo no va a funcionar, si es complejo?” La complejidad ofrece una ilusión de completitud, de haber resuelto un problema, pero esto puede ocultar con frecuencia el hecho de que una solución quizás no esté en realidad completa ni siquiera sea funcional, pues el grado de complejidad dificulta percibirlo. Nuestra mente no acepta entonces con facilidad que un enfoque más sencillo sea más completo y resuelva un problema cuando uno complejo no lo hace, porque resulta muy contraintuitivo.

Un gran ejemplo de esto es que recurrimos a hablar de redundancia en lugar de fiabilidad. La fiabilidad es difícil de medir; la redundancia es sencilla de cuantificar. Un ladrillo es altamente fiable, incluso cuando es uno solo. No hace falta redundancia para que un ladrillo sea estable y robusto. Su diseño es sencillo. Se podría construir una estructura de soporte con muchos palos redundantes que no sería ni de lejos tan fiable como un único ladrillo. Si se habla en términos de fiabilidad – la probabilidad de que la estructura no falle – queda claro que el ladrillo es una opción superior a varios palos. Pero si se dice “pero no hay redundancia, el ladrillo podría fallar y no hay nada que ocupe su lugar”, uno suena ridículo. Sin embargo, cuando se habla de ordenadores y sistemas informáticos nos encontramos con sistemas tan complejos que rara vez la gente distingue cuándo tiene un ladrillo o un palo y, por tanto, dado que no pueden determinar la fiabilidad, que es lo que importa, se centran en la redundancia, fácil de cuantificar, que no importa. El sistema en su totalidad es demasiado complejo, pero buscar la solución sencilla, la que aborda directamente el meollo del problema a resolver, puede reducir la complejidad y proporcionarnos al final una respuesta mucho mejor.

Esto puede observarse incluso en RAID. El RAID en espejo es sencillo, simplemente un disco o conjunto de discos que es una copia exacta de otro conjunto. Es tan sencillo. El RAID por paridad es complejo, con cálculos sobre una franja variable a lo largo de muchos dispositivos que deben codificarse al escribir y descodificarse en caso de que un dispositivo falle. El RAID en espejo carece de esta complejidad y resuelve el problema de la fiabilidad de los discos mediante operaciones de copia sencillas y elegantes que son altamente fiables y muy bien comprendidas. El RAID por paridad es innecesariamente complejo, lo que lo vuelve frágil. Y sin embargo, al hacerlo y al socavar su propia capacidad de resolver el problema para el que fue diseñado, también, simultáneamente, parece más fiable basándose en ningún otro factor que no sea su propia complejidad. La mente humana salta de inmediato a “es complejo, por lo tanto es más avanzado, por lo tanto es más fiable”, pero ninguna de esas progresiones es lógica. La complejidad no implica que sea más avanzado, y ser avanzado no implica que sea fiable, pero la propia mente humana es compleja y se deja engañar con facilidad.

No hay una respuesta sencilla para encontrar la sencillez. Saber que la complejidad es mala por su propia naturaleza, pero inevitable en ocasiones, nos enseña a estar atentos; sin embargo, no nos enseña cuándo sospechar de un exceso de complejidad. Debemos permanecer vigilantes, buscando siempre determinar si existe una respuesta más elegante y no aceptar la complejidad como la respuesta correcta simplemente por ser compleja. Tenemos que cuestionar las soluciones propuestas y cuestionarnos a nosotros mismos. “¿Es esta solución realmente tan sencilla como debería ser?” “¿Es necesaria esta complejidad?” “¿Requiere esto la complejidad que yo había dado por supuesta?”

En la mayoría de las recomendaciones de diseño de sistemas que doy, el primer paso de determinación técnica que normalmente realizo, después del paso de indagar acerca de la necesidad del negocio que hay que resolver, es cuestionar la complejidad. Si la complejidad no puede defenderse, probablemente sea innecesaria y esté frustrando activamente el propósito para el que fue elegida.

“¿Es realmente necesario dividir esas unidades en muchos arreglos separados? Si es así, ¿cuál es la justificación técnica para hacerlo?”

“¿Es realmente necesario el almacenamiento compartido para la tarea para la que lo está proponiendo?”

“¿Justifica realmente el negocio el uso de tecnologías de alta disponibilidad distribuidas?”

“¿Por qué estamos reemplazando un sistema sencillo que era adecuado ayer por un sistema drásticamente más complejo mañana? ¿Qué ha cambiado que hace que una mejora importante, manteniéndose sencilla, no sea más que suficiente y, en cambio, requiera órdenes de magnitud más de complejidad y más gasto que antes no estaban justificados?”

Estos son solo ejemplos comunes; la complejidad existe en cada aspecto de nuestro sector. Busque la sencillez. Aspire a la elegancia. No acepte la complejidad sin examinarla rigurosamente. Sométala a la proverbial prueba de fuego. No permita que la complejidad se cuele donde no está justificada. No peque por exceso de complejidad – en caso de duda, falle de forma sencilla. Simplificar en exceso una solución suele dar como resultado un fallo menor, mientras que hacerla excesivamente compleja deja margen para un grado de fallo mucho mayor. La apuesta más segura es la solución más sencilla. Y si se elige una solución sencilla y se demuestra que es inadecuada, es mucho más fácil añadir complejidad que eliminarla.