This post gives an overview over 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 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 from 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 onprem-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.
The idea is that everything the broker does is kept in structured documents that are versioned in a git repository. The catalog is kept in a
catalog.yml, the provisioning status is kept in a
status.yml and the specifics of an instance are kept in an
instance.yml. This way the broker automatically versions everything in git - you don't have to deploy and run a database to do that.
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 generic OSB API
You can look up everything you need to get started on our generic OSB API Git 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 to
GIT_LOCAL-PATH: The path where the local Git Repo shall be created/used. Defaults to tmp/git
GIT_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 spaces
GIT_USERNAME: If you use HTTPS to access the git repo, define the HTTPS username here
GIT_PASSWORD: If you use HTTPS to access the git repo, define the HTTPS password here
APP_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 Generic OSB API 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 "Generic OSB API", what you as a developer of a service broker have to focus on is to build your CI/CD pipeline. An example pipeline can be found here.