> Microservices are relatively new and unproven.
They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.
They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.
No less natural than "joining the innumerable incompatible and bug-ridden fragments into a single unified solution."
Linux is a bazar. Except distros and package repositories are cathedrals.
Windows is a cathedral. Except software distribution is a bazar.
What I think he is saying is that Microservices people pitch their service against monolith as better, but monolith hasn't been in vogue for 20 years. I saw the same tactic with scrum people pitching against waterfall which hadn't been in vogue for quite a while either.
I remember doing RPC via Java RMI and Jini at some point early in my career in the late 90s. It was really nice and gRPC reminded me of that.
> The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all.
That's the think about the marketing first model we're dealing with now... No real innovation, just branding/name changes and highly tailored customization to lock a customer into a specific platform.
> Those names appeal to non technical product owners that then force adoption onto development teams
Route 53 is a pun on the DNS port—not exactly common knowledge among nontechnical product owners. Anyway, DynamoDB and Route 53 succeed on merit. There are certainly better examples of shitty technologies that win on marketing or other nontechnical considerations. E.g., Oracle anything (of course Oracle aren’t know for being purveyors of microservices).
"Microservice" isn't really about that, it's a marketing paradigm that is here to serve the (paid) tools, not really the architecture, it is EXACTLY like "serverless", it's not an architecture, it's a really about promoting paid platforms.
The parent is 100% right about their point about marketing buzzwords, because that's really all what it is all about.
Like you had a payroll in your enterprise of 1000 employees and you needed that same data in 5 applications in 3 different departments. So you would wrap payroll into a service and have that data accessible in multiple places.
I think that is still a valid approach to build monolith app and use multiple services if they are internal apps.
For customer facing and quickly changing stuff you might want to add microservices to be able to build new features quickly when ideally microservice should have its own database with what it needs to operate.
Because the broke you know isn't called "broke."