Hacker News Reader

Comment by stuaxo | Hacker News Reader

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.

View on HN

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.

And this organizational overhead is why I disagree with his setion about structuring your organization to fit microservices. I have seen first hand over horrible it is when services do not share DBA resources for example. Every service has its own incorrectly and differently configured cloud PostgreSQL instance. Plus it bring really hard to innovate and create new features since many innovative features require you to touch multiple services and talk to a whole bunch of teams.

This. It’s also more expensive. If one DB is multi-AZ, then all of them need to be, otherwise you’re giving up all reliability improvements. So now instead of a single beefy instance in multi-AZ with a few read replicas, every service has that.

And as you correctly point out, the odds are low that there’s any semblance of a centralized configuration (nor that anyone knows what all the options for). So you wind up with 30 different DBs, all with different performance characteristics, and a ton of data duplication. Not to mention the observability nightmare. You want to trace something E2E? Have fun following all the traces and queries.

Somebody has never watched the whole company go down because some other team wrote a bad migration to the central db.

Which is a large reason why I don’t think dev teams should be managing DBs. It’s rare that anyone actually understands them, much less proper administration, configuration, tuning, etc.

If you have no other choice because you’re a tiny startup, then fine, but at least show the DB the respect it deserves, and read its documentation. You wouldn’t (I hope) write and run code when you had no idea how it worked, or what the potential ramifications were, so don’t do it for the rest of your tools.

Yes, I have watched that happen both in microservices and monoliths.

The only good argument I know for microservices is organizational:

When each team is responsible for one microservice, they can manage that with much less painful coordination with other teams.

My experience has been the total opposite. When each team is responsible for a service then to build anything complex you need to have meetings with stakeholders from a bunch of teams. So much time wasted on coordination compared to when working on a monolith. There you usually just need to get buyin from the platform team plus at most one other team. And that assuming you can't just build it and open s pull request which is often the case.

I also definitely prefer a monolith, if possible!

Yes, they can do their own thing without having to worry about their pesky users. In reality, this means that when you consume somebody else’s service and you need something changed, you have the choice to either hack up your own thing or somehow convince the service team to put your needed changes on the backlog. From my experience you often end up with everybody implementing some version of what the official service is supposed to do because the service can’t be bothered to make the changes within a reasonable time frame.

I would do micro services only once the requirements are very stable and there is a clear need for scalability. Microservice first architecture is a recipe for complexity.

I think the cross team dynamics you describe works the same way in a monolith architecture.

One difference/advantage in a monolith is that you don't have to worry which version the other microservices are on.

And TBF this is a great reason for why microservices.

That's the why, but the implication is that it's possibly not the most efficient way to build the system, and that we can't do better because we're no good at communication.

Conway's law

That's a big part of it!

Function is really a tiny issue comparing to serving static assets (ie. a fronted application) by deploying them as a dedicated Nginx microservice with a couple of files copied to the container image :)

Sure… but CPU overhead is kind of a technical detail, not a flaw in the concept. When you have a conversation about microservices, 95% of the time, the conversation veers into these details like CPU overhead. I think that’s what the article author is getting at. It’s a conversational trap—people have so many things to say about microservices.

In the end I think that microservices are not a big deal. It’s like choosing your programming language or choosing whether you want to use object-oriented programming. These decisions all have impact, but they generally aren’t revolutionary decisions. Object-oriented programming didn’t give us a massive wave of reusable code. Rust hasn’t unlocked some new, previously unseen level of developer productivity. Microservices are the same way.

Reply on news.ycombinator.com