Comment by deniska | Hacker News Reader

Comment by deniska | Hacker News Reader

Parent Full thread

Unless you have a strong technical or organizational reason to use microservices, using microservices is just more work to achieve the same results.

Organizational reason would be multiple people/teams who don't want or can't talk much to each other, so they develop pieces of a larger system as relatively independent projects, with clear API and responsibility boundaries. Frontend/backend style web development is an example of such approach, even though we don't typically call these parts "microservices".

A technical reason I can see is some component of a system actually having to be written in a different stack, or to be run in a separate location for business reasons (separate physical computer, separate VMs or containers don't count). Like a firmware running on an IoT system. Or most of the system uses python, but there's a really good library in java for solving some very specific problem, so let's use it.

If neither of these reasons stands, you don't have a microservice architecture, you have a distributed monolith. You just replaced some function calls with RPC. RPC call which takes a much a longer time than a local one, and can randomly fail. Most of your microservices are written in a single stack, so you refactor common parts into a library, but then different services are stuck to use different versions of this library. You end up with a much slower and a much more fragile system which is harder to work on for no good reason.

> no good reason

How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket.

People throw around “distributed monolith” like it’s a dirty phrase but I’ve found it actually a very pleasant environment to work in.

That's a fallicy. You've optimized for one use case, but you've made everything else more complicated as a consequence.

Deploying a single monolith is faster than deploying 10 microservices, especially if you find yourself in the model where your microservices share code, you've ended up with a distributed monolith instead of microservices.

> You've optimized for one use case, but you've made everything else more complicated as a consequence.

Yes, but that use case happens to be something that I need to do 5 times a day - make a small (<200 line) code change to one small part of the distributed monolith, and deploy it immediately.

This also means that if something goes wrong, I can rollback those changes immediately without rolling back the work of any of the other 50 engineers in the company.

Very little signoff required, very small blast radius.

I doubt you can judge the blast radius.

Say your little service just changed how it parsed backticks. Now that innocuous change may affect none of the immediately connected microservices but another services three hops away relied on the old behavior of your parser through some complex business rules driven logic. Now go test and later troubleshoot that vs standing up a single monolithic jar on your laptop and seeing the exception stack trace tell you exactly what you broke.

I can see your point, but I’ve been working like this for 3 years and my anecdotal evidence is that kind of thing simply doesn’t happen.

You would only deploy 10 microservices if all 10 changed at once. Why are all 10 changing at once?

> especially if you find yourself in the model where your microservices share code

Good architecture decisions trump the monolith vs microservices argument. I'm not saying cross-service shared code is inherently bad, but it does have a bad smell.

Don't forget serdes costs for microservices. They kill runtime speeds even with nice toys like flatbuffers.

I don't know, is it really harder to deploy 10 services? Isn't it all automated? The organization overhead is lower because you can leave most of the app untouched and only deploy what you need to.

You could screw it up and make it harder for yourself but its not guaranteed either way.

> People throw around “distributed monolith” like it’s a dirty phrase but I’ve found it actually a very pleasant environment to work in.

For ones I saw, the answer to the question "how do I run our project on a single laptop?" is "haha, you don't". That makes features which could take hours to implement take weeks. But deployment is 5 minutes instead of… 15? Not too worthy of a trade-off.

Your CSV writer probably has both technical and organizational reasons being an independent unit of development. Or, in other words, something which appeared organically, rather than someone deciding months prior before a project even started that authentication and user profiles should live in two parallel universes.

You bring up an excellent point. As of now, it is impossible for me to run my company's backend ecosystem on my machine locally. What we do could easily be done by one simple monolith, but our eng. lead is obsessed with overengineered microservice architecture, so nobody can actually develop locally. Everything on the backend is done by a bunch of lambdas behind an API gateway.

I got so burnt out developing in that environment that I asked to become a pure frontend dev so that I wouldn't have to deal with it anymore.

Often with monoliths, once they go into production service at scale, the deployment can be "3 days, arranged 4 weeks in advance, requiring 9 sign offs including one VP"

I would call that a megalith, and not to be cute but to give a sense of scale which is useful. I think there is a point in which a monolith grows so big that is painfully obvious that size became an obstacle greater than the benefits. Pain tolerance differs so the label gets applied at different sized monoliths.

> deploy in minutes without having to rebuild and deploy a giant monolith

that's a tooling issue not a monolith vs microservice issue.

tooling can allow the exact same speed of deployment for tiny background processing without the need to completely segment your code base.

Why not...

> branch from whatever branch is in prod

> implement change on that branch (in this case adding a column), test

> deploy to prod

I realize the build and deployment process may be more complex than that making it hard... but it doesn't have to be.

I agree that a microservice OR even another system (a collection of services) is a good solution if you need to make quick iterative changes, and you can't do so with your current system.

That workflow is exactly what I do, but it's on a small codebase rather than on a big one.

The benefits of working on a small repo include:

* Faster compilation (only depend on exactly the libraries you need)

* Faster testing (only need to run the tests which are actually relevant)

* Easier to understand for new joiners because there's just less code to sift through

* Faster startup (this is probably java specific - the classloader is slooow)

* No (okay, fewer) rebase wars

* Easy to see what's currently being worked on because the Pull Requests tab isn't 200 long

* Very fast rollbacks without needing to recompile a git revert (just hotswap the container for that particular service). You can't do this in a monolith without risking rolling back someone else's important changes.

Distributed monolith can mean different things. I worked at a place with ~10 services sharing the same DB. It was awful

I worked at a place that had a few dozen services and one DB, worked on by dozens of developers. It was amazing. Oh and one repo, that made a huge difference.

Yeah that doesn’t sound fun at all

> it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith

This is orthogonal to monolith vs microservices. I've worked on monoliths that could easily be (and were) deployed very frequently.

>>> If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule

I call this a worker.

one strong operational reason I have seen recently is resource management.

The monolith where most API endpoints are instant and use constant memory, but some use much more memory and can be slower... is tough.Like if you just give a bunch of memory to each process now you're overprovisioning and if you try to be strict you run into quality of service issues.

If you split out homogenous API endpoints into various groups you now have well behaved processes that are each acting similarly. One process could be very small, another could be much larger (but handle only one kind of request), etc...

of course the problem with standard microservice-y stuff is now you gotta have N different applications be able to speak your stack. The idea of a monolith with feature sets is tempting... but also can negate chunks of microservice advantages.

Ultimately the microservice-y "everything is an API" can work well even as a monolith, and you would then have the flexibility to improve things operationally later.

At the same time, you have to be at a pretty huge scale before resource over-provisioning really hurts the bottom line. You can buy a lot of compute for the price of a single engineer's salary, and it usually takes more than one engineer to support a microservice architecture. Most applications hit problems scaling the database vertically long before they exhaust resources at the application level.

Hmm I get what you’re saying of course but in certain domains (think B2B SaaS) you might be running some compute-intensive stuff enough to where the differential is an issue.

Imagine 95% of your workload can run in 100 megs but 5% requires 1000 megs. You can overprovision of course but in a world of containers if you can isolate the 5% and route it you’re going to have a lot less in terms of operational headaches

I mean, this is kind of how microservices should be done. Start with a MVP monolith then carve off microservices if needed (performance or large team size).

The problem is when the lead dev has been huffing the architecture paint too hard and starts prematurely spinning up microservices because it feels good.

Reply on news.ycombinator.com