Cloud Foundry Advisory Board Call, Oct 2022: Service Fabrik Broker Updates
The Cloud Foundry Community Advisory Board (CAB) meeting in October featured a presentation and demo of Service Fabrik Broker. With only a few days left before the upcoming Cloud Foundry Day, there were also a few announcements regarding the event. The call was moderated by Ram Iyengar from the CF Foundation.
Service Fabrik Broker
The recommended approach for developing Kubernetes-native services is to develop an operator for the purpose. This requires bridging the gap between the Kubernetes resource-based API of the operators with the Open Service Broker (OSB) API expected by the Service Manager, a central repository of service brokers and platforms. Service Fabrik Broker, also known as Interoperator, bridges the gap using a metadata-based approach.
During the call, Jintu Sebastian of SAP, provided an overview of the tool. According to Jintu, Service Fabrik Broker currently has three main functions:
- expose OSB-compliant broker for a service natively hosted on Kubernetes
- schedule the provisioning of service instances across clusters in a multicluster configuration
- facilitate the life cycle operation of Kubernetes-based service instances in an OSB-compliant manner
Service Fabrik Broker makes it easier to provision Kubernetes services on Cloud Foundry. “If you have a service in Kubernetes, likely an operator, and you want to make it OSB-compliant, so it can be used in Cloud Foundry, you can use Interoperator,” explains Jintu. “Interoperator will be the front end, which will serve your OSB request and map in the custom resources of the operator.
“One of the important features of Interoperator is that if you install it in one cluster, it will help you to provision instances in multiple clusters.”
—Jintu Sebastian, SAP
Interoperator is made up of the following components:
- Broker acts as the OSB API adapter and is the component that integrates with the Service Manager.
- Provisioner is a customer controller that watches
SFServiceBindingcustom resources and takes actions to reconcile the corresponding resources of the service operator.
- Schedulers are custom controllers running on a master cluster. These schedulers watch
SFServiceInstancesand assign them an ID of the cluster, where the instance needs to be provisioned.
- Multicluster deployer is a set of custom resources, which manages multiple clusters.
How it works
Service Fabrik Broker makes use of five custom resources that integrate with Service Manager and individual operators. These custom resources include:
SFServicecaptures the manifest details of
SFPlancaptures the manifest details of
OSB Service Plan.
SFClusterstores the details of the cluster, where service instances are to be provisioned.
SFServiceInstancecaptures all the details from the OSB
SFServiceBindingcaptures all the details from the OSB
According to Jintu, Service Fabrik Broker enables operator compliance with an OSB in just a few steps:
- Install the service operator in the required clusters.
- Define the primary cluster.
- Install Service Fabrik Broker in the primary cluster.
Given the CF Foundation’s current focus on Korifi, Anoop believes that Service Fabrik Broker can also help the project in terms of bridging both Kubernetes and Cloud Foundry.
“I believe, we also need an OSB-compliant operator for Korifi. We can use Interoperator’s OSB capabilities to connect to a Cloud Foundry environment. So, service operators who already have a Kubernetes operator don’t need to develop a new OSB broker and can just use Interoperator.”
—Anoop Joseph Babu, SAP
CF Day updates
With Cloud Foundry Day set for October 25, Ram reminded members of the community to register for the event. Those unable to go in person can still virtually attend for free.
The next CAB call is tentatively scheduled for November 16, 2022, at 11 a.m. ET / 8 a.m. PT. Anyone interested in participating can join the CAB Slack channel.