Hacker News Reader

Comment by drob518 | Hacker News Reader

IMO, 99.999% of apps should just use monoliths with basic 1+1 redundancy. Unless you’re working at a FANG and require just insane scale, you really don’t need microservices or even lots of modularity. Just keep it simple. If you need more resources, buy a bigger system and scale up, not out. Only consider scaling out when you have exhausted scaling up.

View on HN

I probably agree more than this comment might suggest, but I think that you run into organizational dynamics limits before you run out of vertical scaling limits.

Shipping a monolith worked on by 250+ devs in 30 teams is slow due to the coordination needed as compared to 30 teams shipping 50-75 services.

Vertical scaling can take you really, really far operationally.

That's the strongest argument I can see; once you can get above 5 - 10 teams, you run into the organizational issues.

But again, most systems will never be there ;)

I've always maintained that microservices are more for scaling people than scaling systems.

I want to frame this and put it on my wall.

Coming up with a greenfield microservice design with arbitrary responsibilities and intercommunication feels so stupid to me. Why not build the thing as a monolith and split parts out when you actually have scaling problems, instead of solving theoretical problems? Development velocity is going to be way higher and it gives developers a chance to discover problems without having to deal with the mental overhead of shipping N services all at once.

The value of fast iteration cannot be overstated. Build the minimum viable version of the project first, then stress test it and break parts out when needed. This is much easier if you write modular code.

> Why not build the thing as a monolith and split parts out when you actually have scaling problems, instead of solving theoretical problems?

I sometimes think programmers are the last people who should be writing software.

The personality type that likes writing code is the exact type that likes tinkering around the edge and working on hypotheticals instead of addressing the problem at hand.

One solution is to have the senior ones (who have already been-there-done-that and lost interest in those possibly low quality outcomes or low velocities from a business perspective) handle architectural decisions and keep things on the rails by way of writing issue specs that the juniors (with those green personalities) will implement, reviewing their code, mentoring them, etc. -- carefully matching an ideal threshold of autonomy for each programmer which will relax over time.

I often see technologies adopted simply because they are the “latest and greatest” and “I want to stay relevant for my next job interview,” rather than sound technical reasoning. Unfortunately, these decisions are made by humans and those humans have lots of cross-cutting decision criteria. It’s a rare and highly mature engineer who can look at a problem and say “This old technology is a perfect fit.”

This is an organizational/tech leadership problem. Good technical leadership will put a kibosh on working on hypotheticals, because what you don't do is as important as what you do.

Good programmers pride themselves on striking compromises and shipping a smaller thing sooner and they love iterating. The ones that are working on hypotheticals unchecked are not bad--just nobody has educated them.

Microservices created the need for more teams, devs, coordination, meetings, scrum teams, scrum master, Jira, CI CD tools, cloud market and so on.. It is very well planned :)

It was — until developers started shouting "You don't need microservices. Just build a monolith."

Then, uncoincidentally, they started crying about how they couldn't find work anymore.

There are a lot of people who shouldn’t be doing software engineering.

2015:

- "I'm struggling to find work and need to make money. What can I do?"

- "Learn to code, good buddy! Software engineering solves all problems."

2025:

- "I learned to code and am still struggling to find work and need to make money."

- "You shouldn't be doing software engineering."

Yep, exactly.

Exactly.

> If you need more resources, buy a bigger system and scale up, not out. Only consider scaling out when you have exhausted scaling up.

This happens at all sorts of companies that are not FAANGs, and don't have "insane scale". There's an extremely large spectrum between the web site for Joe's Coffee Bar and Amazon. On commodity hardware, you hit issues with scaling up a monolith long before you reach FAANG level or "insane scale".

I've worked with multiple startups that have hit scaling limits with their monoliths. Inevitably, dealing with that is a huge problem because the monolith was developed with few resources under heavy time pressure. Modularity is lacking, breaking it up is difficult. Individual devs are often inclined to say that's just a skill issue, and that may have some truth to it, but managing those skill issues is a big part of what corporate software development is about.

This can have a huge impact on a company's funding, ability to deliver new features, ability to scale development, and of course ability to scale the user base. Typically, by the time they hit that wall, scaling the monolith horizontally is not a great option, because it wasn't designed to support that.

It's often been observed that microservices are a primarily an organizational tool, and that's true. But organization is critical if you have multiple development teams.

That doesn't necessarily mean every app should consist of hundreds of tiny microservices. But there can be enormous benefits from implementing an app from the start as independent services based on its natural divisions between modules.

Without knowing what the cause of those scaling problems were (CPU, memory, IOPS, etc.), I’ll have to take your word for it. But having worked at several startups, I can say that it’s a common disease that engineers start to optimize for the “we’re going to have a jillion customers” case long before they even have one customer, and that adds a whole bunch of complexity, cost, and schedule to the development, which increases burn and stands between the company and its cash-flow positive date. In fact, if it forces another round of funding, it can wash out the original employees or even kill the company. On the other hand, it’s easy to raise money when you have customers and are near cash flow positive. You can do a HUGE amount with a modern server with 100+ cores, TB of RAM, etc. IOPS are the one thing which hasn’t scaled quite as well. So yea, I’m being a bit hyperbolic in saying you need to be a FANG to consider it, but I think the main point still stands: most applications, if well-written, can be run well on today’s hardware and scaled up if they need it while eliminating most of the complexity associated with scaling out. Yes, there are exceptions to that rule of thumb.

The problem being, most people are in the cloud, and ‘basic 1+1 redundancy’ simply doesn’t work well in that distributed model and scaled up instances are expensive.

The tooling is good enough to scale out, but micro services are mostly beneficial for organizational scaling.

The value for other concerns is mostly situational.

Big instances are cheap relative to the cost of implementing horizontal scaling (at the app layer), plus engineering cost of Kubernetes or whatever your preferred orchestrator is, plus the heavy cloud tax on going "cloud native."

Even in the old days we were horizontal at the app layer, the persistence layer is what is hard.

Unless you have some very specific need, I was horizontally scaling the app layer in 1996 even in true monoliths.

K8s can be too much, but even when tooling and costs forced us to segment by technology layers, you never tried two node failovers.

If you are trying to share state at the app level you would most reduce availability, because of split brain etc…

The persistence layer was bad enough with shared quorum drives, heartbeat networks etc…

It sounds like you are just spinning up to app servers or are you talking about active/passive or active/active two node clusters?

That is vertically scaling in the way I understand the term, not just scaling out two instances.

I'm talking about true horizontal scaling where load is sharded across replicas. Active-passive is easy. Handling web traffic is also easy. Backend business logic is not so easy.

If you're message driven you can maybe have a set of replicas consume off of a message bus like Kafka or NATS, but now you need to maintain that cluster, as well as build a messaging layer. What protocol do you use, etc?

Then there's the question of what triggers scaling up/down. The simple way is scale on CPU utilisation but then you get flapping issues. Or if load isn't completely evenly distributed you get one replica starving for CPU whilst the rest have too much.

All of these questions go away if you can just provision a big node and be comfortable that it will be able to handle anything within reason.

100%; and if you have a solid structure in your modular monolith - it's trivial to take one or two problematic/performance sensitive modules and turn them into independent services. But most of the systems will never get up to this scale

Right. Launch it, get customers, see what needs to be scaled up, buy a new server, and only then, carve out that problematic piece and scale it as a separate service. But by then you have the data to justify it and you have sidestepped a lot of complexity.

The 1 + 1 setup can make it up even on FAANG level, it's not more about how much a single machine can do but more about how i you organize teams and what kind of swe you want ... bigger companies want "fungible" like SWEs, and it's easier to swap a swe in a microservices architecture vs monoliths.

It’s easier swapping an engineer into a module associated with a well-architected monolith than swapping them into a microservice. Given a monolith uses function calls that are fast and don’t fail when the network cable is unplugged or DNS gets misconfigured, it’s arguably a lot easier. There are fewer failure modes and overall lower complexity. No circuit breakers, back offs, retries, etc.

Reply on news.ycombinator.com