Problem

When a developer is building an application and using Service Binding Operator, the developer needs to know exactly what are the binding data provided by the service. Those are specific to the service and require the developers to dig into the CRDs (or annotation) and to know what will be available. 

There are few problems:

• A developer might not be able to know what bindings information will be available if permission are insufficient
• It forces the developer to know what is the CRD to be used.
• Each operator and services, even providing the same "kind of service" might have binding keys that are different, which makes it hard for a developer to apprehend and to catch:
  • For example, Crunchy Postgres and Cloud Native PostgreSQL will have different bindings.
• Switching from one environment to another one is going to be hard because of the fragmentation between each of the service binding data.
  • A developer might be using a percona mongoDB on one instance, but official mongoDB operator on another one - then the application is not portable.

Description

To simplify the developer experience, we should have the ability to provide abstractions for different classes of services which would hide away:

• The need to know the specific CRDs
• Provide "good enough" default so that it works with ease without knowing the detail of a specific "service" .

As a developer, I'd like to be able to express the need to "bind" to a service without coupling it to a specific service's provider, so that if I transition to a different service, my application is still behaving properly.

Why is that important 

During the development of an application, the developer will most likely express is intention to connect to a database, say "PostgreSQL". Maybe, during the development, the developer will just pull a container to setup PostgreSQL, but then when transitioning to another part of the development cycle, it will connected to a Crunchy Postgres.

Expected work as part of this epic

• Define services classes and categories
  • Work with the service binding upstream working group to express the intention to add that capability to the upstream specification
  • Work on defining the "default" for each classes/categories
• Provide documentation for each of the services classes and categories
• Provide an alternate solution so that the user can "discover" (or find a place) where the different services known to be compliant with Service Binding are documenting their bindings. (similar to this document, but published as documentation)

Acceptance Criteria

• Create a sample application using quarkus:
  • On local development it will use Dev Services and MongoDB
  • In CI use a Percona Postgres
  • In Prod use a Crunchy Postgres

Design Notes:

TBD