Living in a Multicloud World: Bosh, Kubo and the Open Service Broker API
As cloud-native computing takes off in the enterprise, platforms that enable various flavors of cloud native computing are being refined. So far, each of the platforms that have emerged — including Kubernetes, Mesos, and cloud-native application platforms like Cloud Foundry — are being built with particular use cases in mind.
Some platforms are general purpose but have been designed from a particular architectural perspective. Others are more specific to the use cases they are designed to handle. As an example, Kubernetes is a general purpose container management platform, designed from a very container-specific perspective. Similarly, Apache Mesos is a generalized compute resource management platform, but it’s rooted as a way to manage big data systems, predominantly in the Hadoop and Spark ecosystems, are clear. The Cloud Foundry Elastic Runtime is a bit more specific about its use case. It’s focused on getting from code to running, and operable, applications as quickly as possible.
Being a pragmatist, I’ve never believed in a “one platform to rule them all” mindset. The reality is that enterprises use multiple platforms. They always have, and they always will. In today’s cloud-native world, we need a way to get these multiple platforms to work together.
Over the past few months, several initiatives have launched in parallel that together can make this sort of enterprise nirvana possible, including Kubo and the Open Service Broker API (OSBAPI). And perhaps surprisingly, these new efforts use a tool that has been around for years in the Cloud Foundry ecosystem: BOSH.
Why BOSH Makes Sense for a Multi-Platform World
To put Kubo and OSBAPI in perspective, let’s start with BOSH, a distributed systems engineering tool from the Cloud Foundry ecosystem that simplifies release engineering, deployment, and lifecycle management. BOSH answers the question of what installs the platform that you want to install your software on. BOSH is what provides Cloud Foundry’s multi-cloud capability. It has an abstraction layer that lets you talk to virtually any infrastructure type, whether it’s a public cloud like Amazon or Azure, a private cloud, or virtualization infrastructure — an OpenStack deployment, a vSphere cluster, or bare metal. Most importantly, BOSH is designed to support the deployment’s “day two” needs.
A lot of different software is packaged for BOSH, and it works really well for cloud-native application deployment and lifecycle management. The Cloud Foundry Elastic Runtime uses BOSH as its deployment tool.
Kubo: Bringing Multi-Cloud to Kubernetes
Several large enterprises that have adopted BOSH and Cloud Foundry have been using Kubernetes as well. However, lifecycle management of Kubernetes clusters is emerging as a pain point. Last fall, Google and Pivotal teamed up to create Kubo, an open source project that uses BOSH to manage Kubernetes clusters. BOSH provides a consistent and powerful operations and lifecycle management capability for multiple platforms. Kubo is a great example of how open source projects can work together to make things better for users with complex environments.
Beyond Kubo coming together as a way to ease management of multiple platforms, Kubernetes is also evolving. At KubeCon last month, there was a lot of talk about another effort, the Open Service Broker API, because the Kubernetes community is building its new Kubernetes Service Catalog with OSBAPI.
The Open Service Broker API is a set of abstractions, a way to enable platforms and back end services to work together. For example, it could essentially create a contract between a database-as-a-service and a platform, enabling a platform to request a new database instance and then associate it with an application.
OSBAPI makes quick work of integrating multiple services into a platform. And it frees developers up so they can focus on their application code, rather than on provisioning and binding services. Using Kubo can minimize costs, and can give them single click deployment. You can get the history and background of OSBAPI here.
Rather than thinking about the API as something the cloud controller team decides on, think of it as something you implement in the cloud controller. In this way, all kinds of capabilities can be brought into the multi-cloud environment.
For its part, the Kubernetes Service Catalog can simplify the management of heterogeneous systems even further. Services can exist on any platform, yet you’ll have a unified way to manage container-based workloads, things that are appropriate to push out as containers, or things you want to push as code.
Welcome to the Real World
It’s not about picking a single platform. We’re embracing the reality that enterprises are complex environments, and we are focusing on making even competing systems work well together. We’re not forcing users to make a choice; we’re giving them options.
Each of these efforts adds up to creating better experiences for large IT shops grappling with how to deal with multiple complex systems. By making them all work together, everyone wins.
The Cloud Foundry Foundation is a sponsor of The New Stack.
Feature image by Gianpaolo La Paglia via Unsplash.
