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. 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).

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. Todas las integraciones del ESB se implementan en un monolito. 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. 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. De manera similar, 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. Esto se logra mediante la automatización. 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, y los ESB, por el contrario, no son compatibles. Mientras estos últimos son monolíticos, los microservicios son lo opuesto, ya que permiten que los desarrolladores creen aplicaciones e integraciones utilizando los elementos básicos de servicios sin conexión directa. 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 con las herramientas de vanguardia que los desarrolladores ágiles prefieran (como Kibana, Elasticsearch, Grafana, Prometheus, etc.), para 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 se compartan los datos sin problemas entre los sistemas y los departamentos, podrá garantizar una buena experiencia para los pacientes.

Es posible que la tarea de adoptar los microservicios para la integración le resulte abrumadora. ¿Es realmente necesaria? Después de todo, su equipo ya está familiarizado con los aspectos propietarios del ESB que utiliza desde hace años. 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.