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!
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.