I get the joke, but in ideal world, in microservices, there is no such thing as code duplication across services. As a maintainer of a service, I should not give a crap about code present in some other service - it's some other team's code, why would I care? I don't have to even know that the other team exists. In big systems, it happens that I can't even feasibly know the existence of all the applications.

You mean you don’t have 300 versions of your badly developed rapidly evolving platform services rotting away underneath the bit you didn’t duplicate?

I don't. Other teams - maybe they do, maybe they don't. Who cares, not me. I have responsibility for services of my team, I think we are doing a good job.

Being selfish is the core principle of microservice architecture.

Until half your company gets laid off and you have to adopt other people’s shit.

In [an] ideal world, in monoliths, there is no such thing as code duplication across subsystems.

But wait! There's more!

For $19.95, you can replace your single single point of failure with multiple single points of failure!

Or for 100$, get a 5x increase on all failure points - maximum vibes, maximum excitement.

Please, stop it

Except 9/10 times microservices end up wildly dependent on each other, yielding a distributed monolith. Better to use service oriented architecture and just ship the monolith, you can test easier and skip the extra layers of serialization / deserialization.

> end up

So it just happens, right? There is no remedy to this? You know the answer :)

BTW I'm all for monolith.

I think you missed GP's point

Poe's Law FTW!