Introduction: In the previous post, we discussed Kubernetes Open Service Broker API. We follow up on the discussion with an introduction to Azure OSBA which is also complying with the open standard.  

Description: The standard meets the demand for application connectivity to the wide variety of services in the Azure marketplace. OSBA is simple and flexible. It allows applications to provision commodity products such as a MySQL database instance or Azure’s own multi-model database. OSB for Azure is a connector that can work with a Kubernetes, Cloud Foundry, or Open Shift in Azure. At the heart of every OSBA, it's a service catalog that lists the services corresponding to the resource types. Azure invested in the Kubernetes service catalog to leverage cloud-native services to be visible in that container orchestration framework. One of these investments is a command-line interface for the Kubernetes service catalog, aka `svcat`, which enables Azure services to be browsed and matched to resource types. OSBA provisions and binds Azure services in Kubernetes as well as Cloud Foundry and OpenShift. Its support for Azure service fabric is coming soon. All these cloud-native environments need OSBA probation Azure resources like the SQL database the MySQL database, PostgreSQL database, or the assure zone Cosmos DB. OSBA ensures mission-critical applications to be connected to enterprise-grade backend services that are hosted outside the cluster and are not governed by the resource constraints of the cluster. By bringing the container orchestration framework to work with the scale and scope of a backend cloud service, Applications can now leverage the best of both worlds.  

The level of integration does not stop but just a handful of Azure services are being made available on the container orchestration frameworks. It has been planned to be expanded into as many assure services as possible as well as up a plan took to communicate with the Kubernetes community and align the capabilities of the service catalog with the behavior that the customers expect. Finally, Microsoft plans to have an old generic way of describing services by their criteria rather than by specific resource types so that any and every matching service in the OSBA registry can then be used to qualify and meet the requirements for the customer's application.  

As with any API layer, OSBA is expected to be resilient and scalable with support for multiple concurrent requests and fully asynchronous processing that can seamlessly resume even if one replica goes down. OSBA is, therefore, suitable to work in a cloud-native environment like Kubernetes, Cloud Foundry, open shift, or ServiceFabric. The ease of use that comes with the service catalog is not sacrificed with the large variety of resources that can be provisioned with the OSBA.  

Support for OSBA in Kubernetes varies somewhat with OpenShift although the notion of provisioning Azure resources via a command-line interface remains the same, the project template in OpenShift is considerably different from the resource types registered with the service catalog in Kubernetes. The service catalog stores a set of entities called the cluster service classes that describe the services that handled those types of resources. It describes another set of entities called the Service plan that are variations of those services using the service class and the plan a resource can be provisioned outside the cluster in this case the resource happens to be provisioned in the cloud. there are no transactional guarantees expected from the create update delete and list of resources from resource provider as it spans the cluster to the cloud for this purposes state is maintained and the calls are reentrant and idempotent when the user chooses a service class and a plan the service instance is bound to do a set of resources which enables applications to use them as if they were local to the cluster. The process of deleting service instances involves that the bindings are removed, and the resources are de-provisioned. It is possible to have references left in the service catalog when the binding is broken, and the cleanup doesn't occur, but this can be done afterward. Since subsequent service instances create their own bindings, it has little or no impact on the applications' reliance on one or more service instances. the service binding is a link between the service instance and the application. It holds value so long as the service instance is used. The service class and the service plan can have parameters passed in to enable them to function in different modes and environments. 

Conclusion: Together the SBA and the service catalog enable tremendous choices for an application to delegate its dependencies to backend services