Guest: Julian Fischer (LinkedIn)
Company: anynines
Show Name: KubeStruck
Topic: Kubernetes

The AI infrastructure conversation is dominated by GPU scarcity. Who has access to H100s? How much do they cost? When can you actually get them? But Julian Fischer, CEO & Founder of anynines, is asking a different question: once you have AI workloads running, how do you orchestrate them at enterprise scale? His answer applies anynines’ decade of data service automation expertise to a new domain—wrapping complex AI toolchains, large language models, and vector databases in the same enterprise-grade automation that’s proven effective for traditional data services. This isn’t about competing for scarce GPUs. It’s about making AI infrastructure consumable once those resources exist.

The Core anynines Pattern: Complex Open Source Plus Enterprise Automation

Fischer frames anynines’ approach with clarity: “We look for sufficiently complex, distributed, open source projects, and then add and wrap it in automation to make it consumable by the enterprise.” This formula has worked for databases, message queues, and caching layers. Now Fischer sees the same pattern applying to AI infrastructure.

The key insight is that AI workloads aren’t fundamentally different from other complex distributed systems. Large language models require orchestration, monitoring, scaling, and operational management—the same capabilities enterprises need for any stateful workload. Vector databases need provisioning, backup, replication, and access control. These are problems anynines already solves for traditional data services.

What changes in the AI context isn’t the orchestration challenge itself, but the specific technologies being orchestrated. Instead of wrapping PostgreSQL or Redis, anynines would wrap LLM runtimes and vector database engines. The automation patterns—on-demand provisioning, lifecycle management, integration with developer workflows—remain the same.

a9s model: On-Demand LLM Provisioning as a Service

Fischer reveals that anynines has “conducted research on having a product called a9s model that gives you the tooling around on-demand provisioning LLMs.” This isn’t a product announcement, but it signals strategic direction. anynines is exploring how to apply their proven orchestration approach to large language model deployment.

On-demand LLM provisioning addresses a real enterprise pain point. Organizations want to experiment with different models—open source alternatives to GPT-4, domain-specific fine-tuned models, smaller models optimized for specific tasks. But standing up LLM infrastructure is non-trivial. Models are large, require specific hardware configurations, have complex dependency chains, and need careful resource management.

If a9s model follows the same pattern as their data service offerings, it would provide self-service LLM provisioning for developers. Application teams could declare “I need access to Llama 3 70B” and have the infrastructure automatically provisioned, just as they currently declare “I need a PostgreSQL database” in Cloud Foundry or Kubernetes. The underlying complexity—model downloads, GPU allocation, runtime configuration, API endpoints—would be abstracted away.

Fischer’s caveat is telling: “If there’s clients who want that, we’re going to build it.” anynines doesn’t build speculative products. They build solutions driven by customer demand. The mention of a9s model suggests they’re hearing this demand from existing clients who are starting to run AI workloads alongside traditional applications.

Vector Databases: The Natural Extension of Data Service Automation

Beyond LLMs themselves, Fischer points to vector databases as another AI-adjacent opportunity: “You also have, in the context of AI, the demand for other databases, like vector databases, so that could also be a thing.” This is a more obvious fit for anynines’ existing capabilities.

Vector databases like Pinecone, Weaviate, Milvus, and Qdrant have become essential infrastructure for AI applications. They store embeddings generated by language models and enable semantic search, recommendation systems, and retrieval-augmented generation workflows. As enterprises adopt AI, vector databases are becoming as essential as traditional relational databases.

For anynines, adding vector database automation is a straightforward extension of existing data service capabilities. The orchestration patterns are identical: on-demand provisioning, automated backups, scaling based on load, integration with application workflows. The only difference is the specific database technology being wrapped.

This matters because vector databases are still relatively immature compared to traditional databases. Operational best practices are still emerging. Enterprises need help managing these systems at scale. anynines’ approach—taking complex distributed systems and making them enterprise-consumable—is exactly what the vector database market needs.

AI Workloads on Cloud Foundry and Kubernetes: Bridging Traditional and Modern Platforms

Fischer’s comments also acknowledge that AI workloads are already running on Cloud Foundry. This challenges the assumption that AI requires cutting-edge Kubernetes infrastructure. Cloud Foundry, long positioned as a platform for traditional web applications, is adapting to handle AI workloads too.

This creates interesting opportunities for anynines. Organizations with existing Cloud Foundry deployments don’t want to spin up entirely separate infrastructure for AI experimentation. They want to use existing platforms and operational patterns. If anynines can provide AI orchestration capabilities that work across both Cloud Foundry and Kubernetes—just as Klutch does for data services—it simplifies AI adoption for enterprises with hybrid platform strategies.

The broader point is that AI infrastructure doesn’t exist in isolation. Enterprises aren’t abandoning their existing platforms to chase AI trends. They’re looking for ways to integrate AI capabilities into existing application delivery workflows. This is where anynines’ cross-platform approach becomes valuable—AI workloads need to coexist with traditional applications, not replace them.

The Pragmatic AI Infrastructure Strategy: Automation Over Hardware Acquisition

What’s refreshing about Fischer’s framing is the focus on orchestration rather than hardware acquisition. The tech industry conversation around AI is overwhelmingly focused on access to GPUs—who has them, how much they cost, when supply will improve. Fischer doesn’t dismiss this reality, but he’s focused on what happens once organizations have GPU resources.

The implicit argument is that GPU scarcity is temporary. Supply will eventually catch up with demand, prices will stabilize, and enterprises will have access to the compute resources they need. When that happens, the bottleneck shifts from hardware availability to operational capability. Organizations that can efficiently orchestrate AI workloads, provision models on-demand, and integrate AI capabilities into existing applications will have competitive advantage.

anynines is positioning to solve that second-order problem. They’re not trying to become a GPU cloud provider. They’re applying their proven expertise in data service automation to the AI domain. This is a more defensible strategy than competing in the hardware layer, where margins are thin and competition is fierce.

Client-Driven Development: Building What Enterprises Actually Need

Fischer’s repeated emphasis on client demand—”if there’s clients who want that, we’re going to build it”—reveals anynines’ product development philosophy. They don’t chase hype. They build solutions for problems their customers are actively experiencing.

This approach has kept anynines focused on operationally mature, production-proven technologies rather than chasing every emerging trend. It also means their AI strategy will be grounded in real enterprise needs rather than speculative use cases. If anynines builds LLM provisioning capabilities, it will be because existing customers are struggling to operationalize language models in production environments.

For potential customers evaluating AI infrastructure vendors, this client-driven approach is reassuring. It suggests anynines won’t abandon products or pivot strategies based on market trends. They’ll continue supporting and evolving capabilities as long as customers need them.

The Future of AI Infrastructure: Orchestration as the Differentiator

Fischer’s perspective points toward a future where AI infrastructure differentiation comes from orchestration capabilities, not just raw compute access. Every cloud provider will eventually have GPUs available. Every platform will support containerized AI workloads. The competitive advantage will belong to organizations that can operationalize AI efficiently—provision models quickly, integrate them into applications seamlessly, and manage them reliably at scale.

anynines is positioning to be the orchestration layer for that future. By applying proven data service automation patterns to AI workloads, they’re creating a bridge between traditional enterprise platforms and modern AI infrastructure. Organizations don’t have to choose between their existing Cloud Foundry investments and emerging AI capabilities—anynines makes both work together.

For platform engineering teams navigating AI adoption, Fischer’s message is pragmatic: focus on orchestration, not just hardware. GPUs are necessary but not sufficient. What you do with them—how efficiently you provision models, how seamlessly you integrate AI into applications, how reliably you operate at scale—determines whether AI delivers business value or just creates operational complexity.