Volltreffer und Rohrkrepierer bei der Cloud Native Computing Foundation Die Tops und Flops der CNCF-Projekte

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Top oder Flop? Das weiß man meistens erst im Nachhinein. Auch die CNCF kann nicht hellsehen. Darum ist die Entwicklung von neuen Standards und Technologien immer mit erheblichen Unsicherheiten verbunden. Trotz Rückendeckung und Schützenhilfe gehen manche Projekte nun 'mal den Bach runter. Doch wenn es klappt, macht dann „The Next Big Thing“ gleich im großen Maßstab die Runde.

Die CNCF (kurz für: Cloud Native Computing Foundation) ist diese enorm einfluss- und erfolgreiche Open-Source-Organisation, die sich im Rahmen der Linux Foundation mit der Entwicklung und Verwaltung von Technologien rund um den Einsatz moderner Datencenter-Infrastrukturen im Rahmen von „nachhaltigen Ökosystemen Cloud-nativer Software“ auseinandersetzen darf.

Derzeit hostet sie eine Rekordzahl von Projekten: weit jenseits von 140, Tendenz steigend. Damit hat die Stiftung beide Hände voll zu tun. Sogar so sehr, dass die Dachorganisation alle Technologien im Zusammenhang mit dem Metaversum Ende Januar 2023 der Übersichtlichkeit halber in eine eigene Stiftung ausgelagert hat, die Open Metaverse Foundation (OMF).

Das wichtigste Stelldichein der CNCF ist die Veranstaltung „KubeCon + CloudNativeCon“, die zuletzt im Oktober 2022 in Detroit stattfand. Die Zahl der Teilnehmer der Konferenz lag diesmal bei über 8.000. Damit war sie mehr als doppelt so hoch frequentiert wie die vorjährige Veranstaltung für die nordamerikanische Region (in Los Angeles), so Priyanka Sharma, Executive Director bei der CNCF.

Die Vorfreude auf die „KubeCon + CloudNativeCon“ für die Region Europa ist schon spürbar. Die Konferenz soll vom 18. bis 21. April 2023 in Amsterdam stattfinden. Danach verschlägt es sie wieder im November 2023 nach Chicago.

Sämtliche Aktivitäten rund um die Cyber-Sicherheit hat die Stiftung aus der Hauptkonferenz ausgelagert. Ab sofort ist die „Cloud Native SecurityCon“ eine eigenständige Veranstaltung. Die erste fand Anfang Februar in Seattle statt; die nächste steht bisher noch nicht fest.

Disruptive Ideen

Die CNCF ist bekannt als eine Organisation, in der einige der faszinierendsten technologischen und technischen Neuerungen beheimatet sind. Eines der bekanntesten und bedeutendsten Projekte innerhalb der CNCF ist „Kubernetes“ (a.k.a. k8s), ein quelloffenes System für die Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen (siehe dazu auch diesen Bericht „Mit Kubernetes auf Wolke sieben?“).

Google hatte es für sich entwickelt, für nützlich befunden, offengelegt und an die CNCF übertragen. Insidern zufolge bereut man Letzteres im Hauptquartier von Google bis heute noch.

Unter der Obhut der CNCF hat sich Kubernetes zum beliebtesten Container-Orchestrierer der Branche entwickelt. Er hat containerisierte Arbeitslasten von den physischen Datacenter-Infrastrukturen entfesselt. Der Rest gehört zum Allgemeinwissen. Kubernetes hat die Mobilität von Arbeitslasten zwischen Rechenzentren und Clouds auf ein neues Niveau gehoben und die „Hybridisierung“ der Unternehmens-IT ermöglicht. Unter den Projekten des CNCF ist Kubernetes gegenwärtig die Nummer Eins sowohl im Hinblick auf die Tragweite als auch die Dynamik.

Das zweitwichtigste Projekt ist „Prometheus“, das beliebte Monitoring-System für Microservice-basierte Anwendungen. Ursprünglich von dem Berliner Startup „Soundcloud“ entwickelt, hat es sich unter der Obhut der CNCF – als Schwesterprojekt zu Kubernetes – zum zentralen Bestandteil des Cloud-nativen-Ökosystems und einer der tragenden Säulen moderner Datencenter-Infrastrukturen gemausert. Die hervorragende Integration mit Kubernetes hat die Bedeutung von Prometheus gestärkt.

Gemessen an der Dynamik der Entwicklung nimmt den zweiten Platz hinter Kubernetes „OpenTelemetry“ ein, eine quelloffene Plattform für die einheitliche Überwachung von verteilten Anwendungen unabhängig von der verwendeten Programmiersprache und dem Betriebssystem der Ausführungsumgebung.

Auch andere wichtige Bausteine des Cloud-nativen-Ökosystems durften bei der CNCF heranreifen. Die treibende Kraft hinter der Mehrheit ist Kubernetes.

Service Meshes

Mit der rapide fortschreitenden Weiterentwicklung von Kubernetes steigt das Interesse an Service-Mesh-Technologien. Denn die meisten betrieblichen Probleme, die bei der Umstellung auf eine verteilte Architektur auftreten, sind letztlich auf zwei Bereiche zurückzuführen: Konnektivität und Beobachtbarkeit. Es ist halt ein um etliche Größenordnungen komplizierteres Problem, eine Reihe miteinander verwobener verteilter Dienste zu vernetzen und ihre Kommunikation zu debuggen, als bloß eine einzelne monolithische Anwendung an Ort und Stelle in den Griff zu bekommen. Die CNCF-Projekte „Envoy“, „Cilium“ und „Istio“ buhlen um die Gunst der Gemeinschaft im Wettbewerb miteinander.

Envoy ist ein hochleistungsfähiger verteilter Proxy-Server in C++ für die Verwaltung von Netzwerkverkehr in Microservice-basierten Anwendungen, ursprünglich von Lyft entwickelt (siehe dazu auch den Bericht „Open Service Mesh – Das Ende von Istio?“). Es bedient nicht nur einzelne Dienste und Anwendungen, sondern dient auch als ein Kommunikationsbus und eine „universelle Datenebene“ für groß angelegte Microservice-Architekturen.

Die Liste der Referenznutzer von Envoy liest sich wie das Who-is-Who der IT-Branche: Airbnb, AWS, Booking.com. Dropbox, eBay, F5, Google, IBM, Medium, Microsoft, Netflix, Pinterest, Salesforce, Stripe, Square, Tencent, Twilio, Uber, Verizon, VMware, Yahoo Japan, Yelp… Das spricht Bände.

Envoy basiert auf den Erkenntnissen aus einer Reihe von Lösungen, daunter Nginx, Haproxy, Hardware-Load-Balancern und Cloud-Load-Balancern. Das besondere Highlight von Envoy besteht in der Abstraktion des Netzwerkes durch die Bereitstellung gemeinsamer Funktionen auf eine plattformunabhängige Art und Weise. Envoy macht es einfach, die Kommunikation einer verteilten Anwendung in einer Infrastruktur durch konsistente Beobachtbarkeit zu optimieren, wenn sie über ein gemeinsames Service-Mesh hindurchfließt.

Ooops! Jetzt zu den Flops…

So viele sind es eigentlich gar nicht, angesichts des Umfangs der Aktivitäten der Stiftung. Die CNCF überprüft regelmäßig alle Projekte und versucht, den Beteiligten die richtigen Anstöße zu geben, um sicherzustellen, dass ihre Bemühungen für die Gemeinde auch wirklich Früchte tragen.

Eine neue Initiative zur Evaluierung laufender Projekte begann Ende des vergangenen Jahres (2022). Im Zentrum der Aufmerksamkeit stehen die Projekte „Notary v1“ und „Notary v2“.

Notary ist eine der reifsten Implementierungen der TUF-Spezifikation in der Branche (The Update Framework). Sie zielte darauf ab, robuste Sicherheitsgarantien für Updates von Container-Images bereitzustellen, selbst im Falle einer Sicherheitsverletzung der Registry. Notary hatte jedoch Usability-Mängel, die der Gemeinde als unüberwindbar schienen.

Um diese Probleme in den Griff zu bekommen, ohne die Sicherheitsgarantien aufzuheben, hat ein neues Governance-Team ein Projekt Notary v2 ins Leben gerufen. Aus Sicht einiger Gemeindemitglieder sei Notary V2 von seinen ursprünglichen Zielen abgewichen; man habe alle Errungenschaften von Notary v1 über Bord geworfen und würde grundlegende Sicherheitskonzepte verleugnen wollen. Es kracht da jetzt gewaltig.

Wenn es kracht

Justin Cappos, CNCF TAG Security Tech Lead, habe den Technischen Lenkungsausschuss der CNCF bereits vor zwei Jahren darauf aufmerksam gemacht, dass das Projekt aus dem Ruder lief. In einem offiziellen Brief äußerte er im Namen von sechs Unterzeichnern „ernsthafte Bedenken“ über die Richtung von Notary V2. Mehrere Teilnehmer der quelloffenen Gemeinde haben darüber in den vergangenen Wochen auf GitHub Dampf abgelassen.

Zu den größten Kritikpunkten zählt die Geheimniskrämerei. So hätten mehrere Betreuer von Notary v2 „häufige private Treffen mit Firmenmitgliedern der Gemeinschaft“, während sie die Open-Source-Mitglieder darüber im Dunkeln ließen. Dies habe dazu geführt, dass eine Referenzimplementierung geschaffen worden sei, die den erklärten Zielen des Projekts, insbesondere den Sicherheitszielen, nicht gerecht werde.

Letzteres sei der zweite wesentliche Kritikpunkt an Notary v2. So gäbe es beispielsweise „kein strenges Bedrohungserkennungsmodell“ für das Projekt. Dies sei besonders besorgniserregend, da dieses Projekt schon aufgrund seiner Zielsetzung gegen Angriffe robust sein müsse, so Cappos.

Mauscheleien

Neue Entscheidungen zur Sicherheitsgestaltung seien angeblich durch „ein Dekret gewisser Personen innerhalb eines Konzerns“ und „hinter verschlossenen Türen getroffen“ worden, berichtete Santiago Torres, Assistenzprofessor an der Purdue University, der sich mit Sicherheit der Softwarelieferkette, angewandter Kryptographie und Systemsicherheit beschäftigt. Diese Geheimniskrämerei stehe im Widerspruch zum Geist von Open Source und würde nebenbei alle vorherigen Prüfungen des Sicherheitsdesigns und Sicherheitsanalysen an dem Projekt durch Forscher aus akademischen und industriellen Kreisen hinfällig machen, so Torres.

Dem Technischen Lenkungsausschuss stehen mehrere Möglichkeiten zur Verfügung, um die abtrünnige Projektleitung unter Kontrolle zu bringen. Jason Hall, ein Softwareingenieur von Chainguard, fordert eine Zwangsumbenennung des Projektes; danach sollten die Teilnehmer eine neue Bewerbung einreichen, um den CNCF Sandbox-Prozess „wie jedes andere neue Projekt durchlaufen“.

Alle CNCF-Projekte unterliegen zumindest auf dem Papier strikten Vorgaben in ihrem gesamten Lebenszyklus und müssen eine Reihe von Anforderungen erfüllen. Mal schauen, was da jetzt passiert.

Rohrkrepierer

Nicht alle Ideen entwickeln sich bei der CNCF zwangsweise zum großen Knaller. Es gibt auch Projekte, die hoffnungsvoll gestartet sind und sich bald im Nichts auflösten oder von anderen überstrahlt werden. Denn die Adoption schwankt im Laufe der Zeit nicht zuletzt auch in Abhängigkeit von den verfügbaren Alternativen.

Es kommt schon mal vor, dass eine vielversprechende Initiative im Laufe der Zeit – auch durchaus unverschuldet – an Bedeutung verliert. Ist die Luft tatsächlich heraus, kann der Technische Lenkungsausschuss (kurz TOC für Technical Oversight Committee) beschließen, ein solches marodes Projekt „zurückzuziehen“ (im O-Ton: retire) oder zu „archivieren“ (im O-Ton: archive).

Ein zurückgezogenes Projekt wurde früher einmal von der CNCF gehostet und dann offiziell eingestellt. Es wird weder aktiv gepflegt noch sonst wie unterstützt. Ein archiviertes Projekt hingegen bleibt der Gemeinde aus historischen Gründen erhalten, obwohl es ebenfalls nicht mehr aktiv gepflegt oder entwickelt wird. Archivierte Projekte sind noch zugänglich, obwohl sie keine Updates oder Bugfixes mehr erhalten.

Steckengeblieben, verlaufen und aufgelöst

Dieses Schicksal teilten unter anderem eine CI/CD-Lösung namens „Brigade“, das Projekt „OpenTracing“ und die Container-Engine „rkt“.

Es war einmal eine Container-Engine… Flott wie eine Rakete. Das Akronym rkt steht für „rocket“ eben, so ein pfiffiger Name. Heute ist das Projekt fast schon in Vergessenheit geraten. Docker hat sich durchgesetzt; für eine Alternative gab es nicht genug Feuer. Die Gemeinde wandte sich stattdessen anderen Herausforderungen zu.

Es ist wichtig zu beachten, dass einige Projekte schon mal, wie Flops aussehen, weil sie wenig Dynamik zeigen, dafür aber einen langen Atem entwickeln. Denn manche Technologien sind für bestimmte Anwendungen und Organisationen von großem Wert, auch wenn sie keinen breiten Zuspruch finden. Darüber hinaus kann sich die Bedeutung von Projekten im Laufe der Zeit ändern, so dass es möglich ist, dass ein Projekt, das zu floppen scheint, auf einmal eine neue Existenzberechtigung findet.

Neue Hoffnungsträger

Die CNCF nimmt ständig neue Projekte auf. Einige bahnen sich frühzeitig als ein durchschlagender Erfolg an, andere lassen sich damit Zeit. Die Stiftung hat kürzlich ein solches bedeutendes Projekt in ihren Reihen willkommen geheißen: „Kubescape“, eine der am schnellsten wachsenden quelloffenen Sicherheitsplattformen für Kubernetes.

Kubescape (von Armo) deckt den gesamten Lebenszyklus der Anwendungsentwicklung und -Bereitstellung ab, von den frühesten Phasen bis hin zur Verwaltung von Clustern. Sie unterstützt DevOps-Teams mit innovativen Tools wie Software-Bill-of-Materials, Signaturen-Scans und richtlinienbasierten Kontrollmechanismen. DevOps-Teams können mögliche Schwachstellen und Fehlkonfigurationen in ihren Anwendungen mit Hilfe von Frameworks wie Mitra ATT&CK, NSA-Cisa und CIS Benchmark schneller erkennen und beheben. Kubescape evaluiert Objekte anhand einer umfassenden Bibliothek an Posture-Steuerungen.

Mit Kubescape als neuem Sandbox-Projekt hat die Cloud Native Computing Foundation ihr Engagement für eine sichere und effiziente Entwicklung von Cloud-nativen „kubernetisierten“ Anwendungen weiter verstärkt. Es kommt vor allem jenen Unternehmen zugute, die ihre portablen Arbeitslasten in die Multi-Cloud ausweiten möchten.

* Das Autorenduo Anna Kobylinska und Filipe Pereia Martins arbeitet für McKinley Denali Inc. (USA).

(ID:49300606)