Ask HN: Is messaging an alternative to service discovery?

1 points by whiskypeters ↗ HN
I'm a newbie to distributed systems, currently reading Enterprise Integration Patterns[1] (which I strongly recommend). I've read nearly everything available from guys like Martin Fowler, Greg Young and Adrian Cockroft on the topic.

Service discovery is a term I hear often in discussions about microservices and distributed systems platforms like Mesos or Kubernetes. Other than use within the platform internals and application-specific message broker (eg RabbitMQ or NMessageBus), when would service discovery be useful to my distributed application itself?

Coming from a frontend background and thinking in "reactive" terms, messaging seems like the most intuitive solution (specifically, CQS backed by event stores). Can't most problems be solved using a distributed exchange with well-defined routing, queues and proper correlation?

ie. upstream services simply send messages (commands/events) to stream, use exchanges/topic routing to optimize delivery, and relevant actors can react?

[1] http://www.enterpriseintegrationpatterns.com/

0 comments

[ 3.6 ms ] story [ 8.0 ms ] thread

No comments yet.