Von Ticket-Infrastruktur zu On-Demand-KI: Wie ayedo eine Kubernetes -basierte Data-Engineering-Plattform für einen Industriekonzern aufgebaut hat

Datengetriebene Innovation scheitert selten an Ideen. Sie scheitert an Infrastruktur.

Viele Industrieunternehmen investieren in Data Science, KI-Modelle und Advanced Analytics – und merken dann, dass ihre Plattform nicht mitwächst. GPU-Ressourcen sind knapp, Entwicklungsumgebungen starr, ETL-Prozesse schwer skalierbar. Jeder neue Anwendungsfall wird zum Infrastrukturprojekt.

In diesem Beitrag zeigen wir anhand eines anonymisierten Projekts, wie ayedo für einen global tätigen Industriekonzern eine Kubernetes-basierte Data-Engineering-Plattform aufgebaut hat – für ETL-Pipelines, Event-Streaming, analytische Datenbanken und GPU-gestützte KI-Workloads.

Der Kunde bleibt anonym. Der Ansatz ist reproduzierbar – insbesondere für Unternehmen, die On-Prem-Stabilität mit Cloud-Flexibilität verbinden möchten.

Ausgangslage: Funktionierende Plattform – aber strukturell ausgebremst

Der Kunde ist ein internationaler Hersteller industrieller Rohstoffe mit rund 10.000 Mitarbeitenden. Etwa 30 Spezialisten arbeiten im Bereich Data Engineering und Advanced Analytics. Ziel ist es, Produktionsprozesse datenbasiert zu optimieren, Energieverbräuche zu senken und KI-Modelle zur Qualitätskontrolle einzusetzen.

Technisch existierte bereits eine hausinterne Orchestrationsplattform auf Basis von HashiCorp Nomad und Docker . Sie funktionierte – aber sie war nicht darauf ausgelegt, dynamisch zu skalieren oder Data-Teams Autonomie zu geben.

Ressourcen mussten über ein zentrales Infrastrukturteam beantragt werden. GPU-Kapazitäten waren knapp und On-Prem-Beschaffung dauerte Monate. Individuelle Entwicklungsumgebungen – etwa angepasste Jupyter-Setups oder spezielle R-Stacks – ließen sich nur mit erheblichem Abstimmungsaufwand realisieren.

Die Folge war nicht nur technische Friktion, sondern organisatorische. Data Engineers warteten auf Infrastruktur, statt Modelle zu trainieren. ETL-Pipelines wurden verzögert produktiv gesetzt. Innovationszyklen verlängerten sich – nicht aus fachlichen Gründen, sondern wegen fehlender Elastizität.

Gerade bei KI-Workloads ist Zeit ein kritischer Faktor. Wenn Trainingsjobs Wochen auf GPU-Ressourcen warten, wird aus datengetriebener Optimierung schnell ein strategischer Engpass.

Der Kern des Problems: Infrastruktur als Gatekeeper

Das eigentliche Problem war nicht Nomad oder Docker. Es war das zugrunde liegende Betriebsmodell.

Infrastruktur war ein zentral gesteuerter Engpass. Ressourcen wurden manuell geplant. Entwicklungsumgebungen waren nicht reproduzierbar containerisiert, sondern teilweise individuell konfiguriert. GPU-Nutzung war an feste Hardware gebunden.

Das führte zu drei strukturellen Schwächen:

Erstens fehlte echte Self-Service-Fähigkeit für Data Teams.
Zweitens war Skalierung linear an physische Ressourcen gebunden.
Drittens war Reproduzierbarkeit über Projekte hinweg nicht systematisch gewährleistet.

Um KI, ETL und BI-Anwendungen nachhaltig zu betreiben, braucht es jedoch eine Plattform, die Compute, Storage und Orchestrierung entkoppelt und deklarativ steuerbar macht.

ayedos Ansatz: Kubernetes als Data-Engineering-Backbone

Gemeinsam mit dem Kunden haben wir die gesamte Data-Orchestration auf Kubernetes migriert – nicht als reines Infrastruktur-Upgrade, sondern als Fundament für eine moderne, hybride Data-Plattform.

Ziel war es, eine Architektur zu schaffen, die folgende Anforderungen erfüllt:

• Self-Service für Data Engineers
• On-Demand-Skalierung von CPU- und GPU-Workloads
• Reproduzierbare Entwicklungsumgebungen
• Integration in bestehende Konzern-Sicherheitsrichtlinien
• Kombination von On-Prem-Stabilität und Cloud-Elastizität

Kubernetes eignet sich für diese Anforderungen besonders gut, weil es Workloads standardisiert kapselt, Ressourcen dynamisch zuweist und sich nahtlos in Hybrid-Cloud-Szenarien integrieren lässt.

Coder: Reproduzierbare Entwicklungsumgebungen on Demand

Ein zentrales Element war die Einführung von Coder auf Kubernetes.

Data Engineers können nun vollständig containerisierte Entwicklungsumgebungen on-demand starten – über Browser, RDP oder VS Code Extension. Jede Umgebung ist versioniert, reproduzierbar und isoliert.

Das löst gleich mehrere Probleme:

Entwicklungsumgebungen sind nicht mehr an individuelle Workstations gebunden.
Konfigurationen sind als Code definiert.
Teams können Setups teilen und standardisieren.

Statt „Bei mir funktioniert es" existiert nun ein konsistenter, containerisierter Arbeitsraum.

Airflow, Kafka und analytische Datenbanken: Skalierbare Datenpipelines

Für die Orchestrierung von ETL-Prozessen wurde Apache Airflow auf Kubernetes etabliert. Airflow-Jobs laufen containerisiert und können horizontal skaliert werden. Rechenintensive Transformationen lassen sich dynamisch auf zusätzliche Worker verteilen.

Apache Kafka dient als Event-Streaming-Backbone für Produktionsdaten aus Werken und Sensorik. Datenströme werden nahezu in Echtzeit ingestiert und in nachgelagerte Systeme verteilt.

Für analytische Workloads wurden TimescaleDB und ClickHouse integriert – optimiert für Zeitreihen- und High-Volume-Analysen. Beide profitieren von Kubernetes-Ressourcenmanagement und skalierbarem Storage.

CEPH als S3-kompatibles Storage-Backend

Die Plattform benötigt nicht nur Compute, sondern auch skalierbares, hochverfügbares Storage für Trainingsdaten, Modelle und Artefakte.

CEPH wurde als S3-kompatibles Backend implementiert. Es kombiniert hohe Verfügbarkeit mit horizontaler Skalierbarkeit und ermöglicht die Trennung von Performance- und Kapazitätsanforderungen.

Damit können große Datenmengen effizient gespeichert und verarbeitet werden – ohne proprietäre Abhängigkeiten.

GPU on Demand: Hybrid Cloud ohne Vendor Lock-In

Einer der größten Engpässe war die GPU-Verfügbarkeit.

Über eine integrierte Cloud-Layer-Architektur können GPU-Ressourcen nun dynamisch bei europäischen Cloud-Providern provisioniert werden. Trainings- und Simulationsjobs werden bei Bedarf in die Cloud ausgelagert, ohne dass die On-Prem-Architektur angepasst werden muss.

Das Entscheidende dabei: Die Workloads bleiben Kubernetes-nativ. Es gibt keine separate „Cloud-Variante". Nur der Standort des Clusters ändert sich.

So entsteht echte Elastizität, ohne Abhängigkeit von einem einzelnen Hyperscaler.

Identity, Security und Compliance

Die gesamte Plattform ist in Azure Entra ID integriert. Single Sign-On und rollenbasierte Zugriffskontrolle sorgen dafür, dass die Data-Plattform konform mit den Sicherheitsrichtlinien des Konzerns bleibt.

Harbor dient als dedizierte Container Registry mit langfristiger Artefakt-Persistierung. Modelle, ETL-Jobs und Container-Images sind versioniert und nachvollziehbar.

Damit wird Reproduzierbarkeit nicht nur technisch, sondern auch regulatorisch abgesichert.

Ergebnis: Data Engineering ohne Infrastruktur-Bremse

Nach der Migration auf Kubernetes hat sich die Arbeitsweise des Data-Engineering-Teams fundamental verändert.

GPU-Compute steht on-demand zur Verfügung. Entwicklungsumgebungen können in Minuten gestartet werden. Neue Projekte benötigen keine wochenlange Abstimmung mit Infrastruktur-Teams.

ETL-Pipelines werden containerisiert orchestriert und sind horizontal skalierbar. Trainingsjobs können flexibel zwischen On-Prem und Cloud verschoben werden.

Vor allem aber ist die Plattform reproduzierbar. Modelle, Pipelines und Umgebungen sind versioniert. Neue Teams können sofort starten, ohne historische Altlasten oder Setup-Probleme.

Was zuvor organisatorischer Engpass war, ist heute strategisches Asset.

Strategischer Mehrwert: Datenplattform als Innovationsmotor

Die neue Plattform ist mehr als ein technisches Upgrade. Sie ermöglicht eine nachhaltige, wirtschaftlich skalierbare Nutzung von KI und Big-Data-Workloads.

Innovationen lassen sich iterativ entwickeln und produktiv setzen – ohne Wartezeiten auf Infrastruktur. GPU-Engpässe blockieren keine Roadmaps mehr. Neue Analyseprojekte können parallel laufen, ohne Ressourcen-Kollisionen.

Kubernetes fungiert dabei als universelle Orchestrierungsschicht für Compute, Storage und Netzwerk – unabhängig vom physischen Standort.

Warum Kubernetes für Data Engineering die richtige Entscheidung ist

Komplexe ETL-Pipelines, BI-Anwendungen und KI-Workloads sind naturgemäß ressourcenintensiv und dynamisch. Starre Infrastrukturmodelle sind dafür nicht ausgelegt.

Kubernetes ermöglicht:

• Elastische Ressourcennutzung
• GPU-Integration als native Ressource
• Reproduzierbare Container-Workloads
• Hybrid-Cloud-Fähigkeit
• Klare Trennung von Plattform und Anwendung

Gerade in Konzernstrukturen schafft das eine Balance aus Governance und Geschwindigkeit.

Call to Action

Wenn euer Data-Engineering-Team durch Infrastruktur-Engpässe ausgebremst wird, GPU-Ressourcen knapp sind oder ETL-Workloads nur mit Ticket-Prozessen skalieren, ist es Zeit für ein neues Plattformmodell.

ayedo unterstützt beim Aufbau Kubernetes-basierter Data-Engineering-Plattformen – mit hybrider GPU-Nutzung, skalierbarem Storage, orchestrierten ETL-Pipelines und reproduzierbaren Entwicklungsumgebungen.

Damit Daten nicht nur gesammelt, sondern strategisch genutzt werden können.