Opinions and use cases sought for EdgeX Future Messaging Infrastructure


As many of you may know, the Core Working Group has recently taken up the task of discussing/debating some architectural/design issues in the current and future versions of EdgeX.  In last week's meeting, the topic of message infrastructure was discussed.

If you are familiar with the current EdgeX architecture, you know that REST is used as the predominant protocol between EdgeX micro services today.  There are a few key places were messaging infrastructure is used;  namely 0MQ (or alternately MQTT) is used between core-data and export-distro.  0MQ (or MQTT) can also be used between core-data and rules-engine when the rules engine micro service is attached directly to the data flow bypassing export-distro.

When Fuse (now EdgeX) was first envisioned, we at Dell believed that one day a message infrastructure (MQTT, AMQP, DDS, etc.) or other protocol (Web Sockets, SNMP, etc.) could be used as an alternate means of communication between some, many, or all of the micro services.

Several in the EdgeX community have suggested that the topic needs to be revisited and some decisions made in advance of the upcoming releases.  In fact, messaging infrastructure is on our current Roadmap for Delhi.

In the short term (California release), use of Zero MQ between core-data and the north side services has created some issues when we develop Go services running on multiple chip sets (Intel/Arm).  As Go code must be compiled to a particular platform, use of 0MQ (which has native C/C++ libraries) creates some issues and causes us to look for a better message solution as a replacement.

Longer term (initial plans are to have some alternate infrastructure for the Oct 2018 or April 2019 release), we are trying to understand the requirements and considerations of implementing a second (or third, fourth, etc.) infrastructure under EdgeX.  Questions we are asking include:

·        Would/should EdgeX support multiple micro service communication protocols simultaneous (REST and MQTT for example)?  Or do we remove the REST infrastructure for a message infrastructure?

·        Would all the micro services have to speak the additional protocol(s) or is the decision made point-to-point for each service to service connection?

·        Why do we need something other than REST?  What are the use cases and requirements for alternate protocols?  Quality of service concerns?

·        What are the security implications of using an alternate protocol?  How would we secure DDS messaging for example?

·        How would testing change under such infrastructure changes?  What would “Blackbox” testing look like?

We are soliciting the community's feedback and suggestions.  In particular, we’d like specific use cases, requirements, rationale for why you believe EdgeX should adopt alternate micro service communication endpoints.

If you have opinions on which protocols should be supported, provide us your thoughts on your choice backed up by information on why that choice meets your requirements better than the existing REST option today.

Our (the technical working groups) hope is that getting the feedback before the face-to-face meeting in January will allow us to focus the discussion, sharpen the roadmap, and make some decisions at that meeting about implementations for California, Delhi or later releases.

Jim White
Distinguished Engineer, Software Architect & EdgeX Foundry Core Working Group Chair
Dell Technologies | End User Computing, Chief Technology Office (EUC CTO)
Office +1 512-723-6139, mobile/text +1 612-916-6693