Service Fabrik 2.0: An Event-Driven Service Broker Framework

Service Fabrik – A Primer

Service Fabrik is an OSBAPI-compliant broker for provisioning/operating/managing backing services like databases, message brokers, etc. The primary objective of Service Fabrik is to provide a seamless mechanism for creating and operating backing services across different platforms like Cloud Foundry, Kubernetes and more, and across different cloud infrastructures. To know more about Service Fabrik, visit here.

Redesigning Service Fabrik – Motivation

The following was the motivation behind redesigning Service Fabrik and coming up with Service Fabrik 2.0.

• Integrating new provisioning mechanism with Service Fabrik.
• Integrating with built-in backup mechanism and support of the same other than the default approach Service Fabrik provides.
• Event driven architecture, plugging additional component would be extremely easy.
• Reduce/cut-off Cloud Foundry dependency, as we move to support varied other consuming platforms like Service Manager, Kubernetes and more.

What is Service Fabrik 2.0?

• Service Fabrik 2.0 architecture is based on Control loop architecture.
• Control loop architecture is an event driven architecture where the controller receives events as feedback and works upon them.
• Control loop or Feedback loop is a well-known pattern. An example of usage of such control loop architecture is given below.

• Service Fabrik uses Kubernetes API Server for eventing. The API Server also provides REST based mechanism to communicate.
• The workflow is as follows:

1. Broker sends events to API Server.
2. Operators listen for specific events and process them.

High Level Architecture

Capabilities

• Integrating new provisioner becomes very easy.
• Integration with built-in backup mechanism and support, aside from the default approach Service Fabrik provides.
• Provides deployment-hooks to allow service-specific concerns to be addressed in a controlled way.
• Maintains minimal state, hence consuming platforms like Cloud Foundry and provisioning platforms like BOSH dependency can be reduced.
• New operators can be written in any language. This enables polyglot programming which in turn makes it easier for more people to contribute to open source.
• New components for additional functionalities can be easily integrated.

Bringing in new Operators

• Add your services and plans in the Service Fabrik broker catalog.
• Bring in your own CRD and add the resource mappings in the plan metadata.
• Start your operator and do the following:
  • • Register the CRD with Service Fabrik API Server.
    • Start watching the CRD for state change.
    • Process create/update/delete depending on the state change.

 

If you enjoyed this introduction to Service Fabrik’s new design, read our next blogs about how you can bring in new operators.