It was SOA (Service Oriented Architecture) where you would split them up, that predates Microservices by quite a bit. I remember doing that in the early 2000s.
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.
Well, SOA is such a broad term. If you include CORBA, you could say it's terrible. On the other hand, gRPC is a pleasure to work with if you need to deal with different environments.
The OP was pretty explicitly arguing in favor of monolithic architecture.
> 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.
Agreed in essence... The ideology is indeed old, but the practice of putting flashy wrappers and catchy names around the services are new.. Like "Dynamo DB" and "Route 53". Those names appeal to non technical product owners that then force adoption onto development teams... Pure fluff at it's best.
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.
There’s nothing new about marketing your product, and make no mistake that DynamoDB and Route53 are products.
> 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).
> They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.
"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.
I don't think it was "splitting monolith" it was more like connecting separate applications.
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.
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.