[skohan]

Yeah the anti-microservice sentiment is a bit bizarre. It almost reads like the author wants to stick with Ruby-On-Rails circa 2005 as the be-all, end-all of application architecture.

Don't get me wrong, there's such a thing as innovation for its own sake which does not add value, but there is nothing wrong with a single-page application driven by microservices. That architecture is pretty well proven and "boring" at this stage.

[sametmax]

It's not bizarre, it's experience outside of big shops.

First, you probably don't need it. There is a scale at which you benefits from microservices more than they cost. Most companies don't have that scale.

Secondly, unless you have three 10x programmers in your team, the microservice architecture is going to add a lot of complexity that will be a burden to manage.

So as usual, it's what you get VS what it costs.

Micro services are not free.

[eropple]

I would suggest that there is a nontrivial difference between a service-oriented architecture and microservices, and there can often be a lot wrong with the latter when misapplied. In smaller teams, thinking in terms of a service-oriented architecture (I prefer "product-oriented architecture", where something like a shared auth service is a product making semi-formal or formal contractual guarantees to its customers, internal or otherwise, at a business rather than a code level) tends to break up into larger pieces of functionality. You are still paying a cost for doing so, but I have found most clients to be more receptive and better able to manage, say, three of them, rather than a dozen or more.

Most teams don't have the problem that microservices actually exist to solve: a fractured org chart. Because that's when you want and need microservices--when your org chart's reporting chains are separated to the point where you need to separate functionality for human and political reasons, so as to avoid having one set of interests stomp on another. There's a geometric cost to any services; generally speaking one should be sure that the carried organizational and technical load of adding another (in the microservice-swarm pattern this load is smaller on margin but heavier in frequency, and it adds up) has positive ROI.