VMware Tanzu Service Manager Brings Services Running Atop Kubernetes To CF Marketplace

It’s now easier than ever to bring backing services running on Kubernetes to apps running on VMware Tanzu Application Service.

VMware Tanzu Service Manager, now generally available, brings the cf marketplace lifecycle commands to services—such as databases, message queues, or caches—packaged for Kubernetes. You can download Tanzu Service Manager via the Tanzu Network. (Be sure to sign up for a deep-dive webinar scheduled to run October 14 to learn more.)

Partner with aster.cloud
for your next big idea.
Let us know here.

Empower your developers to use backing services atop Kubernetes with familiar commands

For an application to do anything interesting, you need to bind services to it. Enterprise development teams running on Tanzu Application Service have used the Open Service Broker API and cf-marketplace to do just that. This pattern works well for everyone. Developers get fast, self-service access to a catalog of helpful services. Platform teams can control what’s run on the platform, and enable consistent security and day-to-day operations at scale.

But what about services that run atop Kubernetes? Many enterprises want to expose these to developers for use with custom apps. This is the scenario Tanzu Service Manager aims to address.

Tanzu Service Manager is a service broker that exposes a service wrapped in a Helm chart within the cf marketplace. Operators can now choose from the plethora of services available within the Kubernetes ecosystem, and offer these services to developers already onboarded to and familiar with Tanzu Application Service.

Tanzu Service Manager enables services like databases and caches running atop Kubernetes to be offered via the cf marketplace on your Tanzu Application Service

Why should you be excited about Tanzu Service Manager? Our beta users cited the following reasons:

Decoupled lifecycle management for service and the app platform – Tanzu Service Manager allows for services to be deployed on separate infrastructure from the Tanzu Application Service. This offers more flexibility in how you manage your platform, and can allow dedicated teams to manage services.

Expose popular services in your custom applications – Cloud native applications often depend on services like Kafka, MySQL, or MinIO. Tanzu Service Manager allows operators to create a marketplace service from any software title. You just need a Helm chart and production Kubernetes clusters!

Add internal services to your marketplace – You probably have homegrown services in your enterprise. For example, a large bank might write a custom service that enables any app within the bank to connect to a payment network. Now you can connect these services with apps running on Tanzu Application Service. Just package them up with Helm and add them to your cf marketplace.

Optimize infrastructure cost with a familiar tool: service plans – Service plans are a great way to make efficient use of infrastructure at scale. Using Tanzu Service Manager, you can add multiple plans to your services.

A consistent developer experience – We’ve kept the APIs consistent. That means commands such as “cf marketplace” and “cf create-service” stay in place with Tanzu Service Manager. From the developer’s point of view, the only thing that’s new is a larger catalog of services!

A role-based look at how Tanzu Service Manager works

Tanzu Service Manager serves the needs of three types of users: service authors, platform operators, and application developers.

A service author is a team or individual that authors a service and packages a service in Helm. A service in this context is any integration that an application developer could use. This could include backing services such as databases, messaging services, or other custom service types. Services could be products like VMware Tanzu RabbitMQ, open source products like PostgreSQL, services developed in-house, or those offered via a marketplace such as Tanzu Application Catalog. In order to make a service work with Tanzu Service Manager, the service author must wrap their service in Helm. Two quick notes:

Tanzu Service Manager supports deployment of services that might be packaged across multiple Helm charts. This feature provides service authors with flexibility in offering services where packaging or deploying order is important.
Air-gapped environments are supported; a private registry can be configured, and images are tagged and pushed to that registry.

Users interacting with Tanzu Service Manager

Next, we shift our attention to the platform operator (or service administrator). This team or individual is responsible for delivering a secure, scalable platform experience to developers. Platform operators can review catalogs such as Tanzu Application Catalog and add a service that their application developers require. The operator could configure service plans, metadata, and deployment configurations before offering the service in the “cf marketplace.” Platform operators will want to keep the following things in mind:

Service plans can be used to adapt service functionality or define how infrastructure resource constraints act on a service. For example, service plans for RabbitMQ could be used to toggle persistence, or plans could limit CPU or memory resources for a different service.
Service metadata and service plan definitions live outside the service’s Helm chart. This allows for an easier upgrade experience, and also enables the use of this same Helm chart in other contexts.
The operator can choose the cluster where a service gets deployed. Tenancy, resource consumption, and other service-specific requirements may influence the use of a dedicated cluster for a given service offering or plan.
After an operator has configured everything, they can enable service access. Any application developer with access to a given org and space can start to see the service offering in their marketplace.

For the application developer, the experience remains unchanged. Developers continue to use the same commands and have the same self-service experience. They discover services through the “cf marketplace” command, as has always been the case with Tanzu Application Service. They use existing native commands such as “cf create-service” and “cf bind-service” to create instances and bind apps. From the developer’s perspective, the use of Tanzu Service Manager is completely transparent!

Behind the scenes, the Open Service Broker API notifies Service Manager of requests.
Service Manager deploys the service to a VMware Tanzu Kubernetes Grid (or any other Kubernetes) cluster via the packaged Helm chart.
Any services and secrets created by the Helm chart are passed back to the developer’s apps.