Earlier quoted context omitted.
And of course, ignoring the problem of duct-taping all the services together. "Oh we'll just RabbitMQ everything together", sure, great, until you discovered certain services needed a smaller latency, more bandwidth, etc And RabbitMQ libraries are a pain and are not smart
actually this is a question that I have - how do you render the final output ? I mean lets say I request a web page which depends on 5 microservices. What happens ? does rails or whatver block till all five have returned the output - or do you use something like ESI ... how are the microservices composed finally ?
The way you will tackle this will largely depend on many questions like what services are safe to be exposed publicly, what services are dependant on other services, do you have a public API?
For example, you could have a public facing API on each service, or endpoints that render HTML templates. The services may or may not talk amongst themselves, either via the same public API, or a private one. If you make a request to one of the services, and that service needs to make a request to another service to generate the response, you've got to make a call on whether you want a blocking or non-blocking approach. Consider:
1) Blocking until the other services have responded
2) Pinging the server to check when it's done
3) Using web sockets
4) Whatever the hell else you can think of
Alternatively, you might want not want to expose your services publicly, and choose to have a single service that talks to the services on the clients behalf, a middleman. Your client speaks to this service, and the service sends of various requests to the other services. But the problem still stands. To block, or not to block?
AFAIK some big names like Amazon, Spotify, (Twitter?) have multiple public services. You may sometimes notice individual components on their [web] applications failing without bringing down the whole site, since the failures are isolated to the different services. Neat, huh?