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.
13 Responsesso far
Jorge,
Desde mi punto de vista, este es un caso claro de «entre todos la mataron y ella sola se murió».
En primer lugar, no tenemos ni idea de lo que puede haber pasado ahí. Lo único que podemos hacer es aventurar cosas.
Por un lado, no veo equivocada la elección de la plataforma.
Una vez leí que en Microsoft había 2 bandos que eran enemigos irreconciliables. Por un lado estaba el «Raymond Chen Camp», y por otro lado está el «MSDN Camp».
Raymond Chen fue EL desarrollador de Windows. Participó en el OS/2 (de cuando Microsoft e IBM lo desarrollaban juntos), Windows 95/98/… y las DirectX. Su blog es de lo mejorcito que hay por ahí.
Pues bin Raymond Chen tenía la filosofía de que TODO tuviese compatibilidad hacia atrás. Cada vez que avanzaba la versión del sistema operativo, su equipo se tomaba como algo personal que las aplicaciones siguiesen pudiendo ejecutarse. En su blog va contando el porqué de muchas de las decisiones que tuvieron que tomar para que Windows fuese lo que hoy es.
La filosofía del «Raymond Chen Camp» es esa: compatibilidad hacia atrás total en las nuevas funcionalidades.
Y luego está el «MSDN Camp». La filosofía de ese grupo es la de ofrecer nuevas funcionalidades sin pensar en que deba de existir una compatibilidad. Eso hace que puedas centrar tus esfuerzos en ofrecer lo último en tecnología y mantenerte en la vanguardia, pero pierdes al obligar a la gente a tener que estar reescribiendo constantemente código.
La batalla se libró hace tiempo y la ganó el «MSDN Camp». Tenemos un Windows Vista con unas DirectX 10 las cuales no las soporta XP. Entre IE6, IE7 e IE8 tenemos una lista de incompatiblidades que asustan. Los drivers de Windows XP no sirven para Vista. Tenemos 2 versiones de Silverlight y una tercera en camino, cada una con sus «pequeñas» diferencias. SharePoint 2003 no es ni por asomo parecido a estas nuevas versiones. El Office de ahora es completamente distinto en estilo visual al 2003.
Quizás me dirás que las cosas tienen que evolucionar. Eso lo veo del todo lógico. Lo que no veo tan lógico es tener que tirar a la basura todo (tanto código como know-how) y tener que empezar de 0 cada vez que a alguien en Redmond se le ocurra una feliz idea.
Con esta premisa ¿quién es el valiente que dice «vamos a probar con un SQL Server 2005» en un sistema crítico? Los técnicos están formados en el 2000, lo han probado cientos de veces, lo conocen como la palma de su mano y del 2005 lo único que han hecho ha sido instalarlo en su máquina para probar las novedades y alguna que otra migración en sistemas pequeños.
Con esta parrafada quiero decir que no veo mal la decisión de montar un SQL 2000/Windows 2003.
Con respecto a lo del usar Windows en sistemas en tiempo real, Hotmail, una vez comprada por Microsoft siguió manteniendo durante mucho tiempo sus sistemas SMTP en UNIX (creo recordar que era FreeBSD) e incluso sus páginas Web eran servidas por Apache. Y fueron muchísimos años los que estuvo así hasta que migraron a Windows 2000 y a IIS.
En su día leí un documento sobre el proceso de migración de Hotmail a IIS. Lo único que he encontrado ha sido este documento:
http://www.securityoffice.net/mssecrets/hotmail.html
Pero lo he leído muy por encima para saber si era el documento que en su día leí o no.
Lo que sí recuerdo es que en esa época la única referencia de un sistema que sirviese esa cantidad de páginas Web en entornos Microsoft era la propia web de Microsoft. Eso fue un salto al vacío no exento de mucho problemas, pero salió magníficamente bien.
Creo que este ejemplo es más que suficiente para no seguir argumentando que las tecnologías Microsoft no pueden servir como sistema de tiempo real.
Con esto quiero decir, que no cualquier cosa que uses sirve para un sistema en tiempo real. Me explico: Yo ni de coña haría un sistema en tiempo real usando LINQ (básicamente porque entre tú y el SQL-Server hay 5-6 capas). O ni de guasa confiaría en un sistema que u
Tenga, o no tenga culpa Microsoft. Seria acertado que algún responsable de Microsoft explicara su punto de vista al respecto. Yo, por no ir más lejos en alguna ocasión habré utilizado ese mismo proyecto como referencia al defender tecnología .Net. Por esa razón, me ha molestado un poco la falta de información al respecto, también ha cambiado mi valoración con respecto a Microsoft, bajando un punto mi confianza (por falta de explicaciones). Respecto a los comentarios de Steve, que decir… El tío es un monstruo!!!.
Jorge,
No se puede echar la culpa a Accenture por elegir Windows 2003/SQL Server 2000 para su arquitectura. Yo hubiese hecho lo mismo.
Yo estudié la carrera de física y ahí nos decían una cosa que se me quedó: cuando vayas a investigar algo lee siempre lo que se haya hecho sobre el tema. Si no lo haces corres el riesgo de reinventar la rueda.
Plantéate que vas a desarrollar el sistema en pleno 2006. SQL Server 2005 está con un año. Tus desarrolladores y arquitectos de sistema conocen SQL Server 2000 como la palma de su mano. Han hecho cientos de instalaciones y desarrollos sobre ese sistema. Con Windows 2005 lo que han hecho ha sido instalárselo en sus máquinas locales para ver «lo nuevo» y como mucho hacer una migración de algún sistema pequeño-mediano que ni de lejos se le acerca a lo que puede ser el LSE. ¿Quién es el guapo que le pone el cascabel al gato?
Tampoco se puede argumentar que con la arquitectura de Windows 2003/SQL Server 2000 no se pueda construir un sistema en tiempo real. Recuerdo hace tiempo, cuando Microsoft compró Hotmail, estuvieron durante años funcionando con FreeBSD (tanto para el SMTP como para el WebMail que estaba bajo un apache).
Cuando decidieron migrar (existe un documento por ahí con los detalles del proceso de migración, ya no lo he encontrado en la Web de Microsoft y hace tiempo que lo leí, pero creo que es este: http://www.securityoffice.net/mssecrets/hotmail.html) lo hicieron en un Windows 2000 con IIS. Y no usaron ni Active Directory (con 15 millones de usuario, a ver qué AD soporta eso) ni tampoco ASP (usaron ISAPI).
Con Hotmail como ejemplo, a ver quién es el guapo que dice que Windows no sirve como sistema en tiempo real (vale, Hotmail no es un sistema de tiempo real «puro» porque tiene un margen de latencia bastante importante, pero con el LSE es un juego de niños comparado con la carga de Hotmail). Y recuerdo que en su día fue un salto importante hacia adelante. El único sitio Web importante que tenía Microsoft en esos tiempos era su propia página Web, así que fue una apuesta importante esa migración.
Pero si te fijas, no se usó «lo último en tecnología», sino tecnologías consolidadas y muy pegadas al hardware. Por mi parte considero que Microsoft tiene 3 problemas muy importantes que todo desarrollador de sistemas debería conocer:
i) Muchas tecnologías tienes demasiadas capas de abstracción. Por ejemplo, yo ni de coña montaría LINQ para un sistema como el LSE. Es muy fácil, muy productivo y el código sale precioso, pero entre tu código y la base de datos hay como que 5-6 capas de por medio.
Debemos de saber el funcionamiento de las tecnologías y saber el rendimiento que van a tener.
ii) Microsoft siempre te empuja a estar «a la última». Esto es la maldición del «MSDN Camp» (como ves, yo soy de la tendencia del «Raymond Chen Camp»). «Usa silverlight», te dicen y resulta que ya van 3 versiones de SilverLight en 2 años. «Usa MVC» y recién acaba de salir de su fase beta hace unos pocos meses. Dentro de pocos meses veremos ya la campaña por parte de Microsoft para que abandonemos Vista (como la que hubo para que abandonásemos XP). Y ya también estaremos viendo cómo hay gente que estará incluso usando la Beta del Visual Studio 2010 para desarrollar.
Los desarrolladores no debemos de caer en esa trampa de «lo último es lo mejor» y tener criterio para saber qué tipo de tecnología es la más adecuada. Con esto no quiero decir que los avances tecnológicos sean malos, sino que debemos mirar si hay agua en la piscina antes de tirarnos a ella.
iii) Microsoft siempre argumenta que sus tecnologías valen para todo. ¿Que quieres montar una página Web de tu empresa/departamento? Usa SharePoint. ¿Quieres montar un complejo portal empresarial? Usa SharePoint. ¿Quieres montar una base de datos documental con un sistema de Workflow? Usa SharePoint. ¿Quieres montar un repositorio de documentos? Usa SharePoint… Como ves en este ejemplo falla algo. Nada sirve para todo y S
No lo se porque no he trabajado en Accenture. Por por lo visto, y según me cuenta gente que trabajó/trabaja allí….. en Accenture (tan grande como es)…. no hacen lindezas de código. Sin faltar. 😉
Un saludo.
Culpable, en principio tiene que ser Accenture, como dueña y beneficiaría de la cantidad de millones que habrá costado hacer ese SW que por lo visto no funciona. Y despues Microsoft por no dar explicaciones, ya que por no decir claramente que su socio (Accenture) la cagó está dejando en mal sitio a su plataforma .NET.
Muchas gracias por vuestros comentarios.
La única duda grande que tengo de todo esto es:
¿Será .NET un entorno de desarrollo adecuado para aplicaciones Software que requieran procesos en tiempo real o no?.
Si hubiera gente con experiencia en este campo se agradecería.
Yo he hecho aplicaciones con procesos en tiempo real en .NET y no he tenido problemas, pero claro… todo dependerá de la carga de la aplicación, arquitectura, etc., e igual .NET llegado a unos límites que yo a lo mejor no he sobrepasado es incapaz…
Rotundamente no. Un sistema en tiempo real no es un sistema que vaya rápido, sino que sea predecible cuánto tiempo tardará por operación y que ese tiempo no sea alterable.
.NET no es un sistema en tiempo real porque el recolector de basura hace que no lo sea.
Java tampoco lo es (por el mismo motivo), pero hay unas especificaciones que sí convierten a Java en un sistema en tiempo real. ¿Qué hacen? Simplemente obviar el recolector de basura y cuando un objeto sale de ámbito inmediatamente es destruido.
http://java.sun.com/javase/technologies/realtime/index.jsp
Pues dudas razonables, y no solamente vamos a esperar los sistemas de tiempo real, talvez en cualquier solución donde haya bastante carga llegue a sobrepasar su límite y se rompa el .NET no creen?
Definitivamente los arquitectos de microsoft y accenture tienen q dar una explicacion, lo q no vamos a negar es q hasta el momento hay grandes diferencias de productos microsoft con su competencia, ejemplo Windows server Vs Unix o SQL Server Vs Oracle o ahora incluso Teradata.
No sé si habrás leído algo acerca del caso de la London Stock Exchange , en el que
No sé si habrás leído algo acerca del caso de la London Stock Exchange , en el que
Desde luego que la tecnología Microsoft permite realización de soluciones de tiempo real. Yo he participado en alguna banca electrónica, y son sistemas que tienen su cuota de presión.
Otra cosa son los costes necesarios para garantizar un acuerdo de servicio y cómo se alcanzan esas garantías. Y otra cosa es cómo se trabaja en proyectos gobernados por grandes consultoras y cómo se degrada la calidad con los nuevos estilos de asociación tecnológica. Pero esto es digno de libros enteros…
La única duda grande que tengo de todo esto es:
¿Será .NET un entorno de desarrollo adecuado para aplicaciones Software que requieran procesos en tiempo real o no?.
———————–
Yo quiero pensar que si, principalmente porque llevo varios años formándome en .Net para tener mi propia plataforma de trading, y aunque no es comparable con un proyecto como el de la LSE, hay plataformas de trading que están basadas en .Net (NinjaTrader, PT Multistation) que están despuntando frente a las tradicionales, y son capaces de analizar en tiempo real numerosos sistemas de trading de diferentes fuentes de datos.