Giving EdgeX Microservices Some Architectural Love
Drasko DRASKOVIC <drasko@...>
now that we are getting into Go re-write, I think it is a good
opportunity to address some of the architectural issues also.
Jim and Dell team already did great job putting all EdgeX in place,
but for example there is still tight coupling between microservices as
they share data models. In order to do Export Services re-write I am
currently re-defining some of Java classes even from Core repos.
Sharing data libraries between microservices is not a good idea:
- they should be loosely coupled, independently scalable and thus have
separate data models. It of course affects directly possibility to
write microservice in some other programming language.
But this is not the only problem I spotted. There is also sharing of
database instances - for example ExportDistribution microservice will
tap directly into ExportClient's DB:
To give a few references why this is bad practice:
chapter "Create a Separate Data Store for Each Microservice"
Instead of sharing the DB, I would propose that ExportClient exports
an API for accessing it's DB, similar to this REST-based integration
In any case, I would suggest better decoupling of microservices:
- No shared libraries (data models, Java classes, etc, ...)
- No shared storage (databases)
Mainflux Author and Technical Advisor
www.mainflux.com | Industrial IoT Cloud
Engineering Division | Paris, France