Esta mañana he asistido en Madrid a un evento organizado por la empresa CA donde presentó su herramienta Lisa. La verdad es que no había oído a hablar nunca de ella, pero sí de los problemas en el desarrollo de software que esta herramienta te ayuda a evitar, y me explico.

Y es que uno de los mayores problemas que tenemos en el desarrollo de aplicaciones en grandes empresas, y sobre todas las que siguen un arquitectura orientada a servicios, son las dependencias de otras aplicaciones y sistemas.

Aún la más sencilla de las aplicaciones, por ejemplo una aplicación de frontal que directamente trabaja con una base de datos, necesita al menos para probarla que la base de datos esté levantada y escuchando las peticiones y sobre todo que tengamos datos de prueba coherentes y fiables. Y más teniendo en cuenta, que hay ciertos datos que no se pueden usar más de una vez (se queman con su uso). Evidentemente no podemos probar más de una vez la baja de una cuenta corriente, por poner un ejemplo, si la segunda vez no la creamos de nuevo.

Para explicar este problema, se me ocurre una comparación muy gráfica: todos hemos visto como se inicia una partida de billar. Las bolas se colocan dentro de un triángulo en un extremo de la mesa. En el otro extremo, el jugador le da con el palo a la bola blanca con toda su fuerza. ¿Qué ocurre después? Que todas las bolas se desaparraman por la mesa. Lo que empezó con el movimiento de una sola bola provoca que todas las bolas sobre el tablero se pongan en funcionamiento.

Pues bien, imaginad que la bola blanca es el servicio que necesita el frontal para funcionar, por ejemplo el servicio de posición integral de un banco. Este servicio necesita a su vez llamar a otros servicios compuestos que a su vez llaman a otros servicios, lógicas, tablas en diferentes backends de negocio, poniendo en movimiento un gran número de recursos software y hardware de la empresa de la misma manera que se ponen en movimiento sobre el tablero las bolas de billar.

¿Cuantos recursos hardware y software y cuantos datos correctos y coherentes necesitamos tener disponibles para probar un sólo servicio del frontal de una sola aplicación? ¿Cuánto cuesta todo esto? además, si por definición el entorno de desarrollo es un entorno inestable porque todo el mundo está haciendo cambios en su software ¿cuál es la probabilidad de que todo funcione en un cierto momento para que podamos hacer una prueba?… me temo que pocas.

¿Como soluciona Lisa esto? Pues creando una especie de simulación de los servicios de la empresa, CA lo llama virtualización de los servicios. Esto quiere decir que cuando nuestra aplicación consuma servicios de la organización realmente lo que está haciendo es consumir servicios que le proporciona este servidor virtual. No importa la tecnología o protocolo con el que se establece la comunicación SOA, REST, MQ Series, JDBC, etc. etc.

¿Y como aprende Lisa lo necesario para hacerse pasar por el sistema informacional de la empresa? Pues reproduciendo su comportamiento. Es decir, el producto se pone a escuchar durante un tiempo el tráfico de datos real de la empresa (es preferible que sea en el entorno de pruebas o preproducción), las invocaciones a los servicios y sus respuestas. Después cuando se instale en el entorno de desarrollo, se dedicará a reproducir las respuestas aprendidas de tal manera que “engaña” a nuestra aplicación haciéndola crear que realmente está consumiendo los servicios reales.

Otro de los muchos problemas que nos encontramos también es que cuando se externaliza el desarrollo de una aplicación se debe dar acceso al proveedor a los sistemas  de la empresa (al entorno de desarrollo o de integración). En este entorno debemos replicar todo lo que tiene el entorno de producción si queremos que las pruebas sean mínimamente válidas. Deberemos tener una base de datos, un servidor de aplicaciones, una cola de mensajería, gestores documentales, etc. etc.

Normalmente lo que se hace es establecer una red VPN con el proveedor de extremo a extremo para poder conectar sus oficinas con las de la empresa cliente (donde está el entorno de desarrollo). Esto es una solución cara y no exenta de problemas de conectividad, capacidad de la conexión, etc.

Con Lisa, podemos meter esta simulación de la empresa en una caja y que el proveedor lo use en su propia empresa. De esta manera podrá probar su aplicación contra los servicios “de verdad” y sin tener que acceder a los sistemas reales o replicar el entorno del cliente en sus instalaciones.

En definitiva, la herramienta que he visto hoy, viene a llenar un agujero considerable que tenemos en el desarrollo de software. El retorno de inversión parece claro: ahorro de costes al evitarse muchos de los gastos que ocasiona el entorno de desarrollo, mayor facilidad para desarrollar al no depender de terceros, más y mejores pruebas del software evitando que los temidos bugs lleguen a producción, etc. etc.

En pensando en SOA || La paradoja del desacoplamiento de los servicios  web
Foto || Flickr CA

Anuncios