Sometime back, when there was a growing demand for cloud computing, lot of cloud companies started supplying Infrastructure As A Service. This eventually proved to be a lot cheaper yet hazel free option for companies to run their product and service. Over the period cloud companies started providing shared services to make it much easier for companies to run their applications without much worrying about the underneath service licensing and deployment. For example I can use a database service from a cloud provider for my procurement application without much worrying about the licensing and maintenance of the database. The pay-as-you-go strategy enabled customers to bring down the running cost to a great extent. Software providers tied up with various cloud providers to make their platform available in cloud infrastructure to ease application developer job. With this strategy now we have many great platform services available across multiple cloud providers. For example Cosmos DB, Active Directory from Microsoft Azure, S3, Dynamo DB from AWS and Compute Engine, Cloud Storage from GCP.
What if a developer wants to tie services on different platforms to his application which will provide him with great advantage while not compromising on services restricted to a single platform? What platform do you use, where to get the most value out of it in the most efficient way while not trying to build the same on-prem? Isn’t it going to save a lot for companies only focusing on business problems?
Kubernetes has been widely accepted as the best way to deploy and operate containerised applications. One of the key value propositions of Kubernetes is that it can help normalize capabilities across cloud providers. The Open Service Broker API is an industry-wide initiative to meet the demand of consuming cloud services through a simple and secure mechanism. Currently many companies like Google, IBM, Pivotal, Red Hat, SAP are contributing to it.
The Service Catalog provides a way for provisioning instances of services that can be consumed by applications in a standard way. Service Catalog is an extension API that enables applications running in Kubernetes clusters to easily use externally managed service offerings. A Service Broker is an implementation of the open-source Open Service Broker (OSB) API which simplifies the delivery of cloud-platform specific services to applications that run on Kubernetes cluster.
(image credit : www.kubernetes.io)
Using this, an application developer has the ability to request services from a catalog without worrying about how and where they are provisioned. Once the service is available, he can bind the service to his application and consume using associated credential. These provisioning and binding requests are made to Service Brokers, which are registered with the Service Catalog.
Now application developer can run his application on any Kubernetes Cluster without knowing how his application is using MySQL database from Azure and S3 object storage from AWS. Service Catalog and Service Broker completely abstracts out the integration complexities and provide a seamless/unified way for integration. On the other hand, developer does not have to worry about the deployment of MySQL and S3 services.
Service Broker is responsible for translating Service Catalog activities (provision, de-provision, bind, unbind) into appropriate actions for the service.
Service Catalog manages the list of Service Brokers and the list of services in each of the Service Brokers.
Service Instance of a service is created by requesting Service Catalog to provision via the associated Service Broker. This is the software unit for which the vendor will be billing.
Service Binding explains the relationship between the application and service instance. Binding contains the information that an application need for using service instance.
A Service Broker provides numerous Service Classes. For example XSUAA would be one of these Service Classes if the Cloud Foundry Service Broker is deployed in the Kubernetes cluster.
Each Service Class will constitute numerous Service Plans. For example broker and application are two service plans available for SAP XSUAA service.
Following is the catalog marketplace offerings in Kubernetes cluster for SAP Cloud Platform.
$ svcat marketplace CLASS PLANS DESCRIPTION +-----------------------------+-------------+---------------------------------+ feature-flags lite Feature Flags service for controlling feature rollout sdm standard Document management for Business Applications auditlog-management default Retrieve logs and change retention malware-scanner external Scan single files for threats, via HTTP transport standard Provides programmatic access to Transport Management. transport-ci standard Provides programmatic access to Transport Management. hana-cloud hana Leverage the in-memory data processing capabilities of SAP HANA in the cloud as one simple gateway to all data. metering-service development Metering-as a Service on SAP Cloud platform enables services to meter their usage information, so it can be used later for commercial purposes like billing or license compliance. default sap-onpremise-extensibility api-access Connects extension applications running in an SAP Cloud Platform subaccount to an On-Premise system. xsuaa broker Manage application authorizations and trust to identity providers. application
Below are the topics which explains how to consume SAP Cloud Platform Services in applications running on Kubernetes Cluster.
The Service Catalog offers powerful abstractions to make external software offerings available in Kubernetes clusters running in different environments. These services are typically third-party managed cloud offerings which are native to a specific cloud-platform, where the complete abstraction is made much easier masking the integration complexities. Service Catalog and Service Brokers are not restricted just for Public Cloud Platforms but these can be leveraged for multiple internal services. On the other hand, developers can focus on the applications without the need for managing complex services deployment.