Hacker News Reader

Comment by bspammer | Hacker News Reader

> 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.

View on HN

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.

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

> 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.

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.

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.

> 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.

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.

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.

> 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

Yeah that doesn’t sound fun at all

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.

> 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.

Reply on news.ycombinator.com