In the rapidly evolving world of container orchestration, the transition from Cloud Foundry to Kubernetes has presented both opportunities and challenges for enterprise developers. A recent episode of KubeStruck revealed how one company transformed their Cloud Foundry expertise into a Kubernetes-native solution that addresses contemporary data service management challenges.

anynines CEO Julian Fischer recently shared insights into how his company’s deep Cloud Foundry experience led to the creation of Klutch, an open-source platform designed to bring proven service abstractions to the Kubernetes ecosystem. The story begins with a fundamental understanding of what made Cloud Foundry successful in enterprise environments.

“Cloud Foundry, when it comes to building large scale developer platforms, is still a very unique technology,” Fischer explained. The platform’s strength lies in its ability to manage thousands of applications within a single environment while maintaining an exceptional developer experience. However, the real challenge emerges when considering that these applications typically require an equal number of data services.

Cloud Foundry addressed this through the Open Service Broker API standard, introducing crucial abstractions like service instances and service bindings. These concepts allow developers to provision databases and grant application access to data services on-demand, without human intervention. This self-service model empowers developers with operational responsibility for their entire application ecosystem.

The transition to Kubernetes, however, revealed a gap. While Cloud Foundry provides a centralized cloud controller and standardized service broker API, Kubernetes environments are typically distributed across multiple clusters, creating additional complexity layers for data service management.

This realization sparked the development of Klutch. Rather than limiting their data service automation to Cloud Foundry, anynines recognized that Kubernetes environments faced similar challenges, particularly in large-scale deployments requiring systematic data service management for security compliance.

Klutch emerged as a Kubernetes-native solution that translates Cloud Foundry’s proven abstractions into the container orchestration platform that has become the industry standard. The platform addresses the broader challenge faced by organizations managing multiple Kubernetes clusters while needing systematic data service management.

By open sourcing Klutch, anynines aims to give back to the community that supported their growth, providing a valuable solution to contemporary infrastructure challenges that extend far beyond their original data services offering.

Transcript

Swapnil Bhartiya (0:00): Since your roots are also in Cloud Foundry—and Cloud Foundry is all about developer experience, you know, CF push and all those things—can you talk about the origin of Klutch? Where did the foundational blocks come from, and what problem were you looking to solve? Because, as I said, the Cloud Foundry experience helps a lot.

Julian Fischer (0:22): Cloud Foundry, when it comes to building large-scale developer platforms, is still a very unique technology. We run environments where there are thousands, if not tens of thousands, of apps operating within a single environment. The developer experience has always been Cloud Foundry’s strong suit—and still is.

So, if you ask the question, “What does that actually mean?”—one side of the equation is about deploying applications and running them in containers. But the other side is: if you have a thousand apps, they’ll likely require somewhere between 1,000 and 2,000 data services. So, where do those come from?

Cloud Foundry answers that by providing a standard for creating cloud services—the Open Service Broker API—which introduces abstractions. For example, a service instance and a service binding. That answers questions like: How do you provision a database? By creating a service instance. And how do you grant a particular application access to a data service instance? By creating a service binding. We extend that to include backup and restore.

But if you think about the real goal when building an application developer platform, it’s to give developers the means to provision services on-demand—so they can deploy and run their apps independently, without involving other humans—while also taking on full operational responsibility for their applications and the services they use. That was addressed to some extent in Cloud Foundry, but not in Kubernetes.

Coming back to your question: Klutch evolved from the idea behind the anynines data services—the automation, the declarative automation—for up to ten different data services that could be provisioned on demand from Cloud Foundry. So we asked ourselves: Why are we limiting this offering to Cloud Foundry, when the same problem exists in the Kubernetes ecosystem?

Especially in large environments, having a unified database automation layer that works across different infrastructures—including on-prem—is something we saw potential in. So we thought: How would you expose the anynines data services in Kubernetes?

That’s when we realized the same data service challenge exists in Kubernetes, but it’s slightly more complex. You can’t map a single Cloud Foundry environment to a single Kubernetes cluster. That means you’re likely dealing with multiple—if not many—Kubernetes clusters. And then, in the absence of a central cloud controller and the Open Service Broker API, you have to solve the challenge of exposing data services systematically.

We took the valuable lessons and abstractions from Cloud Foundry and translated them into Kubernetes-native technology. That’s the core idea behind Klutch.

In other words, Klutch started from the idea of expanding anynines data services to Kubernetes. But we quickly realized the problem is much broader. Any organization using many Kubernetes clusters and needing systematic data service management—especially for things like security compliance—faces this challenge.

We also came to understand that Klutch isn’t just an adapter for anynines services; it addresses a much wider audience. And so, we felt it was important to make it publicly available. After benefiting so much from open source, we wanted to give back something meaningful to the community—something that solves a real, modern-day problem.