Brainstorm OMRS20 Virtual Unconferencing Session Topics!

Microservice approach to openmrs

I would like to discuss how we could go about migrating Openmrs to microservices along side moving to a more modern tech stack. Am thinking something like Springboot this was raised as a prospect back in 2018. A microservice based approach to feature development. I have been really looking into this over the last few weeks out curiosity and found this Data Model - Documentation - OpenMRS Wiki. Looking at the model I got the felt , this is it we already have our first 10 microservices. Of course it’s not that simple and the devil is in the details. @jdick raised the issue and could be interested @dkayiwa, @ssmusoke and @jthomas also showed interest.

What I expect to get out of the discussion is first is this existing enough to pursue further and work on some sort of proof of concept. If so what would the approach be? Do we refactor or rewrite?

Notes

  • The gateway:
    • Provides authentication via JWT meaning we can share the same token across all microservices
    • Serves the client in our the MFE frontend
    • Load balances the microservices with Ribbon and Provides circuit breaker functionality with Hystrix
    • Provides rate limiting
    • Provides System metrics,logs and api docs
  • All the microservices are stateless and can be scaled individually
  • Each microservice publishes an event whenever data changes on its database the Data Aggregation microservices listens for the events and pushes data into the reporting db from which the Reporting microservices can serve reports. Openmrs will provide references for this two services but implements could be free to bring their own
  • The platform can be extended by adding other microservices and registering the in the registry
  • The setup will heavily rely on a well configured ci/cd process. This could be achieve with either docker-compose or kubernetes
  • Since the process will be centered around containers then everything will be packaged and distributed as a docker container meaning the design of the services should allow easy for installations,configuration and upgrades (For example if an implementer is using docker-compose to deploy their instance and we have a new version of say the person microservice all they need to do is bump up the docker image version and restart)
  • The POC provided has been generated with jhipster and all the core functionality uses tools from the Java ecosystem but this does not limit the tech stack used by individual microservices just that it can registers its endpoints into the registry so implementers can use whatever tech stack their team is comfortable with to extend the core with other features
  • The Data Migration Service will run against the Legacy Openmrs db to help migrate data from the legacy Openmrs db into the various microservices
10 Likes