You Want Microservices, but Do You Need Them?
40 comments
·November 30, 2025stoneman24
I would really like to send this article out to all the developers in my small company (only 120+ people, about 40 dev & test) but the political path has been chosen and the new shiny tech has people entranced.
What we do (physics simulation software) doesn’t need all the complexity (in my option as a long time software developer & tester) and software engineering knowledge that splitting stuff into micro services require.
Only have as much complexity as you absolutely need, the old saying “Keep it simple, stupid” still has a lot of truth.
But the path is set, so I’ll just do my best as an individual contributor for the company and the clients who I work with.
walt_grata
I started making the case for organizational efficiency rather than a technical argument. Demonstrating where the larger number of people and teams necessary to make a decision and a change and how that impacts the amount of time to ship new features has been more effective IME.
szundi
[dead]
echelon
If you have workloads with different shapes, microservices make sense.
If not, do the monolith thing as long as you can.
But if you're processing jobs that need hand off to a GPU, just carve out a service for it. Stop lamenting over microservices.
If you've got 100+ engineers and different teams own different things, try microservices. Otherwise, maybe keep doing the monolith.
There is no "one size fits all" prescription here.
LtWorf
I thought microservices were old by now, which is why this kind of articles are finally appearing.
null
p1necone
I like goldilocks services, as big or as small as actually makes sense for your domain/resource considerations, usually no single http endpoint services in sight.
8f2ab37a-ed6c
It's funny that we've now been having this conversation on HN for at least a decade.
rockemsockem
You need multiple services whenever the scaling requirements of two components of your system are significantly different. That's pretty much it. These are often called micro services, but they don't have to actually be "micro"
twodave
I came here to say the same. If you’re arguing either for or against microservices you’re probably not thinking about the problem correctly. Running one big service may make sense if your resource needs are pretty uniform. Even if they’re not you need to weight the cost of adding complexity vs the cost of scaling some things prematurely or unnecessarily. Often this is an acceptable precursor to splitting up a process.
the__alchemist
On the theme of several other responders:
I don't want microservices; I want an executable. Memory is shared directly, and the IDE and compiler know about the whole system by virtue of it being integrated.
ErroneousBosh
I love the idea that I can compile all my functionality including HTML templates, javascript, and CSS into a single albeit huge Golang binary.
I have never done this yet.
But I love the idea of it.
hosainnet
You can already do this with Deno Compile
SatvikBeri
I loved uberjars back when I was writing Scala. I don't miss much about the JVM, but I really miss having a single executable I could just upload and run without having to pay attention to the environment on the host machine.
null
mjr00
I feel like this has been beaten to death and this article isn't saying much new. As usual the answer is somewhere in the middle (what the article calls "miniservices"). Ultimately
1. Full-on microservices, i.e. one independent lambda per request type, is a good idea pretty much never. It's a meme that caught on because a few engineers at Netflix did it as a joke that nobody else was in on
2. Full-on monolith, i.e. every developer contributes to the same application code that gets deployed, does work, but you do eventually reach a breaking point as either the code ages and/or the team scales. The difficulty of upgrading core libraries like your ORM, monitoring/alerting, pandas/numpy, etc, or infrastructure like your Java or Python runtime, grows superlinearly with the amount of code, and everything being in one deployed artifact makes partial upgrades either extremely tricky or impossible depending on the language. On the operational and managerial side, deployments and ownership (i.e. "bug happened, who's responsible for fixing?") eventually get way too complex as your organization scales. These are solvable problems though, so it's the best approach if you have a less experienced team.
3. If you're implementing any sort of SoA without having done it before -- you will fuck it up. Maybe I'm just speaking as a cynical veteran now, but IMO lots of orgs have keen but relatively junior staff leading the charge for services and kubernetes and whatnot (for mostly selfish resume-driven development purposes, but that's a separate topic) and end up making critical mistakes. Usually some combination of: multiple services using a shared database; not thinking about API versioning; not properly separating the domains; using shared libraries that end up requiring synchronized upgrades.
There's a lot of service-oriented footguns that are much harder to unwind than mistakes made in a monolithic app, but it's really hard to beat SoA done well with respect to maintainability and operations, in my opinion.
SatvikBeri
Re 1: I like Matt Ranney's take on it, where he says microservices are a form of technical debt – they let you deploy faster and more independently in exchange for an overall more complex codebase.
This makes it clear when you might want microservices: you're going through a period of hypergrowth and deployment is a bigger bottleneck than code. This made sense for DoorDash during covid, but that's a very unusual circumstance
eternityforest
I don't want microservices, I think what I really want is self contained WebAssembly modules!
kaladin-jasnah
What's the performance trade-off of something like this over containerization? I have heard of an operating system that runs WASM (https://github.com/JonasKruckenberg/k23).
ethanwillis
highly depends on the wasm runtime we're running things on. I haven't seen any good recent benchmarks (as in the past few years). But, if I remember right wasmer is putting together some and trying to automate the results for them.
rao-v
Unironically this
vb-8448
in my opinion "you need microservices" peaked around 2018-2019 ... does nowadays someone think that, apart from when you reach certain limits and specific contexts, they are a good idea?
dzonga
microservices were an effect of the ZIRP era. you literally have places like Monzo bragging that they've 3 microservices for each engineer.
3 tier architecture proves time and time again to be robust for most workloads.
LaurensBER
1 micro-service per pizza sized team seems to work pretty well.
Put it into a monorepo so the other teams have visibility in what is going on and can create PRs if needed.
LtWorf
Uh? You eat less than a pizza per person?
SiempreViernes
To be fair pizzas are quite easy to scale from small kid sizes up to enough for several persons.
But it is a bit sad that the poster apparently never bought a pizza just for themselves.
hackpelican
8x engineer
I'm helping a company get out of legacy hell right now. And instead of saying we need microservices, let's start with just a service oriented architecture. That would be a huge step forward.
Most companies should be perfectly fine with a service oriented architecture. When you need microservices, you have made it. That's a sign of a very high level of activity from your users, it's a sign that your product has been successful.
Don't celebrate before you have cause to do so. Keep it simple, stupid.