633
u/djingo_dango 3d ago
It’s called a monorepo with modularized components
227
u/Interesting-Agency-1 3d ago
Modular monolith FTW
37
u/MiniGui98 2d ago
It's all fun and games until you have a monolithic modular monolith
7
→ More replies (1)5
u/Interesting-Agency-1 2d ago
You can have multiple modular monoliths each acting as their own microservice to eachother. Service-ception
39
12
→ More replies (2)23
1.1k
u/theofficialnar 3d ago
If it goes down, it all goes down. 😎
711
u/mwax321 3d 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
400
u/WriterPlastic9350 3d 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!
355
u/cross_the_threshold 3d 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.
71
u/mwax321 3d 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)31
u/kurtymckurt 3d ago
The ci better take 24 hours to build and test or you’re not monolithing properly
→ More replies (2)6
u/Tupcek 2d ago
if it is too quick, it’s certainly bug
2
u/inemnitable 2d ago
No no no, if it compiles the first time it's bugged. If it builds fast you accidentally
rm -rf-ed the repo.19
u/HadionPrints 3d ago edited 3d 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.
5
u/cross_the_threshold 3d ago
FORTRAN II or bust!
4
u/mwax321 3d ago
Did you know a guy wrote an entire theme park game in assembly ?????
→ More replies (1)2
u/_DonRa_ 3d ago
No biggie anyone can write assembly it's easy (I wrote hello world in assembly)
3
u/djdanlib 3d ago
WASM doesn't count.
Or does it?
Who even knows these days.
2
u/ashgs872tbhjs 3d 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.
→ More replies (3)3
27
u/mwax321 3d 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 3d 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.
14
u/mwax321 3d 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.
4
u/ashgs872tbhjs 3d ago
You can SSR with React, FWIW, like via NextJS
4
u/HerrPotatis 2d ago edited 2d 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/WriterPlastic9350 2d ago
People liked React and Angular because it made frontends easier, then people realized that React could be used for non-javascript environments, and then realized you can restore progressive enhancement by rendering React on the render and piping a large javascript bundle to the frontend.
Today's SSR builds on this by basically designing an application and having the language (or framework, rather) express which parts require user interactivity and which don't, and this makes it easier to deploy applications to multiple platforms while not compromising the user experience.
We definitely go in cycles for sure, but viewing the path from MVC to frontend only libraries to SSR as being motivated out of where to put the javascript is kind of missing the forest for the trees
→ More replies (1)3
u/FlakyTest8191 2d 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.
2
u/WriterPlastic9350 2d ago
There's some kind of razor out there that essentially states that your software design eventually reflects the political structure within your company, so yeah, I think you've hit the nail on the head. (micro)services are as much about political and human decisions around deploying, or on-call, etc, as they are about technical aspects like scaling
→ More replies (10)2
u/U_L_Uus 2d 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
22
u/unbdndeath 3d 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)13
u/extra_rice 3d 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 3d 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)7
u/Naomi_Tokyo 3d 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)2
2
→ More replies (8)3
u/yousirnaime 3d 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
9
5
3
u/protayne 2d 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 (3)→ More replies (1)3
u/usrlibshare 3d ago edited 3d 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".
2
148
u/Snakestream 3d ago
Having worked with both, microservices are stressful, but the monolith is also very stressful.
51
→ More replies (1)3
u/bremidon 1d ago
Yep. As others have pointed out, the middle is the right way. Architecture is important. There is no safety in the extremes, as enticing as they might be.
42
u/rjwut 3d ago edited 3d 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.
138
u/Crafty_Independence 3d 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
15
u/WhiteIceHawk 2d ago
How about an over 20 years "historically grown" SAP System that is customized to hell and no documentation?
→ More replies (1)9
u/htmlcoderexe We have flair now?.. 2d 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)10
u/cyclodevops 3d 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
86
u/ryuzaki49 3d ago
"Hey let's make this one line change"
Dies while waiting a 3 hour build.
16
u/scumble_bee 3d 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 (2)6
u/Nooblot 2d 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.
6
4
u/Still_Bit_7527 2d 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
4
u/ryuzaki49 2d ago
I have done that. Literally easiest tasks that I would gladly take.
You can even automate it.
2
u/Still_Bit_7527 2d 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..
3
u/ryuzaki49 2d ago
I am currently working on a F500 company that has a lot of bureaocracy and it has to comply with many regulations.
I think there are over 10k microservices at the whole company but I only have to worry about 20 of those.
I would take microservices over a monolith any given day and yes, I am aware of the trade offs.
22
u/deathanatos 3d 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".
→ More replies (1)4
u/Alainx277 2d ago
How would you even accomplish a 10 minute start time???
→ More replies (1)2
u/Ceros007 2d ago
That one guy who was going for the "Look I fixed the boot up time" by removing the Sleep he put here and there but got slacked before
13
66
u/WhosYoPokeDaddy 3d ago
with infra as code it's to the point where it doesn't feel that different
58
u/eightslipsandagully 3d ago
You say that until you're running 50 different docker containers locally and still can't get every feature working on local env
16
9
u/Major_Fudgemuffin 3d 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 2d 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
17
u/autistic-inch 3d 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)4
u/Sqirril 3d 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 2d 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 2d 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.
12
u/KalzK 3d ago
50% stress 100% of time vs 100% stress 50% of time
9
u/ashgs872tbhjs 3d ago edited 3d 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.
153
u/Odd_Soil_8998 3d ago
truth. a well architected monolith is almost always going to be a better choice.
71
u/cornmonger_ 3d ago
mono repo, mono repo
3
7
u/Mateorabi 3d ago
Orphan all the branches! Why do I need to download the entire tree for code I don’t work with!
27
u/Stagnu_Demorte 3d ago
Until you need to scale different parts of the service. But yeah, until then it can really cut down on complexity.
19
u/remy_porter 3d 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.
37
→ More replies (2)2
u/PixelatedGiant 3d 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)→ More replies (1)4
u/Romestus 3d 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)
23
u/se7sbomb23 3d ago
Monolith supremacy: If the ship goes down, at least it goes down as a unified family
8
u/Puzzleheaded-Weird66 3d ago
just have a backup deployment of the monolith on a different server duh
5
6
10
18
u/Decinym 3d ago
Nah I work on a massive monorepo and it’s absolute hell to test changes or integrations if they involve multiple systems.
13
u/pineapplepassionfr 3d 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 3d ago
You don't have to forgo integration testing with multiple repos. Do you not version your APIs or releases??
2
u/Bicykwow 3d ago
Sounds more like a poorly managed monorepo, which is an orthogonal discussion to microservices vs monolith
8
4
3
u/Major_Fudgemuffin 3d 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.
4
u/localhorst69 2d 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
6
u/Public-Investigator9 3d 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.
6
u/sureyouknowurself 3d 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.
11
u/PM_ME_BAD_ALGORITHMS 3d ago
Whoever sold the idea that everything needs to be a microservice should work on marketing, not tech
3
3
u/Flat_Bluebird8081 3d 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 3d 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
2
2
2
2
u/JohnsonJohnilyJohn 2d 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/KronisLV 2d 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).
3
u/ArjixGamer 2d ago
If you have 2 min startup time, you are doing things wrong.
Are you perhaps using shitty stuff like springboot?
(shitty when it comes to startup times)
→ More replies (2)2
2
u/semioticmadness 2d 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.
2
6
u/jameyiguess 2d 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 (7)
5
u/Whitechapel726 3d 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)
1
1
u/Cybasura 3d 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 2d 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 2d 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 2d 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 2d 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 2d 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 2d 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 2d 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
1
u/lart2150 2d ago
I love keeping up with library updates for 700 microservices. keeps me busy all day.
1
u/wesleyoldaker 2d 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
1.8k
u/GenazaNL 3d ago edited 3d ago
That's why you have to go for the in-between. Don't go too micro on them microservices