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.
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.
Below are the topics which explains how to consume SAP Cloud Platform Services in applications running on Kubernetes Cluster.
Register Minikube Kubernetes Cluster with SCP Service Manager
SAP CP XSUAA PaaS in Kubernetes Cluster Application
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.
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.
Register Minikube Kubernetes Cluster with SCP Service Manager
SAP CP XSUAA PaaS in Kubernetes Cluster Application
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.
- SAP Managed Tags:
3 Comments
