[CarlHoerberg]

It depends how you do SOA. We try to publish "events" rather than to "call" another service and expect responses. We try to decide as much as possible in the service that publishes an event, so that information doesn't have to be returned. Other services act on that information.

Your kind of SOA sounds more like distributed RPC, which indeed is complicated.

[JeffJenkins]

Yeah, if you can get away with that model things are simpler. The best first step into SOA to take is offloading work that doesn't need a user response to a pool of workers (often by publishing to a message bus, as mentioned elsewhere in the thread). I've implemented systems like that using Rabbit and Redis and it worked fairly well.

However, some kinds of requests are fundamentally about integrating the results of a bunch of different services into a response to send to the user. In that case you somehow need to gather the results of your rpcs/events in one place to integrate them. An example is Google search where the normal results, ads, and various specialized results/knowledge graph data need to be integrated to present to the user.

Another consideration is how much you want to be able to isolate services. If you have a user/auth service as in the article which completely encapsulates the database and other resources needed for data about users then you'll end up with a lot of calls into that service. It's a disadvantage because of all the reasons in my original comment, but it's great from the perspective of being able to isolate failures and build resilient systems

[CarlHoerberg]

Ok, yes, in the case where you have to have all information on one page. Another way is of course to get that information in a ajax call, or open a SSE/Websocket connection to listen for events from the event bus. But there are of course cases where that's not feasible.

And in the case of auth systems what we typically do is to have a separate app for logins/authentication, then do simple SSO or domain cookie sharing and let each sub system handle the authorization.

My point is that not all SOA has to be as complicated as the article's. But if you go that way, yes, then all your points apply.