Proyectos

13/10/2022

/ , , , , , ,

Nueva arquitectura de microservicios e integración de sistemas

Contexto

La Universidad Nebrija es una universidad española privada e independiente que acoge a más de 12.000 alumnos internacionales, situada a la cabeza de las universidades españolas en el ámbito de la docencia.

Desde el punto de tecnologías de información, al igual que todas las empresas del sector, existen tanto sistemas corporativos como soluciones específicas de mercado para la gestión de su negocio, lo que dificulta consolidar la información entre los sistemas.

UNNE dispone de un conjunto de aplicaciones de escritorio que dan servicios de gestión de académica, matrículas de docencia, gestión de aprendizaje, campus virtuales, etc. Estos sistemas están obsoletos tecnológicamente, trabajan de forma independiente y sin conexión al resto de sistemas corporativos.

Retos

El objetivo es definir e implantar una arquitectura tecnológica que permita la integración de las diferentes soluciones de mercado implantadas, la unificación y sincronización de información, así como la migración de las aplicaciones a medida desarrolladas por UNNE.

Esta actualización tecnológica, no tanto por la tecnología en sí, tiene que hacer frente a retos muy importantes para UNNE:

  • Trabajar desde el minuto cero en el desarrollo de las integraciones para cumplir con los plazos específicos de docencia.
  • Implantar una nueva metodología de trabajo en las distintas áreas de IT.
  • Acompañar al personal técnico de UNNE en la adopción de las nuevas tecnologías a implantar, y vencer la resistencia al cambio.
  • Colaborar de forma ágil con los distintos proveedores de las soluciones de mercado ya implantadas.

La solución

Aunque inicialmente el proyecto debía ser una actualización tecnológica, desde ITERIAM se planteó un proyecto más amplio que incluyese la redefinición de procesos, nuevas metodologías de desarrollo y despliegue aprovechando la utilización de nuevas tecnologías.

Para llevar a cabo una modernización exitosa de estas aplicaciones debíamos hacer un acercamiento mixto. Por un lado, colaborar activamente con los responsables de IT para conocer la situación actual, los sistemas corporativos implantados, los posibles GAPs y limitaciones a la hora de implantar la nueva arquitectura. Por otro lado, recoger los requisitos de las integraciones más urgentes, conocer el alcance funcional y definir los procesos de integración entre los diferentes sistemas.

Las primeras integraciones a realizar correspondían al área financiera, con la integración económica de recibos de matrículas de docencia y la generación de la contabilidad correspondiente, y a la Docencia, con la integración de usuarios y la gestión de membresías de los campus virtuales impartidos por UNNE.

Para cumplir el exigente “time-to-market” trazado por el cliente, las integraciones se deben realizar en periodo estival y tienen que estar disponibles para el inicio del curso académico en septiembre, organizamos varios equipos ágiles de desarrollo, uno por cada área de integración, con un responsable técnico común en contacto directo con el equipo de IT del cliente, para definir la arquitectura, metodología de desarrollo, proponer e implantar las herramientas necesarias.

Siguiendo una arquitectura hexagonal que nos permita ir evolucionando de forma independiente conforme se vayan migrando e incorporando nuevos sistemas, se plantea una arquitectura orientada a microservicios y comunicaciones online asíncronas que permitan la integración de los sistemas mediante procesos desacoplados.

Tecnológicamente, las integraciones y aplicaciones web se realizan sobre entornos dockerizados, utilizando Vue.js para los nuevos frontales y Lavarel sobre PHP 7.3 – por requisitos del cliente – para los microservicios, sin uso de ORMs para no depender de frameworks. La comunicación se realiza a través de colas de mensajería de AWS y Mulesoft, las aplicaciones se despliegan sobre Azure integrando la seguridad con el ADFS de Microsoft 365, y gestionando el despliegue CI/CD con Azure DevOps y Jenkins.

Resultados

En un periodo aproximado de 3 meses, se aborda la integración del sistema académico y financiero, implantando la primera versión de la arquitectura que permitirá migrar de forma desacoplada las aplicaciones de escritorio obsoletas, y la sincronización de la información entre los distintos sistemas corporativos.

La involucración del área de IT desde el primer momento del proyecto permite la rápida implantación y adopción de las nuevas tecnologías en los ámbitos de desarrollo, infraestructura y sistemas.

Actualmente ITERIAM ofrece a UNNE un servicio para el desarrollo y migración del parque de aplicaciones.

Proyectos

02/10/2022

/ , , , , , ,

La mejor app para gestionar tu salud

Punto de acceso único a todos los servicios

Sanitas como empresa puntera en el ramo de salud con una cuota superior al 20% y referente en innovación en el sector evoluciona de forma continua su proyecto MiSanitas, canal de acceso para los asegurados a todos sus servicios digitales.

En 2021 el 12% de las consultas fueron digitales hasta alcanzar 782.000, con picos que superan las 4.200 diarias. Y todas esas consultas se realizan a través de MiSanitas.

Los asegurados tienen la posibilidad de realizar de forma sencilla y desde un punto único todas sus gestiones:

  • Pedir citas médicas, gestionarlas, reprogramarlas y cancelarlas
  • Buscar médicos, hospitales, centros médicos o clínicas dentales
  • Encontrar el centro de urgencia y especialista más cercano
  • Consultar el histórico de visitas al médico y las citas pendientes
  • Guardar médicos favoritos
  • Consultar informes médicos, analíticas, radiografías, etc.
  • Subir informes de otros centros para tener toda la información de salud en un solo lugar
  • Acceder a la tarjeta de salud digital (y de los hijos)
  • Hacer gestiones de la póliza, como solicitar reembolsos y autorizaciones
  • Ver los recibos y copagos en tiempo real
  • Consultar, modificar y personalizar el perfil de cada beneficiario
  • Cambiar la cuenta bancaria y periodicidad
  • Acceder a la biblioteca de consejos de salud

Escalamos los equipos de desarrollo

ITERIAM lleva cuatro años participando en este proyecto escalando el equipo del área de Digital de Sanitas mediante la conformación de squads ágiles siguiendo metodologías como Lean Startup o Scrum. Aportamos diferentes perfiles técnicos (product owners, scrum masters, líderes técnicos, UX, desarrolladores front-end, desarrolladores back-end, testers, maquetadores, etc.) y adecuamos la gestión de la demanda con un trato cercano, transparente y comprometido para cumplir con los objetivos de negocio.

La solución técnica se implementa tanto para web como app, realizando integraciones con todos los servicios digitales de la aseguradora mediante una arquitectura de microservicios y ofreciendo una magnífica experiencia de usuario al cliente.

Proyectos

01/09/2022

/ , , , , , ,

Planes de salud digitales

Contexto

Sanitas ofrece a sus asegurados distintos planes de prevención de salud, categorizados como digitales y no digitales. Los asistenciales son aquellos que el asesor puede dar de alta el plan a un cliente, y los digitales son aquellos en los que el cliente se da de alta sobre dicho programa desde la app.

Con el objetivo de ofrecer el mejor servicio a sus clientes, los asesores realizan un seguimiento individualizado de los objetivos en sus planes contratados. Sin embargo, este seguimiento resulta muy costoso para los asesores, ya que implica utilizar aplicaciones distintas dependiendo del tipo de plan, y no existe sincronización entre ambas aplicaciones.

Por ello, Sanitas se plantea el objetivo de desarrollar una única aplicación que a los asesores la gestión de todos los planes de forma conjunta, simplificando el proceso de gestión y mejorando la usabilidad del sistema.

Retos

La actualización tecnológica de un sistema no solo depende de la tecnología, es muy importante la metodología de trabajo en un proyecto de migración de entornos obsoletos a entornos actualizados. Adicionalmente, en este caso se añadía la complejidad del tiempo, ya que la nueva aplicación debería estar lista con el inicio del año fiscal.

Para la gestión de los programas digitales y asistenciales se necesita encontrar una plataforma única, flexible y escalable que le permita abordar el desarrollo de nuevos programas y la evolución y mantenimiento de los actuales, además de permitir dar de alta a no asegurados.

Además, se desea aprovechar para la creación de un nuevo programa digital preventivo para ayudar a los asegurados en la prevención de enfermedades, trabajando áreas como la nutrición, la actividad física y la promoción de hábitos saludables. Dicho plan se une a otros planes digitales que se han ido elaborando en los últimos años como nutrición, entrenador personal, embarazo o salud infantil.

La solución debe permitir mejorar los costes de licenciamiento y de servicios profesionales necesarios para el desarrollo y mantenimiento de los sistemas para poder optimizar los presupuestos disponibles.

Por último, el sistema debe sincronizarse con sistemas terceros para la actualización periódica de los datos clientes, estado de los planes, etc., facilitar al explotación de datos y el reporte de información.

La solución

Para llevar a cabo una modernización exitosa de estas aplicaciones debemos hacer un acercamiento mixto. Por un lado, colaborar activamente con los responsables de las aplicaciones para conocer todo el alcance funcional, recoger los nuevos requisitos y definir correctamente todas las integraciones entre ellas y con los sistemas corporativos. Por otro lado, analizar en profundidad el código fuente de las aplicaciones ya existentes mediante el uso de herramientas.

Con este acercamiento podemos tener un conocimiento completo de las aplicaciones para su ejecución, que se plantea en tres grandes líneas:

  • Migración de planes asistenciales al nuevo modelo de datos unificado.
  • Creación de un MVP del nuevo plan preventivo digital, incorporando funcionalidades de forma progresiva.
  • Migración de los planes digitales.

Como solución técnica se desarrolla un front-end en Angular 12, comunicado con el back-end mediante una arquitectura de microservicios Java Spring Boot sobre Docker Swarm.

Adicionalmente, se desarrollaron procesos batch (Spring Batch) para la sincronización con los sistemas terceros.

Resultados

Desde el punto de vista de los asesores, se mejora su productividad y rendimiento la disponer de un entorno unificado, mejorando la visión 360 del cliente, la gestión y la usabilidad del sistema.

Desde el punto de vista global de Sanitas, se consigue un ahorro de costes en licencias al dejar de utilizar Dynamics para la gestión de los planes asistenciales, así como una mejora importante en el time-to-market en la integración de nuevos planes.

Actualidad

26/10/2020

/ , , , ,

Diferencias entre DDD, Event Sourcing y CQRS

Hace unas semanas mi compañero Gustavo Caro hacía un repaso de cómo han ido evolucionando las arquitecturas de aplicaciones y en este artículo voy a intentar resolver algunas dudas que surgen cuando nos enfrentamos a arquitecturas orientadas a eventos.

Las arquitecturas orientadas a eventos han crecido en popularidad en los últimos años, y aunque no son un concepto nuevo ya que existen referencias a la programación dirigida por eventos que se remontan a los 70s, sí que están ganando importancia debido a las últimas tendencias en ingeniería del software.

Empecemos por el principio, una arquitectura orientada a eventos (EDA del inglés Event-Driven Architecture) es un patrón distribuido de arquitectura donde diferentes actores se comunican mediante eventos en base a roles: productores y consumidores.

Utilizando este tipo de arquitecturas, las empresas implementan sistemas flexibles que se pueden adaptar a toma decisiones y cambios en tiempo real. Los eventos se capturan a medida que ocurren y permite que productores y consumidores de eventos compartan información sobre el estado y la respuesta en tiempo real.

Los componentes en este tipo de arquitectura están altamente desacoplados lo que facilita escalar horizontalmente. También hay que remarcar el hecho de que añadir nuevos consumidores es sencillo, ya que las integraciones no son punto a punto. En la parte negativa está el hecho de que, debido a la propia naturaleza desacoplada de la arquitectura, hay que ser cuidadoso con los componentes que formen parte y las dependencias entre ellos.

Existen múltiples conceptos alrededor de este tipo de arquitecturas que a simple vista pueden parecer similares, pero te das cuenta de que no lo son cuando indagas un poco más: eventos de dominio, Event Sourcing, CQRS…

En este artículo voy a intentar aclarar las diferencias entre esos conceptos. ¡Empecemos!

Eventos de dominio

En DDD (del inglés Domain-Driven Design), los eventos de dominio se usan para describir hechos de negocio que ocurren dentro del dominio. Estos eventos son relevantes dentro del bounded context pero también para otros bounded context, permitiendo integración entre diferentes dominios.

Una importante característica de estos eventos es que deben contener un alto valor semántico expresado en el lenguaje que hablen los expertos de dominio.

Si quieres profundizar en DDD te recomiendo el siguiente artículo.

Event Sourcing

Event Sourcing hace referencia a sistemas donde el estado de la aplicación completa es almacenado como una secuencia de eventos. Aquí, el termino evento se refiere al “cambio de estado”, no es solamente una “notificación”.

Las aplicaciones persisten los eventos en un Event Store, que es una base de datos de eventos. En lugar de almacenar el estado actual de la aplicación directamente campos de una tabla en la base de datos, los eventos son almacenados cronológicamente y pueden ser usados para reconstruir el estado actual en memoria si fuera necesario.

Como ya nos decía Martin Fowler en un post original del año 2005: “Event Sourcing ensures that all changes to application state are stored as a sequence of events”

CQRS

Command Query Responsability Segregation (CQRS) es un patrón por el cual se tienen estructuras de datos separadas para leer y escribir información. CQRS no tiene que ver estrictamente con eventos, ya que se puede implementar sin hacer uso de ellos, pero es bastante común que se combine CQRS con Event Sourcing.

CQRS Diagram by Martin Fowler

La justificación de usar CQRS es que, en dominios complejos, un modelo único de lectura y escritura puede resultar muy complicado y se puede simplificar separando los modelos. Este hecho puede resultar determinante si los patrones de accesos difieren de manera considerable, como por ejemplo muchas lecturas y muy pocas escrituras.

Conclusiones

Como hemos revisado en este artículo , las arquitecturas orientadas a eventos ofrecen numerosas ventajas, pero en contrapartida los patrones a seguir son algo más complejos que en otras arquitecturas y por tanto hay que pensar bien cuándo conviene hacer uso.

Una herramienta que nos puede ser de gran ayuda en este tipo de arquitecturas es un catálogo de eventos. A medida que la aplicación crece y el número de componentes es mayor, el flujo entre los componentes se hace más difícil de seguir, así como sus interacciones. En este punto es donde un catálogo de eventos cobra importancia.

En relación al tipo de eventos (domino / event sourcing), es importante tener una idea clara del propósito y semántica que cada uno lleva, y aunque no son exclusivos y en algún punto pueden tener la misma información, es una buena practica mantenerlos separados.

En general este tipo de arquitectura puede resultar muy útil y aunque quizás sea complicado implementarlo en un sistema completo, sí que su uso en partes específicas del sistema puede ofrecernos la flexibilidad y desacoplamiento que podemos necesitar.

Actualidad

04/08/2020

/ , , , ,

La evolución de las aplicaciones: camino a los microservicios

La evolución de las aplicaciones siempre ha estado estrechamente relacionada con la evolución tecnológica y las necesidades de los usuarios y las empresas.

Del mismo modo que las organizaciones empresariales evolucionan en la forma de hacer las cosas, las aplicaciones informáticas deben seguir el mismo camino para lograr su único objetivo, satisfacer dichas necesidades y servir al usuario de la forma más eficiente. Es como un ciclo que se retroalimenta constantemente:

Esta evolución ha obligado a un cambio en los sistemas, adaptando las infraestructuras que ofrecen la disponibilidad de dichos servicios y aplicaciones, de tal forma que los usuarios que los consumen lo puedan hacer de una forma más eficiente, segura y además en remoto, es decir, disponible en internet.

Un ejemplo sencillo para mostrar que adaptarse en esta evolución es obligatorio, sería una aplicación de mensajería que tiene un éxito inesperado. Es cierto que el aumento de demanda no es sino el principio del éxito, pero también puede ser el principio del fracaso si la infraestructura que soporta dicha aplicación de mensajería no está preparada para soportar tanta demanda. En este caso, la aplicación está condenada al fracaso.


Aplicación monolítica

La característica principal de estas aplicaciones es que hacen uso de una base de código única para sus servicios y funcionalidades. Es decir, la aplicación es «responsable» de todas las tareas necesarias para realizar una determinada función.

Este tipo de aplicaciones se destacan por combinar la interfaz del usuario y la capa de acceso a los datos en el mismo programa y alojarlos en la misma máquina (o nodo).

Una de las características para tener en cuenta es el llamado escalado vertical. Si el servidor que aloja la aplicación recibe un aumento en las peticiones de usuario, es posible que los recursos existentes en la máquina sean insuficientes. La única posibilidad es aumentar los recursos en dicha máquina (RAM, espacio en disco, etc.) dentro de sus límites.

Goza de una arquitectura sencilla, puesto que toda la aplicación se aloja en el mismo nodo, donde las comunicaciones entre las distintas partes de la aplicación siempre son de forma local.

Debido a su arquitectura, las interferencias entre los componentes de la aplicación son más delicadas, y un fallo en una de sus partes puede poner en evidencia toda la aplicación.

Otra desventaja, la tenemos en la complejidad de las actualizaciones, que pueden afectar a la disponibilidad de todo el sistema durante un período de tiempo durante su despliegue.

Por el simple hecho de tener una infraestructura estática y fija por años, el mantenimiento es más costoso y es más difícil evolucionar de forma eficiente a las nuevas necesidades del mercado.

En definitiva, aunque son fáciles de desarrollar, una aplicación que aglutina toda su funcionalidad no es la mejor opción si queremos aspiraciones crecimiento complejas, más usuarios, más desarrolladores, etc.


Aplicación distribuida

Su principal cometido es tener la aplicación disgregada en múltiples nodos, dando la posibilidad de que en cada nodo exista un componente de la aplicación o un mismo componente replicado en varios nodos.

Esta arquitectura es bastante más compleja y difícil de gestionar y administrar que una aplicación monolítica. De hecho, se deben utilizar numerosas herramientas que antes no eran en absoluto necesarias. Pero esta idea de tener la aplicación distribuida en varios nodos fue un punto de inflexión, que dio lugar a conceptos muy importantes y ha favorecido de forma incuestionable la existencia de aplicaciones mucho más robustas, escalables, eficientes y seguras.

Uno de los grandes conceptos que introduce este tipo de aplicaciones es el escalado horizontal. Es decir, cuando por cuestiones de demanda los recursos actuales ya no son suficientes, en vez de aumentar los recursos de un nodo (escalado vertical), lo que se hace es incrementar el número de nodos dedicados al procesamiento de ese componente demandado. Esto es una gran ventaja ya que el límite de recursos ya no será el soportado por un nodo, sino el soportado por tantos nodos como tengamos en nuestra arquitectura.

Otro gran concepto que surge, aunque todavía no de forma automática y madura, es la llamada elasticidad. Es decir, al igual que se aumentan el número de nodos dedicados para soportar un aumento de demanda, se pueden reducir si la demanda disminuye y dejarlos disponibles para otros procesos. Este concepto contribuye a un reparto de recursos más eficiente.

La seguridad y la robustez mejoran notablemente, ya que es más probable que los problemas de seguridad de un nodo sean cercados en ese nodo, no poniendo en riesgo toda la aplicación si alguno de ellos se pone en evidencia.

Otra gran ventaja con respecto a las aplicaciones monolíticas es que las actualizaciones no conllevan desplegar toda la aplicación ya que, en este caso el despliegue será a nivel de nodo. El mantenimiento es mucho más fácil y la durabilidad de la aplicación será mayor por la facilidad de adaptación a los cambios.

Todas estas características hacen que las aplicaciones distribuidas sean ideales cuando adecuar los recursos que se deben utilizar en función de la demanda sea clave.


Arquitectura SOA

Esta arquitectura fue la que insistió en la utilización de aplicaciones distribuidas y orientadas a servicios.

La idea fue hacer que esos servicios fueran independientes, y las interacciones entre ellos se hicieran bajo ciertos protocolos estandarizados de comunicación, como WSDL y SOAP.

Esta independencia hacía posible que servicios desarrollados por diferentes tecnologías, pudiesen comunicarse entre sí, sin ningún problema.

Debido a que los servicios son más independientes, cambios en ciertos componentes de la aplicación no alteraban al resto, simplemente debían seguir cumpliendo los criterios de comunicación establecidos.


Cloud Native (Cloud Computing)

La arquitectura SOA está más enfocada a la arquitectura de la aplicación. Cloud Native se enfoca más en la arquitectura del sistema que alberga, distribuye y ofrece las aplicaciones.

Este punto de vista, lo que ofrece es básicamente el uso de recursos en la nube bajo demanda automatizada. Es decir, va a existir una elasticidad gestionada de forma automática por el sistema en la infraestructura dedicada a cada una de las aplicaciones que distribuyen. Consiguiendo que el uso de los recursos sea lo más eficiente posible.

Estas infraestructuras dinámicas dedicadas hacen posible que las aplicaciones sean resilientes antes situaciones adversas, por ejemplo, por demanda extrema, errores hardware, etc.


Arquitectura de microservicios

No existe una definición formal pero básicamente es una evolución de SOA y está orientada al trabajo con servicios muy pequeños e independientes.

El objetivo es aislar los distintos componentes de una aplicación con el fin de que cada uno sea una aplicación por sí misma.

Otra de las diferencias con SOA es la comunicación entre los servicios; Ya no sería con servicios web WSDL o SOAP, sino vía HTTP con API-REST.

Muchos beneficios suelen asociarse a los Microservicios, pero tres de los más importantes son: una entrega más rápida, escalabilidad mejorada y una mayor autonomía.

Los microservicios son el facilitador de una mayor agilidad en términos de adaptación a los cambios del mercado. Su filosofía es compatible y está directamente relacionada con procesos ágiles de desarrollo: entrega continua. Es decir, el mantenimiento de la aplicación conlleva modificaciones en los microservicios, pudiendo llevar a cabo muchas subidas a producción en un corto período de tiempo de forma independiente (continuous deliverydeploymentimprovement).

Esto aumenta la agilidad del software porque cada microservicio se convierte en una unidad independiente de desarrollo, implementación, operaciones, versiones, y escalamiento.

En realidad, aquí el término escalabilidad es algo ambiguo. Podría referirse, por ejemplo, a la escalabilidad del tiempo de ejecución del sistema, a su adaptabilidad (a un costo razonable), o a los cambios en el número de usuarios que acceden a él. O también podría referirse a poder aumentar el número de microservicios sin interferencias con los otros o a la capacidad del proceso de desarrollo para acomodar a muchos desarrolladores trabajando en paralelo.

Lo que está claro es que, con los microservicios la unidad a escalar es el servicio. Por tanto, cada uno de ellos son una unidad autónoma que pueden ser desarrollados, desplegados y operados por un equipo diferente. Por eso, suelen implementarse sobre contenedores: un microservicio en un nodo.

En estos casos, es de máxima importancia sincronizar una responsabilidad compartida entre el desarrollador y el sistema que lo alberga. Esta es la base de la filosofía DevOps.

La antigua filosofía introducida hace décadas por el principio «Divide y vencerás» ha sido puesta en práctica en innumerables ocasiones: en los algoritmos informáticos, en el envío de pequeños paquetes de datos en el protocolo IP, en la agrupación de las tareas en 7 capas en la arquitectura de red OSI, etc.

Es curioso como la misma filosofía se sigue adoptando en las infraestructuras tecnológicas actuales. Divide and win my friend 🙂



Nota. Los diagramas de las arquitecturas monolítica y de microservicios pertenecen al blog de Chris Richardson. Te animo a que lo visites para leer sus interesantes artículos.