¿Cuál es su estrategia para migrar aplicaciones en su organización?
En varios clientes a los que atendemos, existen escenarios en los que nos enfrentamos a numerosos componentes heredados en las organizaciones. Muchos de estos son cruciales y fundamentales para la operación del negocio, sin embargo, existen los desafíos de modernizarlos de la manera más adherente a las exigencias de todas las industrias del mercado.
Patrón de estrangulamiento de la aplicación
El patrón Throttle se ha vuelto muy popular y se ha documentado en el sitio web microservices.io ( https://microservices.io/patterns/refactoring/strangler- application.html), el objetivo de este patrón es hacer que las aplicaciones heredadas cambien gradualmente, cambiando los servicios de manera que los consumidores y los canales se vean afectados lo menos posible.
Etapa 1 | Los canales de consumo acceden al 100 % del Servicio heredado |
Etapa 2 | Creamos una fachada, que también es una estrategia inspirada en Pattern Façade (GOF) - https://en.wikipedia.org/wiki/Facade_pattern, pero en este caso, podemos crear una especialización de este patrón que es la API de Facade (Facade API: https://cloud. google.com/static/files/apigee/apigee-api-facade-pattern-ebook.pdf ). El objetivo de esta fachada es abstraer la comunicación entre los canales y los extremos del servicio, en este caso el acceso puede ser del 80% en componentes heredados, y del 20% en componentes ya modernizados. |
Etapa 3 | A medida que las funcionalidades del sistema heredado se modernizan en servicios más pequeños, es decir, se divide este monolito en servicios más pequeños (micro o macroservicios), digamos que en esta etapa los canales del consumidor a través de la API Façade, ahora puede acceder a muchas más funcionalidades de los servicios modernizados y ya no a todas las capacidades de los servicios heredados. |
Pasantía N | En algún momento, el resultado de esta estrategia es simplemente apagarlos legados. |
Tipos de Componentes Legacy más encontrados por nuestro equipo de Consultoría
Procedimientos almacenados y componentes de bases de datos
Hace más de 20 años, era muy común construir aplicaciones en el modelo cliente-servidor (Cliente-Servidor), que se podía dividir en dos formas: Thin Client/Fat Server y Fat Client/Thin Server. Debido a la capacidad computacional mucho mayor en el lado del servidor, el modelo Fat Server fue mucho más utilizado, lo que resultó en la creación de aplicaciones de escritorio utilizando Delphi, Visual Basic, Fox pro, Oracle Forms, accediendo a bases de datos como numerosas funciones (procedimientos almacenados) , debido al gran poder de las bases de datos en la época, por ejemplo, Oracle, que cuenta con PL/SQL, que tiene una capacidad increíble no solo para concentrar reglas de negocio sino varias funciones que facilitaban la construcción de aplicaciones sumamente robustas. Usemos aquí un ejemplo de una arquitectura hecha para un cliente con una combinación de Delphi y Oracle:
Muchos clientes tienen numerosas reglas comerciales, incluso integraciones creadas con PL/SQL. Con el tema del soporte de Windows, muchas de estas aplicaciones por ejemplo Delphi, pero incluso otras tecnologías de los años 90/2000 pueden tener problemas para seguir funcionando, por eso, algunas de estas empresas están literalmente desesperadas y la razón es "¿Cómo puedo migrar esta solución a otro sistema, teniendo en cuenta que todas mis reglas no se pueden portar?
¿Cuál fue nuestra propuesta?
Adquirir un nuevo ERP sería complejo, ya que aún existiría el problema de migrar las reglas comerciales. Entonces, ¿qué sugerimos?
1- Una nueva aplicación de una sola página de front-end con Angular, que traslada la experiencia del usuario de escritorio y agrega todas las mejoras modernas.
2- Esta nueva aplicación SPA accedería a las API REST, que actúan como fachadas para acceder a todas las funcionalidades y reglas que aún se encuentran en la base de datos de Oracle.
3: la atención se centró en las funcionalidades críticas y, con eso, los nuevos usuarios comenzaron a usar esta nueva interfaz, que interactuaba con los mismos datos que la aplicación anterior de Delphi.
4- Gradualmente, todas las funciones se trasladaron al SPA, haciéndolas 100% compatibles con las funciones de la aplicación de escritorio Delphi.
5- Con los usuarios migrados a esta nueva interfaz de usuario en la aplicación SPA, la aplicación de escritorio ya no se usa.
6- Con el uso de APIs, toda funcionalidad escrita en PL/SQL podría dar lugar a un nuevo microservicio utilizando tecnologías como docker, kubernetes, protocolos como WebSockets, etc.
7- La nueva arquitectura, además de los microservicios, ahora tiene 3 bases de datos, algunas cosas todavía en Oracle, pero también coexistiendo con MongoDB y Redis.
Beneficios para el Cliente y el Negocio
Ahorro: El cliente no necesitaba invertir en un nuevo ERP, lo que supondría una inversión importante.
Reducción del riesgo de migración y personalización: Personalizar un ERP trayendo las reglas existentes es una de las tareas más riesgosas y también más costosas para las modernizaciones en este sentido.
Mejora de la experiencia: Los usuarios han conservado la funcionalidad del escritorio, con la riqueza de una aplicación de una sola página, con todas las mejoras aplicadas por las disciplinas de UX ( experiencia de usuario).
Servicio para nuevos canales comerciales: para el acceso de terceros o socios, estos pueden integrarse a través de API que ahora actúan como una capa de entrada central para todos los servicios.
Conclusión
Este es un ejemplo del trabajo que realizamos para varios clientes, atendiendo a la particularidad de cada uno de ellos, aplicando una metodología que llamamos RNC(https://www.skalena.com/modernizacao-legados-skalena), próximamente publicaremos la Parte II de este artículo, donde hablaremos sobre estrategias para modernizar WebServices/SOAP y en la Parte III, sobre el concepto de Lift & Shift.
¿Quieres charlar, tomar un café o incluso una sesión de conversación de 30 minutos sobre estos y otros temas? Envíanos un mensaje: