Technical Articles
Consuming native Microsoft Azure services on SAP Cloud Platform
[UPDATED – 02.02.2021]
Disclaimer: The Multi-Cloud Foundation guide on “Integrating Microsoft Azure Services into Cloud Foundry on SAP Cloud Platform” is removed. Please use user-provided services, instead. See Creating User-Provided Service Instances. Hence some of the links in the blog below might not work anymore.
Hi Enthusiasts,
Often we are asked by our customers about the possibilities to integrate their SAP workloads with native hyperscaler services. SAP Cloud Platform’s cloud foundry environment provides a possibility to provision and to consume native hyperscaler services. In this blog post, let’s see how this is enabled with Microsoft Azure using the Open Service Broker for Azure(OSBA).
OSBA is an open-source API server based on the Open Service Broker API specification. It helps with provisioning managed services in the Microsoft Azure public cloud. The concepts of achieving this are based on Cloud Foundry and service brokers. The step-by-step tutorial on how to achieve this is available in the official documentation. The following image depicts a high-level overview of the steps described in the documentation:
Once the above-depicted integration is implemented, Azure native services such as Azure Database for MySQL, Azure Cosmos DB and so on are available in Cloud Foundry service marketplace as shown below:
With SAP’s multi-cloud strategy, we strive to provide our customers with seamless integration and reuse experience. Stay tuned for more use-cases and scenarios using the native services and I will be happy to hear your feedback as comments below.
Cheers,
Harini
How is a customer charged when they use Azure service from CP? Via CP or directly on Azure?
Regards, Ashwani Kr Sharma
Great question Ashwani! The customers are directly charged by Azure for the Azure services consumed. The pre-requisite here is that the customer has an Azure account and SAP Cloud Platform account.
I think that’s exactly the thing to keep in mind, that this setup means that you will have 3 “vendors” at play.
You will be billed separately, but also support is delivered separately. I’ve played with this setup myself as well, and it works great. I would be very cautious moving this setup to production though, as end-to-end support will be hard to find.
Would be any further use case what we can think about? I was thinking
something like this ? what could be ideal use case, anyone to share quick idea ?
Is this applicable to any service on Azure, the customer would like to spin up Hana on Azure and consume from SCP, is it still possible?