If one component needs to know about the use-case it’s serving for another service in order to do its job, you didn’t factor your components correctly (i.e. either those components really are one component, or the component boundary should just be on a lower or higher abstraction layer than you put it.)

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.

Question then. If S3’s abstraction is so good, why do they keep deliberately poking holes in the abstraction, including but not limited to SQL access to the contents of the individual files? Not to mention each object is a file that can be accessed from the internet, requiring a lot of thought into how to properly protect, limit, and bill access to it.

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?

Those features may look like they're part of the S3 "service", but they're actually separate services built on top of S3, grouped into the S3 API namespace but hitting separate higher-abstraction-layer microservices that themselves make S3 API requests to accomplish their task.

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.

I completely agree. This "looking for the non-leaky boundaries" approach favors simplicity and reliability. Microservices present huge wins; choreographing them poorly is really on you.

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.