By Guest: Julian Fischer (LinkedIn)
Company: anynines
Show Name: KubeStruck
Topic: Kubernetes
Should platform teams still be writing service brokers in 2026? For organizations running both Cloud Foundry and Kubernetes, the answer is increasingly no—but the path forward isn’t obvious. Julian Fischer, CEO & Founder of anynines, cuts through the noise with a stark question: how do you maintain two developer platforms without doubling your operational burden? His solution, a9s Hub with Klutch integration, eliminates redundant service broker development while preserving Cloud Foundry investments during Kubernetes transitions.
📹 Going on record for 2026? We're recording the TFiR Prediction Series through mid-February. If you have a bold take on where AI Infrastructure, Cloud Native, or Enterprise IT is heading—we want to hear it. [Reserve your slot
The Dual-Platform Dilemma: Cloud Foundry Meets Kubernetes Reality
Cloud Foundry isn’t disappearing overnight. Fischer observes that many enterprises have “at least one toe in the Kubernetes waters,” but they’re also seeing committed teams continuing to run production workloads on Cloud Foundry. The challenge isn’t choosing between platforms—it’s managing both without operational chaos.
Historically, exposing a new data service in Cloud Foundry meant writing a custom service broker. But in 2026, with Kubernetes increasingly handling new workloads, does that approach still make sense? Fischer’s answer is unequivocal: “Would you start writing service brokers in 2026?” The implication is clear—platform teams need a bridge, not more bespoke integration code.
Klutch: The Service Broker Integration That Works Across Platforms
anynines’ answer is Klutch, an orchestration framework that Fischer describes as solving the “data service orchestration problem for both Cloud Foundry and Kubernetes.” The key innovation is a Klutch service broker that acts as a universal adapter: any service with Klutch integration automatically becomes available in Cloud Foundry’s marketplace—no new broker code required.
This isn’t theoretical architecture. Fischer positions Klutch as infrastructure that “takes care of the Cloud Foundry community” by reducing the cost of maintaining dual experiences. For platform engineering teams, this means one integration effort exposes services across both environments, dramatically reducing the maintenance tax of hybrid deployments.
a9s Hub: The Umbrella for Data Service Orchestration
When Fischer talks about a9s Hub, he’s describing an integrated stack, not a single product. The hub contains:
- Klutch: The orchestration framework and service broker integration
- anynines Data Services (ADAS): Originally VM-based workloads provisioned via BOSH director, now transitioning to Kubernetes workloads that still perform on-demand VM provisioning
- CF app stage: A replacement for Stratus UI, built on Cloud Foundry’s v3 API for managing applications
- Backstage plugins: Unified UI components, with ADAS dashboards and Klutch functionality reimplemented as backstage integrations
The entire control plane can now run as a Kubernetes workload, giving teams flexibility in how they deploy the infrastructure. Fischer emphasizes that licensing is straightforward: “Get a license from us, you can basically use all the products that are within a9s Hub.”
Why This Matters for Platform Engineering in 2026
The Cloud Foundry-to-Kubernetes migration isn’t a binary switch—it’s a multi-year transition where both platforms must coexist. Fischer’s framing reveals the hidden cost of this reality: platform teams can’t afford to build and maintain parallel toolchains. Every new data service shouldn’t require separate integration efforts for each platform.
a9s Hub addresses this by creating a single source of truth for data service orchestration. Whether a service runs as a VM workload, a Kubernetes pod, or a managed cloud service, Klutch provides the abstraction layer that makes it accessible to developers on either platform. For organizations stuck managing dual environments, this consolidation directly reduces operational overhead.
The shift to Kubernetes isn’t about abandoning Cloud Foundry overnight—it’s about managing the transition intelligently. Fischer’s approach acknowledges that Cloud Foundry has “well-committed clients” who aren’t moving immediately, while also recognizing that “there’s a vivid dynamic about Kubernetes adoption.” Platform teams need tooling that respects both realities.
The Bigger Picture: Data Services as the Migration Bottleneck
Fischer’s focus on data service orchestration highlights a critical but often overlooked migration challenge. Application deployments might shift to Kubernetes relatively quickly, but stateful workloads—databases, message queues, caches—are far more complex to move. Organizations need a strategy that allows applications to migrate incrementally while maintaining consistent access to data services regardless of which platform they run on.
This is where Klutch’s architecture becomes essential. By separating the data service control plane from application clusters, anynines enables a phased migration where applications can move to Kubernetes while still consuming services originally provisioned for Cloud Foundry. The abstraction layer means developers don’t need to change how they declare dependencies—they just describe what they need, and Klutch handles the orchestration complexity.
For platform engineering teams, this translates to reduced cognitive load. Instead of managing separate service catalogs, broker implementations, and access patterns for each platform, they maintain one integration point. As Fischer notes, the Klutch service broker means “any service that has a Klutch integration can be also exposed in Cloud Foundry without having to write another service broker.”
