Apache ActiveMQ 5.0

Desde Apache, a la que aún considero la mejor factoría de software Open Source hoy en día, han lanzado una nueva versión de uno de sus mejores productos, el servidor de mensajería ActiveMQ (http://activemq.apache.org). Este software es el utilizado por la gran parte de herramientas de integración Open Source, como es el caso de Apache Service Mix, como soporte para su mensajería asíncrona.

En esta nueva versión, se han añadido multitud de nuevas funcionalidades (http://activemq.apache.org/new-features-in-50.html) y se han mejorado aspectos tales como el rendimiento de la persistencia, el soporte a Blobs en los mensajes y, por último, ya vienen definidos la mayor parte de los “Enterprise Integration Patterns” gracias a la herramienta Camel de Apache. Incluso proporciona un API para poder invocarlo directamente desde JavaScript, ideal para el escalado de los clientes web ricos que utilizan AJAX como tecnología subyacente.

Con todo lo anterior, creo que para todos aquellos que estáis interesados en el mundo de la integración, os recomiendo que os la descarguéis y le echéis un vistazo. Incluso aquellos que estáis acostumbrados a trabajar con otras herramientas, comerciales en su mayoría, creo que podréis encontrarlo interesante.

Yo, por el momento, haré lo propio y echaré un vistazo para ver realmente lo que ofrece. Conforme vaya avanzando, os iré contando mis impresiones.

SOA. Rendimiento vs Seguridad

En los sistemas de información en general, y en las Arquitecturas Orientadas a Servicios en particular, la seguridad de acceso es uno de los factores más importantes. Más, cuando las empresas no sólo ofrecen sus servicios entre sus diferentes equipos de desarrollo o áreas de la misma, sino cuando estos servicios son ofrecidos a entidad externas. Estas entidades, pueden llegar a ser individuos particulares que, con algo de pericia, pueden llegar a construir sus propios Mashups utilizando alguna de las herramientas gratuitas existentes: Yahoo Pipes http://pipes.yahoo.com/pipes/ , Microsoft Popfly http://www.popfly.com , etc.

Incluso, para ciertos servicios como son los ligados a las tramitaciones y gestiones de expedientes en las Administraciones Públicas, estas seguridades adquieren un carácter legal que implica dejar ciertos registros de Auditoría, garantizar el no-repudio, etcétera.

Por todo lo anterior es preciso dotar a los sistemas de determinadas herramientas que proporcionen seguridad en la invocación a los servicios. Seguridad no sólo de autenticación y autorización, sino también seguridad en el transporte (SSL con certificados, IPSEC, etcétera).

Todas estas capas de seguridad no hacen sino ralentizar el rendimiento de cada uno de los servicios, bien dentro de la plataforma de exposición de servicios en el caso de que se delegue esta funcionalidad dicha infraestructura, o bien en el servicio individual expuesto. Pero, ¿es necesario dotar de seguridad a todos los servicios? Pues lo cierto es que no. El “café para todos” no es algo que puede aplicarse dentro de este contexto. Por ejemplo, ¿tiene sentido dotar del mismo nivel de seguridad a los servicios expuestos internamente dentro de una compañía que a los expuestos para la interoperabilidad con terceros?¿y aquellos que tienen algún carácter económico o legal con el simple servicio de consultar la previsión del tiempo?

Es, por tanto, necesario realizar una catalogación de los servicios en base a los aspectos de seguridad requerida para los mismos e, incluso, esta seguridad puede terminar influyendo en el mecanismo de despliegue.

Consejo: A la hora de definir una Arquitectura Orientada a Servicios, no olvidar nunca los aspectos relativos a la seguridad. El sistema debe contar con el nivel de seguridad justo para proporcionar la funcionalidad requerida, pero el que un sistema o servicio sea seguro, no implica que esté necesariamente bien diseñado. En la seguridad, como en casi todo en esta vida, todo está bien en su justa medida.

Oracle y BEA: Empieza el baile

Es la gran noticia de estas últimas semanas en lo que a adquisiciones/fusiones se refiere: Oracle ha realizado una oferta para la adquisición de BEA Systems.

Hace ya varios meses desde que ciertos analistas apuntaron el interés de inversores propietarios de BEA en vender la compañía, así que los intereses de las grandes compañías como SAP, HP y Oracle no tardaron en surgir. Intereses que, en este último caso, se ha materializado en una oferta formal de 6,7 billones de dólares.

Ante esta oferta, el comité de dirección de BEA se escandalizó, no tanto por el hecho de la oferta de adquisición (¿signo de que ya sabían algo?) sino por el ínfimo precio que se le había dado a la compañía. No obstante, aunque en un principio pudo parecer que se iban a negar ante cualquier oferta independientemente de la cuantía, la voz de los inversores económicos (empresas que hacen que este tipo de compañías sea tan potente en EEUU y de las que, por desgracia, carecemos en Europa) se hizo notar. Aquel NO rotundo se ha tornado en un “eso no pero si fuera esto otro…”.

Ahora ya han puesto un precio de 21 $ por acción, lo que resultaría en más de 8,3 billones de dólares por el total de la compañía (http://www.news.com/BEA-sets-buyout-price-at-21-a-share/2100-1014_3-6215263.html?tag=item ).

Este precio ha sido oficialmente rechazado por Oracle, aunque creo haber visto este tipo de situaciones en algún otro lugar:

La orquesta comienza a sonar. Él le pide bailar. Ella se muere de ganas pero se excusa en que su madre les está mirando. Él le dice que es únicamente un baile, nada más. Ella flirtea ligeramente aunque titubea con intenciones de acceder. Finalmente pone ciertas condiciones. Él podría aceptarlas pero no lo hace (ha de hacerse valer!!), así que simula reflexionar … aunque en lo más profundo de sus corazones saben que están hechos el uno para el otro.


Un saludo, navegantes del mar tempestuoso

La problemática de la actualización de las infraestructuras

En el mundo de los Sistemas de Información, cuando hablamos de las infraestructuras hardware o software, éstos son elementos que nunca se valoran lo suficiente. Se trata de piezas de los que se asume un correcto funcionamiento pero que, en el caso de que fallen, es cuando realmente adquieren el valor que les corresponde. Parece una contradicción pero es así.

Aunque para los legos en esta materia esta afirmación puede resultarles sorprendente , estas infraestructuras están basadas en productos y máquinas que, por lo general, deberían tener un ciclo de vida como el de cualquier otro aplicativo. Pero cuando hablamos de infraestructuras, al tratarse de servicios “core” y sin los cuales los sistemas de información que se basan sobre los mismos dejarían de funcionar, la gestión de estos ciclos de vida se complica sobremanera. Generalmente existen dos orientaciones para llevarla a cabo:

• Orientación “si algo funciona no lo toques”. Es algo que se ve circular en algún correo electrónico de tono jocoso (al menos entre los informáticos, esa rara avis cada vez más extendida entre los que me incluyo) pero realmente es la orientación más extendida entre todos los departamentos de Sistemas. Este modo de pensar y actuar es muy conservador y, a la larga, termina de ser contraproducente. Las sustituciones y/o evoluciones terminan por darse y suelen ser traumáticas. Además, las infraestructuras, aunque estén estables, nunca terminan de dar todos los servicios, ni por lo general de igual calidad, de las versiones de plataformas más evolucionadas. No obstante, para ciertos casos, es posible que esta orientación sea la más adecuada.
• Orientación “vamos a estar siempre a la última”. Esta orientación es muy arriesgada en la mayoría de los casos. Las infraestructuras, por lo general, están sujetas a excesivas actualizaciones y nunca terminan de quedar estables. Por el contrario, las ventajas que aporta esta situación son plataformas “a la última” con lo que ello implica: mayor nivel de seguridad, de corrección de errores o “bugs” y una mayor funcionalidad aportada. Existen organizaciones que, para su escenario de negocio, esta opción es más adecuada.

No obstante, para los sistemas de información de la mayor parte de las empresas, lo ideal es encontrar un equilibrio. Como suele decirse, en el medio está la virtud. Los responsables de las infraestructuras deberían realizar un seguimiento de la evolución de las mismas y tener una política de actualización. Esta política será más o menos conservadora pero deberá existir siempre. Aunque suene un poco ridículo en un blog de tecnología el hablar de valentía, una de las cualidades más deseables en los responsables de las infraestructuras es la no carencia de valentía. El motivo principal por la que los responsables son reacios a realizar actualizaciones de infraestructuras es por la complejidad que posee esta acción de actualización.

Las infraestructuras son servicios “always on” para el conjunto de los sistemas de información. Un mecanismo de trabajo habitual y muy recomendable para llevar a cabo las actualizaciones es diseñar un entorno de laboratorio donde se lleva a cabo una simulación del upgrade. El juego de ensayo para validarlo puede ser más o menos complejo y, cuanto más completo sea, mayor será su coste y su eficacia. Aun y todo, la validación de una actualización en base a las conclusiones sacadas de un entorno de laboratorio, no es fidedigna del todo. No es más allá que una orientación más o menos precisa. El entorno real de prueba de la actualización termina por ser el entorno productivo con todas las implicaciones que esto lleva consigo: posibles caídas del servicio en caso de fallo, quejas a todos los niveles tanto del usuario final de los aplicativos como de los responsables de los mismos dentro de la organización, etcétera. Se dice que uno no valora algo hasta que deja de tenerlo y esto se aplica perfectamente para el caso de las infraestructuras.

A la hora de la verdad, la de realizar la actualización de una infraestructura en un entorno productivo, el contar con una copia de seguridad de todos los elementos afectados en el caso de las infraestructuras software, o un procedimiento de contingencia en el caso de las hardware es, si cabe, lo más importante del proceso. Además, en función de la infraestructura concreta, la recuperación del entorno inicial debe realizarse lo más rápidamente posible. Esta presteza implica que:

• Las copias de seguridad deben realizarse de aquello que garantice una recuperación rápida (incluso una imagen del disco puede ser aplicable en muchos casos).
• Siempre debe existir un procedimiento definido para llevar a cabo la actuación. Esto evita que indecisiones de última hora se den en momentos inconvenientes.
• Las decisiones tienen que ser extremadamente rápidas en caso de fallo. Son servicios que no pueden dejar de funcionar y hay que tener un procedimiento perfectamente acotado además de una persona con la capacidad necesaria de tomar esta decisión con la presteza requerida.

Creo que, con lo anterior, la falta de valentía extendida en los responsables de infraestructuras podría quedar justificada en parte. Pero, no nos engañemos, nunca del todo.

Para terminar con esta gota en el mar de la tecnología, un consejo para aquellos en los que os encontráis en la complicada situación de afrontar este proceso: armaos de valentía (no es tontería) y sed meticulosos y exactos en los pasos a seguir. Tened preparado un procedimiento de marcha atrás por mucho que los entornos de laboratorio hayan sido completos y sed eficaces y rápidos en su aplicación en caso de que sea necesario. Son decisiones complejas en algún caso pero que han de tomarse rápidamente. Eso sí, la frontera entre la valentía y el ser temerario es difusa en muchos casos, y únicamente en el juicio de cada uno esto tiene un matiz claramente diferente.

Un saludo, navegantes del mar tempestuoso