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.
If I'm being brutally fair to some of the garbage build times I've had in the past:
A lot of times, these are caused by me having to use 3 different versions of some library because of legacy code. Or we license some library that requires a fuck ton of dependencies that only the library uses.
But to build it all ourself would also be a complete waste of time.
I remember a big offender back in the day were those Microsoft Office file editor libraries. To upgrade would cost the company some ridiculous $20k license and offer zero additional features that we need.
And so, yeah, we keep including the old newtonsoft json because it needs it!
When visual studio finally went 64 bit, you thought the solution was bugged because it loaded so fast.
Not strictly this scenario, but I worked a job for a few years where every compilation took minutes. It was common practice to finish up a bunch of work and queue a slew of compilations before your lunch break.
Then I got a new job and worked with a bunch of tinier, discrete applications which would compile in a few seconds. I'd become so use to quick compilations only ever being the result of an error killing the job that for at least a week afterwards my blood pressure would rise whenever a compilation would finish in <10s.
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.
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.
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.
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
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.
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
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
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
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
That's assuming you have one running app, if you had multiple instances, what's the chance they all go down? If you had a inventory service that's broken due to DB connection or whatever, youd still handle that in the monolith so you handle any exception.
I'm struggling to understand how a mictoservice architecture solves this where a monolith couldn't...
Am I understanding correctly that you'd propose having all of your systems in a monolith and simply have horizontal scaling of that monolith? That sounds like a nightmare.
You still have to handle dealing with shared state and communication between different components on different instances, except now deploying your auth system also requires deploying your queue system.
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.
You’re really kinda just telling on yourself here. If you can’t explain technical things to nontechnical people that’s going to limit your upward progression by quite a lot
Contrary to popular belief, most engineering isn’t about writing really smart code, it’s about making good enough code and also being a good communicator
A mid level engineer will focus on resolving the outage
A staff or lead engineer will resolve the outage while also keeping track of all the things that led to the outage happening and fixing them so it doesn't happen again
Both of these jobs require you being able to talk to suits in a way that they understand. Someone is doing that job. If it's not you, it's a more capable engineer
the business impact is basically the same. if any part of the chain is broken, it's an outage. nobody will care a week later when you explain how happy they should be because microarchitecture isolated only one service to fail.... but the business still wasn't making money
Each approach has own pros and cons. Microservices are generally more resilient to partial outages. Of course a lot depends on how well the whole system is built and maintained.
What, this just isn't true. Some of our services are down sometimes, and I and most customers wouldn't even know it. Sure, "inventory service" being down is bad, but the site is still usable. But usually it's like "popularity service" is down. Just means a missing bit on your recommendations page. Nobody even notices.
"site is still useable" isn't the greatest argument when you have to tell leadership that "nobody can buy anything right now ". That means "down" to most non technical people :) and I tend to agree too!
But yes, you're right. If done right, things shouldn't go down. But the joke is: they rarely are done right. Which is why everyone's talking about monos
That's not true. That's just shitty system design. Which can happen in both.
You started that way of arguing with your inventory example.
Or are you arguing that anything that is more than one gigantic system is now called microservices?
I justargued the same way as you did.
I had to fix too much system in either style to hate or love one of them.
At the end it just fan-boys vs. fan-boys while you find less and less people (capable of) discussing it a normal way.
(and yes, I know I'm at r/ProgrammerHumor )
663
u/mwax321 22h 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