SAP Cloud Platform and Open Service Broker
A few weeks ago, Harini Gunabalan from the SAP Cloud Platform Product Management published a blog on how to use the Open Service Broker with Azure. Within a few weeks the blog attracted quite a few thousands views and was followed by a series of related blogs by Marius Obert on what you can actually do when combining SAP Cloud Platform, Open Service Broker and Azure.
In this blog I want to outline a few basic things and also get you started.
When I tweeted about Harini's blog there were quite a few questions why this approach should actually be used. From my point of view it addresses one major concern that companies have that want to leverage SAP Cloud Platform. SAP Cloud Platform offers a great platform for SAP customers not only to integrate in existing SAP services, but also build new ones that leverage (business) services that are exposed via this platform. The SAP Cloud Platform is probably SAPs best manifestation of the new "multi-cloud" approach which allows customers to leverage hyperscalers like Microsoft with Azure to "host" SAP services anywhere in the world, really leveraging the infrastructure that Azure provides. With this approach SAP is able to concentrate on three key pillars of SAP Cloud Platform: Extend (existing SAP Fiori services for example exposed via SAP S/4HANA), Integrate and Innovate using new business services (like Master Data or Taxation services).
That is where the real value from my point of view lies when looking at SAP Cloud Platform. (SAP) developers wanting to integrate in existing SAP services or want to leverage business services have a perfect home in the SAP Cloud Platform.
However, when comparing technical services offered by the SAP Cloud Platform with services from Azure, SAP Cloud Platform is does not always offer the same functionalities. That is exactly where the Open Service Broker for Azure (OSBA) comes in. Leveraging OSBA SAP developers can easily consume these services directly from SAP Cloud Platform. They would not even need to know who their Azure admin-colleague is, how to connect to an Azure subscription, evaluate which services are useful, how to connect / authenticate to these services, …
After an admin has setup OSBA once and connected it to Azure, these services are available for any developer using the SAP Cloud Platform. A SAP developer would not even need to know that these services are coming from Azure.
So what exactly is this Open Service Broker and why should you use it?
First of all, when you are one developer looking for combining services from SAP Cloud Platform and Azure, you probably don't need it. You can develop your application anywhere and just select the services that you are interested in (if you have access to Azure). However, when you want to provide a platform for the developers in your company, which might not know where and what services are available from Azure as well, OSBA can be a perfect start. You can provide these services to your fellow developers without having them to figure out how to get access to Azure, how to authentication, …
The Open Service Broker API (https://www.openservicebrokerapi.org) defines the interactions between (in this case) the SAP Cloud Platform and the services offered on Azure.
Actually Open Service Broker is not limited to Cloud Foundry, you can also use it for Kubernetes and other open platforms.
In order to get you started with Azure, Microsoft has released the implementation of Open Service Broker for Azure on GitHub (https://github.com/Azure/open-service-broker-azure, https://osba.sh). As of today there are a bunch of stable Azure services available (like PostgreSQL, CosmosDB, …) and lots more currently being evaluated.
Getting started is quite easy (and I will guide your through the SAP steps as well). The steps below are based on the instruction mentioned https://osba.sh/
Sign-up to SAP Cloud Platform
At first you need an account for the SAP Cloud Platform. You can easily sign up at https://account.hanatrial.ondemand.com/cockpit/#/home/trialhome
Once you have your user you can access the two environments of SAP Cloud Platform. We will skip the older one (Neo) and focus on the Cloud Foundry Trial. Click on this tile and make sure to select Europe (Netherlands) to get SAP Cloud Platform running on Azure.
Initial setup only takes a few seconds and then you are ready to go:
From here we can go the Cloud Foundry Space and from Services -> Service Marketplace we can see a list of default services which are available in SAP Cloud Platform.
All these services can be used by developers in your company to create business applications. In order to give them choice and even more options the Open Service Broker for Azure will list even more services.
Leverage Azure Cloud Shell to setup OSBA
The OSBA uses Redis as a backing service. So the first thing we need to do is setup this Redis Cache. The easiest way to do this is using the Azure Cloud Shell, which can be accessed from https://shell.azure.com
A good starting point is always to check the Subscription ID which you are currently running in. Just run
az account show --query id
And note down the ID, because we will need it later on when updating the manifest.yml file from the OSBA project.
This is the ID of your subscription that you can also see when you go to the Azure Portal (http://portal.azure.com) and select Subscriptions:
Now you can verify if you have already a Redis cache created by issuing
az provider show -n Microsoft.Cache -o table
If you get a NotRegistered
You need to register and create it first.
az provider register --namespace Microsoft.Cache
This might take some time and you can check the process by running the provider show command.
After a few minutes the status should chance from Registering to Registered
In Azure you group resources in so called Resource Group. So the first thing to do is to create a Resource Group. We will call the Group osbaRG and locate it in West Europe
az group create -l westeurope -n osbaRG
az redis create -n osba-cache -g osbaRG -l WestEurope --sku Standard --vm-size C1
Note down the hostname which will be used later.
If you want, you can also verify this in the Azure Portal, where you can find the resource group and the cache:
To retrieve the Primary Key you could do this again either via the portal (Settings -> Access keys) or you can simply run the command:
az redis list-keys -n osba-cache -g osbaRG
The Open Service Broker uses a service principal to provision resources in Azure. So we need to create this SP via
az ad sp create-for-rbac
This now creates a new service principal that we will used in the follow steps. Make sure to note down this information.
Clone the Open Service Broker for Azure from GitHub
Now we have all the information to get the Open Service Broker. For this clone the repo via
git clone https://github.com/Azure/open-service-broker-azure.git
Once that is done you can use Code to edit the manifest.yml file located in the contrib/cf folder and update the variables with the information we retrieved so far. Keep in mind that you have to select a different name / route than the one I have specified since it has to be unique. In the Azure Cloud Shell, just type Code!
You can also update the buildpack to the latest, e.g.
Update 2019-10-06: Thanks to feedback to the blog, please update to the latest buildpack when encountering issues with cflinuxfs2 not being supported anymore: https://github.com/cloudfoundry/go-buildpack/releases/download/v1.9.0/go-buildpack-cflinuxfs3-v1.9.0.zip -- THANKS ravipati9
Hint: since you need to copy and paste the Redit host and password twice, make use of Codes Strg-D and Paste feature.
Once done, use Strg-S and Strg-Q to Save and exit the file.
Connect to SAP Cloud Platform
We are now ready to push the Open Service Broker for Azure to Cloud Foundry. For this we need to connect to the Cloud Foundry environment on the SAP Cloud Platform.
At first we need to set the right API URL for the SAP Cloud Platform. In my case I use
to set the Cloud Foundry environment on Azure in Europe (you can find additional regions and endpoints here)
after that you can login via
cf login
and the email and password that you used for your SAP Cloud Platform account.
With this you can issue a cf push command. Make sure that you do this from the root where you have downloaded the Git repo:
cf push -f contrib/cf/manifest.yml
After a few minutes you should get a result that the app is now running:
If you log on to the SAP Cloud Platform, go to your space -> Application you can also see the App there:
Register the Service in Cloud Foundry
With that the last step is to register the service in Cloud Foundry so that it can be used. For this issue
cf create-service-broker osba-service username password https://osba-service.cfapps.eu20.hana.ondemand.com --space-scoped
Where osba-service is the name of the Open Service Broker app that we deployed, username and password are the actual username and password that we specified in the manifest.yml and the URL is the routes that we got back when pushing the service to Cloud Foundry.
when that is done you can check the SAP Cloud Platform Service Marketplace again where you will see several Azure services ready to be consumed by your developers!
From now on developers using the SAP Cloud Platform cannot only use the services provided by SAP to create applications, but can easily enrich applications using Azure services.
Use Mongo DB APIs in SAP Cloud Platform
Lets say you want to use a Cosmos DB in your SAP application. Then issuing from CF
cf create-service azure-cosmosdb-mongo-account account mongo-db-hbr -c '{"resourceGroup":"osbarg", "location":"westeurope"}'
would create a Cosmos DB (with MongoDB API) in Azure and make it available in SAP Cloud Platform. There is no need for the SAP developer to reach out and interact with the Azure admin to go back and forth to discuss details. It's just there and ready to use!
As a result you can see the service in CF:
cf service mongo-db-hbr
and of course also in the Azure Portal in the related Resource Group:
Now you are ready to go and develop new applications not only leveraging SAP, but also backing services from Azure!
History:
June 20th, 2019: Small updates / corrections. Thanks, Max for the feedback!
