Creating Microservices at TAGNOS

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.

Why Microservices?

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:

1. Reliability

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.

2. Flexibility

Microservices architecture offers a great deal of flexibility in developing the application as different teams manage the different services.

3. Scalability

Each service can be scaled individually and does not require a whole new application instance.

4. Deployment

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.

3. Logging

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.

4. Failover

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.

About the Author

Jag Padala

Engineering solutions for a better experience

For over five years, Jag has helmed the product development at TAGNOS as its Chief Technology Officer. Beginning with a single customer installation when he first joined, Jag has re-architected TAGNOS to create a cloud-enabled and enterprise-scaled product now deployed at Adventist Health, Providence St Joseph’s, and USC Keck to name a few. Jag brings a wealth of enterprise software and product development experience to TAGNOS, including having worked extensively in the supply chain and compliance areas for companies such as Motorola, GE and, most recently, Oracle. This extensive supply chain experience provides Jag the background to be able to create workflow and process optimization software while leveraging his prior startup experience to create and sustain TAGNOS. When Jag isn’t developing end-to-end product solutions for hospitals, you can find him either hiking with his golden retriever Thor, concocting delicious vegan dishes, or blogging about his many travel experiences around the world.

Read More

See More Articles

Empower Care Providers

We illuminate insights, automate operational tasks, and orchestrate workflows to assist healthcare workers to produce the highest level of patient care.