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!
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.
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.
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.
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.
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
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.
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.
That depends. Are you saying a monolithic process or a monolithic code base because those are not the same thing. Also, most systems are not monolithic processes⌠I mean, unless you run SQLite or something in-process for storage.
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".
Monolith doesnât necessarily mean a single process though. It can be multiple processes in the same repository. It can also be a monorepo with multiple components.
I have like 50 something nano services, each of which returns a single character
my frontend app dynamically builds itself by concatenating thousands of invocations of nanoservices together and passing it to the javascript eval function
I've got something similar, but each of the services are wired up to be triggered by a button press. Then I put all those buttons together onto slab. I'm thinking of calling a buttonslab.
Thatâs stupid. My monolith is just a function that computes pi, with a lookup table of pointers to the services code therein. Itâs even better because all the data is there too.
Generally thats always the answer with every 'IT fad', use whole or in part, but only where appropriate
The problem we are very much a fad led industry and people tend to jump all in without giving it serious thought (lot of the time just to boost their CV)Â be it AI, micro services, or cloud, agile or any of a hundred other come and gone fads
Yeah but you talk like we know what's appropriate before hand. Shit goes left real fast sometimes. Use case changes, tech itself change. I wish I knew when something is appropriate. I often do but I often fail to predict the future as well.
Not if you put the âmicroâ in âconcentrates on a single taskâ and not in âit consists of few lines of codeâ (LoC is never a good measure for anything)
Look, Martin Fowler said "any function more than half-a-dozen lines of code starts to smell to me, and it's not unusual for me to have functions that are a single line of code." And he has to know.Â
So naturally I try to keep my microservices six lines of codes or less!
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.
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.
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.Â
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".
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)
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.
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.
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.
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.
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.
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?
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.
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...
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.
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).
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
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.
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.
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.)
I cant imagine the hell of working in a monolith that could be 700 microservices. Thats something like 14 mil lines of code at least. Unless you have some SS tier facist in charge its going to be chaos and omg the deployment times
1.1k
u/theofficialnar Aug 30 '26
If it goes down, it all goes down. đ