[EXTERNAL] Re: Export Go - for preview

Dellabianca, Alberto

+1 on Drasko's rankings

-----Original Message-----
From: edgex-golang-bounces@... [mailto:edgex-golang-bounces@...] On Behalf Of Drasko DRASKOVIC
Sent: Friday, February 23, 2018 4:57 PM
To: JamesWhite2 <James.White2@...>
Cc: Trevor.Conn@...; dejan.mjc <dejan@...>; manuel@...; edgex-golang@...; Garcia, Gorka <Gorka.Garcia@...>
Subject: [EXTERNAL] Re: [Edgex-golang] Export Go - for preview

Hi Jim,

On Fri, Feb 23, 2018 at 5:51 PM, <James.White2@...> wrote:
Dell - Internal Use - Confidential

Thanks for this Trevor and Drasko,

Good stuff!!!

My top 3 requirements would be:
-Broker-less (we've done MQTT and broker before. It's not a problem, but additional broker requires more setup/containers/etc. and can be large footprint depending on implementation. We can and should still allow MQTT as alternative option for those that want it - like we have been offering in Java side to date - but the default should be brokerless).
-Go native (but also provides libraries for Java, C and possibly other languages). As we look at messaging use between other services in the future, support for polyglot is integral to our tenets and needs of the future.
-Lightweight, ease of use, etc.

What I am seeing on this thread is that people feel Nanomsg may be leading candidate?? Would like to hear from others that have an opinions or questions. I'd like to hold this as a major part of our discussion in the Go project meeting (once we have the mono repo work done).
To clarify, my personal order of preference would be:
- NATS - for MVP, because of simplification of the system
- gRPC - because Google is behind it and it is extremely well maintained and documented framework, used in industrial products and with several additional benefits (protobuf, TLS, rate limiting, circuit breaker, ...)
- Nanomsg - because it is a pure TCP and probably very performant

MQTT broker is not adequate for micro-service comm, I think. It is not built for this purpose (like NATS, AMQP, RabbitMQ, Kafka, ...). In any case - there is no native Go implementation of MQTT broker, which would bring us to similar problem of cross-compilation.

Both of the 3 technologies are very good, and if you think that brokerless design is needed - then I would rather investigate gRPC, unless there is some special argument to use TCP-based messaging:
overhead, performance, etc...

I can also advise you to make a small PoC of several microservice communication with NATS, just to get a feel of how simple it is, so you can make an estimation would this actually simplify the system, or make i more complex (extra Docker, etc...).

In any case - it would be hard to say for me which technology is the best for particular EdgeX use-case: all 3 technologies look great, and I think we will need to do research and make a comparison matrix to select the best candidate. Maybe also try to engage a wider dev community out of our edgex-golang group (for example ask on edgex-dev later).

Best regards,
Mainflux Author and Technical Advisor | Industrial IoT Cloud
Engineering Division | Paris, France

Twitter: @draskodraskovic

EdgeX-GoLang mailing list