When it comes to implementing clinical software solutions to help orchestrate workflows in the OR and other hospital departments for better outcomes, it's vital to have a software infrastructure that's nimble, reliable, scalable and easy to deploy. That's why we've created microservices rather than rely solely on monolithic architecture.
Monolithic Application Issues and Drawbacks
The TAGNOS application has many modules that are interlinked and highly coupled. The whole application is built to a single EAR file and deployed to the server.
Though this kind of monolithic architecture is easy to develop, test and deploy, you'll find issues and drawbacks associated with it. For example,
- Reliability – Monolithic applications are not reliable. If there is a bug in any of the modules, there are chances that whole application
might go down.
- Scalability – Monolithic applications can be scaled by creating a new instance and using the load balancer to distribute the traffic among instances. This is a less effective approach because even if there is a requirement to scale one of the modules, the whole application needs to deploy on a new instance. With monolithic architecture, we cannot scale each component independently.
- Redeployment - To update one of the modules or fix a bug, the whole application needs to be redeployed which makes continuous deployment extremely difficult.
Because of all the above drawbacks of monolithic applications, micro services are becoming more and more popular.
In microservices architecture, the whole application is split into smaller, independent and interconnected services. Each service becomes a small application that can be deployed and managed independently by different teams.
The Benefits of Microservices
As you might imagine, using microservices architecture has many benefits:
Microservice architecture can be very reliable. If one module has an issue or goes down, other services keep running and the whole application doesn’t go down.
Microservices architecture offers a great deal of flexibility in developing the application as different teams manage the different services.
Each service can be scaled individually and does not require a whole new application instance.
Deployment becomes easier with Microservices. To update one of module, you just need to redeploy that particular service.
The Cons of Microservices
Despite the advantages detailed above, there are cons of microservices architecture:
- Logging and Monitoring - As each service is running as an independent unit, logging and monitoring of the whole application becomes a
challenging task and requires extra infrastructure or tools such as ELK-Stack for distributed logging.
- Transaction Management - It's difficult to maintain transactions when dealing with independent processes.
- Increased Network Usage - With multiple services working together, it is important for them to communicate with each other at some
level. This communication will lead to increased network usage.
- Network Communications Issues - Microservices communicate over the network through a dedicated mechanism (like REST calls or
messaging). Hence, it’s more likely that something might go wrong (e.g., microservices not available, HTTP request or response gets lost) –
especially in comparison to a programmatic API call. We have to deal with this and implement approaches to handle those situations.
- Testing - Testing becomes a challenging task as services are individual processes. These services have to be tested independently also
integration testing has to be done carefully.
Design Criteria to Consider While Designing Microservices
When you're designing microservices architecture, you need to keep the following design criteria in mind:
1. Circuit Breakers
Circuit breakers matter. It's important to identify the places in microservices and apply logic which will prevent the system from recurrent failure. Failure in one of the microservices should not propagate failure to other microservices.
2. Health Checks and Monitoring
Health checks are basically endpoints provided by a service to check whether the service is running properly. It helps the user to pinpoint the malfunction inside microservices.
Log messages of all microservices for the application have to be logged at common places. Tools such as ELK stack can be used for this.
A microservice needs to be resilient to failures and to be able to restart often on another machine for higher availability.
5. Test Suites
To make microservices robust and reliable, each microservice has to have its own set of unit tests and service test suites.
The Journey to Microservices
The Journey to microservices involves replacing a custom-built queue mechanism with a queue as a service.
The TAGNOS application had java queues between two modules to transfer data which makes the TAGNOS application highly coupled and dependent on each other. To overcome this dependency between modules, we have replaced the java queues with a message broker. This message broker provides a common platform between two modules to send or receive messages.
TAGNOS Implementation Strategy
As a starting point for implementation, it's important to identify existing functionality in the TAGNOS monolithic system that is fairly loosely coupled with the rest of the application and convert that to microservices.
Next, convert other modules of the TAGNOS application also to microservices one by one, until eventually the monolith is cut out completely. These microservices discover each other using service discovery and talk to each other using rest services. The main idea is to slowly replace functionality in the system with discrete microservices.
We welcome your questions.
Thanks for reading.
TAGNOS is the future of clinical automation software solutions with Artificial Intelligence. TAGNOS is the only platform offering predictive analytics utilizing machine learning and RTLS. This groundbreaking platform leverages historical patient data continuously and adjusts operational intelligence to provide sustainable improvement to both the patient experience and metrics.
TAGNOS provides clinical systems integration, customizable reporting, dashboards, alerts, critical communication with staff and family to improve turnaround times. These solutions support patient flow, workflow orchestration, and asset management.
In the course of 13 months, hospitals see a 12.7% reduction in its overall cycle time - saving an average of 40 minutes from each case and over $1.6M per year - more than 11x the typical investment.