4 ms·

Message brokers only work for "fire-and-forget" kind of async operations. As in, when you make a request you are not waiting for a response. I don't think it i

by jatins 7y ago

Message brokers only work for "fire-and-forget" kind of async operations. As in, when you make a request you are not waiting for a response. I don't think it is service mesh OR brokers. Both cater to different use cases.

discreteevent 7y ago
This is true but I would think that if you had to pick one then it is much easier to make a message broker do reliable request-reply/pull than service mesh do reliable events/push.
- sagichmal 7y ago
  The opposite tends to be true. https://programmingisterrible.com/post/162346490883/how-do-you-cut-a-monolith-in-half/ https://programmingisterrible.com/post/162346490883/how-do-y...
  - discreteevent 7y ago
    Good article, thanks: "A protocol is the rules and expectations of participants in a system, and how they are beholden to each other. A protocol defines who takes responsibility for failure. The problem with message brokers, and queues, is that no-one does. Using a message broker is not the end of the world, nor a sign of poor engineering. Using a message broker is a tradeoff. Use them freely knowing they work well on the edges of your system as buffers. Use them wisely knowing that the buck has to stop somewhere else. Use them cheekily to get something working. I say don’t rely on a message broker, but I can’t point to easy off-the-shelf answers. HTTP and DNS are remarkable protocols, but I still have no good answers for service discovery." I would not disagree with any of this but I don't know enough about service meshes to know if they mean that you don't need a protocol (meaning the edges still need to deal with failures after the mesh or broker has retried etc). One thing a broker gives you is that if the problem is that the other service is busy or down then it will eventually get the message. So it avoids one specific kind of failure in the case where eventual consistency is acceptable.
wmfiv 7y ago
This just isn't accurate. Messaging solutions have always supported request-reply. Just as examples, https://activemq.apache.org/how-should-i-implement-request-response-with-jms.html https://activemq.apache.org/how-should-i-implement-request-r... https://nats.io/documentation/concepts/nats-req-rep/ https://nats.io/documentation/concepts/nats-req-rep/ https://www.rabbitmq.com/direct-reply-to.html https://www.rabbitmq.com/direct-reply-to.html
- gshulegaard 7y ago
  I may be off but asynchronously queuing two messages and implementing a synchronous block in business logic does not sound the same to me as a TCP request response cycle.
  - rroeserr 7y ago
    TCP doesn't have a request/response cycle - its a stream of bytes between applications
    - gshulegaard 7y ago
      Correct but TCP provides a reliable data stream between two hosts, the (particular) messaging protocol over it wasn't part of what I was trying to point out.
- VectorLock 7y ago
  While its certainly possible to use in this mode from what I've experienced most people who deploy applications at scale use an async message bus/queue rather than a request/response. At that point is there even much of a benefit vs. simply using a synchronous request/response oriented service?

by jatins 7y ago

discreteevent 7y ago

This is true but I would think that if you had to pick one then it is much easier to make a message broker do reliable request-reply/pull than service mesh do reliable events/push.

sagichmal 7y ago
The opposite tends to be true. https://programmingisterrible.com/post/162346490883/how-do-you-cut-a-monolith-in-half/ https://programmingisterrible.com/post/162346490883/how-do-y...
- discreteevent 7y ago
  Good article, thanks: "A protocol is the rules and expectations of participants in a system, and how they are beholden to each other. A protocol defines who takes responsibility for failure. The problem with message brokers, and queues, is that no-one does. Using a message broker is not the end of the world, nor a sign of poor engineering. Using a message broker is a tradeoff. Use them freely knowing they work well on the edges of your system as buffers. Use them wisely knowing that the buck has to stop somewhere else. Use them cheekily to get something working. I say don’t rely on a message broker, but I can’t point to easy off-the-shelf answers. HTTP and DNS are remarkable protocols, but I still have no good answers for service discovery." I would not disagree with any of this but I don't know enough about service meshes to know if they mean that you don't need a protocol (meaning the edges still need to deal with failures after the mesh or broker has retried etc). One thing a broker gives you is that if the problem is that the other service is busy or down then it will eventually get the message. So it avoids one specific kind of failure in the case where eventual consistency is acceptable.

wmfiv 7y ago

This just isn't accurate. Messaging solutions have always supported request-reply. Just as examples, https://activemq.apache.org/how-should-i-implement-request-response-with-jms.html https://activemq.apache.org/how-should-i-implement-request-r... https://nats.io/documentation/concepts/nats-req-rep/ https://nats.io/documentation/concepts/nats-req-rep/ https://www.rabbitmq.com/direct-reply-to.html https://www.rabbitmq.com/direct-reply-to.html

gshulegaard 7y ago
I may be off but asynchronously queuing two messages and implementing a synchronous block in business logic does not sound the same to me as a TCP request response cycle.
- rroeserr 7y ago
  TCP doesn't have a request/response cycle - its a stream of bytes between applications
  - gshulegaard 7y ago
    Correct but TCP provides a reliable data stream between two hosts, the (particular) messaging protocol over it wasn't part of what I was trying to point out.
VectorLock 7y ago
While its certainly possible to use in this mode from what I've experienced most people who deploy applications at scale use an async message bus/queue rather than a request/response. At that point is there even much of a benefit vs. simply using a synchronous request/response oriented service?