Replacement for Open Service Broker Azure

[rsletta]

Current SAP guidance for integration of Azure services on SAP Cloud Platform Cloud Foundry uses the "Open Service Broker for Azure". This project is no longer maintained by Microsoft, and is for that naturally considered "use at own risk". That project points towards "Azure Service Operator(for Kubernetes)", which is an implementation for Kubernetes and not Cloud Foundry.

Is there any new guidance on how to implement SCP CF <- Azure service integration? Or is it at least something on the roadmap for Embrace, that can mitigate the risk of running unmaintained software (as in OSBA), that doesn't involve implementing something yourself?

[Martin-Pankraz]

Hi rsletta,

The OSBA lifts some burden on the provisioning. But other than that nothing is keeping you from spinning up resources in Azure without OSBA and integrating them through APIs, SCP Destinations and SDKs.

Do you have a requirement that you are missing? Are you looking to integrate a database, serverless functions or the likes?

KR

Martin

[rsletta]

Thanks martin-pankraz.

I read this as that we have a misunderstanding of the role of the service broker. We are in the process of looking at scenario spanning on-premise, Azure (with several services), SAP Cloud Platform (with HANA Cloud), and SAP Data Warehouse Cloud. When exploring how we would do this, we looked at the mission "Consume Microsoft Azure services in SAP Cloud Platform" and "Use Microsoft Azure Services in SAP Cloud Platform". That lead us to the assumption, that we could expose Azure services as accessible services on Cloud Foundry, instead of using other integration methods. And that we could use the service broker to access existing services, for example "Data Lake", using something like "User Provided Service".

best regards

Ronnie

[Martin-Pankraz]

rsletta,

you would miss the native CF binding part described in the missions without the OSBA for sure.

KR

Martin

[gregorw]

Hi Martin,

I think the biggest benefit of the service broker is the automatic management of credentials when provisioning services using it. Hope that there will be a future proof solution.

Best regards
Gregor

[Martin-Pankraz]

Hi gregorw,

in that case CI/CD pipelining would also be interesting. You could have terraform or ARM templates to be run as a "construction" pipe that runs on-demand to spin up your resources in CF and Azure including credentials. I would envision a prior service principal setup in Azure, that can be referenced for all "construction" operations and a seperate CF user for CF CLI. That way you would achieve transparency and centrally governed app infrastructure for your CF app with Azure. That would give you even more flexibility than the OSBA in my opinion.

Only downside is the missing native binding. The app needs to call Azure through APIs. Gateway components and API management solutions secure the calls from the public CF endpoints.

What do you think?

KR

Martin

[gregorw]

Hi Ronnie,

with todays release of Kyma 1.23 Dhahran the Service Catalog was deprecated with this statement:

"We decided to deprecate Service Catalog and all the related components, and in the nearest future, we are going to completely remove them. The main reason for this decision is the fact that hyperscale cloud providers no longer support the Open Service Broker API for service provisioning. Instead, they switched to operators, and we will also follow this approach in Kyma Service Management."

Hope that maybe michael.weingartner can direct this quesiton to the right people responsible for SAP BTP Cloud Foundry on the plan what will be the future there.

Best regards
Gregor

[Former Member]

You guys should definitely post a blog about it - if you haven't. Very important topic. If you discussing about, the community should be paying attention. 😉