How to Add Software Packaged as Helm Charts & Kubernetes Operators to Your Pivotal Platform

“Within DevOps platform teams, the platform manager serves as the primary designer and decision maker for shared self-service platforms.” 

(Source: Gartner, How to Scale DevOps by Building Platform Teams; 8 April 2019; Daniel Betts, George Spafford)

In large enterprises today, platform teams have a lot on their plate. One of these tasks: curating and managing a service catalog. Here, the team offers up a portfolio of add-on services for developers to use with their apps. As you can imagine, developers often request new databases, more caching options, API gateways, and so on.

For these requests, platform teams often evaluate options. Then they select a solution that solves the business problem at hand, ideally while keeping operational complexity to a minimum.

The Pivotal Marketplace includes a carefully curated catalog of best-of-breed services from a variety of vendors. These services are continuously tested to ensure capability with Pivotal Platform. This Marketplace continues to grow, offering more options year after year. But invariably, developers will request a service that’s not listed in the Marketplace. When there’s a valid request, platform teams were stuck.

Now, platform teams have a way to expand their service catalog, while keeping operational complexity low: Container Services Manager (KSM) for Pivotal Platform—now in beta.

Introducing Container Services Manager (KSM) for Pivotal Platform

The big idea behind Container Services Manager (KSM) for Pivotal Platform is simple. It aims to give platform teams an easy, scalable way to bring software packaged for Kubernetes to their foundations.

With KSM, you can open up your marketplace to every service that can be deployed via Helm to a Kubernetes cluster, including charts that deploy Kubernetes Operators. Best of all, KSM exposes the software using the same “as a service” cf marketplace experience you know and love today. Those can be services from Pivotal, other commercial software vendors, or even teams within your organization.

An Inside Look at KSM

KSM makes it easy to expand the list of available, on-demand services for your developers. In addition, KSM allows teams to expose their own services available to the organization. For example, an operations team who wants custom metrics from running production application instances can develop a custom tool, then use KSM to embed this service in every application instance. In this scenario, the team would enjoy a uniform monitoring system across the entire Pivotal Platform.

A conceptual architecture diagram of the primary features of KSM

De-couple Your Platform Automation from Your Services

KSM also opens up more convenient workflows for platform teams. Here’s how.

KSM is a broker for Kubernetes services. These services run on a distinct pool of infrastructure, separate from the Pivotal Platform foundation. This means that, much like the public cloud service broker tiles for AWS, Azure, and GCP, you can decouple the management of your platform foundations from the management of the services running on KSM. Consequently, you can perform platform upgrades and management without as much consideration for the status of these individual services.

KSM Delivers Consistency Where You Need It

It’s important that KSM integrate with your current workflows. Plans can be configured with KSM, so you can control the compute resources used by an individual backing service bound to an application. With BOSH tiles, plans are configured within Operations Manager; they complement Quotas to govern the consumption of backing services. With KSM, plans are configured within each Helm chart.

The value gained by both the platform team and application developers (not to mention other internal service developers) is substantial. The operations team uses KSM to deploy the service onto Kubernetes, then expose it within the cf marketplace. When new services are created, KSM spins up new service instances, configuring the Kubernetes namespaces, and handling all of the keys and various permissions required to bind the application to the service through CredHub.

Using KSM: A Developer’s Point of View

“Self-service capabilities decouple the development teams’ output with that of the platform team.” 
(Source: Gartner, Strengthen Your DevOps Capability With Platform Ops; 26 October 2018, Richard Watson, Gary Olliffe)

For the application developer, the KSM experience remains the same. A database made available through a BOSH tile, or via KSM, is created and bound to an application using the same cf create-service and cf bind-service commands they are using today. 

Bring Kubernetes-Packaged Software to Pivotal Platform Now!

The most successful platform teams obsess over developer happiness. Does that mean saying “yes” to every request? Of course not; you have to be realistic about what you can support at scale.

KSM lets you have it both ways by removes barriers for offering a wide variety of backing services on the Pivotal Platform for your apps. Use to broker multiple Kubernetes services to the Pivotal Platform. So let’s get started!

Check out the overview section of the docs. Then, download the beta and give it a try!

About the Author

Tony Vetter

Tony Vetter is Associate Technical Product Marketing Manager at Pivotal.

More Content by Tony Vetter
Previous
“Make the Easy Thing and the Right Thing, The Same Thing.”  Day 2 at SpringOne Platform 2019
“Make the Easy Thing and the Right Thing, The Same Thing.” Day 2 at SpringOne Platform 2019

Next
Unleashing Human Potential: Day 1 at SpringOne Platform 2019
Unleashing Human Potential: Day 1 at SpringOne Platform 2019

SpringOne Platform 2019 Presentations

Watch Now