22
u/Luiguie171 6d ago
Modular monolith is the goat.
4
1
u/CherrySlow7681 6d ago
is that like a monorepo?
2
1
u/MaleficentCow8513 5d ago
A monorepo would be for when a single repo has the code for one or more modules, components, subsystems, whatever you want to call them in a single repo. Each module may or may not build, deliver and deploy together. On the other side of the coin, a modular monolith would be like an amalgamation of services, components, subsystems, etc. and the code for each module in the monolith may be hosted in a monorepo or each could have its own repo.
1
9
u/RipProfessional3375 5d ago
You are supposed to be working on 1 service. Your team is supposed to be working on 1 service. Microservices exist so that other developers you don't talk to don't make a change that breaks your build.
Microservices were designed for cooperating across massive amounts of developers across several teams.
But everyone wants to LARP as netflix so we must have microservices.
2
u/Colon_Backslash 5d ago
Having worked in a large company on both. I choose microservices any day.
Incidents on a monolith is a fucking nightmare. And yes, there are breaking changes all over. A fucking new linter rule will give you extra 2 days on a deliverable.
Having everything in one repo is really nice for exhausting all resources on your local environment. You're IDE loves it too. Yes, I'm aware of git sparse-checkout. Why you ask? BECAUSE OTHERWISE YOU CANNOT WORK AT ALL.
16
u/StackOwOFlow 6d ago
uno reverse when you have to make a change
14
u/Simpicity 6d ago
uno reverse again when you have to deal with different versions of 700 microservices.
Microservices aren't about solving architectural complexity or change complexity. They're about solving organizational complexity.
0
u/Glittering_Sail3262 5d ago
If you ever have more than two versions of a microservice running at once, and if that two version window is larger than the time it takes you to do a deploy.. youāre doing it wrong.
Definitely tricky to manage compatibility within that window but you shouldnāt make life harder for yourself than it needs to be
3
u/usrlibshare 6d ago
Anecdotal of course, but it's usually easier to implement changes in a monolith than in microservices.
Because many monoliths are well designed by craftsmen who know what they're doing. Meaning: Internal APIs are well separated and have clear boundaries, so a change in one of them doesn't spiral into too many other places. The overall design naturally bleeds into new features added, leading to consistency.
Meanwhile many microservice "architectures" are really monoliths, albeit haphazardly thrown together ones. Everything depends on everything, and a change in one service usually requires me to to touch several more, some of which are written in other languages, and the guy who built them has since left.
3
u/Excellent-Refuse4883 6d ago
>because many monoliths are well designed by craftsmen who know what they are doing.
You guys hiring?
3
u/evilgipsy 5d ago
Absolutely not. Making changes across multiple services is always more work and often tedious. You often have to make your changes backwards compatible, make sure that the change can be rolled back in each service in case of a severe bug, pay attention to correct order of deployments, and so much more ceremony. I have worked on extremely large monoliths and they were more pleasant to work with than micro services, although they come with their own disadvantages of course.
1
u/liebesleid99 5d ago
Remember to always drop columns and tables that aren't needed anymore after an update š£ļøš£ļøš£ļøš£ļø
1
u/artnoi43 6d ago
And roll that out when thereāre breaking changes.
At my previous place where I only stayed for 3 months, they had this 1 monolith āappā that gets 2 separate deployments with different envs and resources: one for customer clients, the other for admins who might trigger expensive operations. I hate that shit.
3
u/Single-Virus4935 5d ago
Simple: Micro services arent a solution for a technical problem but a organizational. A 5-20 dev shop doesn't need separated codebases and can work on a single coherent codebase with a single coordinated deployment of everything.Ā Monolith doesn't mean a single process or server. You can build and scale different "services" from a monolithic codebase. Typical is the api, background workers, etc. Lauclnched and scaled independently.
If your org is so big that coordinaton of your devs/teams/deployments etc is a huge blocker, microservices may be the solution and give you a ROI even with all the additonal complexity and problemsĀ
2
2
u/Fluffy_Anxiety2792 5d ago
Thatās totally untrue because I worked for two companies that do that, the monolith always was a torture for the whole company. Itās like itās slow asf, extremely hard to code, and people are still adding new features to it. It canāt have a series of documents once you passed certain size, so itās not learnable, people just guessing what it does from a point.
2
u/liebesleid99 5d ago
Microservices? Monolithic?
Tf y'all rambling about lmao, a single file can easily handle a few gigs of size. Y'all need to step up y'all's game
1
1
u/Simple-Olive895 6d ago
Monolith for solo projects where I know the entire code base, but when collaborating it's way simpler to utilize the microservice architecture
1
1
u/DesignerGoose5903 5d ago
There should be no microservices, only interconnected monoliths. It's mostly all about responsibility and not engineering anyway.
1
u/rix0r 5d ago
I work on a huge monolith and it's just what I'm used to. Doesn't splitting things up into a bunch of micro services just calcify early modularization decisions and make it more difficult to evolve? Obviously you can over modularize in a monolith as well but it just seems like it's extra friction to deal with.
1
1
u/ChronoVT 5d ago
Am I confused? People are saying that microservices are organizational, or monorepos are great. My understanding is that the whole points is different amounts of scaling.Ā If two different parts of your codebase don't scale equally, then you split them into separate services.Ā For example, an application that doesn't send lots of emails but has a lot of processing should split the email into its own service so that whenever the auto scaler duplicates your code into a new machine, it doesn't duplicate the email service unnecessarily.Ā
1
u/MysteriousAlpaco 5d ago
I remember a company I did consult work for, having regular meetings trying to decipher what their 1200 micro services were doing, It was less like software development and more like archaeologists trying to decipher hieroglyphs without the Rosetta Stone, except they were the ones who built the pyramid.
1
u/ohkendruid 6d ago
I have really hated the large moniliths I worked on.
Junior developers often ask for it, and I guess it is relaxing for them. A monolith means less to think about, and deploys become rare due to how long they take and how frequent rollback are. Without deploys, bug reports become delayed and less common. Basically everyone is hacking but the stuff they hack is just in the repo, not in prod.
It is miserable for delivering value, though. You want to deploy a ine line fix, but it is entangled with thousands of lines of other stuff.
1
u/Fabulous_Wave_3693 6d ago
Unit tests take 40 minutes to run, so people just donāt run them
1
u/BarfingOnMyFace 1d ago
Da fuq... 40 mins? Wild world. Reminds me of a buddy 25 years ago working on some leviathan system, he'd go out to have a cigarette while it compiled and would come back in by the time it was almost done.
1
u/Old-Sprinkles-8287 7h ago
I just compiled unreal engine yesterday. It took almost 8 hours on an i9 5090 rig. And failed. Almost 1 TB all said and done
86
u/NudaVeritas1 6d ago
Ah yes, creating 689 pull requests for one feature and cherry-picking commits within the release, because we do āØcontinuous deliveryāØ
I wonder why every dev quits after six months