Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't start with microservices – monoliths are your friend

arnoldgalovics.com

Post reply on HN
Print view View original

461–468 of 468 posts

Re: Don't start with microservices – monoliths are your friend

#461

Post by addicted »

jameshart wrote: post #288
ozim wrote: post #229

Earlier quoted context omitted.

Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…

The interesting thing about microservices is not that it lets you split up your code on module boundaries. Obviously you can (and should!) do that inside any codebase. The thing about microservices is that it breaks up your data and deployment on module boundaries. Monoliths are monoliths not because they lack separation of concerns in code (something which lacks that is not a ‘monolith’, it is what’s called a ‘big b…

.NET Remoting, from 2002, was expressly designed to allow objects to be created either locally or on a different machine altogether.

I’m sure Java also had something very similar.

Monolith frameworks we’re always designed to be distributed.

The reason distributed code was not popular was because the hardware at the time did not justify it.

Further, treating hardware as cattle and not pets was not easy or possible because of the lack of a variety of technologies such as better devops tools, better and faster compilers, containerization, etc.

Re: Don't start with microservices – monoliths are your friend

#462

Post by CRConrad »

ravenstine wrote: post #238
ozim wrote: post #229

Earlier quoted context omitted.

Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…

> monolith was always supposed to be MODULAR from the start Well, that certainly is sensible, but I wasn't aware that someone had to invent the monolith and define how far it should go. Alas, my impression is that the term "monolith" doesn't really refer to a pattern or format someone is deliberately aiming for in most cases, but instead refers to one big execution of a lot of code that is doing far more than it shou…

> I wasn't aware that someone had to invent the monolith

Why, of course someone had to: Whoever sent it to those hairy guys at the beginning of 2001.

Re: Don't start with microservices – monoliths are your friend

#463

Post by CRConrad »

kgeist wrote: post #272
KronisLV wrote: post #104

I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…

We've been following this modular monolith approach as well (for 3 years now), bounded contexts and all, but our architectural end goal is still "mostly microservices". Maybe it's specific to PHP and the frameworks we use (what the modulith is written in) but the startup time of the monolith is just unacceptable for our processing rates (for every request the framework has to be reinitialized again, with all the 9000…

> modulith

Bravo!

Re: Don't start with microservices – monoliths are your friend

#464

Post by alex-2k1 »

Product Owner: Hey guys, I came up with this really great feature. Our competitors are already doing it so we gotta do it quickly. Is it possible to do it in 2 weeks? Team: No, we need 10 weeks because scale * Product Owner jumps out of the window (obviously realizing product is doomed and company never get another client without this feature)

Is this real life?

Re: Don't start with microservices – monoliths are your friend

#465

Post by jvolkman »

dastbe wrote: post #361

I'm curious, has anyone leveraged bazel's package visibility rules to improve isolation within a monolith? one of the things i don't like about monoliths is that tight coupling is often silent rather than noisy, whereas if someone is editing package visibility rules to make library internals A visible to package B i know exactly what's going on.

Google uses visibility rules all the time (with Blaze, which is basically Bazel). Mixed with the repository's OWNERS system which uses a hierarchical tree of permissions files, you can't take a dependency on someone else's private packages without their permission.

Re: Don't start with microservices – monoliths are your friend

#466

Post by CRConrad »

usrbinbash wrote: post #109
marginalia_nu wrote: post #68

Earlier quoted context omitted.

I've seen organizations that have hundreds of developers organized in 5-10 man teams, each managing their microservice. I think it tends to happen when a large organization decides to get down with the kids and start to do microservices. Conway's law enters into it in a lot of ways. Because of the way the people are organized into tiny isolated teams, the code shares that shape too. There is an event horizon one team…

> It's a lot of code, but it's not a lot of logic. The exact reason why I compare microservices to OOP ;-)

> The exact reason why I compare microservices to OOP ;-)

That's just because some guru -- Uncle Bob, or even more probably Martin Fowler, I think -- some (rather long by now) time ago wrote a lot of examples along the lines of "methods should be at most five, preferably three, lines long" in Java.

If you look for later examples of the same kind of recommendation you'll probably find they're mostly written in funtional languages nowadays, so you could just as well say "that's why I compare microservices to FP".

Re: Don't start with microservices – monoliths are your friend

#467

Post by mbrodersen »

bayesian_horse wrote: post #452
mbrodersen wrote: post #445

Earlier quoted context omitted.

So your argument is that bad developers will mess things up. I am sure most would agree with that argument. What does that have to do with monolith vs. micro-services? Bad developers will make a mess of micro-services as well.

Yes, the original argument was that boundaries can't be enforced. Arguably, it is easier to enforce boundaries between microservices.

You most definitely can enforce boundaries in libraries. Simple make sure that each library can compile and work with only the dependencies available it is allowed to have.

Re: Don't start with microservices – monoliths are your friend

#468

Post by randomswede »

lucian1900 wrote: post #457
randomswede wrote: post #416

Earlier quoted context omitted.

The archetypical "microservice" ecosystem I am aware of is Google's production environment. It was, at that point, primarily written in C++ and Java, neither very famous for being dynamically typed. But, it was a microservice architecture built primarily on RPCs and not very much on message buses. And RPCs that, basically, are statically typed (with code generation for client libs, and code generation for server-side…

Or you can deploy your monolith several times, for each scaling profile. That’s not a reason to do micro services.

It depends. If your monolith requires, say, 16 GB to keep running, but under the hood is about 20 pieces, each happily using less than 1 GB, tripling only a few of these means you may be able to get away with (say) 25 GB. Whereas tripling your monolith means 48 GB.

You can obviously (FSVO "obvious") scale simply by deploying your monolith multiple times. But, the resource usage MAY be substantially higher.

But, it is a trade-off. In many cases, a monolith is simpler. And in at least some cases, a monolith may be better.

Post reply on HN