[cfors]

Take vault for example. Rather than have to toggle a flag in your service to get a secret, you could have the vault sidecar inject the secret automatically into your container, as opposed to having to pass a configuration flag `USE_VAULT` to your application, which will conditionally have a baked in vault client that fetches your secret for you.

Your service doesn't really care where the secret comes from, as long it can use that secret to connect to some database, API or whatever. So IMO it makes your application code a bit cleaner knowing that it doesn't have to worry about where to fetch a secret from.

[xmodem]

This is actually exactly the case I was thinking of. We have a few applications that use vault in a much more in-depth way than fetching a couple of secrets, so have the need to interact with it directly. We then have the much more common case of applications that use vault to fetch their database credentials, and for those we use a sidecar to fetch them at startup and another to renew them every 30 minutes.

The 2x sidecars do with 150 lines of YAML configuration what could be done with a library and 10 lines of java. And I don't buy the other theoretical benefits either. Easier to update? Each service can reference the library centrally from our monorepo whereas the YAML is copy-pasted to every service. It's also statically type-checked. Polyglot? Yeah, fair, but we're an almost entirely JVM shop.

Some of this could maybe be made easier with something like Kubevela but I don't think you're actually eliminating any complexity that way, just hiding it.

[darkwater]

Ok, so you are indeed advocating for the sidecar approach (and on this I fully agree, especially this Vault example)