Sharing experience of implementing Open Service Broker API (https://www.openservicebrokerapi.org/)

1. Challenges of Implementing
the OSB API
NAIL ISLAMOV | ATLASSIAN | @NILEBOX

2. Service brokers advertise a catalog
of service offerings and service
plans, as well as interpreting calls for
provision (create), bind, unbind, and
deprovision (delete).
SERVICE BROKERS

3. SERVICE BROKER ARCHITECTURE

4. Catalog
List of “service classes” (resource
types) and their plans (tiers).
SERVICE BROKER FEATURES
Service Instances
Provisioning reserved resource
instance
Service Instance Binding
Creating and fetching credentials for
resource instance

5. SERVICE BROKER ARCHITECTURE

6. Most of the OSB API decisions have
been made at the times of Cloud
Foundry Service Broker.
OSB

7. CloudFoundry
Spring Boot MySQL broker example
https://github.com/cloudfoundry-community/cf-mysql-java-broker
EXAMPLES
AWS brokers (built using Ansible broker)
https://github.com/awslabs/aws-servicebroker-documentation/wiki
Ansible broker
https://github.com/openshift/ansible-service-broker/blob/master/docs/introduction.md
Other vendors (Azure, GCP) supply their official brokers as well
OSB documentation
Links to some implementation examples
https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md
Brokers for different languages/platforms
Go, Java, NodeJS

8. Help the OSB community by
opensourcing generic libraries for
building brokers in different
languages.
EXAMPLES

9. The only authentication mode
explicitly defined in the OSB
specification is Basic Auth.
AUTHENTICATION

10. Bearer Token Auth (JWT, OAuth 2.0, vendor specific implementations)
Service Catalog has support for arbitrary Bearer tokens provided via Secret resource
AUTHENTICATION
Other authentication modes
OSB allows a platform to support any other authentication protocols, so feel free to reach Service
Catalog or Cloud Foundry folks to add support for yours
Basic Auth
The only authentication mode explicitly defined in the OSB spec
Mutual TLS

11. OSB doesn’t explicitly define the
requirements of the instance state
after the failed update.
INSTANCE UPDATES

12. Update with the fix
Sometimes it might be fine to leave the instance in the “broken” state until the correct update or retries
fixes it
INSTANCE UPDATES
Rollback
If possible, rollback to the previous stable state of the instance

13. You can define different JSON
schemas for instance CREATE and
UPDATE requests.
But you should think twice before
doing that.
INSTANCE UPDATES

14. Cloud Foundry
For some historical reasons Cloud Foundry does not keep the parameters for instance, so every CREATE
or INSTANCE request just gets forwarded to the broker.
INSTANCE UPDATES
Service Catalog
Kubernetes API is declarative and asynchronous, so there is little difference between CREATE and
UPDATE requests, and it is a challenge to support “diff” for PATCH requests.
Update parameters
Some parameters might be sensible only for the initial provisioning of the resource, and are immutable

15. Keep CREATE and UPDATE request
parameters the same. Implement all
specifics on the broker side (ignore
irrelevant parameters, apply only
parameters that have changed since
the last provisioning/update).
INSTANCE UPDATES

16. There is a section in the request that
provides platform-specific
information.
PLATFORM CONTEXT

17. PLATFORM CONTEXT
{
"context": {
"platform": "kubernetes",
"namespace": “myapp"
},
"service_id": "service-id-here",
"plan_id": "plan-id-here",
"bind_resource": {
"app_guid": "app-guid-here"
},
"parameters": {
"parameter1-name-here": 1,
"parameter2-name-here": "parameter2-value-here"
}
}

18. PLATFORM CONTEXT
Vendor specific context
- RedHat OpenShift
- IBM Bluemix
- Microsoft Azure
Platform specific context
- Kubernetes (Service Catalog)
- Cloud Foundry

19. Avoid relying on a particular
platform implementation details if
you can.
PLATFORM CONTEXT

20. OSB makes the Platform (Service
Catalog, Cloud Foundry) responsible
for the orphan mitigation.
ORPHAN MITIGATION

21. Implement cleanup in the broker as
part of asynchronous provisioning
request processing.
ORPHAN MITIGATION

22. IDs are client-provided in OSB
instance/binding requests.
Don’t make assumptions about their
specific format or pattern.
EXTERNAL ID

23. Stateless OSB brokers is a myth.
Try to be smarter.
- Orphan mitigation
- Rollback after the failed update
- Idempotency
- Get ready to support GET requests
STATELESS OSB BROKERS

24. Services support operations (restart,
pause, stop) and jobs (backup,
restore). It’s important to automate
the Ops side of DevOps.
This part is not covered by OSB spec
yet.
OPERATIONS / JOBS / ACTIONS

25. In some situations the service backed
by OSB broker might change its state
by itself.
Currently there is no way to tell the
platform to re-sync.
SYNC AFTER BROKER DRIVEN CHANGES

26. Stateless OSB brokers is a myth.
STATELESS OSB BROKERS