Service to Service Binding

[grimmpp]

What is the problem? Right now the source of a binding is limited to apps.

Who does this affect? I would like to consider apps as service instances of a runtimes in general and I would like to have then only service instance to service instance bindings in general so that the following examples will be supported as well:

• Binding from custom runtimes outside CF, K8s, ... e.g. VMs could easily be bound to existing services.
• Support for multiple runtimes and different types of apps in one marketplace
• Binding between e.g. Jenkins and Artifactory could be possible so that Jenkins gets e.g. binding info (credentials) about access to repositories delivered.
  • Jenkins could be also bound to: chat tool, ticketing system, credential store, ...
• Binding between middleware services like e.g. workflow engine and databases, messaging, monitoring, ... would make sense as well.
• ...

Another big benefit of being able to describe relations (bindings) between all possible combinations of services instances is that I could use Service Brokers to manage a micro-segmented network. During the binding creation process the broker could just manage the network access between consumer and provider in the same way like the credential exchange happens today. The benefit is the same like for credentials because the creation of e.g. network rules is related to the bound services so that cleaning up network rules is part of the binding deletion and during the lifetime of an network rule one can easily see why and for whom it was created. ... From my perspective there should be no specific part about network management in the definition of the Open Service Broker API. The ability to create relations between services in general would be sufficient.

Do you have any proposed solutions? Instead of limiting the source of bindings to apps I propose to allow it in general for service instances and to consider apps as special type of service instances which are from services being runtimes like Cloud Foundry, Kubernetes, ...

[rsampaio]

Hi @grimmpp

The spec defines a binding as child of a service instance, as long a service instance is complete bindings of that service instance can be created, there is no specific restrictions to apps and the mention to an app_uuid in the Binding Resource object is an example Platform specific data that can hint to this kind of relationship and the implementation of a broker can use this object to achieve the result of service to service binding.

Do you have any specific use case that you could describe the interaction with the service instance and service binding endpoints?

[grimmpp]

Thanks a lot for the clarification. That construct makes sense.

I have use cases like described above about bindings between "normal" services like e.g. a Jenkins which could be bound to a Artifactory so that Jenkins gets credentials injected in order to access Artifactory. ...

I have also runtime services like VM as a Service which is not a platform like Cloud Foudnry, Kubernetes, ... . It has no service catalog nor the possibility to create service instances or to do bindings. This is done in Cloud Foundry. In this case we need to treat a VM service instance like a Cloud Foundry app and we need to do bindings from a VM service instance to e.g. databases or to any other services like we would bind to Cloud Foundry apps.

In general our landscape is growing quite a lot. It contains runtimes like Cloud Foundry, Kubernetes, VM as a Service, OpenStack, ... . Personally I would actually prefer a service catalog which is not integrated into one of those platforms and rather one which can combine or manage the platforms and their service catalogs. Something which goes into such a direction is the Service Manager of Peripli. Unfortunately, also here are service bindings not supported. One big benefit why I want to have service bindings between service instances is that we can e.g. easily manage credentials and network policies automatically in the same scope and related to the lifecycle of the service instances for which it is need. Otherwise this would imply we need to have a network service, credential service, ... in which we need to replicate the context and need to keep the lifecycle of those resources in sync to apps and service instances.

From my perspective the issue can be closed. I see the prerequisites from OSB-API fulfilled and I see it now more as an platform and service catalog topic. Hint and tips to the described topic are still welcome. :-)

[pivotal-marcela-campo]

Closing as per previous comments