Building a generic Cloud Service Broker using the OSB API

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.

Architecture of a generic OSB API Service Broker sitting between a service marketplace and the cloud platforms.
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 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 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.


Sign on store door saying

Cloud Infrastructure Services: Enterprise-wide Distribution via a Marketplace

This is a comprehensive overview over provisioning cloud infrastructure services in 2020.

If you work as an Enterprise Architect, in a Cloud Foundation Team, in DevOps - or you're just interested in cloud infrastructure services - this post is for you.

In this post you will learn:

  • What cloud infrastructure services are
  • What benefits you can expect from them
  • Who the stakeholders are – service user and owner
  • About the role of Cloud Foundation Teams
  • About the challenges posed by provisioning of services
  • How a service marketplace helps you offering and using infrastructure services

If you want to dive deeper, this guide will go into more detail on:

  • The Open Service Broker API
  • How service owners can move from cost to profit center
  • Platform service model classification

Chapter 1: Fundamentals of Cloud Infrastructure Services

Let's get started with a quick intro to cloud infrastructure services.

Specifically, we will define what cloud infrastructure services are, what kinds there are, and what they are good for.

What is a Cloud Infrastructure Service?

Any service needed to actually run workload in the cloud is a cloud infrastructure service: These services are provided by AWS, Azure, or GCP for their platforms but can also be provided by third-party vendors or by the developers using the cloud.

Here are a few examples to get a quick and intuitive understanding of what cloud infrastructure services are: A database is such a service or a monitoring stack or the backend connectivity you need to run your application in the cloud. Another example would be a managed CI/CD service like Gitlab or Azure DevOps that is used in addition to the native infrastructure to follow cloud-native best practices.

You can think of cloud services as infrastructure building blocks, that are standardized and reusable, for any imaginable purpose.

What are Cloud Infrastructure Services good for?

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. For example, when deploying your application and you need a database, you just request a service instance of the database of your choice and connect it to your application. Done.

Managed services especially - we'll get to that in the next section - enable developers to focus on their application code and not on operations and dependencies or ordering processes.

The basis is the IaaC services provided natively by the cloud service providers: You can create any other - more complex - service on top of them. Organizations thrive for higher-level services, because it's less effort, accelerates time-to-market, and leverages existing knowledge.

What kinds of Cloud Infrastructure Services are there?

Now for a brief dive into the categories that cloud infrastructure services come in.

The first thing we can ask ourselves is by whom the services are provided:

On the one hand, there are the cloud service providers (CSPs), who offer first-hand services for their platforms.

Then there are a large number of third-party providers who bring their services to users via the corresponding cloud provider marketplaces.

Very often, however, services are also provided inhouse in order to meet very specific requirements.

We can also categorize cloud services by their operating model:

First there is the dimension and the level of management of services.

They come as

  • unmanaged,
  • operated and
  • managed services.

Unmanaged services are provisioned by the vendor and from there on the service user is on his own.

Operated services are monitored by the vendor and recovered if anything goes wrong. The effects of the service on the users' applications and data are still out of the vendor's scope in this case.

Managed services are basically run by the vendor: The responsibility of keeping the service available, providing data backups, recovery, and continuous updates makes this the most comfortable and most expensive way of consuming services.

There is a second dimension to service classification:

Is the service a white- or a blackbox to the user?

Whitebox: Details of the service deployment are visible to the user.

Blackbox: The service only offers a defined interface to control your service instance, but no insight where or how this service is deployed or operated.

Chapter 2: Stakeholders of Service Provisioning

First of all: It is important to know who is responsible for what aspect of a cloud infrastructure service:

The service owner and the service user are the two parties that share interest and responsibility in the service.

The Service Owner

Services can be owned by CSPs like AWS, Azure, and GCP, by third-party companies that offer special monitoring or connectivity services and services can be owned by corporate IT or DevOps-Teams. The owner usually charges for the usage of the service.

The Service User

Service users are usually developers and operators who work on applications in the cloud. The user is usually charged with the cost of the service instance.

The Role of Inhouse Cloud Service Owners

Cloud Foundation Teams, network or database teams are usually in the role of a service provider: They offer Databases-as-a-Service or monitoring services to the developers in the company. They focus on cross-sectional topics that are relevant for many cloud applications. Inhouse service owners can more often than not charge for the services provided - missing processes for billing are a major challenge here.

Chapter 3: The Challenges of Provisioning Services

Cloud Infrastructure Services arise from certain demands in the development teams that work with cloud infrastructure. They need monitoring, databases, connectivity, and so on, to do their job.

Where can developers find the right services?

Depending on the cloud technology they work with, developers have a catalog of 3rd party services to choose from: Google runs its Google Cloud Marketplace, Microsoft offers services in their Azure Marketplace and Amazon has its AWS Marketplace.

From operating systems to data analytics and machine learning services - there are solutions of every category.

Challenges for enterprise-wide service distribution

Even with the endless first and third party services in the marketplaces of the cloud providers there is a massive need for customized solutions:

In a worst-case scenario, the developers can't find a service that solves their problem and they build a solution themselves.

This leads us to the challenges that arise when offering and consuming services within an organization:

  • every team reinvents the wheel
  • intransparent and time consuming processes
  • manual provisioning, e.g. having to send a mail to the service owner
  • no central overview of which services are available within the organization
  • Service delivery is resource and time-consuming when self-service is not available
  • Lack of billing

Supply and demand of services

This set of challenges leads to the fundamental issue of service development and consumption in an organization: Potential service owners are deterred from developing services. It makes them a cost center and every new service adds effort when it comes to provisioning it.

In the next chapter, we'll see how a service marketplace addresses this issue by motivating service owners because they can offer services company-wide, gain visibility and charge for the usage of their services.

Chapter 4: The Service Marketplace

Many IT organizations choose to offer a 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.

The 4 components of a marketplace

Four components make up a cloud service marketplace: a service catalog, provisioning, billing, and service monitoring.

  1. The catalog requires the service owners to create intuitive experiences to discover the right product and help developers choose the right solution. The marketplace will also need to have enough available inventory, which means continually incentivizing service owners to provide new services.
  2. Provisioning acts as the backbone of the whole system. The marketplace has to manage which resources need to be created or deleted, it has to deliver the configuration and provision dedicated service instances.
  3. Billing provides the system of record. This system needs to implement several different billing models, payment methods, and processing.
  4. Lastly, service monitoring allows the service owner to check on running service instances and take care of failed services.

An active marketplace needs these critical systems to work smoothly together.

The major use case of a marketplace working like this is the possibility of offering services in a multi-cloud federation.

Benefits of a service marketplace

We learned that cloud services are the building blocks to a more complex cloud infrastructure. We also learned that there are several ways of offering and accessing services.

A service marketplace is the best option to go for and here is why:

  • Self-service
  • Chargeback
  • Service monitoring

Marketplace implementation with Open Service Broker API

At meshcloud, we've implemented our Service Marketplace solution based on the Open Service Broker API.

The Open Service Broker API defines an interface between platforms and service brokers. 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.

With this technology services of every category can be offered: Managed or unmanaged, black box or white box.

This self-service, on-demand marketplace increases developer velocity and minimizes time to deliver value to the market.

A graphic showing how the meshcloud service marketplace brings service owners and users together using the OSB API
This graphic shows how we at meshcloud implemented a marketplace to bring both service owners and users together.

About the Open Service Broker API
The Open Service Broker API project allows independent software vendors, SaaS providers, and developers to easily provide backing services to workloads running on cloud-native platforms such as Cloud Foundry and Kubernetes. The specification, which has been adopted by many platforms and thousands of service providers, describes a simple set of API endpoints that can be used to provision, gain access to, and managing service offerings.
The project has contributors from Google, IBM, Pivotal, Red Hat, SAP, and many other leading cloud companies.


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.