Service Bindings

[nebhale]

A proposal for concretely defining how Service Binding information is exposed to buildpacks and applications.

[nebhale]

Summoning @markfisher and @scothis for their insights into Kubernetes idioms.

[scothis]

Kubernetes secrets can be mounted as a single directory, with each key in the secret representing a file in that directory. Having the metadata for a single service be split between directories will make it harder to mange.

Likewise, structuring the service binding based on an attribute of the binding, other than name, will make it harder to manage as the tool creating the file system would need deep knowledge of the service.

I'd favor a form that puts all of the content for a single service into a single directory, and devolves the service.toml into individual files in that directory:

 platform
 └── services
     ├── primary-db
     │   ├── endpoint
     │   ├── kind
     │   ├── password
     │   ├── provider
     │   ├── tags
     │   └── username
     └── secondary-db
         ├── endpoint
         ├── kind
         ├── password
         ├── provider
         ├── tags
         └── username

[nebhale]

@scothis The problem I see with that design (versus the service.toml metadata sitting next to the credentials) is that now tags, provider, kind, etc. all have to be keys within the secret rather than attributes (I might have the terminology wrong) on the resource itself. Combine that with the fact that it's important to have the values of the metadata at build time and ideally not have the values of the secrets then, I think there's an argument for keeping the metadata out of the secret payload.

[nebhale]

@scothis Based on discussion in the WG meeting today, there was a preference for the metadata in files, but in a separate directory next to the secrets. Does this compromise work for you?

[nebhale]

Another concern was raised privately via the Heroku team

the inconsistency between the proposed use cases stands out and if we decide to include service_kind and providers namespaces all services should follow this format with default namespaces for those without kind or provider attributes.

The kind/provider division was inspired by Crossplane and serves as a mechanism for describing an abstract service type (e.g. MySQL, Redis) and a concrete implementation (e.g. CloudDB, Redis To Go). I believe that all services, even the more esoteric ones, can be represented with the kind/provider division. To take a couple of examples from the Heroku Add-ons catalog (kind/provider):

• MySQL/JawsDB MySQL
• MySQL/JawsDB Maria
• MySQL/ClearDB
• Redis/Redis To Go
• Redis/Redis Cloud
• Redis/Redis Green
• Redis/Heroku
• Redis/OpenRedis

Now those are the easy ones, multiple providers for an obvious single service kind. But you could imagine something where there is a more 1:1 mapping like APMs. In that case, most of the time you might want only a single kind/provider pair, but you might also want (as in the CF case) for a user to be able to manually create a service binding

• New Relic/New Relic
• New Relic/User Provided
• AppDynamics/AppDynamics SaaS
• AppDynamics/AppDynamics On Prem
• AppDynamics/User Provided

Finally, it'd be totally OK to have a kind that is hyper-specific to a single vendor:

• QRackajack/QRackajack
• Semaphore/Semaphore
• User Agent Identifier/User Agent Identifier

In short, I think it's totally OK to have a single kind/provider pair (with identical values for both) for some services as it leaves us the flexibility to have multiple providers per kind in other places.