I'm not sure what exactly you're doing on your edge node so it's hard to make a recommendation.
Justin On Wed, Mar 15, 2023 at 1:07 PM Yoann Gini <yoann.g...@gmail.com> wrote: > Thanks a lot for that feedback! > > Between the three option (bridges, federation, and broker connection) what > would be the most suited for a configuration only at the edge side? > > All our edges have a certificate available published by a private CA, > ideally I would like my central instance to be with the minimum > configuration possible, accepting anything from anyone with a valid > certificate, letting the Edge instance in charge of all the replication > (bi-directional) settings. > > > > Le 15 mars 2023 à 17:38, Justin Bertram <jbert...@apache.org> a écrit : > > > > The edge use-case with substantial hardware is quite different from the > > classic IoT use-case. Also, the fact that you want to use messaging > between > > clients on the edge device is also a significant difference. Therefore, > my > > answer certainly would change given that the underlying assumptions from > my > > previous answer are invalid. > > > > I have no doubt that some of our users are running a broker on their edge > > devices. The broker can be tuned to run effectively even on very modest > > hardware when necessary. I can't rightly say whether that's a "good > usage" > > in your use-case when it's clear that important details are easy to omit. > > Also, it's hard to say whether core bridges [1], federation, or even > broker > > connections [2] would best fit your needs. > > > > > > Justin > > > > [1] > > > https://activemq.apache.org/components/artemis/documentation/latest/core-bridges.html > > [1] > > > https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html > > > > On Tue, Mar 14, 2023 at 3:12 PM Yoann Gini <yoann.g...@gmail.com> wrote: > > > >> Thanks for your input Justin! > >> > >> Maybe IoT was missleading here, if I speak about EdgeComputing does it > >> change your answer? > >> > >> One of the reasons I was looking for that architecture and that I forgot > >> to mention was the ability to use also the MQ between multiple services > >> locally to the edge. > >> > >> So each edge would be autonomous for their own internal messaging and > then > >> have federations for upstream communications. > >> > >> I was in my context forgetting that IoT usually mean low end device. > >> > >> In my context it’s IoT but with 64 GB of RAM, i7 CPU and Cuda > capabilities > >> on the GPU. > >> > >> So maybe Edge Computer is more appropriate wording. > >> > >> Yoann > >> > >>> Le 14 mars 2023 à 20:02, Justin Bertram <jbert...@apache.org> a écrit > : > >>> > >>> Generally speaking, the software that runs on IoT devices is designed > >> with > >>> the unique constraints of IoT in mind (e.g. poor or intermittent > network > >>> connectivity, limited processing capacity, small amount of memory, low > >>> power, etc.). > >>> > >>> MQTT, for example, is often used for messaging in IoT contexts and it > is > >>> designed to be light-weight and has features like will messages, > retained > >>> messages, link stealing, session expiration, etc. to facilitate unique > >> IoT > >>> use-cases. > >>> > >>> Furthermore, MQTT client implementations offer additional features not > >>> outlined in the MQTT specification. For example, most Paho MQTT clients > >> [1] > >>> offer the ability to automatically reconnect, buffer messages when > >> offline > >>> (which will be sent automatically when the connection is > re-established), > >>> and persist messages (in case the application crashes before it has a > >>> chance to send them). > >>> > >>> In my opinion, adding a broker to an IoT device is not a good idea. > It's > >>> adding complexity where it isn't really required. It will make > >>> configuration, deployment, and debugging more difficult, and it will > >>> require more hardware (which is notoriously limited in IoT). A good > MQTT > >>> client implementation should be able to provide you with all the > features > >>> you need to operate effectively in an IoT context. > >>> > >>> > >>> Justin > >>> > >>> [1] https://www.eclipse.org/paho/index.php?page=downloads.php > >>> > >>>> On Tue, Mar 14, 2023 at 8:52 AM Yoann Gini <yoann.g...@gmail.com> > >> wrote: > >>>> > >>>> Hello, > >>>> > >>>> I'm new here and I'm working on an IoT issue where I'm wondering if > >>>> Artemis and federated queue could help. I'm learning the software in > the > >>>> same time I'm trying to achieve something, so I would like to have > your > >>>> opinion on this: will it work? Is it a good idea? And do you have > sample > >>>> config / blog post to recommend to learn to achieve that? > >>>> > >>>> The idea: IoT devices with some computing capability running local > >> needed > >>>> services as well as an Artemis local instance, with upstream set a > Cloud > >>>> located one. > >>>> > >>>> Configuration in bidirectional to allow both Cloud to pass commands to > >> IoT > >>>> and IoT to report feedback to Cloud. > >>>> > >>>> Goal of Artemis here in the IoT as federated layer (and not directly > IoT > >>>> service connected to the cloud one) would be to provide some sort of > >>>> caching capabilities which would allow the local service to not have > to > >>>> handle disconnected state. Local service will still be able to publish > >> to > >>>> local Artemis and read what was lastly make available before a > >> connectivity > >>>> cut. And when the Internet recovers, the federation (if I understand > it > >>>> well) should resume bidirectional transfer of feedback and orders. > >>>> > >>>> Does that make sense for you? Is it a good usage of the solution that > >> has > >>>> some chance to reliably works? > >>>> > >>>> If so do you have any recommendations for the implementation or any > blog > >>>> post / conference I should look at to learn this? > >>>> > >>>> Cheers > >>>> Yoann > >>>> > >>>> > >> > >> > >
