Jump to section

Los microservicios respaldan la integración de la TI en el sector de la salud

Copiar URL

Los microservicios permiten que los desarrolladores de varios sectores, como el de la salud, creen aplicaciones compuestas por servicios sin conexión directa, lo cual facilita los procesos de desarrollo, prueba, implementación y actualización. Debido a las ventajas que ofrecen, los desarrolladores del sector de la salud los prefieren frente a la generación anterior de tecnología de integración de la TI: el bus de servicios empresariales (ESB).

Al igual que en cualquier otra empresa de gran tamaño, el entorno de TI de un organismo de salud consiste en un conjunto cada vez más grande de diferentes sistemas que deben compartir datos esenciales. Los datos pueden ser vitales durante una emergencia médica. Por eso, todos los sistemas necesitan comunicarse entre sí, desde los de programación, laboratorio, radiología y facturación hasta los de admisión, alta y transferencia (ADT).

Si bien los proveedores de atención médica ya adoptaron la historia clínica digital (EHR), esta tiene un valor limitado si no se pueden compartir los datos entre todas las aplicaciones. El desafío de la integración de los sistemas de la salud se remonta al año 1987, cuando se estableció el estándar internacional Health Level Seven (HL7) para la transferencia de datos clínicos y administrativos entre las aplicaciones que se utilizan en el sector. Luego de adoptar este lenguaje común, surgió la necesidad de conectar las aplicaciones para que se pudieran comunicar por medio de HL7.

Hace varios años, los especialistas en TI descubrieron que las conexiones directas de punto a punto entre ellas no eran prácticas y presentaban cada vez más desafíos a medida que crecía la empresa. Además, a pesar de que HL7 ofrece un formato universal, no había una forma estándar de interpretar los campos, así que se requería transformar los datos y la conectividad para que admitieran la comunicación entre los sistemas de salud.

La primera tecnología de integración que adoptaron los proveedores de atención médica fue el motor de interfaz (IE), un servidor central para todos los sistemas de un hospital. Estos se conectaban con el motor, el cual transformaba los datos y los enviaba a los demás sistemas según fuera necesario. Luego, hace unos 20 años, surgió el bus de servicios empresariales (ESB), que trabajaba de manera similar al motor de interfaz, es decir, como un núcleo para intercambiar datos entre las aplicaciones del sector de la salud, principalmente por medio de HL7. El ESB permite transformar los datos y convertir los protocolos, ofrece funciones de gestión y supervisión sencillas, y es compatible con los servicios web, JMS, HTTP y SOAP. Durante dos décadas, fue la solución de integración más popular, tanto en la salud como en otros sectores.

Desde que surgió el bus de servicios empresariales, el desarrollo de aplicaciones ha evolucionado de forma considerable. Uno de los cambios más importantes es la adopción del desarrollo ágil y DevOps, con lo cual se dejó de lado esta solución.

Los procesos de DevOps representan un ciclo de vida de desarrollo basado en cambios graduales y pruebas automatizadas permanentes. Con estas prácticas, las características que hacían del bus de servicios empresariales una opción tan popular se convirtieron en un obstáculo. En él, todas las integraciones se implementan en un solo lugar; y si bien esto solía ser una ventaja, ahora es lo que lo hace incompatible con DevOps.

En el entorno de desarrollo moderno, el ESB presenta estas limitaciones:

  • No es compatible con los desarrolladores ágiles ni con las herramientas de DevOps: muchos de los desarrolladores actuales salen de la universidad listos para trabajar en los entornos de DevOps y son más productivos cuando utilizan sus herramientas preferidas (es decir, las soluciones más recientes de DevOps). Sin embargo, los ESB no son compatibles con ellas.
  • Los cambios afectan a todo el sistema: cuando se debe realizar algún cambio en las reglas del bus, incluso si se trata de una modificación pequeña, se debe detener todo el motor. Las aplicaciones que interactúen con el ESB experimentarán un tiempo de inactividad problemático e improductivo, y cualquier error que se produzca debido a un cambio podría afectar a todas las integraciones. Como resultado, los equipos adoptan una actitud contraproducente y se resisten a implementar actualizaciones y correcciones.
  • Es un punto único de fallo: dado que todas las integraciones se enrutan a través del mismo núcleo, el bus representa un punto único de fallo para toda la empresa. Si este deja de funcionar, fallarán todas las integraciones.
  • No permite automatizar las pruebas: las pruebas automatizadas son un elemento clave de DevOps. En este tipo de prácticas, se aplica la automatización para probar cada actualización de forma independiente y, de esta manera, evitar la interrupción del proceso de desarrollo. Sin embargo, la interfaz gráfica de usuario y el control de versiones propietarios impiden hacerlo en el ESB.

Al igual que otros sectores, el de la salud incorporó las prácticas modernas de desarrollo ágil, microservicios y DevOps. Esta tendencia se extendió a la integración de los sistemas sanitarios, ya que las aplicaciones y los puntos de contacto digitales nuevos deben lograrla por medio de HL7, REST y otros protocolos. Los desarrolladores de microservicios en el sector de la salud no solo buscan controlar sus integraciones junto con el resto del código que desarrollan (por ejemplo, los datos, la transmisión, la interfaz gráfica del usuario, la infraestructura de mando y control, etc.), sino también empaquetar todos los cambios en unidades que puedan implementarse y trasladarse por el canal de integración y distribución continuas (CI/CD). Las limitaciones mencionadas anteriormente imposibilitan el objetivo de CI/CD entre los códigos de integración y otros.

Los microservicios son el futuro del desarrollo, ya que permiten que los desarrolladores creen aplicaciones e integraciones utilizando los elementos básicos de servicios sin conexión directa. Los ESB, por el contrario, no son compatibles con esta realidad debido a que son monolíticos. Cuando las aplicaciones se dividen en módulos independientes, resulta más sencillo desarrollarlas, probarlas, aplicar cambios, volver a realizar las pruebas, corregirlas, implementarlas, probarlas en la producción, actualizarlas y mucho más.

Los microservicios posibilitan la adopción de DevOps porque permiten realizar pruebas automatizadas. Dado que constituyen elementos pequeños, es posible ubicarlos fácilmente en contenedores para automatizar el proceso de pruebas y favorecer la integración y distribución continuas (CI/CD). En cambio, un ESB monolítico es demasiado grande para alojarse en un contenedor y no puede desglosarse en elementos más pequeños, por lo que no se puede probar de la misma manera.

Sin embargo, la razón más importante para optar por la integración basada en microservicios probablemente sea que respalda a los desarrolladores ágiles y les permite utilizar sus herramientas de DevOps favoritas. Si se eliminan los ESB, pueden trabajar en el entorno de desarrollo ágil que prefieren y con el que están familiarizados. No tendrán que capacitarse para utilizar un sistema propietario y podrán adoptar un enfoque de desarrollo más productivo.

Además, los microservicios permiten que los desarrolladores exploren sus propias necesidades de integración, lo cual democratiza este proceso y evita que se limite a un solo equipo de especialistas en ESB. Nadie comprende mejor los requisitos de datos de una aplicación que sus propios desarrolladores.

Los microservicios también respaldan la gestión de las API y permiten la integración con ellas cuando sea necesario.

A su vez, la integración basada en microservicios ofrece las mismas ventajas que obtendría de un ESB, como la transformación gráfica y la lógica para crear reglas sofisticadas sobre el flujo de los datos en la empresa. Por ejemplo, si le gustan los lienzos de desarrollo gráfico del bus, encontrará algunos similares que admiten la integración basada en microservicios.

La integración basada en microservicios ofrece muchos beneficios:

  • Supervisión y gestión integrales: los microservicios se pueden supervisar a través de las herramientas de vanguardia que los desarrolladores ágiles prefieran (como Kibana, Elasticsearch, Grafana, Prometheus, etc.), a fin de detectar fallas y resolver los problemas antes de que afecten a la empresa.
  • Pruebas automatizadas: una de las principales ventajas de los microservicios y DevOps es la posibilidad de realizar este tipo de pruebas. Cada integración se considera un elemento independiente durante el proceso de prueba, por lo que no se interrumpe ningún otro componente ni se perjudica a las demás aplicaciones.
  • Software de calidad superior: los procesos más eficientes y las pruebas mejoradas permiten producir un software de mayor calidad.
  • Desarrollo agilizado: podrá agilizar el ciclo de vida de desarrollo si elimina los procesos manuales y optimiza el proceso de desarrollo de las integraciones con la automatización y DevOps.
  • Mayor capacidad de adaptación: como las aplicaciones están compuestas de módulos independientes, cada servicio se puede ajustar por separado, sin afectar al resto de la aplicación.
  • Innovación optimizada: los microservicios y DevOps permiten que los desarrolladores diseñen soluciones de integración innovadoras para que la empresa pueda incorporar servicios nuevos y mejorados para los clientes.
  • Agilidad empresarial: el desarrollo ágil siempre mejora la capacidad de la empresa para reaccionar rápidamente ante los cambios en el mercado. Por ejemplo, los requisitos de intercambio de datos de los nuevos proveedores o partners se pueden abordar con rapidez si el equipo de desarrollo ágil utiliza los microservicios para diseñar las integraciones que respalden las relaciones empresariales.
  • Mejor experiencia del cliente: el objetivo principal es satisfacer las necesidades de los pacientes que dependen de sus servicios de salud cada día. Si mejora los procesos y permite que los datos se compartan sin problemas entre los sistemas y los departamentos, podrá ofrecerles una buena experiencia.

Es posible que la tarea de adoptar los microservicios para la integración le resulte abrumadora y se pregunte si es realmente necesaria. Después de todo, su equipo utiliza el ESB desde hace años y ya conoce sus aspectos propietarios. Pero ese es precisamente el problema: ¿qué sucedería si uno o dos de los especialistas en ESB abandonaran la empresa? ¿Cuánto costaría obtener el mismo nivel de habilidades?

El hecho de que parezca demasiado difícil dejar atrás el bus de servicios empresariales monolítico es la mismísima razón para hacerlo. Una vez que no tenga las limitaciones que impone el ESB, podrá disfrutar de los beneficios que ofrece la nueva era de integración.

Casos prácticos de la red de eventos

La EDA junto con la red de eventos admiten varios casos prácticos implementados en estructuras multicloud complejas y distribuidas con diversas pilas de aplicaciones. Los ejemplos que aparecen a continuación son solo algunos de los casos posibles.

Integración de microservicios

La red de eventos conecta fácilmente las aplicaciones basadas en microservicios entre sí, así como con las tecnologías heredadas.

Comercio electrónico

Permite procesar rápidamente las operaciones para garantizar interacciones rápidas y confiables con los clientes a través de los sitios web y las aplicaciones.

Asistencia al cliente

Posibilita la entrega rápida de los datos de interacción con los clientes, para que los equipos de asistencia puedan responderles de inmediato y crear una experiencia personalizada.

Servicios financieros

Ofrece la sincronización inmediata y con baja latencia de los datos comerciales a los proveedores de servicios financieros. También transmite información sobre operaciones sospechosas de manera instantánea para respaldar la detección de fraudes.

Conectividad del Internet de las cosas

Ofrece una conectividad confiable y adaptable del Internet de las Cosas (IoT) a los sistemas de backend, para que puedan procesar los indicadores de un conjunto casi ilimitado de sensores.

La red de eventos ofrece los siguientes beneficios a las empresas.

Capacidad de respuesta inmediata

El éxito empresarial se basa en la capacidad para reaccionar ante los cambios. Una de las principales ventajas de la red de eventos es la transmisión inmediata de datos como flujos de eventos a través de la EDA para posibilitar las respuestas oportunas. Se trata de redes muy eficientes que constituyen la vía más rápida entre el productor y el usuario del evento, y eliminan la latencia en los mensajes. De esta manera, las partes interesadas de la empresa obtienen la agilidad necesaria para reaccionar rápidamente a los problemas que requieren decisiones inmediatas.

Mejora de la experiencia del cliente

La red de eventos permite la entrega inmediata de los datos que utilizan los equipos que trabajan con los clientes y las tecnologías de comercio electrónico. De este modo, las empresas pueden satisfacer las necesidades de los clientes y mejorar su experiencia.

Reducción de los costos operativos

La red de eventos brinda información inmediata sobre la fabricación, las ventas, el inventario y los envíos para que las empresas puedan optimizar las operaciones, mejorar la eficiencia y reducir los costos.

Productividad de los desarrolladores

Con el respaldo de una red de eventos que no depende de ningún tipo de entorno, sistema de mensajería ni protocolo, los desarrolladores de aplicaciones pueden centrarse en la implementación de la lógica empresarial utilizando las mejores tecnologías disponibles. Esto les permite generar innovaciones sin la necesidad de desarrollar una compleja red de distribución de datos y sin presentar limitaciones respecto del entorno de desarrollo, la plataforma de mensajería o el tipo de nube.

Articulos relacionados

ARTÍCULO

Los microservicios respaldan la integración de la TI en el sector de la salud

Los microservicios permiten que los desarrolladores de varios sectores, como el de la salud, creen aplicaciones compuestas por servicios sin conexión directa, lo cual facilita los procesos de desarrollo, prueba, implementación y actualización.

ARTÍCULO

¿Qué son los microservicios?

Los microservicios son un tipo de arquitectura que permite diseñar aplicaciones cuyos elementos funcionan de forma independiente pero coordinada.

ARTÍCULO

¿Qué es una malla de servicios?

Una malla de servicios es una capa de infraestructura que se integra con las aplicaciones y documenta la interacción entre los servicios, lo cual permite optimizar la comunicación y evitar el downtime con facilidad.

Más información sobre los microservicios

Productos

Red Hat OpenShift

Plataforma de contenedores de Kubernetes empresarial con operaciones automatizadas integrales para gestionar implementaciones de nube híbrida, multicloud y edge computing.

Contenido adicional

Informe de analistas

El camino a las aplicaciones nativas de la nube

Ebook

Enseñarle a bailar a un elefante: resumen para ejecutivos

Capacitación

Curso de capacitación gratuito

Developing Cloud-Native Applications with Microservices Architectures

Illustration - mail

Obtenga más contenido como este

Suscríbase a nuestro boletín informativo: Red Hat Shares.