Technical Articles
Multi Cloud Architecture
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.
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.
Hi Satish kumar,
Nice Blog post!
Could you please help us on the below scenario.
We have installed CF components on own Azure server. Cloud foundry platform is ready to use. We want to install SAP cf service broker in our Cloud foundry environment.
Do you know how we can achieve the same?
If we install sap cf broker then we can use all SAP services like xsuaa, destination. Is it feasible?
Thanks,
Rajdeep Bhuva
Hi Rajdeep,
Kindly let me know the following.
In this blog I have installed service broker in Kubernetes Cluster created in AWS to access services which are in SAP Cloud Platform.
Let me know if this helps.
Regards
satish
Hi Satish Kumar,
Thank you for the reply. Please find my answers below.
I don't have an account in SAP cloud platform.
I don't have kubernetes cluster in azure. I have cloud foundry instance in azure and requirement is to make available all the service which SAP cloud platform have.
So, I am looking for SAP service Broker which can have the implementation of all the services.
Do you think it is feasible?
Thanks,
Rajdeep Bhuva