Plattformlos: Wie Choreo eine sichere Kubernetes-Plattform mit GitOps aufbaute

Eine Open-Source-basierte interne Entwicklerplattform (IDP), die auf Kubernetes und GitOps aufbaut und von über 20 CNCF-Tools unterstützt wird – sicher, skalierbar und entwicklerfreundlich.

Hinweis: Entdecken Sie, wie Choreo eine vollständig Open-Source-basierte, plattformlose interne Entwicklerplattform (IDP) mit über 20 Cloud Native-Tools wie Argo, Flux CD, Cilium, Envoy, Kyverno und mehr aufgebaut hat. Ein tiefer Einblick in das, was hinter den Kulissen passiert, mit Humor und Einfühlungsvermögen.

Wenn Sie auf der KubeCon EU 2025 sind, sollten Sie unbedingt am Choreo-Stand S703 vorbeischauen! Ich kann nur sagen: Wenn Sie sich für IDP interessieren, es lohnt sich!

Einführung: Kubernetes ist großartig… bis es das nicht mehr ist

Seien wir ehrlich. Jeder liebt die Idee von Kubernetes. Automatische Skalierung, Selbstheilung, alles deklarativ – was kann man daran nicht lieben?

Nun… bis Ihr Team versucht, es tatsächlich auszuführen. Dann kommen die YAML-Spaghettis, CVE-gefüllte Docker-Images und der eine „temporäre“ Workaround in der Produktion, der irgendwie drei Winter überlebt hat. Plötzlich fühlt sich die coole Container-Orchestrierungsschicht eher wie ein Zweitjob an.

Das ist der Moment, in dem viele Unternehmen anfangen, von plattformlosen Lösungen zu träumen – bei denen Entwickler einfach nur Code einfügen und die Magie passiert. Und auf der KubeCon SLC 2024 habe ich ein verstecktes Juwel entdeckt, das diesen Traum vielleicht endlich wahr werden lässt: Choreo, von WSO2.

Doch bevor wir uns mit der Funktionsweise befassen, sollten wir darüber sprechen, was plattformlos wirklich bedeutet.

Plattformlos: Mythos oder moderne Magie?

Das Versprechen der Plattformlosigkeit ist verführerisch:
👉 „Einfach Entwickler einstellen. Keine Infra. No ops. Keine Kopfschmerzen.“

Wenn Sie Plattformen wie Heroku kennen, wissen Sie, wie man sich das vorstellt: Entwickler geben einen Push zu Git, und schon ist die App live. Aber lassen Sie uns die Realität auspacken.

Die Illusion 🍄:

• Keine Infra-Teams
• Keine DevOps
• Kein YAML
• Nur Funktionen, die ausgeliefert werden

So sieht es in einer Broschüre eines Anbieters aus:

Die Realität 🤯:

Selbst in einem „plattformlosen“ Setup betreibt jemand die Infra. Sie sind es nur nicht – es ist Ihr Provider (wie Heroku oder in diesem Fall Choreo). Das bedeutet, dass Sie immer noch für die Infrastruktur bezahlen – nur eben in Form einer monatlichen Rechnung.

Und für regulierte Umgebungen kann Heroku schnell zu einem No-Go werden:

• Keine stabilen ausgehenden IPs
• Keine VPN-Unterstützung
• Keine Kontrolle über das Netzwerk
• Eingeschränkte Konformitätsgarantien (z. B. ISO 27001, BSI C5 Typ II, EU Cloud Code of Conduct usw.)

Die Realität sieht anders aus: Natürlich gibt es immer noch eine Plattform und ein Infrastrukturteam – es wird nur vom Anbieter oder einem Hyperscaler wie AWS, Azure oder GCP bereitgestellt.
Sie zahlen immer noch dafür durch Lizenzen und Nutzung. Und das ist völlig in Ordnung – aber seien wir ehrlich, das ist nicht wirklich plattformlos.

Diese Lösungen sind immer noch gültig – sie hätten sich sonst nicht durchgesetzt. Aber mein Ingenieurherz kämpft mit einigen von ihnen, insbesondere mit Heroku.

Um ehrlich zu sein: Heroku ist ein großartiges Produkt.
Aber aus der Sicht des Endbenutzers ist es eine so geschlossene Blackbox, dass ich es nicht nur langweilig, sondern auch für 99 % meiner europäischen Kunden ungeeignet finde – vor allem aus rechtlichen Gründen und wegen der begrenzten Kontrolle über die Netzwerkintegration.

Was also, wenn Sie das Heroku-Erlebnis wollen, aber mit Kontrolle auf Kubernetes-Niveau und Compliance auf Unternehmensniveau? Dann bekommen Sie Choreo! Ich werde später erklären, wie es sich von Heroku mit privaten Dataplanes unterscheidet.

Choreo eingeben: Das verborgene Juwel, das Sie kennen sollten

Zuerst hätte ich Choreo fast übersehen. Nur ein weiteres SaaS, dachte ich. Bis ich einen Blick unter die Haube warf – und etwas ziemlich Wildes fand.

Choreo ist eine vollständig auf Open-Source basierende interne Entwicklerplattform (IDP), die vollständig auf 20+ CNCF-Tools aufbaut, mit einer Kubernetes-nativen Denkweise. Wir reden hier von:

• Argo Workflows für CI/CD
• Buildpacks.io für die Erstellung von Container-Images
• Harbor für die Container-Registrierung
• Cilium + eBPF + Envoy für Netzwerke und Sicherheit
• Kyverno für Richtlinien
• KEDA für die automatische Skalierung
• Flux CD für GitOps
• Prometheus, Thanos, OpenSearch… für Beobachtbarkeit
• und mehr…!

Und das Beste daran? Es verpackt all dies in eine saubere Benutzeroberfläche, die sowohl den Entwicklern als auch den Plattformingenieuren Spaß macht.

Es ist nur ein Stein – bis Sie ein großartiges Team mit einer großartigen Vision haben. Fügen Sie den richtigen Druck hinzu, und es wird ein Diamant… oder zumindest ein verborgenes Juwel.

Damals, im November 2024 auf der KubeCon in SLC, war ich zwar beeindruckt von der Eleganz von Choreo, hatte aber dennoch meine Zweifel. Damals war es nur als SaaS verfügbar, und die Botschaft lautete: „Sie brauchen kein Plattformteam.“
Das hat mich wirklich beunruhigt. Nicht etwa, weil ich mir Sorgen um meinen Job mache (das tue ich nicht), sondern weil die meisten Entwickler, mit denen ich zusammenarbeite, sich einfach nicht um Sicherheit, Compliance, FinOps … Sie wissen schon, all die „lustigen“ Unternehmensbelange kümmern.

Aber die Dinge haben sich geändert – auf eine gute Art und Weise.
Das SaaS-Angebot von Choreo umfasst jetzt eine spezielle Ansicht für Plattform- und DevOps-Teams, die es ermöglicht, richtige Self-Service-Portale zu erstellen. Und es wird noch besser…

Ich hatte die Ehre, an der WSO2CON2025 in Barcelona teilzunehmen, an einer „Birds of a Feather“-Sitzung teilzunehmen und einen Blick hinter die Kulissen zu werfen, was als Nächstes ansteht.

Aber bevor wir dazu kommen, möchte ich Ihnen zeigen, warum ich diese Plattform für so elegant halte.

Schmerzen beim Entwickler: Sicherheit beginnt (und scheitert) bei der Entwicklung

Seien wir ehrlich – bei fast jedem Projekt, an dem ich teilgenommen habe, war die anfängliche Sicherheitslage nicht besonders gut.

Nicht, weil die Leute unvorsichtig waren, sondern weil von den Entwicklern verlangt wird, alles zu tun – und die Containersicherheit ist immer noch ein bewegliches Ziel.

Veraltete Abhängigkeiten, aufgeblähte Images, unsichere Basisschichten, kein SBOM, keine Signierung – und jeder streitet immer noch darüber, was „Best Practice“ wirklich bedeutet. Sind es mehrstufige Builds? Distroless? UBI? Signierte Registrierungen?

Und ganz ehrlich? Die meisten Entwickler, die ich kenne, wollen nur eine Sache:
👉 Goldene Pfade und Leitplanken, damit sie sich auf die Auslieferung von Funktionen, die Behebung von Fehlern und die Einhaltung von Sprint-Zielen konzentrieren können – und nicht auf YAML-Kämpfe und Compliance-Kaninchenlöcher.

Stellen Sie sich eine Welt vor, in der ein Entwickler seinen Code überträgt und die Plattform sich um alles andere kümmert:

• Build-Pipelines laufen automatisch
• Tests und CVE-Scans werden ausgeführt
• Ein Best-Practice-Container-Image wird erstellt
• Es wird an eine Registry übertragen

Keine Dockerdateien, keine komplexen CI-Setups, kein Herumspielen mit kubectl.

Das ist genau das, was Choreo tut. Code pushen → einen sicheren, produktionsbereiten Container erhalten.

Aber Moment, da ist ja auch noch YAML… Natürlich ist ein Container allein nicht genug. Um ihn tatsächlich bereitzustellen, braucht man Manifeste:

Selbst eine „einfache“ Webanwendung benötigt mehr als 6 Kubernetes-Objekte, die unter Berücksichtigung von Sicherheit, Skalierbarkeit und Compliance konfiguriert werden.

Stellen Sie sich vor, dass Entwickler all dies definieren müssen (SecurityContext, Ressourcen, horizontale Pod-Autoskalierung usw.) und gleichzeitig Geschäftslogik schreiben. Nein danke.

Genau hier glänzt Choreo. Mit Choreo können Entwickler nur den Workflow definieren: wie sich die Anwendung durch die Umgebungen bewegen soll (Entwicklung → QA → Produktion).

Die Plattform kümmert sich um den Rest – von der Erstellung von Manifesten bis zur Durchsetzung von Richtlinien und der Bereitstellung.

Das beinhaltet:

• Sichere Voreinstellungen (RBAC, mTLS usw.)
• Netzwerksicherheit mit Cilium
• GitOps-basierte Bereitstellungen
• Isolierung über Namespaces
• und mehr…

Mit anderen Worten: Die Entwickler konzentrieren sich auf das Schreiben des Codes, während die Plattform dafür sorgt, dass Konformität, Sicherheit und Zuverlässigkeit von vornherein fest eingeplant sind.
Schön – die Anwendung wird bereitgestellt. Aber jetzt wird es erst richtig interessant.

Denn die Wahrheit ist: Selbst verwaltetes Kubernetes ist nicht standardmäßig sicher.
Standardmäßig gibt es in der Regel keine Netzwerkrichtlinien, kein geeignetes RBAC, kein mTLS zwischen den Diensten und definitiv keine Richtlinien-Engine wie Kyverno zur Durchsetzung von Best Practices und Branchenkonformität.

Irgendjemand muss sich um all das kümmern – idealerweise ohne die Erfahrung der Entwickler zu ruinieren. Und das ist nicht einfach, insbesondere in einem Modell mit geteilter Verantwortung.

Das ist der Punkt, an dem mir klar wurde:
Choreo automatisiert Kubernetes nicht nur – es macht es standardmäßig sicher, selbst in Modellen mit geteilter Verantwortung.

Nächster Punkt: Werfen wir endlich einen Blick unter die Haube und sehen, was Choreo wirklich kann.

Was ist eigentlich eine Choreo?

Choreo von WSO2 ist eine vollständig verwaltete, unternehmenstaugliche interne Entwicklerplattform (IDP), die darauf ausgelegt ist, sowohl die Softwarebereitstellung als auch die Entwicklung zu rationalisieren – mit einem starken Fokus auf Sicherheit, Entwicklererfahrung und bewährten Methoden.

Sie kombiniert zwei wichtige Welten:

• Software-Bereitstellung: Erstellen, Bereitstellen, Ausführen und Verwalten von Anwendungen in großem Umfang.
• Software-Entwicklung: Handhabung von APIs, modularen Diensten, Beobachtbarkeit und Wiederverwendung – alles bereits integriert.

Choreo ist vollständig auf Cloud Native Open-Source-Tools aus der CNCF-Landschaft aufgebaut. Diese Komponenten wurden sorgfältig ausgewählt, um eine vollständige, produktionsreife Plattform mit minimaler Komplexität zu liefern.

Einige der wichtigsten Werkzeuge sind:

• Argo Workflows
• Flux CD
• Harbor
• KEDA
• Cilium + eBPF
• Envoy
• Kyverno
• Prometheus / Thanos
• und mehr..

Zusammen bilden sie das Rückgrat von Choreos meinungsstarker, standardmäßig sicherer IDP.

Das nächste Diagramm zeigt die gesamte Architektur von Choreo – von CI/CD bis hin zu mandantenfähigen Kubernetes-Clustern.

Ja, es sieht kompliziert aus. Aber wenn man es in seine Einzelteile zerlegt, ergibt es tatsächlich eine Menge Sinn. Aber lassen Sie uns die Architektur in zwei Teile aufteilen.

Auf der linken Seite des Diagramms sehen Sie die Perspektive des Entwicklers – wie zuvor abstrahiert.

Was hier auffällt, ist, dass die Pipeline auf Argo Workflows läuft, was sie unabhängig von einem bestimmten Git-Anbieter wie GitHub oder GitLab macht.
Das heißt, Ihr Quellcode befindet sich immer noch in Ihren eigenen Repositories – ob das nun GitHub, GitLab oder ein anderes unterstütztes System ist.

Auf der linken Seite sehen wir auch die Seite für die Entwickler:

• Git-Push löst einen Build über Argo-Workflows aus
• Container werden mit Buildpacks gebaut
• Images werden an eine Harbor-Registry übertragen

Wenn man sich die rechte Seite des Diagramms ansieht, mag das Ganze zunächst etwas überwältigend erscheinen. Aber wenn Sie sich auf die wichtigsten Komponenten konzentrieren, ergibt alles einen Sinn.

Sie können sehen, dass Flux CD verwendet wird, um Choreo-Komponenten direkt auf Kubernetes zu installieren.
Zusätzliche Komponenten wie Cilium, Prometheus, Redis und andere werden mit Argo CD bereitgestellt – zumindest soweit ich das System verstanden habe.

Was dieses Setup so elegant macht, ist die Tatsache, dass es standardmäßig eine Cloud-native Microservices-Architektur verwendet, die speziell für Kubernetes entwickelt wurde – mit eingebauter Sicherheit, Beobachtbarkeit, Skalierbarkeit und Isolierung.

Wenn ein Benutzer ein Projekt und eine Phase in der Choreo erstellt, wird dies einem dedizierten Namespace in Kubernetes zugeordnet, der auch als „Zelle“ bezeichnet wird.

Alle Workloads, die in dieser Zelle eingesetzt werden, sind vollständig vom Rest isoliert.

Wenn Sie eine Kommunikation zwischen verschiedenen Projekten oder Zellen wünschen, müssen Sie explizit eine API bereitstellen. Diese Freigabe erfolgt über Cilium, eBPF und Envoy, wobei in der Regel das Routing über ein Egress Gateway erfolgt – zum Beispiel, um das Internet zu erreichen.

Kubernetes kann DNS-basierte Regeln wie iits-consulting.de für Egress Policies nicht ohne Weiteres verarbeiten – aber dank eBPF (über Cilium) ist das kein Hindernis mehr.

Für die interne Kommunikation (von einer Zelle zur anderen) wird der Datenverkehr über ein internes API-Gateway geleitet, wobei Netzwerkrichtlinien den Zugang streng regeln.

Und hier kommt der spannende Teil:
Dieses Setup ermöglicht mTLS zwischen Diensten (falls erforderlich), identitätsbewusste Kommunikation und Token-Validierung direkt am API-Gateway – alles direkt einsatzbereit. Sie können sogar einzelnen Diensten eindeutige Identitäten zuweisen und diese während des Token-Austauschs verifizieren. Es ist leistungsstark, flexibel und sicher.

Zusammengefasst: Mit Choreo erhalten Sie eine moderne, sichere Kubernetes-Plattform, die:

• Ein Zero-Trust-Netzwerkmodell umsetzt (standardmäßig ist alles verweigert)
• Dynamisches Skalieren über KEDA unterstützt
• Sichere API-Verwaltung bereitstellt (z. B. über das WSO2-Gateway – falls erforderlich)
• Logs, Metriken und Events zentralisiert
• GitOps für alle Deployments verwendet
• Und eine strikte Isolation zwischen Projekten gewährleistet

Ich gebe zu – am Anfang fiel es mir schwer, die Architektur zu verstehen. Alles wirkt so API-gesteuert, und ständig hört man Begriffe wie Northbound, Southbound oder East-West-Traffic – alles gängige Konzepte in integrationslastigen Architekturen, wie sie beispielsweise von WSO2 verwendet werden.

Aber sobald Sie das nächste Diagramm sehen, beginnt es, Sinn zu ergeben.

Legende:

• North-South: Entwickler → Control Plane (z. B. Code pushen, Deployments auslösen)
• Southbound: Control Plane → Data Plane (Workloads in Cloud-Umgebungen bereitstellen)
• East-West: API ↔ INT ↔ UI (Dienste kommunizieren innerhalb derselben Umgebung)
• Northbound: Data Plane → Control Plane (Logs, Metriken und Statusmeldungen senden)

Um zu verstehen, warum WSO2 Choreo so aufgebaut hat, wie sie es getan haben, hilft ein Blick auf ihre Wurzeln.

WSO2 ist ein Open-Source-Technologieunternehmen, das seit vielen Jahren besteht – bekannt vor allem für leistungsstarke Middleware-Lösungen in den Bereichen API-Management, Integration sowie Identitäts- und Zugriffsmanagement (CIAM).
Ihre Plattformen haben Unternehmen dabei unterstützt, digitale Services sicher, skalierbar und cloud-nativ bereitzustellen – lange bevor diese Begriffe zu Branchen-Buzzwords wurden.

Es ist also absolut nachvollziehbar, dass sich Choreo von Grund auf API-gesteuert und sicherheitsorientiert anfühlt.
Das ist kein Zufall – es ist Teil ihrer DNA.

Kommen wir nun zu einer praktischen Demo.

Demo – Praxisnahe Arbeit mit Choreo (SaaS)

Wenn Sie unter https://console.choreo.dev ein Konto erstellen, erhalten Sie Zugriff auf fünf kostenlose Komponenten – mehr als genug, um zu experimentieren oder sogar eine kleine Anwendung zu hosten.

Sobald Sie sich in der Benutzeroberfläche befinden, können Sie Ihre Organisation und Ihr Projekt einrichten – das entspricht direkt der internen Struktur von Choreo.

Im oberen Bereich der Oberfläche wird stets die SaaS-Lösung als Control Plane dargestellt (Choreo Concepts), darunter befindet sich die Data Plane, die das Kubernetes-Cluster repräsentiert. Es sieht so aus, als würde Choreo den Azure Kubernetes Service (AKS) für die Workloads verwenden – zumindest macht es diesen Eindruck.

1. Erster Schritt: Erstellen Sie eine Organisation und ein Projekt.

Standardmäßig werden zwei Stages erstellt: Development und Production.

2. Nun erstellen Sie eine Komponente (Deployment) innerhalb der Choreo-Konsole.

Was passiert in Kubernetes in dieser Phase?

Ganz genau – im Cluster selbst passiert zu diesem Zeitpunkt noch nichts. In diesem Schritt verknüpfen Sie die Komponente mit einem GitHub-Repository. Um es einfach zu halten, habe ich für die Demonstration ein Beispiel-Repository verwendet.

Aber im Hintergrund geschieht bereits etwas. Ein Git-Repository wird initialisiert – vermutlich mit Argo Workflows – und eine Container-Registry wird im Hintergrund eingerichtet. Wo genau das läuft, lässt sich schwer sagen, aber sehr wahrscheinlich befindet sich das Ganze in der von Choreo verwalteten Control Plane.

Das bedeutet, dass verschiedene Verbindungen hergestellt werden. Argo Workflows verbindet sich mit dem GitHub-Repository, und Sie können das Auto-Build bei jedem Commit aktivieren.

Dies entspricht dem zuvor gezeigten CI/CD-Workflow:

Nun versucht Choreo, wie im Diagramm gezeigt, die Anwendung mit buildpacks.io zu erstellen. Es werden auch Sicherheitsprüfungen durchgeführt. Wenn kritische Sicherheitslücken (CVEs) gefunden werden, schlägt der Build fehl. So sieht das aus:

Sie können sehen, dass ich eine ältere Version von next verwendet habe. Also habe ich das mit npm audit fix behoben und erneut gepusht. Das Ergebnis:

Jetzt erscheint ein Deploy-Button, der es Ihnen ermöglicht, den standardmäßigen Deployment-Flow zu starten:

Was passiert wahrscheinlich im Hintergrund

Wenn Sie sich an den vorherigen Workflow erinnern, passiert wahrscheinlich Folgendes innerhalb der Choreo-Control-Plane:

1. Ein Container-Image wird erstellt und mit einem Tag versehen.
2. Kubernetes-Manifeste werden erstellt.
3. Diese Manifeste werden mithilfe von Argo Workflows in den entsprechenden Namespace bereitgestellt.

Ich glaube, hier wird Argo Workflows und nicht Argo CD verwendet. Der Grund: Ich sehe keine GitOps-ähnliche Verbindung zwischen den generierten Manifeste und einem Git-Repository. Wenn Argo CD verwendet würde, müssten die Manifeste wahrscheinlich auch in einem Repository gespeichert werden. Ich könnte mich irren, aber das ist meine Interpretation.

Wenn dieser Flow vollständig mit Auto-Build bei Commit und Auto-Deploy implementiert wäre, würde der Workflow folgendermaßen aussehen:

Was passiert in der Control- und Data-Plane (vereinfachte Ansicht):

Choreo erstellt eine Cell, die die Komponente enthält (in diesem Fall eine einfache Web-App – eine To-Do-Liste). In Kubernetes werden verschiedene Tools im Hintergrund verwendet, wie zum Beispiel:

• Netzwerk-Policies
• Integration mit dem API-Gateway, um North-South-Traffic zu ermöglichen

Zu diesem Zeitpunkt ist die Komponente noch recht einfach und verarbeitet nur den eingehenden Traffic. Aber es wird interessanter, wenn Sie:

• Mehrere Komponenten in dieselbe Cell hinzufügen oder mehrere Projekte einfügen und die Kommunikation zwischen ihnen ermöglichen

Dies bringt uns näher zum nächsten Diagramm:

Wenn Sie genau hinsehen, werden Sie in der Choreo-Konsole unter Deployments auch feststellen, dass KEDA verwendet wird.

Es gibt noch viel mehr, was Sie mit dieser SaaS-Plattform tun können. Kürzlich hat Choreo Integrationen für Platform Engineering und SRE hinzugefügt. Diese Funktionen ermöglichen es Ihnen, nicht nur Self-Service-Funktionen zu definieren, sondern auch Compliance-Regeln, Governance-Politiken, Workflows und mehr.

Wie ich zu Beginn erwähnt habe: Entwickler einzustellen, reicht nicht aus. Es muss auch jemand Verantwortung dafür übernehmen, Unternehmensstandards, Sicherheit und betriebliche Best Practices durchzusetzen.

Ich habe zu Beginn auch gesagt, dass es meiner Meinung nach besser als Heroku in Bezug auf Flexibilität ist, und hier ist der Grund:

So können Sie sich mehr auf Folgendes konzentrieren, indem Sie die Choreo-Konsole verwenden und die Workloads auf Ihrer privaten Data Plane ausführen und dabei von folgenden Vorteilen profitieren:

• Strengeren SLAs
• Mehr Flexibilität und Kontrolle
• Compliance
• Zusätzlichen Sicherheitsrichtlinien und -tools

Aber der spannende Teil kommt noch…

OpenChoreo: Der beste Teil? Es wird Open Source!

Ja, Sie haben richtig gelesen – Choreo wird unter OpenChoreo Open Source.

OpenChoreo ist eine vollständig Open-Source Internal Developer Platform (IDP), die sowohl für Platform Engineers als auch für Entwickler konzipiert ist.

Außerdem hilft es Ihnen, das „IDP-Dilemma“ zu lösen.

Die meisten Organisationen stoßen auf dasselbe Problem, wenn sie eine Internal Developer Platform in Betracht ziehen:

Option 1:

🔧 Bauen Sie Ihre eigene Lösung – Sie haben die Kontrolle, aber es kostet Zeit, Talent und kontinuierliche Wartung.

Option 2:

📦 Kaufen Sie eine SaaS-Lösung – leichter zu übernehmen, aber oft mit begrenzter Anpassungsmöglichkeit und möglichem Vendor-Lock-in.

OpenChoreo bietet einen dritten Weg: Eine Open-Source, selbst gehostete, produktionsbereite IDP – die Ihnen das Beste aus beiden Welten bietet:

• Kontrolle, Flexibilität, Enterprise-Features und kein Lock-in

Sie können es heute bereits bereitstellen – aber beachten Sie, dass es sich noch in aktiver Entwicklung befindet und derzeit ein zentrales Portal fehlt, um OpenChoreo vollständig zu integrieren.

Nach der KubeCon EU werde ich einen praktischen Blog veröffentlichen, in dem ich meine Erfahrungen, Walkthroughs, die Roadmap und alles Weitere, was ich hinter den Kulissen lerne, teile.

Vergessen Sie nicht, das Projekt auf GitHub mit einem ⭐ zu versehen, am Choreo-Stand (S703) auf der KubeCon vorbeizuschauen und beizutragen, wenn Sie können – jeder Beitrag hilft!

Kontaktinformationen

Haben Sie Fragen, möchten Sie plaudern oder einfach in Verbindung bleiben? Vermeiden Sie die Medium-Kommentare und lassen Sie uns auf LinkedIn verbinden 🤙. Vergessen Sie nicht, den Medium-Newsletter zu abonnieren, damit Sie kein Update verpassen!