Anwendungsentwicklung mit Kubernetes

Kubernetes gilt weithin als ideale Plattform für Teams in großen und mittleren Unternehmen mit hohen Verfügbarkeits- und Autoscaling-Anforderungen. Es hat jedoch auch zu Reibungsverlusten in bestehenden Entwickler-Workflows geführt. Diese Änderung kann als Teil eines umfassenderen Vorstoßes zur Einführung des Mikroservice-Paradigmas und der zunehmenden Komplexität der Art und Weise, wie Software ausgeführt wird, verstanden werden. In diesem Artikel werden wir untersuchen, wie sich das Problem der Softwareentwicklung mit diesem Paradigmenwechsel entwickelt hat.

Entwicklerschleife

Beginnen wir mit dem Konzept einer Entwicklungsschleife und ihrer Rolle in Entwicklungsworkflows. Die Entwicklungsschleife für jedes Softwareprojekt besteht aus zwei separaten Schleifen, die sich in Git überschneiden.

Das sind -

• Innere Entwicklungsschleife — Der Prozess beinhaltet das Schreiben, Kompilieren und Testen eines Codeabschnittes auf der eigenen Workstation eines Entwicklers. Diese Schleife wird fortgesetzt, bis ein zufriedenstellender Teil des Codes nach Git verschoben wurde.
• Äußere Entwicklungsschleife — Diese Schleife wird ausgelöst, nachdem der Code von der Workstation des Entwicklers nach Git verschoben wurde. Es beinhaltet das Ausführen von Tests und die Bereitstellung des Endprodukts. Idealerweise sollte dieser Prozess als kontinuierliche Schleife eingerichtet werden, in der Bereitstellungen bei jedem Code-Push erfolgen, der die Tests besteht.

Diese Schleifen fließen ineinander und bilden einen vollständigen Softwareentwicklungszyklus.

Der Aufstieg des Mikrodienstes

Das Aufkommen von Mikrodiensten hat kleine, unabhängige und lose gekoppelte Softwarekomponenten hervorgebracht, die eine bessere Skalierbarkeit und Zuverlässigkeit bieten. Wir werden an dieser Stelle nicht auf die Vorteile eingehen, da sie sehr gut bekannt gemacht wurden, aber unsere Bedenken ergeben sich aus der daraus resultierenden erhöhten betrieblichen Komplexität.

Betrachten wir ein einfaches Setup, bei dem Frontend ruft die api, das wiederum mit zwei anderen Diensten kommuniziert, die Identität und dB. In diesem Szenario arbeitet unser Entwickler an der api Ebene, die sowohl Downstream- (Frontend) als auch Upstream-Abhängigkeiten (Identity, db) hat. Lassen Sie uns untersuchen, wie der Entwicklungsprozess für die api Serviceänderungen in den beiden verschiedenen Entwicklungsschleifen -

Innere Entwicklungsschleife

• Zugriff auf Upstream-Abhängigkeiten - api Der Dienst muss sowohl mit Identity- als auch mit DB-Diensten kommunizieren, um erfolgreich ausgeführt zu werden.
• Zugriff auf Downstream-Abhängigkeiten — Um zu testen, ob die Änderungen an der api Der Dienst ist mit seinen Downstream-Abhängigkeiten kompatibel. Es ist auch wichtig, Downstream-Anfragen an diesen Dienst umzuleiten.

Äußere Entwicklungsschleife

• Upstream-Abhängigkeiten - Damit ein e2e-Test für den ausgeführt werden kann api Dienst, es muss Zugriff auf eine laufende Kopie von geben Identität und dB Dienstleistungen
• Downstream-Abhängigkeiten - Es besteht auch ein Bedarf an einer Möglichkeit, die Frontend um zu Testzwecken auf diesen Dienst zuzugreifen.
• Gehosteter Endpunkt — Zusätzlich zu den oben genannten Anforderungen müssen wir auch diese Kopie des hosten api Service, damit er direkt getestet werden kann

Das innere Dev-Loop-Problem ist etwas, das Telepräsenz von Botschafter Labs hat für gelöst. Wir haben versucht, das Outer Dev Loop-Problem auf dem zu lösen TrueFoundry-Plattform von Fängt ab.

Wir stellen vor: TrueFoundry Intercepts

Das Konzept von TrueFoundry Intercepts funktioniert, indem es die drei Probleme des äußeren Entwicklungsschleifens löst, die in den vorherigen Abschnitten beschrieben wurden. Wir verfolgen die folgende Strategie, um dieses Problem anzugehen -

• URL-Vorschau — Mithilfe der Plattform selbst ist es einfach, eine Kopie eines vorhandenen Dienstes an einem bestimmten Commit-SHA bereitzustellen. Auf diese Weise können Sie Vorschau-URLs erstellen, die einer bestimmten Commit- oder Pull-Anfrage gewidmet sind.
• Header-basierte Intercepts — Mithilfe von Intercepts kann ein Dienst weiterhin dieselbe URL verwenden und gleichzeitig einen zusätzlichen Header hinzufügen, der zur Vorschaukopie umleitet. Zum Beispiel können wir einen Intercept an das anhängen api Dienst, der basierend auf einem Header, der an sie übergeben wird, zu einer Vorschaukopie umleitet. Das bedeutet Frontend kann weiterhin mit derselben URL arbeiten, indem Sie beim Testen einfach einen zusätzlichen Header übergeben.

💡

Weitere Informationen zu TrueFoundry-Intercepts finden Sie in unseren Dokumenten - https://docs.truefoundry.com/docs/intercepts

Fazit

Wir haben die Veränderungen im Entwicklungsablauf erörtert, die durch das Aufkommen von Microservices verursacht wurden, und darüber, wie wir versuchen, ihnen zu begegnen. Dies bleibt eine offene Frage, und wir können in Zukunft mit noch innovativeren Lösungen in diesem Bereich rechnen.

Chatte mit uns

Wenn Sie die Rendite Ihrer LLM-Projekte maximieren und Ihr Unternehmen in die Lage versetzen möchten, KI richtig zu nutzen, würden wir uns freuen, mit Ihnen zu chatten und Notizen auszutauschen.

Hab ein ☕️ bei uns

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

Deploy and Fine-tune Open Source LLMs With a Few Clicks!

TrueFoundry offers an intuitive solution for LLM deployment and fine-tuning. With our Model Catalogue, companies can self-host LLMs on Kubernetes, reducing inference costs by 10x in just one click. Discover how to deploy a Dolly-v2-3b model and fine-tune a Pythia-70m using TrueFoundry in our blog.

TrueFoundry Blog Truefoundry