This post gives an overview of OSB API service brokers and introduces an open-source generic OSB using git.
If you work as an Enterprise Architect, in a Cloud Foundation Team, in DevOps – or you’re just interested in implementing the OSB API – this post is for you.
In this post we will answer the questions:
- How can cloud services be distributed enterprise wide?
- What are cloud service brokers?
- How does the OSB API work?
- What are the advantages of the OSB API?
Also, we’ll go into detail on our generic Unipipe Service Broker that uses git to version cloud service instances, their provisioning status, and the service marketplace catalog.
The Service Marketplace as Central Distributor for Cloud Services
Platform services play an increasingly important role in cloud infrastructures. They enable application operators to quickly stick together the dependencies they need to run their applications.
Many IT organizations choose to offer a cloud service marketplace as part of their service portfolio. The marketplace acts as an addition to the cloud infrastructure services provided by large cloud providers like AWS, GCP, or Azure.
Service owners can build a light-weight service broker to offer their service on the marketplace. The broker is independent of any implementations of the service itself.
What exactly is a Service Broker and how does OSB API work?
The service broker handles the order of a cloud service and requests a service instance on the actual cloud platform. The user can choose from a catalog of services – e.g. an Azure vNet instance – enter necessary parameters and the broker takes care of getting this specific instance running for the user. In this example, the cloud service user would specify the vNet size (how many addresses do you need?), if it needs to be connected to an on-prem-network and so on.
A popular choice for modeling service broker to marketplace communication is the Open Service Broker API. The OSB API standardizes the way cloud services are called on cloud-native platforms across service providers. When a user browses the service catalog on the marketplace, finds a cloud service useful for his project, and orders it an OSB API request is invoked for provisioning the service.
Building a Cloud Service Broker using the OSB API and GIT
At meshcloud we offer a Service Marketplace with our cloud governance solution that communicates via the OSB API. A service broker has to be build to offer services on this marketplace: We started an open source project to provide developers with a generic broker called the Unipipe Service Broker.
The idea is an implementation of GitOps.
To understand how UniPipe can help to implement GitOps, consider the following definition:
The core idea of GitOps is (1) having a Git repository that always contains declarative descriptions of the infrastructure currently desired in the production environment and (2) an automated process to make the production environment match the described state in the repository.
The broker is implementing (1) by creating and maintaining an updated set of instance.yml files for services ordered from a Platform that speaks OSB API.
The automated process (2) can then be built with the tools your GitOps Team chooses.
The actual provisioning is done via a CI/CD pipeline triggered by changes on the git repository, using Infrastructure-as-Code (IaaC) tools that are made for service provisioning and deployment like terraform.
Using git might be a limiting choice for service owners who expect frequent concurrent orders. But from our experience, the majority of service brokers are called more like once an hour than once a second – even at large companies.
Configuration of the Unipipe Service Broker
You can look up everything you need to get started on our Unipipe Service Broker page.
The custom configuration of our generic broker can be done via environment variables. The following properties can be configured:
GIT_REMOTE: The remote Git repository to push the repo toGIT_LOCAL-PATH: The path where the local Git Repo shall be created/used. Defaults to tmp/gitGIT_SSH-KEY: If you want to use SSH, this is the SSH key to be used for accessing the remote repo. Linebreaks must be replaced with spacesGIT_USERNAME: If you use HTTPS to access the git repo, define the HTTPS username hereGIT_PASSWORD: If you use HTTPS to access the git repo, define the HTTPS password hereAPP_BASIC-AUTH-USERNAME: The service broker API itself is secured via HTTP Basic Auth. Define the username for this here.APP_BASIC-AUTH-PASSWORD: Define the basic auth password for requests against the API
The expected format for the GIT_SSH-KEY variable looks like this:
GIT_SSH-KEY=-----BEGIN RSA PRIVATE KEY-----
Hgiud8z89ijiojdobdikdosaa+hnjk789hdsanlklmladlsagasHOHAo7869+bcG x9tD2aI3...ysKQfmAnDBdG4=
-----END RSA PRIVATE KEY-----
Deployment using Docker
We publish generic-osb-api container images to GitHub Container Registry. These images are built on GitHub actions and are available publicly
$ docker pull ghcr.io/meshcloud/generic-osb-api:v1.0.5
Deployment to Cloud Foundry
In order to deploy the Unipipe Service Broker to Cloud Foundry, you just have to use a configured manifest file like this:
applications:
- name: generic-osb-api
memory: 1024M
path: build/libs/generic-osb-api-0.9.0.jar
env:
GIT_REMOTE: <https or ssh url for remote git repo>
GIT_USERNAME: <if you use https, enter username here>
GIT_PASSWORD: <if you use https, enter password here>
APP_BASIC-AUTH-USERNAME: <the username for securing the OSB API itself>
APP_BASIC-AUTH-PASSWORD: <the password for securing the OSB API itself>
./gradlew build # build the jar of the Generic OSB API
cf push -f cf-manifest.yml # deploy it to CF
Communication with the CI/CD pipeline
As the OSB API is completely provided by the Unipipe Service Broker, what you as a developer of a service broker have to focus on is building your CI/CD pipeline. An example pipeline can be found here.
To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We’re looking forward to get in touch with you.