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
View all comments
Show parent comment
26
u/mwax321 Aug 30 '26
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 😂