Ask HN: At what size do Microservices make sense?

Microservices are mostly an organizational tool: how do you get 500 programmers to work on one website?

Solution: one service per team, aka microservices.

(Occasionally there are technical reasons to have multiple services, e.g. one for loading data and one for processing data. But that's not really the same thing.)

I thought managers would give up on talking about "microservices" about 2 years ago I thought they would latch onto "blockchain" and "crypto." The are still talking about "microservices" but just mean that they want each team to have their own hardware and communicate over the network. Look, this stuff is three decades old at least. When someone says "microservices" I know they are a clueless idiot manager. They can't explain what they are talking about in terms of build, deployment, versioning, networking, processes, etc. They try to enforce mistakes that explode performance. They say "monolith bad." The can't really say anything beyond that because they are faking it.

Don't like monoliths? here's a "microservice architecture" for you, Java servlet API, circa 1997. Everyone can package their micro-service into a WAR file and deploy it to a service environment. That's right, Companies were doing this shit in the 90's. It probably amazes these same people to know there were servers and computer networks in the 1980's as well. Http was not even the first popular protocol of its kind.

What I hate are these managers who pretend they know what they are talking about saying, "microservices", but they are fucking faking it every step of the way.

Visibility of benefits depends on how your engineering organization is structured. Once you have a lot of teams working with monoliths becomes very painful. Having independently deployable unit starts making more sense then. Each service owner has to expose APIs for their users and that forces them to think more about how their service is supposed to be used and what problem is it solving. This also gives autonomy to teams in developing/maintaining their services (tech choice/programming language). Services also help in isolation and QoS. For example if you have different services handling order execution and order listing, the service handling execution has to be highly available and responsive while you can be a bit lax with other one.

With services you do need to have a good monitoring system in place. Also having ability to trace a request across services is a great boon. Helps in proper communication across teams.

These are of course only some of the reasons I could think but one thing should be clear that going Microservices route involves buy-in from the engineering org and a good enough developer population (I feel ~30+ is good to start)

It's a buzz word with no content. "Microservice architecture, or simply microservices, is a distinctive method of developing software systems that tries to focus on building single-function modules with well-defined interfaces and operations." That is the normal way of developing software systems.

In practice, it can mean responsive web sites that relies on AJAX end points or a collection of REST api:s. But you can never know that any two people mean the same thing when they speak about "microservices."

In my opinion your perceptions are correct. Microservices aren't a cure-all to be applied indiscriminately. They're a design pattern that's useful in some contexts and less so in others.

In order to really benefit from the use of microservices your organizational structure has to be non-monolithic as well (Conway's law), i.e. ideally you'd have cross-functional teams that take end-to-end responsibility for single microservices.

If you have to ask the question you don't want to do it :)