Microservices are so expensive in terms of overhead.

Think: how much overhead, one function has in terms of the CPU calling it, then returning it.

How many 1000s of X more are you adding by making that a function inside another webserver.

Yes, there are times when a microservice is correct, there are many-many-many other times where using them is pure waste.

The CPU and network overhead are at least 1000x, but organizational costs are at least another 1000x on top of that (Unless you have a billion users or something, then the organizational costs might be a more manageable 10-100x — Building out fleets of data centers is expensive.)

The organizational costs come from communication overhead between engineers: Sync or maybe async calls within a codebase turn into an ad hoc distributed system, where a different team (and maybe different management chain) owns each network endpoint.

The part about no good definitions of micro-services is a bit far-fetched. I have one that is perfectly functional, though it requires an architect who is enthusiastic about micro-services, hasn't written any code in at least ten years, and who has no operational responsibilities nor experience. Getting one of these is not too hard; they abound. After that minor hurdle is cleared, the test is simple and has two parts: first, the functionality must fit in an ordinary function of some programming language, even Fortran will do in a pinch. Second, the architect has said that this must be a micro-service with its own git repository and independent database. That's it. If these two conditions are met, then this piece of functionality qualifies as a micro-service.

The point isn’t that there are no good definitions. The point is that there are many definitions.

I also have a working definition of a microservice, which is that it is a functional part of a system which exposes its functionality to other parts of the system via HTTP. This works for my team.

In general, we shouldn’t fetishize any particular technology, idea, or phrase. If a term obfuscates more than it clarifies, it’s not very useful.

Wouldn't that be considered an API?

An API is an abstract interface - the "I" stands for interface after all. An implementation of an API can be a microservice.

I certainly don't understand this HN's trend of hating on microservice, and the previous trend of hating monolith. I have worked in both extreme and both works fine. Sure there are things which could be implemented 20% faster with monolith or microservice architecture, but it was never in the top 5 issue that I face while doing software engineering.