Cloud Native

How to Unify Data Service Orchestration Across Kubernetes and Cloud Foundry On-Prem | Julian Fischer, anynines | TFiR

0

Infrastructure teams running both Kubernetes and Cloud Foundry are forced to build and maintain separate integrations for every data service they operate. On-premise deployments add a second layer of complexity: VM-based services live in separate networks from Kubernetes application clusters, and there is no standard mechanism to bridge them. For organizations in Europe, digital sovereignty requirements are pushing more workloads back on-premise, making this problem more urgent, not less.

In this interview on TFiR, Julian Fischer, CEO at anynines, walks through the two core business cases driving adoption of Klutch, the anynines data service orchestration platform, and explains how the a9s Hub for On-Prem and the N9 Network Connector address both the integration and the networking challenges directly.

Guest: Julian Fischer, CEO at anynines
Show: TFiR

Here is what every platform engineer and infrastructure architect running mixed Kubernetes and Cloud Foundry environments needs to know.

Technical Deep Dive

Q: What is Klutch and what problem does it solve for teams running Kubernetes and Cloud Foundry?

Julian Fischer, CEO at anynines, explains that Klutch is a data service orchestration platform designed to eliminate the need for separate integrations when running services across both Kubernetes and Cloud Foundry. At its core, Klutch allows teams to write a single service integration and have that integration exposed automatically in both environments. This directly reduces the duplicated engineering effort that mixed-environment infrastructure teams currently absorb.

“Write one integration for Klutch and get your integration for Kubernetes and Cloud Foundry for free.” — Julian Fischer, CEO, anynines

Q: How does the Klutch service broker work and what does it expose to Cloud Foundry environments?

Fischer describes a Klutch service broker that anynines developed to allow any service integrated with Klutch to be exposed inside a Cloud Foundry environment. Once a service is integrated at the Klutch layer, the service broker handles the Cloud Foundry surface automatically, removing the need for a separate Cloud Foundry-specific integration. The direction, as Fischer puts it, is that a single integration covers both runtimes without additional work.

“We also started to develop a Klutch service broker that allows you to integrate any service that you have integrated with Klutch and expose it in a Cloud Foundry environment of your choice.” — Julian Fischer, CEO, anynines

Q: What is the a9s Hub for On-Prem and who is it designed for?

The a9s Hub for On-Prem is a complete data service orchestration solution built on top of Klutch, targeting organizations that operate in on-premise environments where data privacy and digital sovereignty are non-negotiable requirements. Fischer notes that European organizations in particular are facing direct political pressure to maintain sovereign infrastructure, which is driving renewed investment in on-premise Kubernetes and Cloud Foundry deployments. The solution combines anynines data services for on-demand database provisioning with Klutch to cover both Kubernetes and Cloud Foundry in a single platform.

“If you don’t live under a rock and you are in Europe, you’d know that digital sovereignty became a major political goal these days.” — Julian Fischer, CEO, anynines

Q: What infrastructure does the a9s Hub for On-Prem support and what is the OpenStack and VMware context?

Fischer explains that in current on-premise scenarios, customers typically run either OpenStack or VMware, with a strong tendency toward OpenStack. The a9s Hub for On-Prem is designed to operate on top of these environments, combining the anynines data services layer with Klutch to deliver a complete orchestration stack. This means organizations on OpenStack or VMware do not need to rebuild their existing infrastructure to gain unified Kubernetes and Cloud Foundry data service orchestration.

“In those scenarios, often customers these days have either OpenStack or VMware with a strong tendency towards OpenStack.” — Julian Fischer, CEO, anynines

Q: What is the on-prem networking challenge when exposing VM-based data services to Kubernetes clusters?

Fischer identifies network isolation as the core operational challenge in on-premise deployments: Cloud Foundry, the data service instances (running as virtual machines), and Kubernetes clusters each live in separate networks. There is no native mechanism to expose a VM-based data service into a Kubernetes application cluster’s network without custom work. This forces infrastructure teams to solve a multi-network bridging problem before any data service can be consumed by Kubernetes workloads.

“If you have a Cloud Foundry in your own network, you have the data services with all the service instances in one network and you have your Kubernetes clusters and they have their own networks. How do you expose a data service that is a virtual machine in the Kubernetes network?” — Julian Fischer, CEO, anynines

Q: How does the N9 Network Connector in Klutch solve the VM-to-Kubernetes network exposure problem?

Fischer explains that anynines added the N9 Network Connector inside Klutch to address this specific multi-network problem. The connector uses a network connector interface and provides an implementation that automatically exposes any service integrated with Klutch to the Kubernetes application cluster, regardless of whether that service is running as a virtual machine or a container. The result is seamless consumption of on-premise data services from Kubernetes workloads without manual network configuration per service instance.

“It’s a VM no problem. It’s a container no problem. So it’s basically becoming a full fledged orchestration framework.” — Julian Fischer, CEO, anynines

Q: What are the two major business cases anynines is currently focused on for Klutch?

Fischer confirms that the two primary business cases in current focus are the a9s Hub for On-Prem and the a9s Hub for AWS. Both solutions place Klutch at the core and are being developed in response to direct customer requests to help build production solutions on top of Klutch. The on-prem case targets sovereign, private infrastructure environments, while the AWS case targets cloud-hosted deployments where the same orchestration model applies across managed and self-managed services.

“There are two major business cases that currently are in our focus. One is what we call a9s Hub for On-Prem and the other is a9s Hub for AWS.” — Julian Fischer, CEO, anynines

Resources & Documentation

  • anynines, vendor platform for Klutch, a9s Hub for On-Prem, a9s Hub for AWS, and on-demand data service provisioning
  • OpenStack, open source cloud infrastructure platform referenced as the primary on-premise substrate for a9s Hub for On-Prem deployments

***

👇 Click to Read Full Raw Transcript

Swapnil Bhartiya: That’s fascinating. You mentioned seeing traction for Klutch increasing. Can you walk us through the specific business cases you are focusing on right now?

Julian Fischer: So that’s basically the fundamental learnings. We now see traction for Klutch increasing. And among those organizations we talk to, we also have been asked to help customers build solutions based on Klutch. And there are two major business cases that currently are in our focus. And one is what we call Any Nines Hub for on Prem and the other is Any nine’s hub for aws. So at the core of Any nine’s hub is always Klutch. So it allows you to go and integrate Kubernetes. But we also started to develop a Klutch service broker that allows you to integrate any service that you have integrated with Klutch and expose it in a cloud Foundry environment of your choice. So write one integration for Klutch and get your integration for Kubernetes and Cloud Foundry for free is the direction we’re headed. So in the case of Any nine’s Hub for On Prem, as the name suggests, you are in an on premise scenario. Data privacy is important and I mean, if you don’t live under a rock and you are in Europe, you’d know that digital sovereignty became a major political goal these days. So there’s a higher pressure in maintaining the sovereignty, which also means on premise becomes more important than it used to be. So in those scenarios, often customers these days have either OpenStack or VMware with a strong tendency towards OpenStack. So with such an environment, the combination of the anynines data services for on demand database provisioning and Klutch makes up a complete solution for data service orchestration for both Kubernetes and Cloud Foundry. So that’s a strong business case and it’s something where we see traction. One of the challenges in this case is especially about networking. So if you have a cloud foundry in your own network, you have the data services with all the service instances in one network and you have your Kubernetes clusters and they have their own networks. How do you expose a data service that is a virtual machine in the Kubernetes network? And we have added what we call the N9 network connector in Klutch. It’s using the network connector interface and it provides an implementation where all the services that integrate with Klutch can be exposed to your Kubernetes application cluster seamlessly. So it’s a VM no problem. It’s a container no problem. So it’s basically becoming a full fledged orchestration framework.

Why AI Observability Fails Without Dynamic Data Collection Control | Shahar Azulay, groundcover | TFiR

Previous article