Microservices and SOA using messaging

Question

I've been very interested in trying out microservices/SOA as an architecture and am having a hard time conceptualizing how the integration between services would actually be done.

I like the idea of using messaging to decouple the clients from the services, but don't understand how a system could utilize it exclusively. The typical async operations and pub/sub stuff obviously makes sense - scenarios like creating a new order, broadcasting data for reporting, etc. What I don't understand is whether people typically try to use messaging for common request/reply scenarios - for example, a user hits their "profile" page and part of the data that needs to get rendered on the page is from a user service.

I know common messaging implementations provide REST-like reply/request functionality but is that often used for simple data requests? It seems more likely that microservices would both expose REST endpoints and also register with a message broker for different types of communication it will participate in, but all these presentations I watch of SOA and microservice architecture seem to suggest they only use one or the other..

Thanks for any elaboration/experiences!

Answer 1

I have posted about this before - but generally speaking, synchronous operations (for example, a user clicking a button and expecting some data back) are synchronous for a reason.

That is to say, synchronous - not because of the technology used to process their call - but because of a built-in and generally inflexible expectation on the part of the user that things should happen in real time and not "offline" (even if there is no material difference most of the time).

So, it's generally unwise to put any kind of offline or asynchronous technology stack in between a user and their expected response.

As with all things, exceptions abound (and could spawn a whole new conversation), but certain types of user calls can and should be handled "off-line" depending on the situation.

However, I do feel that the focus of your assertion:

I like the idea of using messaging to decouple the clients from the services

misses the point somewhat. We don't actually want to decouple clients (or consumers) and services.

We would expect a client for, say, the Accounts Payable business capability to be highly coupled to the accounts payable microservice.

Similarly we would expect a high degree of coupling between a service endpoint signature bool ProcessTransaction(Transaction transaction) and the consumer of such an operation.

Where decoupling becomes really important is decoupling between services which support different business capabilities.

And it's here that the benefits of messaging really make a difference. Let me know what you think and if this has helped you at all.

Answer 2

I think when you ask how often "messaging" is used in request/response, you probably mean asynchronous communication.

I'll take a different (opposite) perspective than some of the answers here, and say that you should almost always use async, even in request/response. This is because async means you're not blocking your program waiting for a response, and your program can keep on doing some other processing while waiting for a response.

For example, imagine you are implementing Twitter's homepage. You fire off a bunch of requests to different microservices ("get me recommended followers", "get me latest timeline", etc."). You don't want to block and serialize all of these requests. You want to fire them off async and that creates a much better user experience, because as the responses come back in, they update the UI in realtime.

Twitter uses Finagle (http://twitter.github.io/finagle/guide/index.html) for exactly this (async RPC). It doesn't do some of the things a messaging system would do (in particular, it's really tied to the JVM, and it doesn't implement flow control or queues), but it does implement async request/response.