Header Ads Widget

Ticker

6/recent/ticker-posts

Modernización heredada o perseguir arcoíris


 Las aplicaciones de mainframe, o aplicaciones heredadas, a menudo limitan la capacidad de una organización para responder rápidamente a los datos cambiantes y las condiciones operativas. Esto es muy evidente en la industria de servicios bancarios y financieros, donde los sistemas heredados hasta ahora han ralentizado el ritmo de la digitalización de un extremo a otro. Además de limitar la capacidad de las instituciones financieras para aprovechar nuevas oportunidades comerciales, la ausencia de una digitalización completa también ha comprometido la experiencia del cliente, un diferenciador clave en la era digital.

La innovación más rápida, mejor y más rentable es el nombre del juego para mantenerse a la vanguardia en el campo de los servicios financieros altamente competitivos. Para las instituciones financieras, la digitalización es un requisito previo fundamental para impulsar el crecimiento empresarial, fidelizar a los clientes, crear nuevas fuentes de ingresos y ampliar la cuota de mercado. Sin embargo, los bancos y las empresas financieras tradicionales están limitados por los sistemas heredados: no pueden responder rápidamente a las tendencias cambiantes y los cambios del mercado, lo que compromete su capacidad para competir con las fintech y los nuevos participantes.

En los últimos años, se ha convertido en una gran tendencia migrar aplicaciones heredadas a microservicios en todo tipo de empresas. Los microservicios son la arquitectura del día. Muchas corporaciones luchan por definir el enfoque correcto para exponer sus aplicaciones heredadas mientras mantienen el monolito estable, seguro, con el negocio funcionando como de costumbre mientras tanto.

¿Qué es "Legacy"?

Todo el mundo tiene su propia opinión sobre lo que se clasifica como legado, así que vamos a definirlo aquí. Legacy puede variar desde un mainframe hasta una aplicación monolítica. Lo que distingue a las aplicaciones heredadas es tener uno (o varios) de los siguientes atributos:

  • Falta de modularidad : las aplicaciones heredadas no son modulares ni en capas. No existe una separación clara de preocupaciones, también conocida como BBOM (Big Ball of Mud).
  • Confianza en enfoques obsoletos : los desarrolladores y las partes interesadas de la empresa que desarrollaron la aplicación heredada se han trasladado durante mucho tiempo a otros campos. Por lo tanto, nadie comprende claramente lo que sucede en la aplicación.
  • Corrección de errores insostenible : la mayoría de las correcciones de errores se manejan mediante ingeniería inversa. Hay suficientes minas terrestres aquí y allá que explotan varias veces al año.
  • Modelos de datos opacos : el modelo de datos había crecido mucho más allá de su intención hasta el punto de que nadie puede decir qué columnas (o tablas) sirven para qué propósito (si es que tienen alguno).
  • Sin seguimiento de uso : no se sabe qué aplicaciones acceden a la base de datos y obtienen los datos para su procesamiento comercial.
  • Procesos redundantes : los lotes ocasionales se ejecutan en segundo plano, realizando actualizaciones, pero nadie sabe con qué propósito.

Agregue a esta tabla, columnas y nombres de variables en la base de código en un idioma extranjero, y tendrá una receta lista para el desastre.

Dado este contexto, las empresas enfrentan muchas luchas comunes cuando comienzan la modernización del monolito para permitir la transformación digital. Como observó Bill Doerrfeld sobre las API nórdicas , “Romper el monolito al exponer aplicaciones heredadas como microservicios está de moda. Sin embargo, como las empresas se están dando cuenta rápidamente, los microservicios impulsados ​​por API traen advertencias no deseadas ”.

Enfoque de migración

Existen varios enfoques para la digitalización o la migración de mainframe; hablemos de algunos de ellos.

Re-interfaz

Este enfoque aconseja mantener la lógica empresarial en el mainframe en su forma actual, pero desbloquearla a través de API REST y servicios web. Si bien esto puede ayudarlo a comenzar rápidamente en términos de resultados comerciales y entregables iniciales, no lo lleva demasiado lejos debido a su esfuerzo poco entusiasta por proporcionar API amigables para el consumidor. La forma en que se exponen generalmente las interfaces de mainframe es fundamentalmente diferente de cómo se ve una API amigable para el consumidor . No es exagerado decir que este enfoque no es más que el proverbial "ponerle lápiz labial a un cerdo".

Volver a escribir

Una reescritura implicaría migrar los datos del mainframe y reescribir completamente los procesos comerciales en los marcos modernos. Cambiaría el idioma fuente de la aplicación original, por ejemplo, de COBOL o Natural a Java o C #. Sin embargo, la modernización de los sistemas centrales existentes a través de un enfoque de Big Bang puede no ser factible dado su potencial para interrumpir el funcionamiento habitual. Una opción menos riesgosa es adoptar un enfoque incremental para mejorar la infraestructura y agregar capacidades. Si bien, en teoría, suena como una idea noble, viene con su propio conjunto de problemas.

Monolito o microservicio

En el ejercicio de modernización heredada, la primera y más importante pregunta es: ¿necesitamos un diseño distribuido como microservicios o monolito será suficiente?

Las aplicaciones monolíticas suelen ser una propuesta mucho más económica, ya que no es necesario lidiar con toda una serie de problemas de sistemas distribuidos. La mayor desventaja de la arquitectura distribuida es la complejidad de diseñarla y desarrollarla. Se requiere mucho más tiempo y esfuerzo para construir e implementar una serie de microservicios que una aplicación monolítica. Desde el punto de vista de la confiabilidad, existe una mayor probabilidad de falla durante la comunicación entre los diferentes servicios cuando usamos microservicios. Los puntos débiles adicionales son los costos de ejecutar microservicios, así como su orquestación y monitoreo.

Para ser claros, no estoy diciendo que nunca debas usar microservicios, pero me preocupa que los microservicios se estén convirtiendo en el nuevo predeterminado. “¿No está utilizando microservicios? Bueno, entonces claramente no te tomas en serio la ingeniería de software ". Las personas ya no toman decisiones, simplemente asumen que los microservicios son el camino a seguir. Esto no siempre conduce en la dirección correcta.

En mi opinión, una arquitectura monolítica modular bien diseñada es suficiente para empezar; La arquitectura de puertos y adaptadores con una aplicación maven de varios módulos es un buen punto de partida. No es necesario introducir un límite de red como excusa para escribir un código mejor. No se requieren microservicios, ni ningún otro enfoque para modelar una pila técnica, para escribir código más limpio o más fácil de mantener. Una estructura de monolito fuerte le permitirá reemplazar cualquier segmento de aplicación con un microservicio cuando sea necesario. Probablemente deba concentrarse primero en un mejor monolito. Como dijo una vez Simon Brown, "si no puedes construir un monolito bien estructurado, ¿qué te hace pensar que los microservicios son la respuesta?"

Una vez que decida que debe pasar a un enfoque de microservicio, ya ha realizado una gran parte del trabajo de diseño por adelantado. Probablemente ya comprenda su dominio lo suficientemente bien como para poder extraerlo. Un enfoque SOA sólido comienza en el código mismo y se mueve hacia la topología física de la pila a medida que pasa el tiempo.

No eres Amazon, Twitter, Facebook o Netflix.

Como señaló Christian Posta en su publicación de blog , el viaje a los microservicios es solo eso: un viaje. Será diferente para cada empresa. No hay reglas estrictas y rápidas, solo compensaciones. Copiar lo que funciona para una empresa solo porque parece funcionar en este instante es un intento de saltarse todo el viaje, y probablemente fracasará.

El punto aquí es que su empresa probablemente no sea Netflix. De hecho, diría que, por complejo que sea el dominio en Netflix, no es tan complicado como una empresa heredada. Buscar y mostrar películas, publicar tweets, actualizar un perfil de LinkedIn, etc., es probablemente mucho más simple que los sistemas de procesamiento de reclamaciones de seguros, por ejemplo. Estas empresas de Internet migraron a los microservicios debido a la velocidad de comercialización y al gran volumen y escala. Las empresas de hoy tendrán que enfrentar la complejidad tanto en el dominio como en la escala. Este es un viaje que equilibra el dominio, la escala y los cambios organizacionales, y será diferente para cada organización.

Las organizaciones comerciales convencionales generalmente tienen un enfoque similar: crear sistemas confiables y estables que brinden valor al negocio, todo con recursos de ingeniería limitados. Los problemas con los que lidiarás dentro de estas organizaciones no son de la escala de Google, Facebook o Uber. Citando a Justin Etheredge de su artículo , “trabajar en un entorno de ingeniería enorme como Google o Netflix significa resolver problemas a gran escala con una cantidad casi insondable de recursos de ingeniería. Por lo general, tienen acceso a un gran conjunto de herramientas y bibliotecas internas en las que apoyarse y que les permiten escribir software a escala ".

Muchas herramientas innovadoras como Chaos Monkey, Kafka y Envoy nacieron de empresas como Netflix, LinkedIn y Uber. Sin embargo, ¿ha visto alguna vez este tipo de herramientas surgir de una institución financiera? Necesitamos reconocer más claramente que los departamentos de TI comunes no tienen el mismo conjunto de habilidades que el equipo de ingeniería de Netflix.

No puede migrar lo que no sabe

Sé que suena muy intuitivo, pero la cantidad de veces que las personas no logran captar este simple concepto me hace creer que merece atención. El primer obstáculo importante que las personas suelen encontrar cuando se embarcan en este viaje hacia la digitalización es la falta de conocimiento sobre la aplicación que están migrando.

Muchas organizaciones de TI "no saben lo que no saben" cuando se trata de sus aplicaciones de mainframe heredadas. En la industria de servicios financieros, el mainframe tiene un largo legado de aplicaciones que se remonta a más de 50 años. El conocimiento de programación original y los programadores que se desarrollaron en él a menudo ya no existen. Muchos necesitan una radiografía en el código de su aplicación existente para identificar las complejidades ocultas que los afectarán mientras construyen su nueva infraestructura brillante. La información de los procesos comerciales centrales y los requisitos previos o invariantes para esos procesos falta en gran medida. Revertir la ingeniería de toda la aplicación para comprenderla es un trabajo que requiere mucho tiempo y recursos, prácticamente imposible para cualquier aplicación que no sea trivial.

No se puede exagerar la necesidad de esta información, ya que no se puede migrar algo que no se conoce. Y aquí surge la necesidad de un experto en dominios; alguien que entienda la aplicación desde un punto de vista comercial o funcional. Por lo general, estas personas escasean. De hecho, muchas empresas intentan esto muchas veces porque, después de todo, la definición de cordura es repetir una estrategia fallida hasta que tenga éxito.

Experto en DDD y modelo de dominio demasiado ambicioso

El siguiente desafío al que se enfrentan los equipos a menudo es definir el enfoque correcto para descomponer su monolito heredado en microservicios. Aquí generalmente definimos un alcance para cada microservicio utilizando enfoques basados ​​en análisis de arriba hacia abajo, como Event Storming o Domain-Driven Design. Aquí es donde se necesitan expertos en DDD para facilitar esta discusión entre expertos técnicos y de dominio. En esta coyuntura crucial del proyecto, las decisiones se toman en torno a eventos, contextos delimitados y objetos de dominio, todo lo cual podría afectar profundamente su arquitectura de microservicio. Este ejercicio determinará el éxito o el fracaso de su esfuerzo de migración; obtener esta descomposición mal, y nada puede salvar el proyecto. Si está haciendo DDD, realmente necesita expertos en dominios.

Además, es bastante fácil dejarse llevar por el ejercicio DDD y desarrollar un modelo de dominio encantador, limpio y con una imagen perfecta de cómo debe comportarse su aplicación después de la migración. En el entusiasmo de la nueva arquitectura, es fácil olvidarse de adoptar un enfoque incremental. Hasta que se complete la migración de la aplicación, tanto los sistemas antiguos como los nuevos deben ejecutarse simultáneamente y mantenerse sincronizados para mantener el negocio funcionando como de costumbre. Aquí es donde la realización golpea como una roca: los modelos de dominio ambiciosos pueden funcionar muy bien para proyectos Greenfield, pero pueden no encajar bien cuando parte de su aplicación se ejecuta en el sistema anterior.

Al diseñar un nuevo modelo de dominio, las personas a menudo pasan por alto el hecho de que su nuevo modelo todavía debe funcionar con los datos existentes. Por ejemplo, puede introducir nuevos atributos, pero esos atributos no pueden ser obligatorios porque no tiene esa información para los registros existentes en el sistema anterior. Por ejemplo, si su aplicación heredada no almacena la información de género de su cliente, no puede tener un atributo de género obligatorio en su nuevo modelo actualizado.

Una buena prueba es verificar que las tablas de bases de datos existentes puedan adaptarse a su nuevo modelo de dominio. Necesitará que esto funcione si desea migrar datos de todos modos, y los conocimientos adquiridos serán útiles. Además, este ejercicio también evitará que realice asociaciones incorrectas. Por ejemplo, si en el sistema anterior tiene asociaciones como Familia tiene Familia-Miembros y Familia tiene vehículos; en el nuevo sistema no se pueden tener asociaciones como Familia tiene Familia-Miembros y Familia-Miembros tienen vehículos. Después de todo, ¿cómo obtendrá los miembros de la familia individuales para los vehículos existentes?

Sincronización de datos entre el sistema antiguo y el nuevo

Como dijo Tim Berners-Lee, "los datos son algo precioso y durarán más que los propios sistemas". En sus esfuerzos de migración, llegará a un punto en el que tendrá que mantener sincronizados los datos entre sus sistemas antiguo y nuevo, y aquí es donde surge una nueva serie de problemas.

CDC / Captura de datos modificados

A menudo se sugiere CDC (Change-Data-Capture) como una solución para mantener sincronizados los almacenes de datos antiguos y nuevos. Para beneficio de los no iniciados, CDC es la transmisión de cambios en la base de datos siguiendo el registro de transacciones. Pero lo que la gente a menudo no aprecia es que CDC funciona cuando tiene el mismo modelo de datos (piense en la replicación de datos en varias instancias) o unas pocas tablas y columnas (piense en otro microservicio que almacene en caché sus datos para facilitar el acceso).

Tratar de usar CDC para sincronizar datos en dos modelos de datos (en diferentes almacenes de datos) que son tremendamente diferentes entre sí en términos de nombres de tablas, nombres de columnas, claves externas y relaciones es una tarea no trivial. Esto empeora si tiene identidades diferentes en los almacenes de datos antiguos y nuevos, por ejemplo, si tiene UUID en el nuevo sistema y alguna identificación alfanumérica en el sistema anterior. Ahora tiene un caso de uso no trivial de crear tablas de mapeo para identificar qué Id en el nuevo sistema corresponde a qué Id en el sistema anterior. Si el modelo de datos es significativamente diferente, es posible que no haya una relación uno a uno entre estos identificadores.

Agregue a estas preocupaciones una falta de conocimiento sobre el propósito que cumplen estos sistemas, y tiene una receta para el desastre. El uso de tecnologías como la captura de datos modificados, ETL, mensajería y duplicación de datos a menudo no llega a la integración en tiempo real con las aplicaciones centrales de mainframe que necesitan las empresas de ritmo rápido y las expectativas de los clientes.

Escrituras dobles

Otra solución que se sugiere a menudo en tales escenarios es la escritura dual; desde la aplicación migrada, escribimos tanto en el modelo de datos heredado como en el nuevo. Sin embargo, simplemente emitir estas dos solicitudes puede dar lugar a posibles inconsistencias. La razón es que no podemos tener una transacción compartida que abarque ambas aplicaciones. En circunstancias desafortunadas, podemos terminar teniendo el nuevo registro persistente en la nueva base de datos pero no haber enviado el registro correspondiente a un sistema heredado (por ejemplo, debido a algún problema de red). O, al revés, es posible que hayamos enviado el mensaje al legado pero no pudimos conservar los datos en la base de datos local. Transacción de compensación / Sagas no funcionará; ¿Qué pasa si no tiene una identificación devuelta de legacy? ¿Qué pasa si alguien realmente ha visto esos datos? Todas estas situaciones son indeseables. Por supuesto,

De manera similar, suponga que después de un tiempo se da cuenta de que sus dos almacenes de datos se han vuelto inconsistentes entre sí. En ese momento, ¿quién decide cuál es la correcta? ¿Hubo un error en su código de persistencia para el legado o en su código de persistencia para el nuevo almacén de datos?

Para agregar más, para los requisitos de auditoría, ¿cuál era la marca de tiempo cuando se creó la entidad? ¿Es la marca de tiempo de su inserción en el almacén de datos heredado o la hora de su inserción en el nuevo almacén de datos?

La moraleja de la historia es que los datos, la integración de datos, los límites de los datos, los patrones de uso empresarial, la teoría de los sistemas distribuidos y el tiempo son las partes difíciles de los microservicios (¡ya que los microservicios son en realidad solo sistemas distribuidos! Teniendo esto en cuenta, mi sugerencia debería ser que el modelo de datos sea el último en evolucionar. Una vez que tengamos nuestra funcionalidad, modularidad e integración resueltas, lo más probable es que tengamos más sabiduría para ayudar a decidir cómo abordar el modelo de datos heredado. Una buena base de código modular, especialmente las clases de repositorio y DAO, puede ayudarlo con una transición sin problemas si finalmente decide migrar a un nuevo modelo de datos.

Conclusión

No se puede negar que los sistemas heredados requieren modernización; de lo contrario, son vulnerables a bloqueos en cualquier momento. Como lo corroboró The Washington Post , eso es lo que sucedió el Día de los Impuestos de 2018. Ante problemas técnicos, el Servicio de Impuestos Internos no pudo procesar las declaraciones de impuestos presentadas electrónicamente. Aunque el IRS no especificó qué salió mal, el hecho de que muchos de sus sistemas de TI estaban desactualizados en ese momento, dos de ellos con casi seis décadas de antigüedad, podría haber contribuido a la falla informática.

El software heredado suele ser difícil (o imposible) de mantener, respaldar, mejorar o integrar con los nuevos sistemas debido a su arquitectura, tecnología subyacente o diseño. Según lo informado por The Business of Federal Technology (FCW), en 2019, el gobierno federal de los EE. UU. gastó el 80 por ciento del presupuesto de TI en operaciones y mantenimiento. Este gasto incluyó principalmente sistemas heredados obsoletos, que plantearon problemas de eficiencia, ciberseguridad y riesgo de misión. Para poner eso en contexto, solo el 20% de la financiación de TI se asignó al desarrollo, la modernización y la mejora. Entonces, podemos concluir que la tecnología heredada es una barrera importante para la transformación digital. Por lo tanto, la modernización heredada es una solución natural al problema. Aun así, debemos pensar detenidamente cómo abordar el problema y llegar a una solución razonablemente buena.

Publicar un comentario

0 Comentarios