this post was submitted on 12 May 2024
184 points (90.7% liked)
Programmer Humor
31250 readers
1092 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Micro services are a lot easier to scale out since they behave independently from each other, you can have different levels of replication and concurrency based on the traffic that each part of your system receives.
Something that I think is pretty huge is that, done right, you end up with a bunch of smaller databases, meaning you can save a lot of money by having different levels of security and replication depending on how sensitive the data is.
This last part also helps with data residency issues, which is becoming a pretty big deal for the EU.
Something to consider is a monolith can have different entry points and a focused area of work. Like my web application monolith can also have email workers, and background job processers all with different container specs and scaling but share a code base.
And coming from a background where I work heavily with Postgres a bunch of smaller segregates databases sound like a nightmare data integerity wise. Although I'm sure it can be done cleanly there are big advantages with having all your tables in one database.
I see, I'm definitely biased towards micro services after years of dealing with horribly made monoliths but I see what you mean.
At the end of the day I think both approaches have pros and cons.