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.