In this post we will see how we can use Open Service Broker API to accelerate XaaS where X = [Software , Infrastructure , Platform]
Cloud had an immense impact in making development a lot easier but as usual there was a certain problem. Choosing a specific cloud platform because of the services offered made the development possible but it made the development and management life cycle tougher and in-turn making the multi cloud service model complex. The Open Service Broker (OSB) APIs were introduced to solve the complexity in establishing the multi cloud in the market.
The Open Service Broker API project allows Independent Service Vendors (ISVs), SaaS providers and developers to easily provide backing services to workloads running on cloud native platforms such as Cloud Foundry , Kubernetes and OpenShift. This specification describes a simple set of API endpoints which can be used to provision, gain access to (bind) and manage service offerings.
By standardizing the industry on the Open Service Broker API, we can build a foundation for an ecosystem that transcends a single community - Abby Kearns
If you see the image, Service Broker is the one that does the hard work. Service brokers manage the life cycle of services, and platforms interact with service brokers to provision, get access to and manage the services they offer. The Open Service Broker API (OSB API) defines these interactions, and therefore allows software providers to offer their services to anyone, regardless of the technology or infrastructure those software providers wish to utilize.
Service Catalog describes all of the services that can be provisioned through a service broker, and each service is made up of Plans. Plans typically represent the costs and benefits for a given variant of the service e.g Small, Medium, Large plans. (GET /v2/catalog)
Service Instance is a provisioned instance of a service and plan as described in the service broker’s catalog. (PUT /v2/serviceinstances/{instanceid})
Once a Service Instance is provisioned, you’ll want your application to start communicating with that instance. From a service broker’s perspective, this is called a Service Binding.
PUT /v2/service_instances/{instance_id}/service_bindings/{binding_id}
Deprovisioning service instances just deletes all the resources created upon the initial provisioning of the service instance.
Considering from SaaS perspective, we could use OSB model in below ways:
Service Catalog - Catalog of all the Software Services offered Service Instance - Service instance is nothing but the Subscription that's created once user buys an Service. Service Binding - Entitling of Users to the Service can be considered as Service Binding.
This model provides significant benefits for both development and operations teams:
- Operators no longer have to manually provision and delegate access to services. They simply configure a marketplace of services and service plans and rest everything is self-service, reducing the administrative overhead many enterprises face today.
- With an unified specification as outlined by OSB , we can develop applications and associate them with any number of provisioned middleware and routing software without having to worry about the underlying infrastructure as it is all abstracted by Cloud-Native Platform and Service Broker respectively.
That's all I have for now, let me know your thoughts and Keep Learning !!!!!
This article is also published on Medium