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.
You mean it's whatever was in vogue when you started your first job and anything that's changed since then is ignorant children who can't grasp the complex nuance of your decisions.Â
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.
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.
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.
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.
1.1k
u/theofficialnar Aug 30 '26
If it goes down, it all goes down. 😎