El blog de Jorge

El caso de la LSE (London Stock Exchange) y los procesos en tiempo real

Esta entrada tiene que ver con algunos comentarios que se han hecho en mi blog respecto a uno de los temas que trataba, y que a fin de cuentas y con el objetivo principal de aclarar y recabar opiniones enriquecedoras, encuentro este tema tan interesante como la propia programación o la propia toma de decisiones acerca de la arquitectura a elegir a la hora de abordar un proyecto, más que nada porque tiene relación directa con todo esto.

Es un tema peliagudo por las sensibilidades que pueden despertarse, pero está ahí, puede ocurrir y no se puede ignorar. Nuestra profesión no debe ignorar cualquier situación, y es bueno siempre cuestionarse absolutamente todo. ¿Lo estaremos haciendo bien o no?.

Hay quien sobre el tema que traigo querrá ver el vaso medio lleno, y en la otra parte el vaso medio vacío, como siempre, pero es bueno quitarse la gorra típica pro-Linux y pro-Windows, aparcar los prejuicios y plantearse cuestiones relativas al ámbito general del desarrollo y de las IT que es donde estamos centrados con independencia de en qué entorno u entornos nos encontramos más cómodos.

El caso es que la LSE (Bolsa de Valores de Londres - London Stock Exchange), tercera bolsa más grande del mundo, aceptó gastarse 40 millones de libras esterlinas en implantar Infolect y TradElect sobre 12 servidores HP Proliant entre Septiembre del año 2005 (fecha de la puesta en marcha de Infolect) y el T2 del año 2007 (última fase del TRM de la puesta en marcha de TradElect) [http://www.londonstockexchange.com/prices-and-news/stocks/welcome/18-06-2007-exchangelaunchtradelect.htm].
Estos productos fueron desarrollados por Accenture con la colaboración de Microsoft.

El diseño de TradElect (basado en .NET Framework, C#, SQL Server 2000 y con Windows Server 2003 como sistema operativo) era por otro lado obsoleto en el momento de la implantación, ya que hablamos de un producto del año 2003 implantado entre Septiembre de 2005 y Junio del 2007.
La decisión de implantar TradElect por otro lado la llevó a cabo la hasta entonces presidenta ejecutiva de la LSE, pero esto como todo lo que quiero poner, únicamente un dato, no una defensa ni en favor ni en contra de nada ni nadie.

Adicionalmente, se indican en algunos sitios Web que hay unos gastos elevados derivados del entorno Windows que no alcanzo a saber el porqué porque no se citan en ningún sitio cuales ni cuanto, y tampoco sé si son ciertos esos comentarios vertidos en la red sobre este tema o no.

Para ponernos en situación, el pasado año, concretamente el 8 de Septiembre de 2008, la LSE sufrió su peor fallo en 8 años obligando a la LSE a suspender sus operaciones durante casi 7 horas en el momento más crítico de la crisis de créditos estadounidense y la medida de sostenibilidad que impulsó el presidente estadounidense Barak Obama.
Se cortaron las cabezas entonces de toda la ejecutiva de la LSE, se perdieron muchas transacciones, dinero, y la reputación de la LSE se vió dañada y perjudicada.
"The London Stock Exchange (LSE.L) suffered its worst systems failure in eight years on Monday, forcing the world’s third largest share market to suspend trading for about seven hours and infuriating its users."

El caso de éxito que publicó Microsoft en su Web fue borrado este verano una vez que la LSE había dirigido sus esfuerzos y movimientos hacia MillenniumIT, basado en un sistema Linux, sistema operativo usado también por otras bolsas mundiales.
Sin embargo y buscando un poco, todavía se puede acceder a la información del caso de éxito [http://download.microsoft.com/download/f/1/f/f1f9101e-c4cd-400b-a7eb-2c71d221a627/LSE_WinServ03.pdf].

El caso es que según parece, una vez ocurrió el fallo del 8 de Septiembre de 2008 se empezó a barajar la posibilidad de saltar nuevamente a Linux de donde venían en la LSE previamente con el fin de ahorrar costes, pero la inversión realizada obligaba a continuar con el sistema que falló al menos de momento y hasta tener sustituto. Desde el 8 de Septiembre de 2008, el sistema no ha fallado.

Sin embargo, la dañada reputación, la petición de garantías respecto al uso de la LSE, y los posibles (y esto lo digo yo a título personal) bandazos de Accenture y Microsoft para depurar responsabilidades (si las hay), pudo hacer que la LSE con su nuevo director general a la cabeza moviera ficha hacia los entornos con los que trabajó unos años antes del "accidente" del 8 de Septiembre del 2008 y que se saben que funcionaban correctamente.

El argumento esgrimido (si no lo he traducido mal) por Steven J. Vaughan-Nichols defensor a ultranza de Linux y anti Microsoft indica que .NET Framework es incapaz de soportar procesos en tiempo real y que SQL Server no podrá llevarlo a cabo en ninguna de sus versiones [http://blogs.computerworld.com/london_stock_exchange_suffers_net_crash]:
"The programmers and serious database administrators in the audience can already see where this is going. Sorry, Microsoft, .NET Framework is simply incapable of performing this kind of work, and SQL Server 2000, or any version of SQL Server really, can’t possibly handle the world’s number three stock exchange’s transaction load on a consistent basis."

El resultado de todo lo sucedido hace un año es que la LSE ha terminado de adquirir totalmente hace poco más de un mes la empresa india MillenniumIT con sede en Sri Lanka por 18 millones de libras esterlinas [http://www.millenniumit.com/news/index.php?def_news=95 y http://www.londonstockexchange.com/about-the-exchange/media-relations/press-releases/2009/london-stock-exchange-group-to-acquire-millenniumit-for-us30m-18m.htm].

El dato curioso es que esta empresa se dedica al desarrollo de sistemas y aplicaciones bursátiles basándose en Linux/Unix, con Sun Solaris y Oracle como socios, concretamente con el producto Millennium Exchange [http://www.millenniumit.com/pdf/20090605_exchange.pdf].

Con esta adquisición, la LSE planea no solo ahorrar 10 millones de libras esterlinas anuales de gastos derivados y transaccionales a partir del 2011, sino que la compra de Millennium es para la LSE una fuente de ingresos y Know-How adicional que ahora sí tendrá gracias a la empresa que ha comprado y que posee una aplicación que podría revender o compartir con otras bolsas internacionales.

Sé que no tenemos toda la información, es más, seguro que las causas reales de lo que pasó nunca salgan a la luz, y también tengo claro que solo estamos teorizando y especulando, pero yo planteo preguntas al aire (hazte la tuya propia y trata de darla respuesta) y coméntala en voz alta con el punto de vista constructivo como objetivo siempre.

Lo que yo planteo son muchas preguntas, y son...

¿Es culpable de aquel fallo únicamente Microsoft que colaboró con Accenture en el proyecto?.
¿Es culpable únicamente Accenture?.
¿Es culpa de SQL Server que es incapaz y será incapaz de procesar en tiempo real la información de los procesos como afirma Steve?.
¿Es la plataforma .NET Framework incapaz de llevar a cabo operaciones transaccionales en tiempo real como ha indicado también Steve?.
¿Es culpable el sistema operativo de turno (Windows 2003 Server)?.
¿Falló la gestión del proyecto?.
¿Fue un fallo en el Software o en el Hardware lo que provocó el colapso el pasado 8 de Septiembre de 2008?.
¿Se realizaron test unitarios, test de funcionalidad, test de carga y pruebas fidedignas para un proyecto de esa naturaleza?.
¿Hubo calidad en el desarrollo del Software?.
¿Se mintió cuando se dijo que el sistema era capaz de mejorar el rendimiento, disponibilidad y agilidad de los procesos de la LSE que se hacían antes con Linux?.
¿Hubo sistemas redundantes capaces de continuar con los procesos detenidos o bloqueados, o como parece ser no los había (lo cual es MUY grave) o quizás sí los había pero fallaron?.
¿El diseño del entorno fue el culpable o debemos culpar a la plataforma .NET entera incluido SQL Server como hizo en nota de prensa el bueno de Steve?.
¿Tiene sentido seguir trabajando en el año 2008 con un SQL Server 2000 y más una empresa tan importante y que se gasta tanto dinero como la LSE?.
¿Falló todo?, ¿Infolect y TradElect o solo una parte [http://www.londonstockexchange.com/information-providers/technical-library/technical-specifications/tradelect-infolect.doc]?.
Pregunta conspiracional de turno (siempre tenemos que poner encima de la mesa todos los argumentos y descartarlos si acaso) ¿hubo mano negra en el sistema para que fallara y provocara el fallo en cadena que se produjo después de que las pruebas demostraran que el sistema era capaz de procesar ese volumen de información y más en tiempo real?.
¿Debemos olvidarnos de .NET, sistemas operativos Windows y SQL Server como bases de datos?.
¿Es malo el Software privativo y mucho mejor el Software no privativo?.
¿Somos los programadores de .NET tan pésimos?.
¿Hemos elegido los programadores de .NET la peor plataforma para desarrollar soluciones y aplicaciones Software?.

¿Dónde está el fallo?.

Yo tengo mis propias conclusiones con los pocos datos que tengo (y con tan pocos datos, seguramente mis conclusiones sean erróneas), pero prefiero que cada uno opine libremente lo que piensa y los que hayan tenido experiencia en el trabajo en tiempo real argumente o comente sus impresiones basados en sus experiencias o lo que sepan.

No se trata de buscar en sí culpables o mejores o peores, ganadores o perdedores, sino básicamente indicar dónde podrían estar los fallos para aprender de ellos, dónde debemos tener cuidado, o donde están las limitaciones para que sean conocidas por todos.

Un saludo.