Sobre la complejidad accidental de los sistemas supply chain

Joannes Vermorel

El computing hardware moderno es extremadamente capaz. Un smartphone modesto ofrece miles de millones de FLOPS (operaciones en coma flotante por segundo) mientras almacena cientos de gigabytes de datos. Un único smartphone podría técnicamente ejecutar una asignación de inventario predictiva para una red minorista muy grande. Los datos históricos requerirían una representación adecuada¹ y, en el procesamiento de datos, se tendrían que utilizar técnicas más esbeltas como la differentiable programming. Por ello, los sistemas supply chain de alto rendimiento deberían ser algo dado. Seguramente, las empresas pueden permitirse algo un poco mejor que un smartphone para operar y optimizar sus supply chains. Sin embargo, una observación casual de los sistemas supply chain de nuestros clientes en Lokad indica exactamente lo contrario: estos sistemas son casi siempre lentos, y con frecuencia tortuosos.

Los líderes actuales del software supply chain (ERP, WMS, MRP, etc.) tienen dificultades incluso para sostener 1 solicitud por segundo en su API backend. En Lokad, se nos recuerda dolorosamente tales horribles rendimientos a diario, ya que estamos a la vanguardia del proceso de data retrieval. Para una docena de clientes, la recuperación inicial de datos tomó casi un mes². La lentitud de las diversas APIs representa el 99.9% del problema. Los sistemas capaces de sostener 1MB/segundo para su data extraction son pocos y distantes entre sí. Los sistemas que no nos obliguen a reextraer innecesariamente los mismos datos una y otra vez –para alcanzar las partes más actualizadas– son aún más raros. Esos sistemas típicamente cuentan con 100+ recursos de computación adicionales a su disposición en comparación con lo que tenían hace 2 décadas, y sin embargo, no son fundamentalmente más rápidos³ ni hacen las cosas radicalmente mejor. Algunos de los proveedores más progresistas que aprovechan la in-memory computing requieren varios terabytes de RAM para gestionar redes minoristas, lo cual es una cantidad espantosamente grande⁴ de RAM considerando lo que se está haciendo con esos recursos.

Esta “complejidad accidental” de muchos (¿la mayoría?) sistemas supply chain se puede rastrear hasta dos causas fundamentales: primero, expectativas incorrectas acerca del progreso del propio computing hardware, y segundo, la falta de cuidado en el diseño interno de la solución.

En cuanto al progreso del computing hardware, hasta hace una década, no existía una sola compañía (grande) en la que la primera ley de Moore no hubiera sido planteada decenas de veces (usualmente de forma incorrecta). Había la sensación de que las computadoras se volvían ridículamente más rápidas todo el tiempo. Desafortunadamente, esto dejó de ser trivialmente cierto desde principios de los años 2000. Esta perspectiva incorrecta de un progreso indefinido llevó a muchas compañías de software, mucho más allá del mundo supply chain, a cometer errores masivos. Muchos de los problemas asociados con Windows Vista (lanzado en 2006) se podían rastrear hasta las expectativas originales –en 2001, cuando se lanzó Windows XP– de que los ingenieros de Microsoft creían que las CPUs funcionarían a 6Ghz para 2006. Nos acercamos al final de 2020, y las CPUs de gaming de alta gama apenas alcanzan los 5Ghz. El computing hardware nunca dejó de progresar; sin embargo, dejó de hacerlo de manera trivial, al menos en lo que respecta a las compañías de software.

En los años 80 y 90, tan pronto como un software funcionaba, incluso si era algo lento en el momento de su lanzamiento, se daba por sentado que al año siguiente su velocidad sería decente, y al siguiente, excelente. Las compañías de software agresivas como Microsoft jugaron muy bien esta carta: a sus ingenieros se les daba (todavía se les da) el mejor computing hardware que el dinero puede comprar, y empujaban sistemáticamente el rendimiento del software al límite de lo que era aceptable, sabiendo que el hardware resolvería esencialmente el problema de rendimiento, con un año o dos de diferencia. Después del desastre de Vista, los equipos de ingeniería de Microsoft se dieron cuenta de la magnitud del problema y cambiaron su enfoque –Windows 7 fue una mejora importante. Sin embargo, le tomó una década a Windows recuperarse verdaderamente en el frente del rendimiento. Hoy en día, la perspectiva es casi exactamente la opuesta: los mejores equipos de Microsoft ya no dependen del hardware futuro, y casi exclusivamente se centran en ofrecer un rendimiento inmediato superior a través de un software superior⁵.

Sin embargo, el mundo del software empresarial resultó ser mucho más lento en notar el problema, y siguió construyendo software durante la década de 2010 como si el computing hardware futuro estuviera a punto de resolver todos sus problemas, tal como había sucedido muchas veces en el pasado. Desafortunadamente, para la mayoría de los proveedores de software empresarial, aunque el computing hardware continúa progresando, hace una década dejó de progresar de manera trivial⁶ en la que el proveedor simplemente podía esperar a que se produjera la mejora en el rendimiento. El software tiende a acumular peso con el tiempo (más características, más opciones, más pantallas, etc.). Así, la tendencia natural del software complejo es ralentizarse con el tiempo, y no mejorar, a menos que exista un esfuerzo intenso y dedicado en este frente.

Lamentablemente, desde una perspectiva de ventas, el rendimiento es en su mayoría una cuestión secundaria. Las demostraciones se realizan con cuentas de juguete que sólo incluyen una fracción ínfima de la carga de datos que el sistema enfrentaría en producción. Además, las pantallas de interés para la alta dirección reciben una cantidad desproporcionada de pulido en comparación con aquellas destinadas a los empleados de base. Sin embargo, estas últimas son exactamente las pantallas que se utilizarán miles de veces al día, y por lo tanto, son las que deberían merecer mayor atención. Sospecho que las APIs frecuentemente ofrecen un rendimiento terrible porque pocos compradores investigan si las APIs realmente están ofreciendo un rendimiento alineado con su propósito previsto. Los proveedores de software lo saben, y adecuan sus inversiones en ingeniería en consecuencia.

Esto me lleva al segundo aspecto del problema de rendimiento: la falta de cuidado en el diseño interno de la solución. Actualmente, se requieren decisiones estratégicas de diseño de software para aprovechar la mayor parte de las mejoras continuas del hardware. Sin embargo, una decisión de diseño es una espada de doble filo: empodera, pero también limita. Se necesita un liderazgo fuerte para comprometerse tanto en el lado comercial como en el técnico con una decisión de diseño. La indecisión es más fácil, pero, en consecuencia, como lo ilustra la gran mayoría del software empresarial, el rendimiento (y la experiencia de usuario en general) sufre enormemente.

Una trampa del software moderno (no sólo el empresarial) es la sobreabundancia de layers. Los datos se copian, se transfieren, se agrupan, se sincronizan, … a través de docenas de capas internas dentro del software. Como resultado, la mayor parte de los recursos de computación se desperdicia tratando con la “plomería interna” que, por sí misma, no aporta ningún valor añadido. En términos de diseño, la solución es tan simple de concebir como difícil de ejecutar: se debe hacer un uso frugal de componentes de terceros, especialmente aquellos que implican algún tipo de capa⁷. Desde la perspectiva de un proveedor de software, agregar una capa más es la manera más rápida de añadir más “cool features” al producto, sin contar la sobrecarga.

En Lokad, hemos optado por una pila extensamente integrada al diseñar toda nuestra plataforma en torno a un núcleo compilador. En el lado negativo, perdemos la opción de conectar fácilmente cualquier proyecto open source al azar en nuestro diseño. Las integraciones siguen siendo posibles, pero normalmente requieren cambios más profundos en el propio compilador. Por el lado positivo, logramos un rendimiento de “bare metal” que suele considerarse impensable en lo que respecta al software empresarial. En general, considerando que los componentes open source están envejeciendo gravemente, este enfoque ha demostrado ser particularmente efectivo durante la última década⁸.

La multi-tenencia mutualizada es otra elección de diseño que impacta radicalmente el rendimiento, al menos desde la perspectiva de la “relación calidad-precio”. La mayor parte del software empresarial –siendo el software supply chain uno de ellos– tiene requerimientos de recursos de computación muy intermitentes. Por ejemplo, en el extremo del espectro, tenemos el forecasting numerical recipe, que se ejecuta sólo una vez al día (más o menos) pero tiene que procesar todos los datos históricos cada vez. Disponer de un conjunto estático de recursos de computación⁹ dedicado a un cliente es sumamente ineficiente.

Nuevamente, en Lokad, hemos optado por una infraestructura completamente mutualizada. Este enfoque reduce nuestros costos operativos en la computación en la nube mientras ofrece un rendimiento que de otro modo no sería económicamente viable (los costos de la computación en la nube superarían los beneficios supply chain). Para asegurar una orquestación general fluida de todas las cargas de trabajo, hemos diseñado un alto grado de “predictabilidad” para nuestro propio consumo de recursos de computación. El DSL de Lokad (lenguaje de programación específico de dominio), llamado Envision, ha sido concebido para respaldar esta empresa. Por ello, clases enteras de construcciones de programación –como los bucles arbitrarios– no existen en Envision: esas construcciones no son compatibles con los requisitos de “alta predictabilidad” que implica el procesamiento de datos supply chain.

En conclusión, no esperes que un sistema supply chain obeso se ponga en forma pronto si es que ya no lo está. Mientras el computing hardware sigue progresando, ya es bastante rápido. Si el sistema es lento, lo más probable es que sea porque antagoniza su hardware subyacente, y no porque al hardware le falte. Reparar el problema es posible, pero en su mayoría es cuestión de diseño. Desafortunadamente, el diseño fundamental del software es una de las cosas que tiende a ser casi imposible de arreglar en el software empresarial una vez pasada la etapa de diseño del producto. Sin embargo, es posible recuperarse, como lo ha demostrado Microsoft, pero no todas las empresas (tanto proveedor como cliente) pueden permitirse la década que se requiere para hacerlo.