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

Keep the monolith, but split the workloads

incident.io

Post reply on HN
Print view View original

131–140 of 161 posts

Re: Keep the monolith, but split the workloads

#131

Post by marcosdumay »

taneq wrote: post #76
devoutsalsa wrote: post #27

Earlier quoted context omitted.

A monolith doesn’t have to be one giant ball of mud. It can be discrete, well-factored services all by itself. I recently worked on decomposing a monolith into micro services, but it felt like we were just spreading one big problem over multiple services. All of the services ended up being tightly coupled, even the the goal was to avoid that. We created a macrolith.

Exactly! All this debate seems to stem from people being forced to work with a big ball of mud and then concluding that no one process should ever be allowed to become that big, because big processes are balls of mud. And so, having missed the real lesson (which isn’t ‘don’t make it big’ but rather ‘don’t make it out of mud’!) they build a big ball of little balls of mud.

> they build a big ball of little balls of mud

Nah, they make a lot of sturdy, well structured rocky balls.

And let them move around a big mud soup that is outside of their sight. So they don't even see mud.

Re: Keep the monolith, but split the workloads

#132

Post by withinboredom »

dontlaugh wrote: post #120
ohgodplsno wrote: post #77

Earlier quoted context omitted.

If your database isn't the performance issue and those two services spent 99% of the response time on calculating the 15755th digit of pi, not separating the database isn't a problem. Similarly, if both of your services need to fetch some user information, but you haven't created a user information service with its own database they could both talk to, having a shared database is fine. Splitting each and every servic…

Why even bother then? If your code shares the same database then it’s a single service. Anything else is just unnecessary overhead.

Wut? You can share databases and simply not write to the shared database because it’s a read only replica. Saves a bunch of overhead…

There’s a dozen reasons to share a db.

Re: Keep the monolith, but split the workloads

#133

Post by dontlaugh »

withinboredom wrote: post #132
dontlaugh wrote: post #120

Earlier quoted context omitted.

Why even bother then? If your code shares the same database then it’s a single service. Anything else is just unnecessary overhead.

Wut? You can share databases and simply not write to the shared database because it’s a read only replica. Saves a bunch of overhead… There’s a dozen reasons to share a db.

Then you're depending on the schema of the other service, which means you can't deploy them independently. You might as well have kept everything in a single service.

Re: Keep the monolith, but split the workloads

#134

Post by ac2u »

0xbadcafebee wrote: post #94

I never see a blog post looking at the specific requirements of an application and fitting the architecture, data model, and implementation to those requirements. "Monolith vs Microservices" is like saying "18-wheeler vs 20 Toyota Corollas". There are other forms of transportation, and using just one mode may not serve your business well. By the way, it's 2023... if you have a greenfield project, you should be using…

>if you have a greenfield project, you should be using event-driven data processing. We got rid of the horse and buggy, let's please get rid of cron jobs.

I don't see why event driven processing and cron-jobs (or any other time-based task scheduling mechanism), are strictly mutually exclusive.

Re: Keep the monolith, but split the workloads

#135

Post by curioussavage »

marcosdumay wrote: post #130
KronisLV wrote: post #36

I quite like the article and the advice it presents, building what I'd call modular monoliths (that can have modules be enabled or disabled based on feature flags) is indeed a good approach for both increasing resiliency and decreasing the blast radius of various issues. However, this bit stuck out to me: > When a bad Pub/Sub message was pulled into the binary, an unhandled panic would crash the entire app, meaning w…

> There's always some error handling logic wrapping around the request handling Yeah, some languages make this easier than others. The way you described it made me think it was Rust, a language where those handlers are not trivial, but not incredibly hard either. But it seems that Go developers have it worse (no big surprise here). Of course, the champions on unhandled failures are always C and C++, where almost any…

I actually found that in practice my go applications were much more resilient. First one in production was handling well over 100k req/s and it was extremely reliable. As a beginner it was very satisfying.

Re: Keep the monolith, but split the workloads

#136

Post by withinboredom »

pphysch wrote: post #125
ahofmann wrote: post #15

One often finds derogatory remarks about PHP, or that the popularity of the language is declining. Interestingly, the concept of PHP prevents exactly such problems, as a monolith written in PHP only ever executes the code paths that are necessary for the respective workload. The failure that the Rails app experienced in the post simply wouldn't have happened with PHP. Especially for web applications, PHP's concept of…

> Interestingly, the concept of PHP prevents exactly such problems, as a monolith written in PHP only ever executes the code paths that are necessary for the respective workload. This is just lovely when you have hundreds of PHP endpoints written by your predecessors and each endpoint has rewritten an arbitrary slice of the stack (usually data model layer) because there is no common code path required. Refactoring an…

Hmmm. When was the last time you wrote php? One file per route has been outdated for over 10 years.

Re: Keep the monolith, but split the workloads

#137

Post by mjr00 »

jameshart wrote: post #126
mjr00 wrote: post #95

Earlier quoted context omitted.

It's not about monoliths always being a ball of mud. Even the most well-composed monolith still has problems with teams wanting to do conflicting release cycles, needing clearer ownership over who has responsibility for what part of the codebase, and knowing who should be responsible for on-call for which services. And there is, of course, dependency hell, since everything in your monolith probably should depend on t…

> everything in your monolith probably should depend on the same version of third-party libraries. And definitely runs on the same underlying language/compiler/runtime version

Yep. Want to upgrade from Python 3.8 to 3.10? Good luck, cause you've gotta get every engineering team in the organization to buy in and schedule time to do upgrade testing, not to say anything about fixing any breaking changes.

Re: Keep the monolith, but split the workloads

#138

Post by pphysch »

withinboredom wrote: post #136
pphysch wrote: post #125

Earlier quoted context omitted.

> Interestingly, the concept of PHP prevents exactly such problems, as a monolith written in PHP only ever executes the code paths that are necessary for the respective workload. This is just lovely when you have hundreds of PHP endpoints written by your predecessors and each endpoint has rewritten an arbitrary slice of the stack (usually data model layer) because there is no common code path required. Refactoring an…

Hmmm. When was the last time you wrote php? One file per route has been outdated for over 10 years.

This particular codebase I am maintaining is 10-20 years old.

The point stands. Isolated code paths are great until you have to care about the ways they are not actually isolated (e.g. common database, platform-specific code, etc.).

Re: Keep the monolith, but split the workloads

#139

Post by withinboredom »

krab wrote: post #100
Jupe wrote: post #72

Earlier quoted context omitted.

While I completely agree that the efforts to build and maintain a set of micro-services are often better leveraged by a single monolith (even one that has several "run modes" as you've done here), a few questions inevitably come up: How do you coordinate the efforts of 200 engineers on a single repo/code base? Do engineers frequently get into long/drawn-out merge sessions as common code may be modified by a number of…

I have worked in a company with a monolith and about ten teams working on it. This is what helped: - Merging was automated (a robot tried to run tests against fresh master and merge only if green). - Deploy was fully automated and limited to working hours. - We added tests for problematic parts. For example static analysis for database migrations to prevent only safe actions in an automated fashion. However, if somet…

I worked on a monolith with 100+ devs working on it daily. Merging was automated as well for us, and a few unit tests were run on a production env — basically tests that asserted an engineer didn’t do anything stupid like add an infinite loop, or any of the other dozens things engineers had done that caused downtime. Deployment was done by running a script that took a lock, monitored the deployment progress, then released the lock. Sometimes you’d run the script and see people who hadn’t deployed yet, so you’d send them a message and ask if it was good to deploy. Sometimes they would say no if they found a last minute bug, so they would deploy your code for you.

Surprisingly, coordination isn’t that difficult. Humans are pretty good at talking to each other.

Re: Keep the monolith, but split the workloads

#140

Post by withinboredom »

dontlaugh wrote: post #133
withinboredom wrote: post #132

Earlier quoted context omitted.

Wut? You can share databases and simply not write to the shared database because it’s a read only replica. Saves a bunch of overhead… There’s a dozen reasons to share a db.

Then you're depending on the schema of the other service, which means you can't deploy them independently. You might as well have kept everything in a single service.

Aren’t you doing that anyway with json, protobufs, or whatever and using RPC? There’s always some agreed upon contract between services and changing that contract can always be delicate.
Post reply on HN