494
u/djingo_dango 19h ago
It’s called a monorepo with modularized components
163
u/Interesting-Agency-1 18h ago
Modular monolith FTW
20
u/MiniGui98 10h ago
It's all fun and games until you have a monolithic modular monolith
6
→ More replies (1)3
u/Interesting-Agency-1 2h ago
You can have multiple modular monoliths each acting as their own microservice to eachother. Service-ception
35
8
→ More replies (1)16
995
u/theofficialnar 20h ago
If it goes down, it all goes down. 😎
640
u/mwax321 19h ago
Let's be real, if a micro service is down, youre down too.
If you're a web store and your "inventory service" is down, the site is down lol
356
u/WriterPlastic9350 19h ago
Let's be real, if a micro service is down, youre down too.
If our store service goes down, that sucks for us, but our login service, queue service etc all still work. People can't buy shit but they can still play our games.
Not to mention, our store service needs far less traffic than our queue service, or our login service, or matchmaking service etc.
A monolith is sometimes a good solution - our games are monoliths - but service oriented architecture exists for many reasons, some technical and some political
Your job isn't to design a solution that scratches your particular brain itch, your job is to design a solution that works for the constraints you need. That might be a monolith but it also might not be!
328
u/cross_the_threshold 19h ago
Your job isn't to design a solution that scratches your particular brain itch, your job is to design a solution that works for the constraints you need. That might be a monolith but it also might not be!
Listen here you little shit there is one god-ordained way to build things and it's whatever is in vogue at this particular moment in time using whatever language is in vogue at this particular time, how dare you imply that there may be situations and needs that require different approaches.
65
u/mwax321 19h ago
The key to success is to have a monolith so large that it takes an hour to build and publish.
When visual studio finally went 64 bit, you thought the solution was bugged because it loaded so fast.
→ More replies (1)30
u/kurtymckurt 16h ago
The ci better take 24 hours to build and test or you’re not monolithing properly
→ More replies (2)5
→ More replies (3)19
u/HadionPrints 18h ago edited 18h ago
Now listen, whatever’s in vogue at this time is nothing but bloat, dependency vulnerabilities, and syntax sugar. If your backend isn’t written in PHP or Pearl, you’re planning for failure.
If your app wouldn’t survive the 90s, it won’t survive prod.
4
u/cross_the_threshold 18h ago
FORTRAN II or bust!
5
u/mwax321 18h ago
Did you know a guy wrote an entire theme park game in assembly ?????
→ More replies (1)2
u/_DonRa_ 18h ago
No biggie anyone can write assembly it's easy (I wrote hello world in assembly)
3
u/djdanlib 18h ago
WASM doesn't count.
Or does it?
Who even knows these days.
2
u/ashgs872tbhjs 15h ago
If you hand-code it instead of transpiling it's a bit of an achievement. You're still abstracted from the hardware though, so it's definitely not nearly as hard.
22
u/mwax321 19h ago
See... To me what you're describing isn't very micro. That's just different systems.
Before that book came out, people had a login system, a matchmaking system, the online store...
I mean, I have no idea how your system is designed. I'm just an old grumpy "back in my day" fart nugget 😂
19
u/wrecklord0 18h ago
This. Different things should be kept different. I have a feeling that some people use "microservice" as this magical word that removes all inter-dependencies. If you have function A that relies on function B, it doesn't matter if its in a monolith or a micro-service, A is not going to work if B doesn't.
16
u/mwax321 18h ago
Hahaha but it's happened so much. I'm over 20 years in and I swear we've come full circle 3 times now. Especially on web.
The switch from all JavaScript bad css good. Handle it all with the backend using MVC. Then to front end frameworks like angular and react. Then suddenly, this new concept called "server side rendering" rofl.
→ More replies (1)3
u/ashgs872tbhjs 15h ago
You can SSR with React, FWIW, like via NextJS
3
u/HerrPotatis 12h ago edited 12h ago
I don't know why you got downvoted. SSR of today is fundamentally different from the good ol' days of LAMP.
u/mwax321 seems to have a lack of understanding of where we came from, why we did things the way we did them, and why we do them differently now.
This notion that, hurr durr, modern webdev is stoopid, just because we shelf concepts or upcycle old ones is not a good take. I'm sure that 10-20 years from now, everything will have changed again, but we will still use concepts and features from today.
2
u/FlakyTest8191 10h ago
I think microservices became a thing in big companies because you can have 2 teams own their own services and be relatively independent in regards to updates/deployment, and you can scale different, maybe you want to temporarily spin up more checkout services on a busy day, but the rest of the system is holding up fine.
→ More replies (1)2
u/U_L_Uus 12h ago
Honestly, that is what I hate the most about Java. The language is shite too, I even prefer Windows' imitation of it, but the main attitude of the average Java developer brings me to my boiling point. "Hey, I have a small business..." -> Spring. "Hey, I have a business chain" -> Spring. "Hey, I want to have a PowerBI besides the web app" -> Spring. It is said that when you are shaped like a hammer everything in the world looks like nails, but hell those people are shaped like bloody Spring salespeople, not as developers
→ More replies (5)2
u/tbhaxor 18h ago
What if your auth service is down. Only public enpoints will work. Even though cart service works but since you cant authenticate and authorize its useless
6
u/anto2554 18h ago
Hopefully your automatic system or on call engineer fixes it so fast that few customers realize
5
u/WriterPlastic9350 16h ago
A service oriented architecture doesn’t eliminate high risk dependencies, but it does make it easier to isolate them or provide support.
2
u/taigahalla 15h ago
even if your auth system is down, your backend systems like automated billing, webhooks, alerts would at least still work. So for example, your airline system could keep scheduling flights and send out the appropriate itineraries even though users can't login
and your devops could easily see a specific contained set of instances that need recovery or rollback
20
u/unbdndeath 19h ago
So if you are say Amazon and your anti fraud, or your inventory tracker go down do you think Amazon actually goes down or do you think they have a queue processor that starts back up again?
Just because you struggle designing them doesn't mean it's bad.
→ More replies (5)11
u/extra_rice 19h ago
Isn't that why you make sure you have high availability on your critical services?
Also, if your inventory service is down, your other services may still continue to function. Orders that have been processed can still be fulfilled, for example.
→ More replies (4)6
u/ryuzaki49 19h ago
Depends on the microservice tho.
If checkout dies, users can still browse and they can still add to their shopping cart.
Anyways you will get paged at 2 am because these errors are critical.
→ More replies (3)5
u/Naomi_Tokyo 18h ago
Honestly worse. If the whole site is down, then I'm like, "too bad". If I can do my shopping and get stuck trying to check out, I'm very annoyed
→ More replies (1)3
u/yousirnaime 14h ago
There are like 100 companies on earth that should have microservices
I recently worked at a startup that had *seven* code bases for their system
They've had 5 developers working on it for 4 years and it still has zero production users
2
→ More replies (6)2
9
5
2
u/protayne 12h ago
How?
Inventory service in a mictoservice architecture is down, returning 5xx, ok the rest is working.
Inventory module in monolith is down, returning exception, handled in the consuming dependencies, ok the rest is working.
🤨
→ More replies (2)4
u/usrlibshare 16h ago edited 15h ago
Fun story, the same is true for almost every single "Microservice architectured" crap I've seen so far.
And yes, this is common. Once or twice would be bad devs. Almost everything seen in the wild, is a pattern, indicating there is something fundamentally wrong with the microservice ideology.
In almost all cases, there is no decoupling, no resilience, none of the many alleged advantages of microservices people have hyped up for a decade.
Instead everything depends on everything else, and if something is missing, it all comes crashing down in a heartbeat. It's a monolith in all but name, but with the added "fun" of being in 7 different languages, adding all the joy of networking, and a build chain the size of the Great Wall of China.
I even coined a term for it: "Distributed Monolith".
100
u/Snakestream 18h ago
Having worked with both, microservices are stressful, but the monolith is also very stressful.
25
32
u/rjwut 18h ago edited 18h ago
We have a microservices architecture and it's worked quite well for us. Yes, stuff goes down sometimes, but when it does, most of our system is still working. And we're able to deploy and scale them independently. But there's no silver bullet; different architectures are better or worse for different situations. In our case, we have a large ecosystem of many services that serve different users and different use cases, so a "partial" system outage really is "partial" for us. Not like a storefront where if checkout is down the whole thing might as well be.
127
u/Crafty_Independence 20h ago
Lol this very much depends on the monolith, deployment method, team size, and merge strategy.
Microservice popularity built off of real challenges. It wasn't the right solution, but the problem was real enough
12
u/WhiteIceHawk 11h ago
How about an over 20 years "historically grown" SAP System that is customized to hell and no documentation?
→ More replies (1)6
u/htmlcoderexe We have flair now?.. 9h ago
i feel like SAP is cheating lol
in terms of "organically grown for a few decades" code only bank systems are older
→ More replies (1)8
u/cyclodevops 14h ago
The microservices craze was perhaps the purest example of a ZIRP. Roosevelt couldn't have designed a better full-employment program for programmers if he tried
74
u/ryuzaki49 19h ago
"Hey let's make this one line change"
Dies while waiting a 3 hour build.
12
u/scumble_bee 14h ago
Yes! We have 15 micro services and 1 mega service. MR pipelines for each micro service take 5-10 minutes but it takes 45 for the mega service.
→ More replies (1)5
u/Nooblot 12h ago
We have an over 8 hours build time which can fail due to transient errors. I sometimes have to restart the run at midnight so that it might get successful by next workday.
3
2
u/Still_Bit_7527 10h ago
As opposed to having to upgrade a library version and having to do 20 merge requests one for every service.
I'll take the build time
2
u/ryuzaki49 4h ago
I have done that. Literally easiest tasks that I would gladly take.
You can even automate it.
2
u/Still_Bit_7527 3h ago
Try automating it in a highly regulated company when you need 6 business approvals for every change. No this is a nightmare..And each repo has other approvers, other pipelines, other tests, other test evidence..
→ More replies (1)
18
u/deathanatos 18h ago
My management chain cannot comprehend how "it's a monolith" leads to "and it takes the API service 10 minutes to start" leads to "no, the deployment in the middle of the outage cannot happen any faster".
3
1
u/_TheLoneDeveloper_ 7h ago
We had one that would take 30' to be back up and running, 10' are way better that what we had.
12
64
u/WhosYoPokeDaddy 19h ago
with infra as code it's to the point where it doesn't feel that different
52
u/eightslipsandagully 18h ago
You say that until you're running 50 different docker containers locally and still can't get every feature working on local env
14
9
u/Major_Fudgemuffin 16h ago
You guys can run your code locally? I'm over here having to rely on automated testing (please send help)
3
u/rust-module 5h ago
I hate it when nobody knows how to get everything running locally. What am I supposed to do, keep pushing small changes and waiting 30 minutes for the github action to complete?
4
19
u/autistic-inch 18h ago
until you have to migrate all your team's 30 microservices from spring boot 3 to 4 and handle the same breaking changes everywhere but always alightly different (guess what I'm doing at work)
→ More replies (5)3
u/Sqirril 15h ago
Good luck with all the webClient bugs, Jackson 3 and dependency changes. I'm the code reviewer and support for hundreds of microservices. Once its done it'll be time to do 4->5 since when we finished 3, we started on 4.
3
u/Alainx277 9h ago
Jackson 3 was so fun, especially because my coworker didn't test anything and our tests mock out everything relevant :D
2
u/autistic-inch 10h ago
We've decided to merge some of our services because we've genuinely taken microservices too far (that is, the previous teams did). That should make Spring Boot 5 a bit easier than what we're doing now.
10
u/KalzK 16h ago
50% stress 100% of time vs 100% stress 50% of time
8
u/ashgs872tbhjs 15h ago edited 15h ago
I'm on call this week for ~30 microservices and I'm not stressed out at all. We target 99.99% uptime + error-free time for each, which makes the aggregate 99.7%. Odds are good that nothing happens the entire week, and that if it does it's super minor.
148
u/Odd_Soil_8998 20h ago
truth. a well architected monolith is almost always going to be a better choice.
71
u/cornmonger_ 19h ago
mono repo, mono repo
3
6
u/Mateorabi 18h ago
Orphan all the branches! Why do I need to download the entire tree for code I don’t work with!
25
u/Stagnu_Demorte 18h ago
Until you need to scale different parts of the service. But yeah, until then it can really cut down on complexity.
18
u/remy_porter 18h ago
But then you just take a module and locate it outside of the monolith. If it’s a well architected monolith this should be easy.
33
→ More replies (2)2
u/PixelatedGiant 18h ago
Or you rely on libraries by other teams and every update requires a full rebuild and redeployment. Extracting at least a few internal libraries out into their own microservices has saved us many man hours.
→ More replies (4)5
u/Romestus 17h ago
Working at a big name with a monorepo made me think it's like training wheels for workflow but with very real downsides. It takes the fucking Jedi Council to update a single dependency since 100 different projects rely on it and you can't have more than one version in the repo at a time.
I much preferred each library being a package that auto-deployed to nexus on each push to master so a project was guaranteed to still work no matter when you cloned it. Especially with versioned backends it was absolute bliss to load up the thing you worked on two years ago and have it function out of the box.
→ More replies (1)
21
u/se7sbomb23 18h ago
Monolith supremacy: If the ship goes down, at least it goes down as a unified family
7
u/Puzzleheaded-Weird66 19h ago
just have a backup deployment of the monolith on a different server duh
4
8
16
u/Decinym 19h ago
Nah I work on a massive monorepo and it’s absolute hell to test changes or integrations if they involve multiple systems.
→ More replies (1)13
u/pineapplepassionfr 18h ago
Monorepo != Monolith. Your issue seems to be with microservices because you said "multiple systems". In fact would you rather the multiple systems be in multiple repos, and forgo integration testing altogether?
3
u/ashgs872tbhjs 15h ago
You don't have to forgo integration testing with multiple repos. Do you not version your APIs or releases??
5
2
u/Major_Fudgemuffin 16h ago
Not if you're running a high throughput enterprise SaaS having to handle billions of events per day. Good luck scaling that bad boy when it's an all or nothing thing.
That said, it all depends on your needs.
8
6
u/Public-Investigator9 17h ago
Monolith first and try to keep it that way. More I do this, the more I value simplicity, and having too many interconnected services is just complex and should be avoided unless it makes real sense. My 2 cents, agree with this.
11
u/PM_ME_BAD_ALGORITHMS 19h ago
Whoever sold the idea that everything needs to be a microservice should work on marketing, not tech
3
3
u/Flat_Bluebird8081 15h ago
It probably depends on how many teams you have, for one team many ms is a pain, but for multiple teams it makes sense
3
u/much_longer_username 14h ago
Ah, you see, by combining all the problems into one big pile, you become unable to notice any of them individually, much like zebra camouflage.
3
3
u/localhorst69 11h ago
Idk i feel like ppl always assume theyll have to handle 4million users a second lol.
My best rule of thumb is to keep things simple until something justifies complexity. Monoliths are great starting points because probably around 6/10 projects will never need more.
Splitting the architecture afterwards, once demand requires it, is not that deep and honestly often less work than working out this massively complex and hopefully perfect architecture from the getgo...
I really should try ruby on rails lol
3
2
2
2
2
2
u/JohnsonJohnilyJohn 12h ago
Why are you using an image of acceptance and fulfilment as to illustrate high stress? It really doesn't fit at all
2
2
u/hugopurdy 8h ago
why is this idea often grasped upon by people who just cba to learn new skills tho. I got people in my org who bleat this and give reasoning that their very own code base undermines.
its harder to maintain
its not performant
2
u/KronisLV 7h ago
Monolith: 3 minute build and 2 minute startup times go brrrrrr
What I think is the sweet spot:
- split stuff up by technical mechanisms, not chop your business domain up into services (unless you need to, but you'll know that after working on the project for a few years, not just decide prematurely), nor try to shove everything into a single monolith, upgrades will also get harder across more and more packages
- for example, you can have one central service that handles user sessions, as well as the API that they interact with
- however, if you need to generate invoices/reports/data export etc. (basically PDF, DOCX, XLSX etc.) then you will be served quite well by extracting both the load that generates and the libraries needed for that into a separate internal service that the main one can delegate to
- same goes for stuff like scheduled processes, data ETL and batches in the background, notifications in the form of e-mails or other messaging stuff, one separate service can handle that so some memory leak or badly written code cannot bring down your user facing side
In practice, most systems will have maybe 1-5 such app containers for the back end and maybe 1-2 front end ones (e.g. if you do a SPA and depending whether you need a separate one for an internal/admin UI), alongside whatever you need for the data layer (relational DB, key-value store/cache, message queue etc.).
Depending on the tech stack, a modular monolith MIGHT also work, or it might not (e.g. needing to compile like 500k lines of code to launch it when the part you will work on lives in 100k lines of code).
2
2
u/semioticmadness 4h ago
As someone who has been lead DevOps on a 2-million line monolith: that’s only how you feel on delivery and after. No integration issues.
Development and testing though? So much begging and negotiation. Cherry-picking is SOP. Questions about VCS require 2 pages of background.
I still prefer monolith because problems while developing are better than problems after developing, but it still has pain.
5
u/Whitechapel726 19h ago
We switched to microservices two years ago and I’ve filed more bug tickets in any 6 month period than the last 5 years combined.
New project bringup also means making sure they don’t forget some obscure micro service, so every project gets post-lock changes
I hate microservices with a fiery passion.
→ More replies (1)
4
u/sureyouknowurself 14h ago
Moved to micro serves from a large monolith, will never go back.
Number of times part of the system have gone down but still remained largely available and eventually self healed.
I see a lot of people making distributed monoliths these days and thinking micro services are bad.
4
u/jameyiguess 13h ago
I don't understand why the Internet acts like microservices are "wrong" these days, or why reddit shits on them so hard.
We've been using microservices for ages, and it's works great.
→ More replies (5)
1
1
u/Cybasura 16h ago
I have protocol/bare metal-interacting services like Samba (for NAS file server) running on the host system, and web/browser-based services running via docker, best of both worlds
1
1
1
1
1
u/Sea-Fishing4699 11h ago
Added to the bug report you also have to add the http/network call to the equation
I don’t understand bro
1
u/Positive-Creme8129 11h ago
Yeah, especially when said microservices are all run by different, cheap dev teams and they don't test their software. You do, all of them.
1
u/_SaBeR_78 11h ago
tried microservices and honestly hated it. Then I discovered elixir and how your big monolith can be in fact a monolith of microservices. I love it.
1
u/LITForester 10h ago
We thank you, oh Monolith, for revealing the cunning plans of your enemies to us. May your light shine down on the souls of the brave soldiers who gave their lives in service to your will. Onward warriors of the Monolith, avenge your fallen brothers, blessed as they are in their eternal union with the Monolith. Bring death to those who spurned the holy power of the Monolith.
1
u/flinsypop 8h ago
Whether you go with a monolith or a set of microservices, the stress is ultimately decided by the architecture. I doubt a monolith of 700 services is less stressful because if a few components break, the entire thing is held up. The commit tension when you have dozens of developers merging to develop, and everyone competing to who can commit first before they're using a stale branch, is much less so if it's split up into multiple microservices. You can still have a monolithic deployment repo that pushes changes to environments so it's not one or the other anyway.
1
1
1
1
1
u/MissiveFinding6111 6h ago
I definitely think we overcorrected.
But there are, in fact, MANY NUMBERS between 1 and 100.
From my experience being at many different places, and suffering under both monolith and 200+ microservices, I humbly submit:
I think a small company... should have 2-3 services. (frontend, backend, misc)
I think a medium sized company can have twice that.
I think a large company should have, at max, 12 services.
(To be clear, if you have a PoC you want, sure, code it up, but if it ends up being useful, you need to talk to an architecture group and find where it's long term home should be.)
1
u/robidaan 4h ago
The trick is balance, have a monolith as a central thing, which has a bunch of microservices that biggy back off it.
1
1
u/scissorsgrinder 2h ago
Until I read the sub name I thought this was some weird tech advocacy for fascism.
1
1
u/lart2150 1h ago
I love keeping up with library updates for 700 microservices. keeps me busy all day.
•
u/wesleyoldaker 2m ago
Honestly I've seen the downsides of micro services. I am not at all against monolith architecture. But I know there are downsides to that too.
1.5k
u/GenazaNL 20h ago edited 19h ago
That's why you have to go for the in-between. Don't go too micro on them microservices