Von Bare Metal zu Google Cloud Kubernetes

Hinweis: Unsere Kundeninstanzen laufen weiterhin On-Premise bzw. in einer Virtual Private Cloud. In diesem Artikel geht es um den Umzug der internen Test- und Demoumgebung von weyer data engineering in die Google Cloud. 

Es ist Freitag, 18 Uhr. Die meisten starten in den Feierabend, wir drücken auf „Enter“ und starten damit eine Migration, die wir seit über einem Monat vorbereitet haben. 

Was als ambitionierter Plan begann, ist jetzt Realität: Unsere AITEZA Demo- und Testinstanz läuft vollständig in der Google Cloud, orchestriert mit Kubernetes, deployed über Helm Charts und kontinuierlich ausgerollt via GitOps mit FluxCD. Hier ist die Geschichte, wie wir dorthin gekommen sind und was wir dabei gelernt haben. 

Jede erfolgreiche Migration beginnt lange bevor der erste Container in der neuen Umgebung startet. Bei uns begann sie vor über einem Monat, als ich die komplette Zielinfrastruktur in der Google Cloud aufgebaut habe. Von Anfang an war klar: Wir machen keine Kompromisse bei der Reproduzierbarkeit. Jede Komponente, vom Ingress Controller über die Datenbanken bis hin zu unseren Application Services, wurde mit eigenen Helm Charts abgebildet. 

Warum Helm? Weil wir ein Deployment wollen, das sich in einem einzigen Befehl ausrollen lässt. Kein manuelles Konfigurieren, kein „funktioniert auf meiner Maschine“. Jeder Wert, jede Konfiguration, jedes Secret ist versioniert, parametrisiert und über Values-Files steuerbar. Das klingt nach Mehraufwand im ersten Moment, aber es zahlt sich exakt in dem Moment aus, in dem man unter Zeitdruck deployen muss. Und dieser Moment kommt immer. 

Parallel dazu haben wir FluxCD als GitOps-Engine aufgesetzt. Das Prinzip ist simpel und gleichzeitig mächtig: Der gewünschte Zustand unserer Infrastruktur wird in Git definiert. FluxCD überwacht das Repository und reconciled das Cluster automatisch gegen den definierten State. Ein git push ist unser Deployment-Trigger, kein manuelles kubectl apply, keine fehleranfälligen Skripte. Das Repository ist die Single Source of Truth. 

Was folgte, war ein intensiver Monat des Testens. Das gesamte Team hat die neue Infrastruktur auf Herz und Nieren geprüft. Load Tests, Failover-Szenarien, Netzwerk-Policies, RBAC-Konfigurationen, Health Checks und Readiness Probes. Nichts wurde dem Zufall überlassen. 

Wir haben systematisch geprüft, ob die einzelnen Services unter Last korrekt skalieren und der Horizontal Pod Autoscaler wie erwartet reagiert. Ob die Daten Pod-Neustarts und Node-Ausfälle überleben. Ob die Services korrekt isoliert sind, die Network Policies greifen und der Ingress sauber mit TLS-Terminierung konfiguriert ist. Ob unser Monitoring und Alerting uns Probleme zeigt, bevor unsere Nutzer sie bemerken. Und ob wir im Ernstfall aus Backups wiederherstellen können und wie lange das dauert. 

Erst als wir das Vertrauen hatten, dass die neue Umgebung produktionsreif ist, haben wir den Migrationstermin festgelegt. 

Der erste große Schritt war die Migration unserer Embedding-Daten. Für ein Information-Retrieval-System wie AITEZA sind Embeddings das Herzstück. Sie bestimmen, wie präzise und relevant die Suchergebnisse sind. 

Bisher hatten wir unsere Embeddings auf einem dedizierten GPU-Server selbst gehostet: Das funktionierte, aber es band uns an eigene Hardware, erforderte GPU-Management und war nicht elastisch skalierbar. Im Zuge der Migration haben wir uns entschieden, auf ein State-of-the-Art Embedding Model bei einem externen Provider umzusteigen. Bessere Qualität, weniger operativer Overhead. 

Die Herausforderung: Alle existierenden Dokumente mussten mit dem neuen Modell vollständig neu embedded werden. Bei der Menge an Daten, die wir verarbeiten, ist das kein trivialer Batch-Job. Embedding-Provider haben Rate Limits und Quotas, und wer die ignoriert, steht schnell mit 429 Too Many Requests da. 

Deshalb haben wir ein eigenes Migration-Tool entwickelt, das die Re-Embedding-Jobs intelligent steuert. Es respektiert die Quotas des Providers, verteilt die Requests gleichmäßig über die verfügbaren Zeitfenster und nutzt exponentielles Backoff bei Throttling. Das Tool lief den gesamten Freitagabend und die Nacht durch, und am Samstagmorgen waren alle Embeddings im neuen Format bereit. 

Samstagmorgen, frischer Kaffee, klarer Kopf. Der Plan stand fest, die Runbooks waren geschrieben. Jetzt ging es um Ausführung. 

Zuerst die finalen Backups. Bevor irgendetwas migriert wird, haben wir vollständige Backups aller produktiven Daten erstellt. Datenbanken, Konfigurationen, User-Daten, alles gesichert und verifiziert. Ein Backup, das man nicht getestet hat, ist kein Backup. 

Dann die S3-Synchronisation. Unsere Object-Storage-Daten mussten aus den bestehenden S3 Buckets in die Google Cloud übertragen werden. Mit parallelen Transfer-Threads haben wir die Daten synchronisiert und anschließend Checksummen verglichen, um die Integrität sicherzustellen. 

Danach die letzte Validierung. Smoke Tests gegen die neue Umgebung. Funktioniert die Authentifizierung? Liefert die API korrekte Ergebnisse mit dem neuen Embedding-Provider? Stimmen die Antwortzeiten? Alles grün. 

Und dann der Moment der Wahrheit: der DNS-Cutover. Wir haben die DNS-Einträge auf die neue IP-Adresse des Google Cloud Load Balancers umgestellt. Dank niedriger TTL-Werte propagierte die Änderung schnell. Innerhalb weniger Minuten zeigten die ersten Requests auf die neue Infrastruktur. 

Dann hieß es: Monitoring beobachten. Logs prüfen. Metriken checken. Alles stabil. Migration abgeschlossen. 

Ein Kubernetes-Cluster ist nur so gut wie die Architektur, die darin läuft. Deshalb will ich kurz zeigen, wie unser Setup aufgebaut ist. 

Das Herzstück bilden das Backend und Frontend von AITEZA als eigenständige Helm Deployments. Das Backend stellt die API für das gesamte Information-Retrieval-System bereit, das Frontend liefert die Benutzeroberfläche aus. Beide sind unabhängig voneinander skalierbar und über den Ingress sauber nach außen exponiert. 

Was für uns ein echter Gamechanger ist: Das AITEZA Backend läuft jetzt mit mehreren Replicas gleichzeitig, also mehrfach redundant. Fällt ein Pod aus, übernehmen die anderen nahtlos. Und wenn wir ein neues Release deployen, passiert das als Rolling Update: Kubernetes fährt die neuen Pods schrittweise hoch und nimmt die alten erst vom Cluster, wenn die neuen bereit sind. Für unsere Nutzer bedeutet das: Zero Downtime bei Updates. Kein Wartungsfenster, kein „bitte kurz warten“. Auf dem alten Bare-Metal-Setup brauchte jedes Deployment ein Wartungsfenster. AITEZA musste für ein paar Minuten offline gehen, während wir die neue Version ausrollten. Das ist jetzt Geschichte. 

Für die Anwendungsdaten setzen wir auf PostgreSQL in einer Hochverfügbarkeitskonfiguration mit PgPool-II als vorgeschaltetem Connection Pooler und Load Balancer. PgPool verteilt Leseanfragen auf die verfügbaren Read Replicas und routet Schreiboperationen an den Primary, transparent für die Applikation. Das Ergebnis: bessere Performance unter Last und Ausfallsicherheit, ohne dass das Backend wissen muss, mit welchem Datenbankknoten es gerade spricht. 

Das ist übrigens keine exotische Herangehensweise. ChatGPT setzt mit seinen über 600 Millionen Nutzern auf exakt dieselbe Architektur: PostgreSQL mit PgBouncer als Connection Pooler und mehreren Read Replicas, um die massive Leselast zu verteilen. Wenn es für eine der meistgenutzten Anwendungen der Welt gut genug ist, sind wir damit in guter Gesellschaft. 

Daneben laufen im Cluster noch eine Reihe weiterer Services, die das Gesamtsystem abrunden. LiteLLM als einheitliches Gateway vor verschiedenen LLM-Providern gibt uns die Flexibilität, Modelle und Anbieter zu wechseln, ohne Anwendungscode anzufassen. Apache Tika zusammen mit IBM Docling extrahieren Text aus Dokumenten aller Art, bevor sie embedded und durchsuchbar gemacht werden. FluxCD mit seinen vier Controllern bildet das Rückgrat unserer automatisierten Deployment-Pipeline, bei der ein git push der einzige manuelle Schritt ist. Und für Secrets setzen wir auf den External Secrets Operator, sodass sensible Daten niemals in einem Git-Repository landen. Der sichere Zugriff auf den Cluster selbst läuft über Teleport mit zertifikatsbasierten, kurzlebigen Tokens und vollständigem Audit-Log. Zero Trust in der Praxis. 

Wenn ich das Vorher und Nachher vergleiche, fühlt sich das wie ein Generationensprung an. 

Kubernetes auf GKE gibt uns Container-Orchestrierung mit automatischem Scaling, Self-Healing und Rolling Updates. Kein manuelles Server-Management mehr. Helm Charts für jede Komponente machen Deployments deklarativ, wiederholbar und versioniert. Ein neues Environment? Ein helm install entfernt. FluxCD als GitOps-Pipeline bedeutet, dass jedes Deployment nachvollziehbar ist. Wer hat was wann geändert? Git Log fragen. Rollback nötig? git revert und FluxCD erledigt den Rest. Managed Embedding Services statt selbst gehosteter GPU-Infrastruktur reduzieren den operativen Aufwand drastisch und geben uns Zugang zu den neuesten Modellen ohne eigene Hardware-Investitionen. Und das AITEZA Backend mit mehreren Replicas und Rolling Updates bedeutet, dass wir jetzt deployen können, wann immer wir wollen, ohne dass ein einziger Nutzer etwas davon merkt. 

Jede Migration lehrt einem etwas. Hier unsere wichtigsten Takeaways. 

Vorbereitung schlägt Geschwindigkeit. Der eigentliche Umzug am Samstag war fast unspektakulär, und genau so soll es sein. Die wirkliche Arbeit steckte im Monat davor: Infrastruktur aufsetzen, Charts schreiben, testen, iterieren. 

Tooling lohnt sich. Das eigene Batching-Tool für die Embeddings-Migration hat uns Stunden manueller Arbeit und potenzielles Quota-Chaos erspart. Invest in gutes Tooling zahlt sich immer aus. 

GitOps von Anfang an. FluxCD bereits in der Testphase einzusetzen hat dafür gesorgt, dass das Deployment-Modell schon erprobt war, bevor es produktiv wurde. 

Das hier war der erste Schritt. Die Demo- und Testinstanz läuft stabil in der Cloud, und wir sammeln jetzt Erfahrungen im laufenden Betrieb. Als nächstes stehen die Optimierung des Autoscalings, der Ausbau unserer CI/CD-Pipeline und die weitere Härtung der Sicherheitsarchitektur auf dem Plan. 

Eines ist sicher: Der Umzug in die Cloud ist kein Projekt mit einem Enddatum. Es ist der Beginn einer kontinuierlichen Verbesserung. Und genau das macht es spannend. 

Für unsere Kunden ändert sich an der Wahlfreiheit nichts. AITEZA lässt sich weiterhin genau dort deployen, wo es für das jeweilige Unternehmen am meisten Sinn ergibt, ob On-Premise im eigenen Rechenzentrum, auf einem klassischen VPS oder in der Cloud bei einem Anbieter der Wahl. Diese Flexibilität ist uns wichtig und bleibt ein Kernversprechen unseres Produkts. Was wir mit diesem Cloud-Setup gewinnen, ist vor allem eines: ein stabiles, produktionsnahes Environment, in dem wir AITEZA unter realen Bedingungen betreiben und Erfahrungen sammeln können, die direkt in unsere Enterprise-Deployments einfließen. Denn je besser wir unsere eigene Plattform im Betrieb verstehen, desto besser können wir unsere Kunden bei ihren individuellen Deployment-Szenarien unterstützen.

Vereinbaren Sie hier direkt einen Termin, um AITEZA persönlich zu testen und sich von den Vorteilen zu überzeugen: