How can you get any work done like this?
Are you all working at massive corps that develop at a glacial pace?
Sounds like you all spend your time shuffling papers rather than doing anything meaningful.
People get work done by knowing what they're doing, which I'm not sure you are able to tell.
There is plenty of literature that explains quite thoroughly the process of software architecture. Basically all major software architecture styles from the past four decades reflect the need to encapsulate and insulate implementation details, including the need to specify a domain model and how it should be specific and exclusive to each project.
Somehow, you are oblivious to basic principles but still feel entitled to insult others based on domain knowledge you clearly lack.
To implement microservices, one takes what is a service in a normal application, a handful of code files in a normal application. Maybe some model files, a service, validators and a repo file. A slice of an application.
One creates a new project file, build files, etc. Maybe a new repo, maybe not. You then wrap that simple service in a bunch of boilerplate plumbing code so it can actually work on its own.
So, basically, a ton of extra code, right off the bat. Each time.
Then to do it right according to this thread, you duplicate the definition files between your services, multiple times, add JSON schema files that you didn't have to maintain before, and, someone else has mentioned, create an extra library on top of all this so your colleagues can implement it as if it were just a normal method call.
Even more code!
And that's your microservice. A lot of extra work. Busy work as far as I can see, no benefits. Just to do exactly what it used to do.
But, worse still, it has huge drawbacks, including:
1. Very slow "method" calls. Normal method calls are obviously orders of magnitude faster than whatever you're doing. L1 Cache is always going to be massively faster.
2. Poor debugging
3. Complicated devops requirement
4. Hidden complexity in the interaction between services that is impossible to see
That's what this thread is about when the original poster says "you're doing services wrong".
So, no, I'm not the first person to mention them. You just need to read the context of the discussion.
The article even states Microservices are not suitable for startups - the conversation in this thread has been able service oriented architectures which is a much broader topic.
I don't know where you're getting implementation details leaking when it's just API definitions being shared - they don't leak implementation details unless they're badly designed, which would affect them either way.
OOP languages have interfaces.
You can do this already without adding any sort of microservice, schemas, duplicate definition files, externally maintained libraries, etc..
It's a basic feature of most languages.
It is NOT an exclusive benefit of a microservice pattern. Stop claiming that, it's one of the most frustrating claims/lies microservice advocates make.
The actual benefit is that you're forcing developer to use interfaces. At a massive cost.
There are much cheaper alternatives. You enforce a Dependeny Injection pattern on your services. Code reviews. Linting tools.
So no, this is not basic stuff.
And worse still, if your team can't properly use interfaces in your languages, how do you expect them to suddenly learn to use them properly in your services?
Firstly, the space and time scales. If your two-pizza team has twenty services, and they communicate like this, and interfaces change a few times a week, then there will be quite a lot of pointless paperwork. If your two-pizza team has one service, used by other teams, and the interfaces change once a month, then this might be an appropriate amount of speed bump.
Secondly, tooling. If your APIs are all done by hand, then making an update is a modest amount of boilerplate. If you are generating everything from schemas, and you have your build down tight, then it can be a matter of changing the schema file, pushing, waiting for that to propagate, then adding the necessary data to the message you changed.
services map to teams, not units of functionality
imo minimum org size to use microservices is something like 50 engineers