Open Service Broker for vRealize Automation Cloud

vRealize Automation Cloud is the main topic in my series of blog posts explaining in detail what we are demoing in our breakout session HBO3559BE (US: HBO3559BU) at VMworld Barcelona. This one will go into the details of my implementation of the Open Service Broker Specification for vRAC.

Open Service Broker API Specification

Started within the Cloud Foundry community, Open Service Broker API (OSB API) gained quite some traction in 2016/2017. It aims to become an industry standard facilitating to provision and consume services in a uniform way. Swisscom is engaged with Cloud Foundry and has developed one of the CF certified PaaS platforms. OSB API is used within Swisscom to consume distributed reusable services from multiple consumer platforms. I was leading an initiative to enable OSB also on top of vRA 7.x and refactored the broker to use it with vRAC. I will conclude this post with my personal take aways on the OSB API Specification.

Application Architecture


Big Picture of the OSB Architecture

My OSB for vRAC is a spring boot application written in Java. The OSB Spec is generated from the OpenAPI specification available on the OSB API repository. There is also an official spring library for the OSB but at the time I started implementing it was not supporting the latest version of the spec.

Spring boot can easily be deployed with the application binaries, but I wanted to make it deployable on Kubernetes. I added a docker image build and pushed it to docker hub. A K8s deployment yaml and the application can be deployed on our PKS cluster.

The demo version works with an in-memory DB for caching catalog and persisting UUID/resource ID associations.

Service Catalog

OSBs must publish a catalog with the services they are offering. The catalog is defining an “instance schema” for “create” and one for “update”. This schema must be a valid JSON Schema since OSB version 2.13. Services can have multiple “plans” defining concrete variants of a service in terms of resources and number of instances (t-shirt sizes).

For my first version I simply get the input schema definition of the catalog API:{{blueprintId}}/inputs-schema

This returns exactly what I need for the OSB API: a nice JSON schema for the blueprint inputs. All I had to add are “deploymentName” and “description” as a mandatory and an optional parameter for all blueprints. And I could use this API call as the schema URL in the service description.

“create” and “update” are generated in the same way, I did not go into the details of updating a blueprint, yet.

Service Provisioning

Service provisioning is straight forward: convert the OSB API call into a blueprint request for vRAC. The differences are quite minimal, this is vRAC catalog API:

   "deploymentName": "cas event subscriber",
   "description": "cas event subscriber",
   "plan": false,
   "blueprintId": "{{blueprint_id}}",
   "inputs": {
      "region": "region:aws-eu-west",
      "image": "ubuntu",
      "flavor": "medium",
      "hostname": "evtscr1",
      "refreshtoken": "{{refresh_token}}"
   "simulate": false

This is an OSB call:

   "service_id": "{{service_id}}",
   "plan_id": "{{plan_id}}",
   "context": {
      "platform": "esc",
      "stage": "DEV",
   "organization_guid": "{{organization-uuid}}",
   "space_guid": "{{project-uuid}}",
   "parameters": {
      "deploymentName": "cas-event-subscriber",
      "description": "CAS Event Subscriber",
      "region": "region:aws-eu-west",
      "image": "ubuntu",
      "flavor": "medium",
      "hostname": " evtscr1",
      "refreshtoken": "{{refresh_token}}"

The “context” is an optional parameter that allows to pass a business context with the “organization_guid” and “space_guid” to trigger i.e. billing or access rights.

Service provisioning is done asynchronously hence we must poll for success or error.

An interesting particularity of this definition is that the primary ID (the service instance ID) is given by the user in form of a UUID. The broker must ensure that this UUID is unique and must persist it with the association to the technical service ID – in this case to the deployment ID of vRAC. For my demo purposes I just took an in-memory DB that stores a mapping record.

Service Fetching and Binding

Fetching the service is possible with the user given UUID. The binding operation could return credentials, parameter to reach the service or does even a reservation of the given instance.

Take Aways

I like the OSB specification because it is quite simple and a very good fit for simple and rather static services. If you have a good client framework you will integrate such services in very short time. And I like the formal description by JSON schema in the latest versions. This allows you to generate input forms dynamically.

I found, however, that for vRA 7.x there are still a lot of limitations that are not acceptable:

  • Context sensitive definitions are not supported. The catalog should even be immutable as stated in the spec. With vRA you can create forms that show i.e. a drop down list based on free addresses for the given tenant. As the catalog is basically created and cached offline, there are no means to support this kind of dynamicity according to the context.
  • Day 2 actions are not really considered in the spec. There are some discussions around this topic, but I was not very pleased with the outcome: every service should define an URL to a proprietary REST service. This keeps the OSB API very lightweight, but the burden is offloaded to the service and the consumer of the proprietary API.
    Day 2 actions can be quite complex with respect of their input forms; basically, we could see the same complexity as with provisioning the service.
  • If you do not have a lot of different service consumers, this additional layer is only one component more you must build and maintain. And if you create an OSB per service endpoint, you lose even the notion of brokering services on a single endpoint: a client still must deal with different endpoint addresses, versions and authentication. The adapter to a spec that does not solve all aspects alone will bring no added business value.

With the latest vRAC release custom forms were introduced. I did not start working on a context sensitive catalog, yet, because I want to find a reliable solution to the day 2 actions challenge. The OSB spec allows to have extensions, but I think, the value of the OSB gets diminished, if proprietary extensions must be introduced. I plan to do a PoC with an extension of the schema either on the update instance calls (is a day 2 action an update of an instance?) or by adding a new call for actions. Actions could and should be described in the same way as in the “create” or “update” schemes. In addition, it must be possible to get a list of available actions or a context sensitive catalog entry for a selected service. “Stop VM” should not be offered if the VM is stopped, and a tenant should only see the networks he’s allowed to see and are applicable in the given context.

VMworld Barcelona

If you’re attending don’t forget to register for the Breakout Session HBO3559BE. We will demo this functionality live on stage. And stay tuned: I will explain in detail how we have configured Code Stream for our evaluation test.