Performance Vs Flexibility – EdgeX Microservices Could be Combined
Written by Dell’s Jim White, EdgeX Foundry TSC Member and Chair of Core Services Working Group
I was posed a great question recently by one of our EdgeX contributors. As he suggested, he was “wrapping his head around EdgeX” when he wondered if it made sense to have the core microservice (those being core data, core metadata, and core command) all be different microservices. As he commented: “I think the microservice design is a good option, allowing to separate some components outside of the core of EdgeX”, but as he further suggested, “it seems that a lot of time and CPU is spent with RPC between those microservices.” Would it be better (both easier and faster), he mused, “to have only one core service implementing all those together?”
As I indicated to this developer – he can consider his head fully wrapped around the EdgeX architecture if he is coming to such questions. Indeed, his question is a legitimate consideration. Architecture is about tradeoffs. EdgeX is about offering options to meet the potential tradeoff considerations. In this case, performance versus flexibility.
We (the original creators of EdgeX) believe there are legitimate reasons why you may want to separate those concerns (core data, metadata and command). As each is a different function, you may need to improve or significantly modify one of the functions.
For example, we envision a very different and more secure offering of command microservice in the future that checks authentication/authorization before actuation is allowed on a device. The microservices may need/want to separate their repositories. Both core data and metadata use MongoDB today, but we have seen situations at Dell (and actually done implementations) where for security, performance, or other reasons that the underlying persistent storage is different for each microservice. The sensitivity of the incoming sensor data may be such that the core data microservice has to be constructed differently and completely isolated from metadata and command to meet legal or regulatory considerations. There may also be cases where, due to availability of resources or need (or again to secure some data), that the various functions need to reside physically on different platforms (EdgeX on a more distributed layout).
Having said this, there are also other use cases where these core microservices (and others) may be combined – as indicated by the contributor, likely for optimal performance, to in order to reduce footprint, etc.. In fact, at Dell we conducted such an exercise to prove this out. By combining core data, metadata and command, we were able to reduce the footprint and improve performance of the Java core services significantly and we envision going forward there will be, potentially, an offering of a single “combined” core microservice in EdgeX. This will be at the expense of flexibility, but for those looking to productize EdgeX, this may be a perfectly acceptable trade off.
Productization of EdgeX and its use in real world edge/IoT use case scenarios are apt to uncover all sorts of interesting needs. EdgeX is a collection of building blocks to create a solution. Some refinements and adjustments to EdgeX may, and probably will, need to be made to accommodate a particular use case. The flexibility of EdgeX is its strength. And don’t forget, the flexibility allows those who adopt and embrace it to figure out ways to add value – and thereby generate potential revenue – from their adaptations.
So, the contributor that asked the question about potentially combining microservices was absolutely right on track with his thinking. We will welcome combined core service (or other services) as alternatives as EdgeX marches forward – while at the same time maintaining separate core microservices to support other use cases. The beauty of microservices is that they can be replaced and augmented in many ways – in some cases by collapsing them.
