Turns out the complexity didn’t go anywhere, it was just biding it’s time, waiting for the right moment to strike back.
Damn you, entropy!
S3 is an example of a correctly-favoured service. Object storage is a non-leaky abstraction. Object storage doesn’t need to know what an object “is” or why something is storing one. There’s no use-case-specific policy that can be applied to only specific “types” of objects. There’s just objects and buckets, and policies you can apply arbitrarily to any object or bucket because they’re policies about objects and buckets, rather than policies about some higher-level thing.
If your component’s API doesn’t create a clear, obvious, “self-contained” abstraction like object storage’s “objects and buckets” abstraction, then you don’t really have an extractable component; you just have a monolith that talks to itself using an extra layer of indirection.
Nobody said making the leap to distributed systems architecture would be easy. In fact, quite the opposite has been alerted, over and over.
Do not complain about complexity and simultaneously reach for hard problems.
I’m not trying to be snarky, I’m just pointing out that even a on-the-surface-ideal abstraction is leaky as hell. If S3, storing objects, can’t keep it’s abstraction clean, how can we be reasonably expected to keep our own abstractions clean?
The fact that all of those services that seem to be "a part of" S3 can be implemented on top of S3, without touching the code of S3 at all, and without the higher-abstraction-layer code having to reimplement any of the S3-layer logic to do its job, is precisely what makes S3 a well-factored service.