[sandGorgon]

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 ?

[chrisvxd]

Adopting a microservice architecture does nothing to define how you "render your output"- the devil is still in the details, but that is why a microservice is so interesting and flexible.

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?

[virmundi]

One approach that makes sense in an enterprisy way is to use an ESB. BPEL can help here. Your ruby app calls the ESB on a service. Behind the scenes the ESB composes the calls efficiently into a final product for you. The enterprise system bus will aggregate the parts into a useable whole defined by your domain.

A benefit of this is that people get a unified view of the system. You can pull parts as needed. You can survive partial outages better than a monolithic app.

Of course you can still call each of the services independently. The ESB is just another tool in your box.