NATS instead of Service Discovery

[Michael Binette]

I'm starting a new microservices project and don't love the idea of running etcd or Zookeeper (or Consul, etc.) instances for service discovery. Most examples and projects I see tend to use these types of discovery services with micro services. To me it seems like a much better solution to use NATS with Queue Groups and simply throw the messages out there to get handled. The simplicity seems too good to be true. What am I missing? What do I get out of service discovery and direct connections to the microservice that I can't get by defining my subjects, publishing them, and just expecting someone to pick up that message and process it, possibly returning an answer? I want to make sure I can add new subscribers without modifying the publisher and basing my logic on service discover seems to kill that idea.

The project is your fairly run of the mill web application that has to collect user data, save it, trigger additional processes to work with the data, etc.

[ivan.k...@apcera.com]

Regarding your specific question about adding new subscribers without modifying the publisher, the answer is yes, you can add new subscribers without changing anything on the publisher side. The philosophy of pub/sub is that the publisher does not assume anything about the audience. It just sends messages. The server is responsible to keep track of the interest and send to any connected subscriber, or simply drop the message if there is no interest.

[Michael Binette]

Thanks Ivan. I knew you could add new subscribers easily with the NATS solution. It seems more difficult if you are using a service discovery type of workflow.

[Asaf Yishai]

We are considering the exact same thing. We are using consul.io now, with direct microservice communication, but it feels too fragile. We are planning to switch to nats.io for all messaging.

[Ivan Kozlovic]

That's great to hear!

[Colin Sullivan]

Awesome!

--
You received this message because you are subscribed to the Google Groups "nats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to natsio+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Colin Sullivan | Principal Engineer

colin.s...@apcera.com  | @ColinSullivan01

[ged...@gmail.com]

https://fly.io/blog/a-foolish-consistency/

[panan...@gmail.com]

In my previous project I've also decided to get rid of service discovery mechanisms and rely solely on nats. May be you'll find interesting some ideas from my design which I've tried to explain here.

вторник, 14 марта 2023 г. в 19:24:41 UTC+7, ged...@gmail.com: