Open didier-durand opened 3 years ago
@didier-durand I'm intrigued by this because MQTT was my initial thought on a protocol too but now, I'm unsure.
Assuming devices are able to publish to MQTT topics, what benefit do you see in writing Akri-specific protocol support for (an) MQTT (broker) over an above, running an MQTT broker in the cluster?
@DazWilkin:
Hi Daz,
This is why I suggested MQTT:
This has numerous advantages coming from the normal benefits of a pure cloud-native architecture:
All in all, my answer is not directly about you "why MQTT" but about why the Akri architecture is very interesting from my perspective. Then, I asked for MQTT in this ticket because it probably is by far the leader of IoT protocols: so, its support in Akri will be very beneficial to Akri & MQTT.
Please, let me know what you think of the above: I am deeply interested in different perspectives.
Didier
Hello @didier-durand,
Definitely agreed on how MQTT is important for IoT. Curious about your thoughts on MQTT integration to Akri. Are you suggesting to include an MQTT broker as part of Akri so leaf devices could connect to the cluster? This would still require the devices to register to the broker, not Akri finding the devices. Or are you suggesting something else? I am asking to understand how well this would fit into the Akri architecture.
@jiria :
Yes, I would definitely embark an MQTT broker as part of Akri and expose it via A k8s Service to the objects on the outside. I would do that because it would allow a quite easy (and passive) discovery of the objects based on the interception of CONNECT / CONNACK dialogs between MQTT client and broker (As per your point: that's how Akri would "find the devices" to quote you). Also, as per my answer to @DazWilkin , it would make the system more "compact", so more efficient to manage via k8s mechanisms only. Additionally, Akri would also be able to have a much tighter control of the objects allowed to connect since they could be configured (name, password) as new Akri objects.
If you keep the broker external, you will need separate mechanisms to install, patch and configure it. Also, the configuration of objects would then also be external to Akri, which wouldn't be the most efficient.
But, you can also envision a setup where the broker is pre-existant or separate for good reasons. Akri would then only be one of its subsribers. But, that's - from my perspective - a secondary option when the "embarked broker" option cannot be used.
Happy to continue the discussion if needed
Best
Didier
Thanks. Thinking out loud, please let me know if this is matching your thinking or if you have other thoughts. A new MQTT DiscoveryHandler would be added. This handler runs on every node (as part of or loosely coupled with Akri Agent) and would have an LB Service assigned to it that MQTT devices would connect to (this would be somewhat unique but lets see the rest). This handler would start the MQTT auth flow. We currently try not to have the DiscoveryHandler deal with secrets to reduce its complexity and improve reusability. Wonder if the auth flow Client ID could be taken here and compared against the include/exclude list in the MQTT protocol Akri Configuration. If the device is meant to be included, an MQTT broker/Akri broker is started and somehow, the device is redirected (is something like HTTP 303 possible here?) to the broker and continues its communication with the broker directly. Though this would be tricky, since the broker would be started by the Akri Controller after while and it does not make sense for DiscoveryHandler to keep the connection open until then.
This also turns Akri upside down as leaf devices would come knocking as opposed to Akri finding leaf devices. So when the Akri broker is deployed, instead of being provisioned with some information about the device that is connecting, it would be the device that would have to be provisioned with the IP of the broker.
I feel that running MQTT broker as part of DiscoveryHandler directly does not make sense, as these are running on every node and are pretty stateless at the moment.
Thoughts?
@jiria : Sorry for my delayed answer! (hectic year end..) On your points:
I am happy to continue this thread if you've more questions or I have been unclear.
Didier
Sorry for delayed response from my side as well. Need a bit more time to think about it.
@didier-durand and @jiria might I add to this discussion that the OASIS Standards Body also has an MQTT-SN MQTT-Sensor Netowrks Protocol v1.2
From my understanding this doesn't hamper the existing MQTT brokers but builds up an additional transparent gateways that can collect information from sensor nodes (here, Leaf Devices) and also provides a Discovery and Advertisement Protocols which can be an amazing feature for AKRI's Protocol Integration Roadmap.
I am only getting started with AKRI but MQTT is worth the effort for integration with AKRI since a very large pool of systems use this protocol.
@didier-durand @jiria I have provided a draft proposal for the MQTT integration with Akri (see #341). Since the discussion has gone down for more than 6+ Months, I would like to get your opinions (if possible) on it so that we are all on the same page.
Issue has been automatically marked as stale due to inactivity for 45 days. Update the issue to remove label, otherwise it will be automatically closed.
I think one of the big questions that I have is: how do we know when a device has gone away? Would it make sense to have a TTL where a lack of messages triggers a deletion?
@agracey you could build something around the Last Will and Testament Logic available in an MQTT Broker. Docs here
I looked at how MQTT is used in the wild and how we could do this MQTT discovery handler, I'll try to do a proposal for it next week (I'll likely take parts of yours @shantanoo-desai if you are okay with it).
The main points are:
👍🏻 for having this! It would allow bringing in MQTT devices running on constrained micro controllers.
Is your feature request related to a way you would like Akri extended? Please describe.
MQTT is a key protocol in the IoT world. It would be extremely beneficial if Akri could directly communicate with devices implementing this protocol to report data / get instructions. That would make the path between device and kubernetes application much shorter than it is for other projects lilke KubeEdge whose architecture entails more elements between device and K8s application.
Many use cases show how it's used today or will be used in the future.
Describe the solution you'd like
Akri may rely on existing protocol implementations to deliver this feature rapidly
Describe alternatives you've considered
The only one known as of now is Kubeedge with the disadvantage mentioned above.
Additional context
https://dzone.com/articles/why-mqtt-has-become-the-de-facto-iot-standard