Modernización de sistemas centrales e intermedios con Azure Logic Apps
En esta guía se describe cómo su organización puede aumentar el valor empresarial y la agilidad mediante la modernización de los entornos de sistema central y de rango medio mediante Azure Logic Apps. El mundo empresarial actual está experimentando una era de hiper innovación y está en una búsqueda permanente para obtener eficiencias empresariales, reducción de costos, crecimiento y alineación empresarial. Las organizaciones buscan formas de modernizarse y una estrategia eficaz es aumentar el valor empresarial de los recursos heredados existentes.
Para las organizaciones con inversiones en sistemas centrales e intermedios, esto significa hacer el mejor uso de las plataformas que enviaron humanos a la luna o ayudaron a crear mercados financieros actuales y ampliar su valor mediante la nube y la inteligencia artificial (IA). Este escenario es donde Azure Logic Apps y sus funcionalidades nativas para la integración con sistemas centrales y de rango medio entran en juego abriendo la puerta al mundo de la inteligencia artificial para inversiones heredadas. Entre otras características, Azure Logic Apps incorpora las funcionalidades principales de Host Integration Server (HIS), que se ha usado para la integración de sistemas centrales y de rango medio en el núcleo de los clientes más estratégicos de Microsoft durante más de 20 años. Como resultado, Azure Logic Apps se ha convertido en una plataforma de integración como servicio (iPaaS) para sistemas centrales.
Cuando los desarrolladores empresariales compilan flujos de trabajo de integración con Azure Logic Apps, pueden entregar aplicaciones nuevas de manera más rápida con poco o menos código personalizado. Los desarrolladores que usan Visual Studio Code y Visual Studio pueden ser más productivos que los que usan las herramientas y tecnologías de desarrollo del sistema central de IBM, ya que no requieren conocimientos sobre los sistemas centrales y la infraestructura. Azure Logic Apps permite a los analistas de negocios y a los responsables de la toma de decisiones analizar e informar más rápidamente sobre la información heredada fundamental. Pueden acceder directamente a los datos de los orígenes de datos del sistema central, lo que elimina la necesidad de que los desarrolladores del sistema central creen programas que extraigan y conviertan las complejas estructuras del sistema central.
Funcionalidades nativas de nube para la integración del sistema central e intermedio
Desde 1990, Microsoft ha proporcionado integración con sistemas centrales e intermedios a través de Microsoft Communications Server. La evolución adicional de Microsoft Communications Server creó Host Integration Server (HIS) en 2000. Mientras HIS comenzó como una puerta de enlace de arquitectura de redes del sistemas (SNA), HIS se expandió para incluir almacenes de datos de IBM (DB2, VSAM e Informix), sistemas de transacciones de IBM (CICS, IMS e IBM i) y mensajería de IBM (serie MQ). Los clientes estratégicos de Microsoft han usado estas tecnologías durante más de 20 años.
Para permitir a los clientes que ejecutan aplicaciones y datos en Azure para seguir usando estas tecnologías, Azure Logic Apps y Visual Studio han incorporado gradualmente estas funcionalidades. Por ejemplo, HIS Designer para Logic Apps que se ejecuta en Visual Studio y la herramienta de diseño 3270, le ayudan a crear artefactos de metadatos necesarios para los conectores integrados que se usan para la integración de sistemas centrales y de rango medio en Azure Logic Apps. Estos conectores integrados se ejecutan con los mismos recursos de proceso que los flujos de trabajo de aplicación lógica estándar. Este diseño no solo le permite lograr escenarios de baja latencia, sino que también amplía su alcance para abordar más necesidades de recuperación ante desastres y alta disponibilidad del cliente.
Para obtener más información sobre las funcionalidades de Microsoft para la integración de sistemas centrales e intermedios, continúe con las secciones siguientes.
Microsoft HIS Designer para Logic Apps
Esta herramienta crea artefactos de metadatos del sistema central e intermedio para Azure Logic Apps y funciona con Microsoft Visual Studio proporcionando un diseñador gráfico para poder crear, ver, editar y asignar objetos de metadatos a artefactos del sistema central. Azure Logic Apps usa estos mapas para reflejar los programas y los datos en sistemas centrales e intermedios. Para obtener más información, consulte HIS Designer para Logic Apps.
Herramienta de diseño 3270 de Microsoft
Esta herramienta registra pantallas, rutas de navegación, métodos y parámetros para las tareas de la aplicación para poder agregar y ejecutar esas tareas como acciones del conector 3270. Aunque HIS Designer para Logic Apps tiene como destino sistemas transaccionales y datos, la herramienta de diseño 3270 tiene como destino aplicaciones 3270. Para obtener más información, consulte Herramienta de diseño 3270.
Conectores de Azure Logic Apps para sistemas centrales e intermedios de IBM
En las secciones siguientes se describen los conectores integrados basados en proveedores de servicios que puede usar para acceder a sistemas centrales e intermedios de IBM e interactuar con ellos al crear flujos de trabajo estándar en Azure Logic Apps.
Nota:
Aunque algunos de los siguientes conectores están disponibles como conectores "compartidos" que se ejecutan en Azure global, esta guía se centra en los conectores integrados basados en proveedores de servicios, que solo están disponibles cuando se crean flujos de trabajo estándar en Azure Logic Apps.
IBM 3270
Este conector de Azure Logic Apps para 3270 permite que los flujos de trabajo estándar accedan a las aplicaciones del sistema central de IBM y las ejecuten; estas normalmente se controlan mediante la navegación a través de pantallas del emulador 3270. El conector usa la secuencia TN3270. Para obtener más información, consulte Integración de aplicaciones controladas por pantallas 3270 en sistemas centrales de IBM con Azure mediante Azure Logic Apps y el conector para IBM 3270.
Customer Information Control System (CICS) de IBM
Este conector de Azure Logic Apps para CICS proporciona flujos de trabajo estándar con la capacidad de interactuar e integrarse con programas CICS mediante varios protocolos, como TCP/IP y HTTP. Si necesita acceder a entornos CICS mediante LU6.2, debe usar Host Integration Server (HIS). Para obtener más información, consulte Integración de programas CICS en sistemas centrales de IBM con flujos de trabajo estándar en Azure Logic Apps mediante el conector CICS de IBM.
IBM DB2
Este conector de Azure Logic Apps para DB2 permite conexiones entre flujos de trabajo estándar y bases de datos DB2 locales o en Azure. El conector ofrece a profesionales de TI empresariales y desarrolladores acceso directo a información fundamental almacenada en sistemas de administración de bases de datos DB2. Para obtener más información, consulte Acceso y administración de recursos de IBM DB2 mediante Azure Logic Apps.
Archivos de host de IBM
Este "conector" de Azure Logic Apps para archivos de host proporciona un contenedor fino alrededor de la característica "Analizador de archivos planos" en Host Integration Server. Este "conector" sin conexión proporciona operaciones que analizan o generan datos binarios hacia archivos de host y hacia ellos. Estas operaciones requieren que estos datos provengan de cualquier desencadenador u otra acción que genere datos binarios. Para obtener más información, consulte Análisis y generación de archivos de host de IBM mediante Azure Logic Apps.
IBM i
Este conector de Azure Logic Apps para IBM i permite que los flujos de trabajo estándar interactúen e integren con programas COBOL y RPG que se ejecutan en sistemas IBM i mediante TCP/IP. Si necesita acceder a entornos de IBM i mediante LU6.2, debe usar Host Integration Server (HIS). Para obtener más información, consulte Integración de programas COBOL y RPG en midranges de IBM con flujos de trabajo estándar en Azure Logic Apps mediante el conector IBM i.
Information Management System (IMS) de IBM
Este conector de Azure Logic Apps para IMS usa el componente IBM IMS Connect, que proporciona acceso de alto rendimiento desde flujos de trabajo estándar a transacciones IMS mediante TCP/IP. Este modelo usa la cola de mensajes de IMS para procesar los datos. Para obtener más información, consulte Integración de programas IMS en sistemas centrales de IBM con flujos de trabajo estándar en Azure Logic Apps mediante el conector IMS de IBM.
IBM MQ
Este conector de Azure Logic Apps para MQ permite conexiones entre flujos de trabajo estándar y un servidor IBM MQ local o en Azure. Microsoft también proporciona funcionalidades de integración de IBM MQ con Host Integration Server y BizTalk Server. Para obtener más información, consulte Conexión a un servidor de IBM MQ desde un flujo de trabajo en Azure Logic Apps.
Desafíos para la modernización de sistemas centrales e intermedios
Los sistemas centrales e intermedios pueden hospedar varios entornos que contienen programas, datos, archivos y herramientas. A lo largo de los años, es posible que estos entornos no se hayan refactorizado o se hayan dejado crecer y alcanzar sus límites, a pesar de las actualizaciones de hardware. Estos entornos también podrían haber sido mantenidos por varios desarrolladores y administradores de TI, que siguen diferentes patrones de programación y técnicas, o bien contrataron a otras partes para ayudar con tareas que requieren experiencia escasa en el mercado. Junto con un grupo de profesionales experimentados, todos estos factores crean un trabajo complejo y desafiante de modernizar entornos de sistema central y de rango medio.
Aunque la lista siguiente no es completa, la definición de una estrategia de modernización correcta incluye mínimamente formas de controlar las siguientes tareas:
- Mantener los indicadores y objetivos actuales de nivel de servicio para sus entornos.
- Administrar la coexistencia entre los datos heredados junto con los datos migrados.
- Realización de DevOps en entornos durante la coexistencia.
- Administrar las interdependencias de la aplicación.
- Definir el futuro del programador y los trabajos del sistema central.
- Definir una estrategia para reemplazar productos comerciales (COTS).
- Realizar actividades de pruebas funcionales y no funcionales híbridas.
- Mantener dependencias o interfaces externas.
Teniendo en cuenta estas tareas, los clientes suelen elegir cualquiera de las siguientes rutas de acceso para llevar a cabo la modernización de sistemas centrales y de rango medio:
Big bang
Este enfoque se basa principalmente en el modelo de entrega de software en cascada, pero con iteraciones en fases. El enfoque big bang es adoptado más por los clientes con sistemas de sistema central pequeños o intermedios y entornos de baja complejidad debido a un bajo número de líneas de código, baja densidad de aplicaciones y sistemas heredados conocidos o lenguajes de programación.
Ondas Agile
Este enfoque sigue los principios Agile de la ingeniería de software. El enfoque de las ondas ágiles es adoptado más por los clientes con sistemas centrales o de rango medio más grandes y entornos de alta complejidad debido a un gran número de líneas de código, alta densidad de aplicaciones, sistemas menos conocidos o lenguajes de programación, y un gran número de dependencias e interfaces.
La elección entre estas rutas de acceso depende de las necesidades y los escenarios de su organización. Cada ruta de acceso tiene ventajas y desventajas que se deben tener en cuenta. En las secciones siguientes se proporciona más información sobre estos enfoques de modernización.
Big Bang o cascada
Normalmente, una migración en big bang tiene las siguientes fases:
Visualización: inicio
Planificación: identifique y prepare los resultados de planificación, como el ámbito, el tiempo y los recursos.
Compilación: comienza una vez aprobados los resultados de planificación.
Esta fase también espera que se haya identificado todo el trabajo de las dependencias y, a continuación, se puedan iniciar las actividades de migración. Se producen varias iteraciones para completar el trabajo de migración.
Estabilización o pruebas: comienza cuando el entorno migrado, las dependencias y las aplicaciones se prueban en las regiones de prueba del entorno del sistema central.
Implementación: después de aprobar todo, la migración pasa a producción.
Las organizaciones que suelen elegir este enfoque se centran en el tiempo de bloqueo, el ámbito de la migración y los recursos. Esta ruta parece una opción positiva, pero incluye los siguientes riesgos:
Las migraciones pueden tardar meses o incluso años.
Las implementaciones en producción son más arriesgadas.
El análisis que se realiza al principio del recorrido de migración o durante la planeación ya no es preciso porque esa información suele estar obsoleta.
Las organizaciones suelen centrarse en tener documentación completa para reducir los riesgos de entrega para la entrega.
Sin embargo, el tiempo dedicado a proporcionar artefactos de planificación provoca exactamente el efecto opuesto. Centrarse en planear más que en ejecutar tiende a crear retrasos en la ejecución, lo que provoca un aumento de los costos a largo plazo.
Ondas Agile
Un enfoque Agile está orientado a los resultados y se centra en la compilación de software y no en la planificación de resultados. Las primeras fases de una entrega ágil podrían ser caóticas y complejas para las barreras organizativas que necesitan desglosarse y alinear el equipo de migración. Sin embargo, después de que el equipo de migración madura después de varios sprints de ejecución, el recorrido se vuelve más suave. El objetivo de este enfoque es publicar con frecuencia características en producción y proporcionar valor empresarial antes que con un enfoque de big bang.
Normalmente, una migración de ondas Agile tiene los siguientes sprints:
Sprint cero (0)
- Defina el equipo, un trabajo pendiente inicial y las dependencias principales.
- Identifique las características y un producto viable mínimo (MVP) que se va a entregar.
- Inicie la preparación del sistema central con un conjunto seleccionado de elementos de trabajo o casos de usuario para comenzar el trabajo.
Sprint 1, 2, ..., N
Cada sprint tiene un objetivo en el que el equipo mantiene una mentalidad de envío, lo que significa que se centran en completar los objetivos de migración y publicar resultados en producción. El equipo puede usar un grupo de sprints para ofrecer una característica específica o una ola de características. Cada característica incluye segmentos de cargas de trabajo de integración.
Existen elementos compartidos, como trabajos e interdependencias, y tienen impacto en todo el entorno. Una estrategia correcta se centra en habilitar parcialmente los trabajos, rediseñar las aplicaciones para la modernización y dejar los sistemas con la mayoría de las interdependencias hasta el final para reducir primero la cantidad de trabajo de migración y, a continuación, completar el ámbito del esfuerzo de modernización.
Microsoft recomienda modernizar las cargas de trabajo del sistema central y de rango medio siguiendo un modelo iterativo basado en oleadas ágiles centrándose en las inversiones en la nueva plataforma, al tiempo que limita el crecimiento de los sistemas heredados. Este enfoque reduce considerablemente los riesgos de implementación conservando el valor empresarial existente, al tiempo que introduce el entorno modernizado. De este modo, su equipo también puede aprovechar las aptitudes tecnológicas que ayudan a su negocio a ser más competitivo. Este escenario es donde Azure Logic Apps puede ayudarle en el recorrido de modernización.
Patrones de modernización
Un buen diseño incluye factores como la consistencia y la coherencia en el diseño y la implementación de componentes, la capacidad de mantenimiento para simplificar la administración y el desarrollo, y la reutilización que permite a otras aplicaciones y escenarios reutilizar componentes y subsistemas. En el caso de las aplicaciones y los servicios hospedados en la nube, las decisiones tomadas durante la fase de diseño e implementación tienen un gran impacto en la calidad y el costo total de propiedad.
El Centro de arquitectura de Azure proporciona patrones de diseño e implementación probados que describen el problema que abordan, consideraciones para aplicar el patrón y un ejemplo basado en Microsoft Azure. Aunque existen varios patrones de diseño e implementación, algunos de los patrones más relevantes para la modernización del sistema central incluyen los patrones la "Capa anticorrupción", "Saga", "Choreography" y "Strangler Fig".
Patrón de capa anticorrupción
Independientemente del enfoque de modernización que seleccione, debe implementar una "capa anticorrupción" mediante Azure Logic Apps. Este servicio se convierte en la capa de fachada o adaptador entre el sistema heredado del sistema central y Azure. Para obtener un enfoque eficaz, identifique las cargas de trabajo del sistema central para que se integren o coexistan como cargas de trabajo de integración del sistema central. Cree una estrategia para cada carga de trabajo de integración, que es el conjunto de interfaces que debe habilitar para migrar una aplicación de sistema central.
Para obtener más información, consulte Capa anticorrupción.
Patrón Fig Strangler
Después de implementar la capa anticorrupción, la modernización se produce progresivamente. Para esta fase, debe usar el patrón "Strangler Fig" en el que se identifican las cargas de trabajo o las características del sistema central que puede modernizar de manera incremental. Por ejemplo, si decide modernizar una aplicación CICS, debe modernizar no solo los programas CICS, sino que probablemente las aplicaciones 3270 junto con sus correspondientes dependencias externas, datos y trabajos.
Finalmente, después de reemplazar todas las cargas de trabajo o características del sistema central por el nuevo sistema, finalizará el proceso de migración, lo que significa que puede retirar el sistema heredado.
Para obtener más información, consulte Patrón Strangler Fig.
Patrones Saga y Choreography
Las transacciones distribuidas, como el protocolo de confirmación en dos fases (2PC), requieren que todos los participantes de una transacción la confirmen o reviertan antes de que la transacción pueda continuar. Las arquitecturas híbridas en la nube funcionan mejor si parten de un paradigma de coherencia final en lugar de un modelo de transacción distribuida.
El patrón de diseño "Saga" es una forma de administrar la coherencia entre los servicios en escenarios de transacciones distribuidas. Una saga es una secuencia de transacciones que actualiza cada servicio y publica un mensaje o evento para desencadenar el siguiente paso de la transacción. Si se produce un error en un paso, la saga ejecuta transacciones de compensación que contrarrestan las transacciones anteriores. Para obtener más información, consulte Patrón Saga de transacciones distribuidas.
En Azure Logic Apps, los flujos de trabajo pueden actuar como coreógrafos para coordinar sagas. Las acciones de flujo de trabajo son atómicas, por lo que puede volver a ejecutarlas individualmente. El tipo de acción Ámbito proporciona la capacidad de ejecutar un grupo de acciones solo después de que otro grupo de acciones se realice correctamente o produzca un error. Azure Logic Apps realiza transacciones compensatorias en el nivel de ámbito, mientras que Azure Event Grid y Azure Service Bus proporcionan la administración de eventos necesaria para dominios específicos. Todos estos servicios, que componen Azure Integration Services, proporcionan la compatibilidad necesaria para los clientes cuando necesitan una plataforma de integración fiable para escenarios críticos. Para obtener más información, consulte Patrón Choreography.
Aunque en este artículo se tratan varios patrones de modernización, las soluciones complejas requieren muchos más patrones y comprender claramente los objetivos de modernización de la organización. Aunque la tarea de ampliar el valor de los activos heredados es difícil, esta opción es la mejor manera de conservar la inversión en estos activos y prolongar su valor empresarial.