Virtualización de servicios

En ingeniería de software , la virtualización de servicios es un método para emular el comportamiento de componentes específicos en aplicaciones heterogéneas basadas en componentes, como aplicaciones basadas en API , aplicaciones en la nube y arquitecturas orientadas a servicios . Se utiliza para proporcionar a los equipos de desarrollo de software y control de calidad/pruebas acceso a componentes del sistema dependientes que se necesitan para probar una aplicación bajo prueba (AUT), pero que no están disponibles o son difíciles de acceder para fines de desarrollo y prueba. Con el comportamiento de los componentes dependientes "virtualizado", las pruebas y el desarrollo pueden continuar sin acceder a los componentes reales en producción. La virtualización de servicios es reconocida por proveedores, analistas de la industria y publicaciones especializadas como diferente del mocking. ^{[ 1 ] [ 2 ]} Consulte aquí una comparación de herramientas de simulación de API.

La virtualización de servicios emula el comportamiento de los componentes de software para eliminar las restricciones de dependencia en los equipos de desarrollo y pruebas. Dichas restricciones se producen en entornos complejos e interdependientes cuando un componente conectado a la aplicación bajo prueba es:

• Aún no está terminado
• Aún en evolución
• Controlado por un tercero o socio.
• Disponible para pruebas únicamente con capacidad limitada o en horarios inconvenientes.
• Difícil de aprovisionar o configurar en un entorno de prueba.
• Necesario para el acceso simultáneo de diferentes equipos con configuraciones de datos de prueba variadas y otros requisitos.
• Restringido o costoso de usar para pruebas de carga y rendimiento.

Aunque el término "virtualización de servicios" refleja el enfoque inicial de la técnica en la virtualización de servicios web , la virtualización de servicios se extiende a todos los aspectos de las aplicaciones compuestas: servicios, bases de datos , mainframes , ESB y otros componentes que se comunican utilizando protocolos de mensajería comunes. ^{[ 3 ] [ 4 ] [ 5 ]} Otras herramientas similares se denominan simuladores de API , herramientas de simulación de API, dobles de prueba en la red .

La virtualización de servicios emula únicamente el comportamiento de los componentes dependientes específicos que los desarrolladores o evaluadores necesitan para completar sus transacciones de extremo a extremo. En lugar de virtualizar sistemas completos, virtualiza solo segmentos específicos del comportamiento dependiente que son críticos para la ejecución de las tareas de desarrollo y prueba. Esto proporciona la lógica de aplicación necesaria para que los desarrolladores o evaluadores obtengan lo que necesitan sin tener que esperar a que el servicio real esté completo y disponible. Por ejemplo, en lugar de virtualizar una base de datos completa (y realizar toda la gestión de datos de prueba asociada, así como configurar la base de datos para cada sesión de prueba), se supervisa cómo interactúa la aplicación con la base de datos y luego se emula el comportamiento de la base de datos correspondiente (las consultas SQL que se pasan a la base de datos, los conjuntos de resultados correspondientes que se devuelven, etc.). ^{[ 6 ] [ 7 ]}

La virtualización de servicios implica la creación y el despliegue de un "activo virtual" que simula el comportamiento de un componente real necesario para probar la aplicación en cuestión, pero al que resulta difícil o imposible acceder con fines de desarrollo y prueba.

Un recurso virtual sustituye a un componente dependiente al escuchar las solicitudes y devolver una respuesta adecuada, con el rendimiento apropiado. En el caso de una base de datos, esto podría implicar escuchar una sentencia SQL y devolver filas de datos. En el caso de un servicio web, podría implicar escuchar un mensaje XML a través de HTTP , JMS o MQ y devolver otro mensaje XML. La funcionalidad y el rendimiento del recurso virtual pueden reflejar la funcionalidad y el rendimiento reales del componente dependiente, o bien simular condiciones excepcionales (como cargas extremas o errores) para determinar cómo responde la aplicación bajo prueba en esas circunstancias.

Los activos virtuales suelen ser creados por:

• Grabación de la comunicación en tiempo real entre los componentes mientras el sistema se ejecuta desde la aplicación bajo prueba (AUT).
• Proporcionar registros que representen la comunicación histórica entre componentes.
• Análisis de las especificaciones de la interfaz de servicio (como un WSDL ).
• Definir el comportamiento manualmente con varios controles de interfaz y valores de fuente de datos.

Posteriormente, se configuran para representar datos, funcionalidades y tiempos de respuesta específicos.

Los activos virtuales se implementan localmente o en la nube (pública o privada). Con entornos de desarrollo/prueba configurados para usar los activos virtuales en lugar de componentes dependientes, los desarrolladores o evaluadores pueden probar la aplicación en la que están trabajando sin tener que esperar a que los componentes dependientes se completen o estén disponibles. ^{[ 3 ] [ 4 ] [ 7 ]}

Los analistas de la industria informan que la virtualización de servicios es más adecuada para "empresas de TI con una experiencia significativa en 'omitir' las pruebas de integración debido al 'software dependiente', y con un entorno de prueba razonablemente sofisticado. ^{[ 8 ]}

Un enfoque alternativo para sortear las restricciones de acceso al entorno de prueba descritas en la introducción de este artículo consiste en que los miembros del equipo desarrollen métodos ficticios u objetos simulados que sustituyan a los recursos dependientes. La deficiencia de este enfoque se hizo evidente a principios de la década de 2000 con el auge de la arquitectura orientada a servicios . ^{[ 9 ]} La proliferación de aplicaciones compuestas que dependen de numerosos servicios dependientes, junto con el auge del desarrollo de software ágil tras la publicación del Manifiesto Ágil en 2001, hizo cada vez más difícil para los desarrolladores o evaluadores desarrollar manualmente la cantidad, el alcance y la complejidad de los métodos ficticios o simulados necesarios para completar las tareas de desarrollo y prueba para el desarrollo de aplicaciones empresariales modernas. ^{[ 10 ]}

El primer paso en la evolución de la simulación a la virtualización de servicios fue la tecnología empaquetada en las herramientas de prueba de SOA desde 2002. ^{[ 11 ]} Las primeras implementaciones de virtualización de servicios se diseñaron para automatizar el proceso de desarrollo de emulaciones simples tipo simulación para que las aplicaciones compuestas pudieran probarse de manera más eficiente. ^{[ 12 ]} A medida que los sistemas empresariales continuaron volviéndose cada vez más complejos y distribuidos, los proveedores de herramientas de software cambiaron el enfoque de la simulación a la virtualización de servicios más centrada en el entorno. ^{[ 2 ]} Si bien la simulación aún puede completarse mediante el desarrollo y la gestión manual de simulaciones, lo que se conoce como "virtualización de servicios" se completa utilizando una de las tecnologías de virtualización de servicios comerciales disponibles (COTS) como plataforma para el desarrollo y la implementación de sus "activos de virtualización de servicios". ^{[ 10 ]}

La creciente popularidad ^{[ 13 ]} del desarrollo de software ágil y DevOps ha generado demanda de un nuevo conjunto de herramientas para ofrecer virtualización de servicios a las comunidades que trabajan de esta manera. ^{[ 14 ]} Prácticas como la entrega continua y el abandono del desarrollo en mainframes y sistemas monolíticos para adoptar arquitecturas más distribuidas basadas en microservicios se adaptan bien a las capacidades de la virtualización de servicios. Los equipos ágiles y de DevOps prefieren trabajar con herramientas ligeras que tengan menos sobrecarga acumulada y sin restricciones de licencia engorrosas. ^{[ 15 ]}

• Doble de prueba
• Gemelo digital