Announcing Open Service Broker for Azure 1.0 and more community updates

A few months ago, we announced a preview of the Open Service Broker for Azure (OSBA), the simplest way to connect applications running in cloud native environments, like Kubernetes, Cloud Foundry, and OpenShift, to the rich suite of managed services available in Azure.
Today, we are pleased to announce the 1.0 release of OSBA with full support for Azure SQL, Azure Database for MySQL, and Azure Database for PostgreSQL. With this major milestone, we thought it would be a good time to recap some of the great work that’s been happening in this area over the last few months, both from Microsoft and the community.

OSBA reaches 1.0

Since announcing the preview of OSBA at KubeCon, we’ve been working closely with customers to understand their workflows and ensure that they would be well supported in the broker. This included expanding our set of service classes to enable creation of an empty database server and the creation of a database within an existing server. With this broader set of classes, we believe we can enable most of the relational database workflows used by customers.
We’ve also spent a lot of time ensuring that OSBA itself is resilient and scalable, with support for multiple concurrent requests and fully asynchronous processing that can seamlessly resume even if an instance of the broker crashes. This makes OSBA ideal to run in a containerized environment like Kubernetes. With the 1.0 release, we believe OSBA is ready to take on the task of connecting mission critical applications to Azure’s enterprise-grade backing services.

svcat CLI goes upstream

Along with OSBA, our KubeCon announcement included a new CLI tool for interaction with the Kubernetes service catalog, known as svcat. Much like how the service catalog itself seeks to bring the power of Cloud Foundry’s service broker concept to Kubernetes, we created the svcat CLI to deliver the ease-of-use of the cf CLI to the service catalog. We were thrilled to see that the community agreed and happily contributed the tool to the upstream service catalog effort, where it is now available standalone or as a kubectl plugin. We are really pleased to see that svcat is now the predominant way to interact with the service catalog.

Kubeapps

The combination of containers, Kubernetes, and the service catalog makes it easy to deploy popular cloud applications in a reliable, scalable way. Bitnami’s KubeApps project takes this powerful combination and wraps it in an intuitive dashboard. We’ve enjoyed working with our partners at Bitnami to bring OSBA into KubeApps, enabling customers to deploy solutions like WordPress built on Azure Database for MySQL and Artifactory on Azure Database for PostgreSQL.

OSBA in OpenShift

In May, Microsoft and Red Hat announced a strategic partnership to provide a jointly operated managed OpenShift service on Azure. As part of that announcement, we demonstrated the use of OSBA in OpenShift using an OpenShift project template, enabling customers to deploy Azure services directly from the OpenShift console and connect them to their containerized applications running in OpenShift. We’ve enjoyed working with Red Hat on the Kubernetes service catalog project, so it’s great to see the service catalog and OSBA working together to enable great Azure-based solutions in OpenShift.

What’s next

Going forward, we have three areas of focus for OSBA and the Kubernetes service catalog.
First, we intend to expand the set of Azure services available in OSBA. We will start by re-enabling services like Azure Cosmos DB and Azure Redis, which were previously available in the preview. Over time, these services will progress to a stable state as we learn how customers intend to use them.
Second, we want to continue working with the community to align the capabilities of the service catalog with the behavior that customers expect. This includes giving the cluster operator the ability to choose which classes/plans are available to developers and eventually to scope that to specific namespaces for even greater control.
Finally, we are committed to a vision for the Kubernetes service catalog and the Open Service Broker API that enables developers to describe general requirements for a service, such as “a MySQL database of version 5.7 or higher” and then have those requirements fulfilled by the most appropriate service instance in a given environment. We have outlined a potential implementation of this vision, known as service catalog templates, and we intend to continue refining it with input from the community and from customers.
Our work on the Kubernetes service catalog and the Open Service Broker API is a great example of how Azure delivers open source solutions to our customers, with much of our investment flowing back upstream to help those in other environments. To be sure, there is a lot more to do here and we look forward to working together to get it done!
We’ll see you on GitHub!
Sean

Sean McKenna

Sean McKenna is a Principal PM in the Azure Cloud Native Compute team where he works on a number of projects related to containers and Kubernetes, including the Azure Kubernetes Service, Azure Container Instances, and the Open Service Broker for Azure. A Microsoft veteran, Sean is loving the new culture at the company and enjoys the opportunity to work across the industry to solve real customer problems. He lives in Seattle with his wife and infant son, where he enjoys exploring the natural beauty of the Pacific Northwest along with its vibrant microbrew scene.

See more articles from this author