Anwendungsentwicklung mit Kubernetes

Kubernetes gilt weithin als die ideale Plattform für Teams in großen und mittelständischen Unternehmen mit hohen Anforderungen an Hochverfügbarkeit und Autoscaling. Es hat jedoch auch zu Reibungsverlusten in bestehenden Entwickler-Workflows geführt. Diese Veränderung lässt sich als Teil eines breiteren Trends hin zur Einführung des Microservice-Paradigmas und der zunehmenden Komplexität des Softwarebetriebs verstehen. In diesem Artikel untersuchen wir, wie sich das Problem der Softwareentwicklung mit diesem Paradigmenwechsel entwickelt hat.

Dev Loop

Beginnen wir mit dem Konzept des Dev Loop und seiner Rolle in Entwicklungs-Workflows. Der Entwicklungsloop für jedes Softwareprojekt besteht aus zwei separaten Schleifen, die sich über Git überschneiden.

Diese sind –

• Innerer Dev Loop – Dieser Prozess umfasst das Schreiben, Kompilieren und Testen eines Codefragments auf der eigenen Workstation des Entwicklers. Diese Schleife wird so lange fortgesetzt, bis ein zufriedenstellendes Stück Code nach Git übertragen wird.
• Äußerer Dev Loop – Diese Schleife wird ausgelöst, nachdem der Code von der Workstation des Entwicklers nach Git übertragen wurde. Sie umfasst das Ausführen von Tests und das Deployen des Endprodukts. Idealerweise sollte dieser Prozess als kontinuierliche Schleife eingerichtet sein, bei der Deployments mit jedem Code-Push erfolgen, der die Tests besteht.

Diese Schleifen greifen ineinander und bilden einen vollständigen Softwareentwicklungslebenszyklus.

Aufstieg der Microservices

Aufkommen von Microservices hat kleine, unabhängige und lose gekoppelte Softwarekomponenten gebracht, die eine bessere Skalierbarkeit und Zuverlässigkeit bieten. Wir werden die Vorteile hier nicht weiter diskutieren, da sie bereits hinreichend bekannt sind; unsere Bedenken ergeben sich vielmehr aus der daraus resultierenden erhöhten operationalen Komplexität.

Betrachten wir ein einfaches Setup, bei dem frontend den Service api aufruft, welcher wiederum mit zwei weiteren Services namens identity und db kommuniziert. In diesem Szenario arbeitet unser Entwickler auf der Schicht api, die sowohl Downstream- (Frontend) als auch Upstream-Abhängigkeiten (Identity, DB) hat. Lassen Sie uns untersuchen, wie sich der Entwicklungsprozess für den Service api in den zwei verschiedenen Dev Loops verändert  –

Innerer Dev Loop

• Zugriff auf Upstream-Abhängigkeiten – Der Service api muss sowohl mit dem Identity- als auch mit dem DB-Service kommunizieren, um erfolgreich ausgeführt zu werden.
• Zugriff auf Downstream-Abhängigkeiten – Um zu testen, ob die am Service api vorgenommenen Änderungen mit seinen Downstream-Abhängigkeiten kompatibel sind, ist es ebenfalls wichtig, Downstream-Anfragen an diesen Service umzuleiten.

Äußerer Dev Loop

• Upstream-Abhängigkeiten – Damit ein E2E-Test für den Service api ausgeführt werden kann, muss Zugriff auf eine laufende Kopie der Services identity und db bestehen.
• Downstream-Abhängigkeiten – Es muss auch eine Möglichkeit geben, frontend zu Testzwecken den Zugriff auf diesen Service zu ermöglichen.
• Gehosteter Endpunkt – Zusätzlich zu den oben genannten Anforderungen müssen wir diese Kopie des Services api auch hosten, damit sie direkt getestet werden kann.

Das Problem des inneren Dev Loops ist etwas, das Telepresence von Ambassador Labs gelöst hat. Wir haben versucht, das Problem des äußeren Dev Loops auf der TrueFoundry-Plattform durch Intercepts zu lösen.

Einführung von TrueFoundry Intercepts

Das Konzept von TrueFoundry Intercepts funktioniert, indem es die drei im vorherigen Abschnitt beschriebenen Probleme des äußeren Dev Loops löst. Wir verfolgen dabei die folgende Strategie –

• Vorschau-URLs – Über die Plattform selbst ist es einfach, eine Kopie eines bestehenden Services bei einem spezifischen Commit-SHA zu deployen. Dadurch können Sie Vorschau-URLs erstellen, die einem bestimmten Commit oder Pull Request zugewiesen sind.
• Header-basierte Intercepts – Intercepts ermöglichen es einem Service, weiterhin dieselbe URL zu verwenden, während ein zusätzlicher Header hinzugefügt wird, der auf die Vorschaukopie umleitet. Beispielsweise können wir dem Service api einen Intercept hinzufügen, der basierend auf einem übergebenen Header auf eine Vorschaukopie umleitet. Das bedeutet, dass frontend weiterhin mit derselben URL arbeiten kann, indem beim Testen einfach ein zusätzlicher Header übergeben wird.

💡

Um mehr über TrueFoundry Intercepts zu erfahren, konsultieren Sie bitte unsere Dokumentation – https://docs.truefoundry.com/docs/intercepts

Fazit

Wir haben die Veränderungen im Entwicklungsablauf besprochen, die das Aufkommen von Microservices mit sich gebracht hat, und wie wir versuchen, diese zu adressieren. Dies bleibt eine offene Frage, und wir können in der Zukunft noch innovativste Lösungen in diesem Bereich erwarten.

Sprechen Sie mit uns

Wenn Sie den Ertrag Ihrer LLM-Projekte maximieren und Ihr Unternehmen befähigen möchten, KI optimal zu nutzen, würden wir uns freuen, uns mit Ihnen auszutauschen.

Trinken Sie einen ☕️ mit uns

Erfahren Sie, wie TrueFoundry Ihnen hilft, LLMs in 5 Minuten zu deployen:

Deployen und Fine-tunen Sie Open-Source-LLMs mit nur wenigen Klicks!

TrueFoundry bietet eine intuitive Lösung für LLM-Deployment und Fine-Tuning. Mit unserem Model Catalogue können Unternehmen LLMs selbst auf Kubernetes hosten und die Inferenzkosten mit nur einem Klick um das Zehnfache senken. Entdecken Sie in unserem Blog, wie Sie ein Dolly-v2-3b-Modell deployen und ein Pythia-70m mit TrueFoundry fine-tunen.

TrueFoundry Blog Truefoundry