Los servicios virtuales cambian las reglas del juego del desarrollo de software

Una cosa está clara: la virtualización de servicios va a cambiar las reglas del juego para el desarrollo de software. A medida que se conocen las ventajas de este concepto relativamente nuevo, los profesionales de desarrollo de aplicaciones, de empresas de todos los tamaños, están descubriendo su potencial. En lugar de invertir en costosas infraestructuras nuevas para probar cómo se comportarán las aplicaciones en un entorno de producción, los equipos de desarrollo pueden lograr el mismo objetivo salvando las grandes limitaciones que encuentran durante el ciclo de vida de desarrollo. Y además, pueden configurar sus plataformas cambiando distintas variables y preparándolas para diversos escenarios. En resumen, es una solución real para los complejos retos que presenta el desarrollo de software.

Sin embargo, conforme la virtualización de servicios se va popularizando, otras prácticas y tecnologías comienzan a reclamar su poco fundado protagonismo en ese espacio, por ello es preciso distinguir cuáles son los servicios virtuales genuinos que aportan una importante innovación en las operaciones de desarrollo, y diferenciarlos de aquellas tecnologías o prácticas que realmente no lo son.

La auténtica virtualización de los servicios

Una definición precisa de la virtualización de servicios sería el proceso de capturar y simular el comportamiento, datos y rendimiento de cualquier sistema que se necesite para desarrollar o probar software. El servicio virtual es un determinado tipo de software de simulación que funciona donde otras formas de virtualización de servidores no consiguen llegar a los sistemas que no están disponibles, o que están incompletos, y no pueden replicarse como una máquina virtual. Un servicio virtual es bastante similar a un entorno real y permite avanzar en el ciclo de desarrollo superando las limitaciones.

Los pretendientes al trono

Los servicios virtuales “falsos” son prácticas o tecnologías que se identifican así pero en realidad no lo son. Veamos algunas de las formas en que aparecen estos mal llamados servicios virtuales en los escenarios de desarrollo:

1. Test Stubs como servicios virtuales: Son de largo la imitación de servicio virtual más común en los entornos de desarrollo. El mercado de herramientas de pruebas de software es muy amplio y competitivo. Cualquier herramienta de pruebas que permite a un desarrollador incluir una simple petición/respuesta como un stub (componente sustituto de una invocación real) en el contexto de una prueba, empezará a llamar a ese stub un servicio virtual. Pero esto no es ni mucho menos igual que los servicios virtuales inteligentes construidos dinámicamente que simulan transacciones con estado o en un contexto, distintos y dinámicos escenarios de datos, patrones de rendimiento, etc.

2. Máquinas virtuales como servicios virtuales: La virtualización convencional también tiende a compararse con la virtualización de servicios. De hecho, las soluciones de virtualización de hardware y servidores pueden virtualizar un entorno para el desarrollo de software, pero sólo si se tiene visibilidad de todo el entorno. Aunque pueden replicar imágenes de máquinas Intel, discos duros, software de desktops y CPUs, las máquinas virtuales no pueden manejar los activos más pesados y con más limitaciones de un entorno de desarrollo, ni pueden crear una imagen de nada que esté fuera del ámbito de control del equipo.

3. Librerías creadas manualmente como servicios virtuales: Este tipo puede ser difícil de identificar porque a menudo proviene de personas que han trabajado mucho en ello, tanto en la propia compañía como en sus proveedores. Una empresa puede tener un equipo de desarrolladores que haya creado y mantenido con mucho esfuerzo su propio “Framework de Respuestas Simuladas” de servicios y datos ficticios pensados para responder como el otro extremo necesario de una transacción compleja. Inevitablemente, esos elementos codificados manualmente son frágiles y requieren cada vez mayor esfuerzo de mantenimiento, lo cual lleva a la pregunta ¿mi equipo dedica el tiempo a desarrollar y probar la funcionalidad y asegurar su calidad o invierte el tiempo en gestionar las librerías de stubs?

4. Directorios de servicios como virtualización de servicios: Cuando se lanzaron los primeros sistemas de virtualización de servicios para usuarios, allá por 2006-2007, había otra definición de la industria flotando entre los proveedores de tecnología de integración de sistemas. Esta definición se basaba en la acción de consultar un directorio de servicios para obtener dinámicamente en enlace, dirección o URL real de un servicio al que se quería invocar. Por tanto estos directorios se veían como catálogo de “servicios virtuales” y eran útiles para redirigir mensajes de servicios a los destinos adecuados, pero no representaban nada parecido a la virtualización o a la simulación del comportamiento de un sistema complejo y necesario para desarrollar o probar una aplicación.

5. Virtualización de servicios asociada a “la nube”: Cloud es ideal para reducir los costes operativos, ya que ofrece el despliegue de potencia de proceso y capacidad elástica prácticamente ilimitada y a la carta. Pero la nube no elimina dependencias por sí misma. Si se está haciendo un trabajo de integración de sistemas empresariales, necesitará una solución de virtualización de servicios lo suficientemente robusta para resolver los «cabos sueltos» para los sistemas que no están disponibles o son demasiado complicados de desplegar en la nube con la frecuencia o celeridad necesaria.

6. Trabajo externalizado como virtualización de servicios: De todas estas falsificaciones, ésta es la que tiene más sentido y es más fácil de detectar. Simplemente significa que se obtienen recursos humanos que actúan como «asistentes virtuales» que hacen las cosas por uno. Sigue siendo popular en la práctica, pero afortunadamente ya no se ven empresas de consultoría que llamen a esto «virtualización de servicios», ahora lo llaman simplemente externalización del trabajo.

¿Qué hacer al respecto?
Cualquiera de las anteriores “falsas” formas de virtualizción de servicios amenaza con minar el valor real de la virtualización de servicios, y retrasar los beneficios que pueden obtener los equipos de desarrollo utilizándola en sus proyectos. ¿Cuál sería la mejor forma de evitar que ocurra esto?

La mejor manera, simplemente, es que los profesionales implicados en el ciclo de vida de desarrollo de aplicaciones conozcan bien la virtualización de servicios: qué es, qué ventajas puede ofrecer y qué servicios virtuales falsos pueden surgir en sus propios escenarios de desarrollo y pruebas. Con una mayor información, la probabilidad de que vayan apareciendo falsas virtualizaciones de servicios será cada vez más ocasional, y las empresas estarán en mejor posición para aprovechar la virtualización de servicios para ahorrar costes y mejorar la entrega de software crítico.