Das Wichtigste der KubeCon/CloudNativeCon 2022 in Valencia Die Zukunft wird in Software kodiert, ein Großteil davon Cloud Native

Anbieter zum Thema

VMware Global Inc Zweigndl. Deutschland

DataCore Software GmbH

Schwarz IT KG

andrea ludwig pr

Größer, schöner, mehr Projekte …. Die „KubeCon/CloudNativeCon 2022“ hat in der vergangenen Woche mit rund 7.000 Teilnehmern vor Ort und rund 10.000 Teilnehmern am Bildschirm stattgefunden und brauchte mit Komparationen nicht sparen. Neue Begriffe beziehungsweise Akronyme wie „WASM“ für „Web Assembly“ und „SBOMS“ für „Software Bill of Materials“ sickern nun ins kollektive Gedächtnis.

Der Veranstalter der CloudNative-Conferenz, die Cloud Native Foundation (CNCF), deren größtes Projekt laut Chris Wright, Vizepräsident und Chief Technologist bei Red Hat sowie Mitglied des CNCF Governing Board, nach wie vor „Kubernetes“ ist, hat gleich am ersten Tag darauf verwiesen, dass die Organisation 38 neue Mitglieder in etwa einem halben Jahr dazugewonnen habe. Damit ist die Anzahl der Mitglieder auf über 800 angewachsen.

Stolz ist man unter anderem, dass mittlerweile auch End-User-Companies zu den Mitgliedern zählen. So ist erst vor Kurzem der Flugzeughersteller Boeing als „Platin-Member“ eingestiegen, wo sich sonst Contributor-Schwergewichte wie AWS, Microsoft, SAP und Google platzieren. Als „Silver Member“ neu dabei ist etwa das deutsche Unternehmen B1 Systems, das Beratung, Support und Trainings im Linux- und Cloud-Umfeld anbietet.

Die Foundation hat das Unternehmen Slashdata mit einer Studie zum Status Quo beauftragt. Deren Zahlen zufolge arbeiten rund 7,1 Millionen Entwickler weltweit mit Cloud-nativen Techniken und 5,1 Millionen mit Kubernetes (siehe: Abbildungen 1 und 2). Also: Immer weniger Unternehmen Lieferanten und Berater wie Anwenderunternehmen kommen um den Einsatz herum.

Bildergalerie

Das zeigt sich auch im Auftritt der Aussteller: Waren die Stände der ersten CNCF-Veranstaltungen noch mehr oder minder handtuchgroß, war nun die Mehrheit mit einem von CeBIT-Zeiten her gewohnten Standformat in zwei riesigen Hallen vertreten, manche Firmen, wie Giltlab, sogar zweimal, in jeder Halle einmal.)

(Kleine Anmerkung; die Verteilung der Standnummern war durchaus kreativ. Zum Beispiel befand sich der Stand P10 nicht etwa neben oder zumindest in der Nähe von P11 und P12 in Halle 2, sondern in Halle 1)

Entsprechend gesalzen waren auch die Eintrittspreise; pro Einzelperson von rund 300 Dollar im Early-Bird Zeitraum vom 21. Dezember 2021 bis zum 7. Januar 2022, bis zu 700 Dollar vor Ort. Ein Company-Ticket lag zwischen 999 Dollar und 1650 Dollar. Da sollte sich der Besuch schon lohnen.

Für wen taugt die CNCF?

Da CNCF-Projekte Open Source sind, hat die Geschäftsführende CNCF-Direktorin Priyanka Sharma, gleich einmal ihre Eröffnungs-Keynote der Aufforderung gewidmet, die Techniken bitteschön nicht nur zu konsumieren, sondern auch dazu beizutragen, mit Code oder auch Ideen. Das aber macht es schwierig für Unternehmen, die nicht der Kategorie groß zuzurechnen sind.

Zum einen ist die Vielzahl der Projekte durchaus selbst eine Herausforderung. Zwar versucht die Foundation die Entwicklung und das Aufpoppen neuer Projekte zu kanalisieren - es gibt Sandbox-Projekte, in denen vielleicht ein Prototyp existiert, aber nicht viel mehr; es gibt die Incubator-Projekte, in denen unter Umständen rivalisierende Ideen und Codierungen ausprobiert, ergänzt, getestet und um Unterstützung geworben wird, und es gibt den Status „Graduation“. Bei Erreichen dieses Status gibt es eine Art Sicherheit, dass dieses Projekt nicht mehr verschwinden wird, weil eine große Community dahintersteht.

Selbstredend gibt es auch Hersteller, die neben dem Know-how zu ausgewählten Projekten auch dazu passende Produkte, häufig Enterprise-Editions vermarktet werden. Dazu passen dann auch Zertifizierungen und Qualifizierungen; denn Cloud-native-Entwickler und -Operatoren sind auf dem Markt schwer zu finden und teuer, was für nicht-große Unternehmen eines der Probleme darstellt. Und dann existieren zahlreiche Initiativen, Arbeitsgruppen ….. Und ist das noch nicht aufwändig genug, programmieren die CNCF-Überzeugungstäter selbst.

Managed Services

Es gäbe ja Managed-Service-Anbieter - und diese werden gerne als Alternative für Mittelständler genannt, die sich das gewünschte Maß an DevOps-Know-how nicht ins Unternehmen holen können, - aber bestehe ein Problem, sei es ein fehlendes Puzzleteilchen oder ein notwendiger Bugfix, wollten die Teilnehmer des End-User-Panels aus Dave Zolotusky, CNCF TOC Member and Principal Engineer bei Spotify, Christopher Dziomba, DevOps Engineer bei der Deutschen Telekom, Christian Huening, Technical Director bei Finleap Connect, Anusha Ragunathan, Principal Software Engineer bei Intuit und Guy Templeton, Principal Software Engineer bei Skyscanner nicht warten. Das bedeutet nämlich Verzögerung.

Trotzdem diagnostiziert die Cloud-Native-Untersuchung von Slashdata einen Anstieg von Managed Services. Bei der Mehrheit der Container-Orchestrierungs-Tools - darunter fünf der sechs meistgenutzten – handelt es sich um verwaltete Kubernetes-Lösungen (siehe. Abbildung). Zugleich aber ist der Anteil der Entwickler, die sich für ein einziges Orchestrierungs-Tool entscheiden, zurückgegangen: 49 Prozent der Entwickler, die Orchestrierungs-Tools verwenden, nutzten im ersten Quartal 2021 nur ein Tool.

Sechs Monate später ist dieser Anteil auf 46 Prozent gesunken, wobei viele berichten, dass sie selbst verwaltete Lösungen in Verbindung mit vom Anbieter verwalteten Diensten nutzen. Besonders in großen Firmen (über 5.000 Mitarbeiter) ist der „Container-Orchestrator“ verbreitet.

Umdenken

Apros Zertifizierung: Interessenten können sich für die Monitoring-Umgebung „Prometheus“ eine Qualifikation ausweisen lassen. Die Zertifizierung zum „Prometheus Certified Associate“ (PCA) findet online in Form eines Multiple-Choice-Tests statt und ergänzt etwa „KCNA“, „CKAD“ und „CKA“. Wer am Beta-Test teilnimmt und die Prüfung besteht, kommt kostenlos an das Zertifikat.

Zu den großen Unternehmen dürfte auch Mercedes Benz gehören: Das Unternehmen betreibt aus Ulm mehr als 700 Kubernetes-Cluster und 3.500 Maschinen auf der ganzen Welt in OpenStack-Rechenzentren vor Ort. Insgesamt aber handelt es sich um mehr als 900 Cluster, 810 davon in Europa., nichts davon in Indien, Südamerika und Australien. Die Reise, so haben es Lead Expert Mercedes-Benz Tech Innovation Peter Mueller, DevOps Engineer Jens Erat und Product Owner Sabine Wolz in ihrer Keynote erzählt, dauere nun nach einem holprigen Start nun bereits sieben Jahre. Inzwischen zähle das Team zu den Top-20-der Kubernetes-Kontributoren.

Ursprünglich sei der Schwenk zu Open Source durch den Wunsch getrieben gewesen, die Kosten in den Griff zu bekommen, nicht um Schnelligkeit. Heute gehe es hauptsächlich darum, den Entwicklern und Operatoren eine Self-Service-Plattform zur Verfügung zu stellen, die es ihnen sicher und schnell ermögliche Features umzusetzen, Tickets zu bearbeiten und Prozesse zu automatisieren – mithilfe eines eigenen Cloud-Management-Systems. Der Treiber heute: Continuous Improvement. Durch die Migration auf „Cluster API“ wurde etwa die alte Bereitstellung ersetzt, die aus „Terraform“, benutzerdefinierten, selbst geschriebenen Tools und Kubernetes-Operatoren bestand.

SBOMS

Der Begriff Software Bills of Materials, kurz SBOMS, ist nicht komplett neu, selbst US-Präsident Biden hat ihn schon verwendet, doch erst die kürzlich aufgetretenen Probleme mit „Apache Log4j“ oder auch bei Solarwinds durch den Angriff NotPetya haben deutlich gemacht, wie sehr die so genannte Software Supply Chain anfällig für Angriffe sind. Im Gartner-Report „Innovation Insight for SBOMs“ heißt das: „Angriffe auf die Sicherheit der Software-Lieferkette haben die Risiken offengelegt, die mit kommerziell beschafften Tools und Plattformen verbunden sind, weil man nicht weiß, was in der Schachtel ist.“ Nach Meinung etlicher CNCF-Kontributoren und -User ist das Open-Source-Universum besonders anfällig.

Shane Lawrence von Shopify erläuterte in seiner Keynote die Notwendigkeit jeden Teil der Software-Erstellung und -auslieferung abzusichern, am Beispiel herabfallender Container. Das erste Problem: Ein paar Container lösen sich aus der Verankerung auf einem Schiff, kommen ins Rutschen und reißen letztlich mehr Container mit sich, als ursprünglich durch Mängel an der Halterung betroffen waren. Das zweite Problem: Die Suche nach einer passenden Vorrichtung oder nach einer passenden Illustration, lässt so manch einen vergessen, zu überprüfen, woher die Werkzeuge oder auch das ‚Marketing-Tool‘ kommen.

Selbst wenn dem ursprünglichen Hersteller vertraut wird, wer sagt, dass es genau das Bild, das Tool ist und keine modifizierte Kopie. Eigentlich müssten Herkunft und das, was sich mit dem ausgesuchten Asset anstellen lässt dokumentiert sein, eventuell zertifiziert. In einem Umfeld, in dem Applikationen durch jede Menge Fremdcode und APIs entstehen, lässt sich aber nicht alles überprüfen und noch gibt es keinen Standard und nur wenige Tools für SBOMS.

Gartner zu SBOMs

Bei Gartner lautet die Diagnose: „Software-Engineering-Teams verfügen häufig nicht über die Tools, Praktiken und Standards, um Details über anfällige Softwarepakete systematisch zu ermitteln und unternehmensweit auszutauschen“, und weiter: „Die Synchronisierung von Software-Stücklisten (SBOMs) mit den entsprechenden Software-Artefakten stellt eine große Herausforderung dar.“

• Nach Angaben des im März dieses Jahres überarbeiteten Reports von Gartner werden jedoch bis 2025 rund 60 Prozent der Unternehmen, die Software für kritische Infrastrukturen entwickeln oder beschaffen, SBOMs in ihrer Software-Entwicklungspraxis vorschreiben und standardisieren, gegenüber weniger als 20 Prozent im Jahr 2022.

• Bis 2024 werden 90 Prozent der Analyse-Tools für die Softwarezusammensetzung in der Lage sein, SBOMs zu generieren und zu verifizieren, um die sichere Nutzung von Open-Source-Software zu unterstützen, jetzt sind es noch 30 Prozent.

Die Empfehlungen der CNCF an diejenigen, die für die Entwicklung von Anwendungen verantwortlich sind, sollten:

• Die Transparenz der gesamten Software-Lieferkette verbessern, indem Abhängigkeiten zwischen Open-Source-Komponenten im Software-Entwicklungszyklus (SDLC) mithilfe von SBOMs verfolgt werden.

• Betroffene Komponenten erkennen und Schwachstellendaten austauschen, indem sie SBOM-Standards zum Austausch von Informationen über Komponenten und deren Beziehungen verwenden.

• Sicherstellen, dass SBOMs zusammen mit Software-Artefakten neu erstellt werden, indem SBOMs während des Software-Erstellungsprozesses generiert werden, anstatt sich auf vorab generierte SBOM-Daten zu verlassen. Verwendung von Analysetools für die Softwarezusammensetzung, um SBOMs für Open-Source-Komponenten von Drittanbietern zu generieren und zu verifizieren.

• Minderung der Sicherheitsrisiken in der Softwarelieferkette, indem kommerzielle Software-Anbieter aufgefordert werden, während des Beschaffungsprozesses standardbasierte SBOMs, zum Beispiel Software Package Data Exchange [SPDX], Software Identification [SWID], CycloneDX, bereitzustellen.

Auch die CNCF hat ihr Whitepaper zum Thema überarbeitet, siehe: „Announcing the Refreshed Cloud Native Security“ und eine Referenzarchitektur „Factory Reference Architecture“ dazu vorgestellt.

Link zu den Videos von der Cloud Native SecurityCon EU 2022

WASM

Cloud Native WebAssembly, kurz WASM, wurde ursprünglich für den Browser entwickelt, aber gewinnt auch auf dem Server und im Edge-Bereich an Popularität. So ist das Projekt WebAssembly im vergangenen Jahr mit dem angesehenen „Programming Languages Software Award“ der ACM SIGPLAN ausgezeichnet worden.

Der Hintergrund: Im Cloud Native Computing verschwimmt die Grenze zwischen Hardware und Software. Alles wird in einer „Wolke“ abstrahiert. Das hat zu einer explosionsartigen Zunahme von Microservices, Messaging Queues, Datenströmen und serverlosen Funktionen geführt. Diese Komponenten werden von verschiedenen Entwicklern geschrieben und sind potenziell nicht vertrauenswürdig, müssen aber sicher und nahtlos zusammenarbeiten.

Die traditionelle Methode der Verwendung von Netzwerk-APIs oder der neuere Ansatz der Verwendung von Docker-Containern zur Isolierung von Softwarekomponenten ist langsam und schwerfällig. Und hier kommt WebAssembly ins Spiel: Der Ansatz hat sich als leistungsstarke, plattformübergreifende und polyglotte Software-Sandbox für Cloud-native Softwarekomponenten etabliert. So können etwa die Runtimes in mehrere Programmiersprachen und Host-Umgebungen eingebettet werden. Sie lassen sich auch mittels Container-Tools und Daten-Streaming-Frameworks verwalten und orchestrieren.

Die CNCF beherbergt mehrere WebAssembly-bezogene Projekte und Initiativen:

• WASMEdge, ein Sandbox-Projekt, ist eine voll funktionsfähige WebAssembly-Laufzeitumgebung, die für Cloud- und Edge-Computing-Anwendungen optimiert ist.

• WASMCloud , ein Sandbox-Projekt ist eine Actor-basierte WebAssembly-Host-Laufzeitumgebung, die die Anwendungsentwicklung für WebAssembly vereinfachen soll.

• Das Sandbox-Projekt Krustlet ist ein Kubelet beziehungsweise Knotenagent auf jedem Kubernetes-Knoten, der WebAssembly-Dateien als Arbeitslasten ausführen kann. Es vereinfacht die Möglichkeit, WebAssembly-Programme in Kubernetes auszuführen.

• Kubernetes kann nun die WASMEdge-Laufzeitumgebung verwalten und WebAssembly-Anwendungen Seite an Seite mit anderen Container-Anwendungen orchestrieren. Es kann auch WebAssembly-Programme über Krustlet ausführen.

• KubeEdge, im Inkubationsstatus, ist ein Laufzeitmanagement- und Orchestrierungswerkzeug für Edge Computing. Es arbeitet mit WASMEdge zusammen, um eine WebAssembly-Laufzeit auf Edge-Geräten zu unterstützen.

• Das Incubator-Projekt CRI-O entwickelt ein OCI-konformes Container-Verwaltungs-Tool. WASMEdge hat CRI-O erweitert, um WebAssembly-Anwendungen in Standard-Docker-Image-Repositories und -Verwaltungswerkzeuge zu unterstützen.

• Envoy, abgeschlossen und nach Kubernetes das Projekt mit dem meisten Zulauf, nutzt WebAssembly zur Unterstützung dynamischer Erweiterungen in Service-Mesh-Proxys.

Links zu WASM-Übersichstseiten:

WASM-Videos von der KubeCon/CloudNativeCon

WASM-Landscape

Plattform-Teams

Eher schleichend und sicher von Anwenderunternehmen getrieben vollzieht sich ein kultureller Wandel. Zu den Schlagworten, die hier hinein gehören, zählen Plattform-Teams, FinOps und Service-Meshes. Noch immer herrscht eine positive Aufbruchstimmung unter den Entwicklern (und Operatoren) wenn es um DevOps, also Development und Operations geht – Entwicklung und Betrieb. Was tatsächlich passiert ist, bürdet den Entwicklern immer mehr Aufgaben und Verantwortung auf, insbesondere durch das Testen und Security.

Inzwischen gehen CNCF-Sprecher davon aus, dass sie nun entlastet gehören: Es gibt (wieder) Plattform-Teams. Denen kommen im Wesentlichen Aufgaben zu, die denen von Enterprise-Software-Architekten ähneln, damit die CNCF-Cluster und -Pods nicht ausufern, damit Regularien zur Erstellung, zum Testen, Security-Guidelines, die Zuteilung von Ressourcen klappt. Service-Meshes, denen ein Großteil solcher Regeln quasi immanent sind, können diese Aufgaben vereinfachen.

Der Umgang mit Ressourcen

Mithilfe von FinOps lässt sich auch noch bewerten wo welche Cloud- und/oder Hardware-Ressource sinnvoll ist, damit möglichst weder Geld noch Rechen-Power verschwendet werden; typische Projekte hier ist etwa „Kubecost“. Im Blog von Asaf Liveanu, Co-Founder & CPO at Finout, findet sich Folgendes: „Die Kostenoptimierung ist ein wachsendes Anliegen für Unternehmen, die sich schnell auf Open-Source- und Cloud-native Projekte auf der Grundlage von Kubernetes umstellen. Während die Flexibilität eine der Hauptstärken von Kubernetes bleibt, führt sie häufig zu übermäßigen Ausgaben aufgrund einer Überversorgung mit Workload-Ressourcen.“

Die größte Herausforderung bei der Kostenprognose und -kontrolle in einem Kubernetes-Kosten-Management-Ökosystem sei die Komplexität und die fehlende Transparenz darüber, wie Kubernetes-Cluster-Ressourcen mit der zugrundeliegenden Infrastruktur verknüpft sind. Um die Gesamtkosten in Kubernetes zu verwalten, sei es wichtig, den Ressourcenverbrauch auf Pod-Ebene zu identifizieren und zu bewerten, wie sich dies auf die Arbeitslast auswirke.

Das ist keinesfalls trivial: Ein typisches Kubernetes-Ökosystem kann aus mehreren Workloads mit unterschiedlichen Ressourcenanforderungen bestehen - von allgemeinen Ressourcen wie CPU und Speicher bis hin zu spezialisierten Ressourcen wie GPU-Beschleunigern oder Hochgeschwindigkeitsspeichern. Liveanu spricht von einer Ressourcenasymmetrie, die von einem „kube-scheduler“ gehandhabt wird, der einen Scoring-Algorithmus verwendet, um den richtigen Knoten für jede Arbeitslast zuzuweisen.

Bildergalerie

Aber der Bewertungsalgorithmus ist eine Kombination aus mehreren Faktoren, einschließlich der Verfügbarkeit von Ressourcen und benutzerdefinierten Bedingungen. Daher kann es komplex sein zu verstehen, wie und wann ein Knoten einer Arbeitslast zugewiesen werden soll. Außerdem schwankt der Ressourcenbedarf, was auf neue Bereitstellungen, Neuausrichtung oder Zerstörung von Pods innerhalb von Knoten zurückzuführen ist.

Anforderungs- und Limit-Parameter können bei der optimalen Zuweisung von Ressourcen an Pod-Workloads innerhalb eines Knotens helfen. Wenn in einem Knoten mit mehreren Pods einer von ihnen nicht über eine definierte Anforderung und ein Limit verfügt, neigt der Pod dazu, alle im Knoten verfügbaren Ressourcen zu verbrauchen. In solchen Fällen erhalten andere Pods nie die benötigten Ressourcen, was sich auf die Gesamtleistung und die Kosten des Clusters auswirkt. Das Projekt, das hier unbedingt Erwähnung finden muss, ist „Envoy“.

Und dann gibt es noch OpenTelemetry

Die Metrik-Funktionen von OpenTelemetry gehören ebenfalls in diese veränderte Denke. Es ist mittlerweile das zweitgrößte CNCF-Projekt. Spezifikation, APIs, SDKs und andere Komponenten, die Metriken erstellen, erfassen, verarbeiten und anderweitig mit ihnen interagieren, können die Funktionalität von OpenTelemetry Metrics nun nutzen, da sie jetzt als Release-Kandidaten verfügbar sind, beginnend mit Java, .NET und Python.

Die Version 1.0 der Metriken umfasst Folgendes:

• Metrikfunktionalität in den sprachspezifischen APIs von OpenTelemetry, die sprachspezifische Schnittstellen zur Erstellung und Bearbeitung von Metriken und zur Zuordnung von Metadaten und Attributen zu den einzelnen Metriken bieten. Diese sind nützlich für:
  ...- Entwickler von gemeinsam genutzten Bibliotheken, die an Endbenutzer verteilt werden, damit diese Endbenutzer OpenTelemetry nativ zur Erfassung von Metriken aus diesen Bibliotheken verwenden können. Beispielsweise verwendet gRPC diese APIs, um Latenz-, Durchsatz- und Fehlerratenmetriken für jede RPC-Methode eines bestimmten Dienstes zu erstellen.
  - Entwickler, die Web-Dienste oder Client-Anwendungen erstellen und pflegen, damit sie benutzerdefinierte Metriken erstellen oder mit vorhandenen Metriken interagieren können. So könnte beispielsweise ein E-Commerce-Unternehmen die API nutzen, um die Anzahl der getätigten Käufe über einen bestimmten Zeitraum zu verfolgen.

• Die Metrikfunktionalität ist in den OpenTelemetry-SDKs für Java, .NET, Python und JS (kommt nächste Woche) enthalten, die Metriken von den APIs erfassen und in gewissem Umfang verarbeiten. Die Unterstützung von Metriken für andere Sprachen ist noch in der Entwicklung. Diese sind nützlich für:
  - Entwickler von Anwendungen, die von anderen Organisationen genutzt werden, wie Datenbanken und Message Queues, die Metriken über OTLP (oder „Prometheus“) bereitstellen, damit ihre eigenen Endbenutzer die Leistung dieser Anwendungen überwachen können. Bei diesen Anwendungen kann es sich um offene oder geschlossene Quellen handeln.
  - Entwickler von Anwendungen innerhalb einer Technologieorganisation, die Metriken erfassen möchten, die von OpenTelemetry-APIs innerhalb ihrer Anwendungen generiert werden, entweder von ihren eigenen Entwicklern oder von gemeinsam genutzten Bibliotheken, von denen ihre Anwendungen abhängen. Diese Metriken können über OTLP oder über jeden anderen OpenTelemetry-Exporter exportiert werden.

• Die Collector-Unterstützung für Metriken umfasst die Fähigkeit des Collectors, Metriken aus einer Vielzahl von Datenquellen wie Host-Metriken oder vorbereiteten Anwendungen zu erfassen. Der Collector bietet auch die Möglichkeit, Metriken von Datenquellen zu empfangen, die mehrere Datenprotokolle wie das native OpenTelemetry-Protokoll (OTLP) und OpenMetrics-konforme Protokolle wie Prometheus verwenden. Außerdem werden die konfigurationsgesteuerte Verarbeitung von Metriken sowie native OTLP-, Prometheus- und benutzerdefinierte Exporteure unterstützt, um Observability-Metriken an On-Cloud- und On-Premises-Überwachungssysteme Ihrer Wahl zu senden. Dieses Feature-Set ist nützlich für:
  - Alle, die Metriken von ihren Hosts, etwa Linux-VMs, Windows, VMs und Kubernetes oder von vorgefertigten Anwendungen wie Datenbanken und Message Queues erfassen möchten.
  - Jeden, der Metriken aus bestehenden Quellen wie OTLP, zum Beispiel aus OpenTelemetry SDKs und vorgefertigten Anwendungen, Prometheus oder anderen erfassen möchte.
  - Jeden, der Metriken und Metadaten, die aus diesen Quellen erfasst wurden, verarbeiten oder verändern möchte.
  - Jeden, der Metriken von einem Format in ein anderes konvertieren möchte. So kann der Collector beispielsweise Metriken aus einer Mischung von OTLP- und Prometheus-Quellen erfassen und dann alle Metriken an ein einziges Ziel unter Verwendung von OTLP (mit den semantischen OpenTelemetry-Standardkonventionen), Prometheus oder einem anderen Exporter senden.

• Vollständige Unterstützung des OpenTelemetry-Protokolls (OTLP) für die effiziente Serialisierung und Übertragung von Metriken zwischen Systemen.

• Einen Metrik-Abschnitt der Spezifikation, der verschiedene Arten von Metriken, ihre Formen, ihre Verarbeitung und semantische Konventionen definiert. Dieser Teil wird in erster Linie von OpenTelemetry-Mitarbeitern verwendet, bietet aber auch OpenTelemetry-Benutzern, die Metriken oder Metadaten erstellen eine Anleitung.

Die gesamte Funktionalität ist eine Ergänzung zur bestehenden Tracing-Unterstützung von OpenTelemetry, und beide Signaltypen verwenden die gleichen Metadaten und semantischen Konventionen.

Die grüne WG

Frisch eingeführt wurde die Arbeitsgruppe „Environmental Sustainability“ der CNCF. Sie will

• ökologische Nachhaltigkeitsfaktoren für die Cloud-Native-Landschaft definieren,

• Open-Source-Projekte zur Beobachtung und Messung des CO2-Fußabdrucks der Cloud-Native-Infrastruktur fördern und unterstützen,

• den CO2-Fußabdruck optimieren und schließlich reduzieren sowie

• die Cloud-Native-Infrastruktur fördern, um Umweltprobleme zu bekämpfen.

Vorgestellt haben Kate Mulhall und Emma Collins von Intel die Working Group mit dem Verweis, dass die CPU-Auslastung zumeist gerade einmal bei 20 Prozent liege und der Energieverbrauch der IT wachse und wachse. So sei der Internet-Traffic im Jahr 2020 um 40 Prozent gestiegen. Erstaunen mit hörbarem Raunen ging durch das KubeCon/CloudNativeCon-Publikum als die Intel-Vertreterinnen einen Vergleich des Energiebedarfs unterschiedlicher Programmiersprachen heranzogen um für die Teilnahme an der Arbeitsgruppe zu werben.

Wird der Wert, 1,00 für Code in der Programmiersprache „C“ angesetzt, gelangt man bei Java auf einen Wert von 1,90 und bei den im Cloud-Native-Umfeld besonders beliebten Sprachen „Python“ und „Perl“ auf Werte von 75,88 und 79,58 (siehe: Abbildung). „Wir wollen das Bewusstsein für ökologische Nachhaltigkeit als Schlüsselelement der Open-Source-Entwicklung schärfen und Projekte unterstützen, die das Verständnis für Energietreiber fördern. Alle Aktivitäten sollen sich positiv auf die Community auswirken, indem sie ein Umdenken bewirken, die Effizienz steigern und die Nachhaltigkeit auf die Tagesordnung aller setzen“, heißt es in der Arbeitsgruppenbeschreibung.

Nicht nur wegen des erwachenden Umweltbewusstseins gab Van Jones, Polit-Kommentator beim Sender „CNN“, den Besuchern der KubeCon/CloudNativeCon mit: „Die Zukunft wird in Computer-Code geschrieben“, nach dem er vorausgeschickt hatte, dass nicht Gesetze und Regeln die bestimmenden Größen seien und forderte sie auf, sich dessen bewusst zu sein.

%boxheader%

Und sonst so?

1. Die Cloud Native Foundation engagiert sich für die Ukraine. Wie stark, das zeigte sich am ersten Keynote-Tag. Zunächst sandte Ihor Dvoretskyi in Armee-Kleidung einige Grußworte aus seinem Heimatland, der Ukraine.

Im zivilen Leben ist Dvoretskyi Developer Advocate bei der Cloud Native Computing Foundation. Er ist Produktmanager für Kubernetes und leitet die Product Management Special Interest Group, die sich auf die Verbesserung von Kubernetes als Open-Source-Produkt konzentriert. Darüber hinaus ist er am Kubernetes-Release-Prozess als Feature-Lead für mehrere Kubernetes-Releases beteiligt.

Anschließend stellte Olena Nyzhnykevych, Razom's head of Major & Transformational Gifts, die Hilfsorganisation „Razom for Ukraine“ vor.

2. Jim Zemlin, Executive Director der Linux Foundation, kündigte an, dass sich die Organisation nun stärker um die Belange der europäischen Firmen kümmern wolle. Tatsächlich ist geplant, ein europäisches Büro einzurichten; Mitarbeiter werden gesucht.

3. Die Telcos haben Probleme. Diese sind erstens technischer Natur, deshalb wolle man zusammenarbeiten, so die Teilnehmer einer Podiumsdiskussion zu diesen. Es trafen sich Kirsten Newcomer, Director, Cloud and DevSecOps Strategy bei Red Hat, Paul Graham, Director of UK Engineering, Matrixx Software, Darragh Grealish, Co-Founder and Partner, Cloud and 5G Business Development bei 56K.Cloud, Vinodhkumar Raghunathan, Director, Product Management, Commercial OSV Strategy, Network Platforms, bei Intel und Philippe Ensarguet, CT bei Orange Business Services. Es geht dabei hauptsächlich um das Bilden einer Netzwerk-Cloud auf der Basis von Cloud-Native-Technologien.

Die zweite Art der Probleme hängt damit zusammen, dass man zwar einerseits Open Source nutzen wolle, auch bereit sei, etwas von dem eigenen Wissen zu investieren, man andererseits fürchte, zu viel des eigenen Know-how abzugeben.

Der dritte Problemkomplex rankt sich um die Tatsache, dass die Hyperscaler sowohl in der Wahrnehmung als auch im Generieren von Umsatz weit vor den Telco-Unternehmen liegen. Während Google, AWS und Microsoft im Cloud-Geschäft weiterhin prägnant wachsen, haben die Telcos mit sinkenden Einkommen und Margen zu rechnen. An dieser Stelle darf erwähnt werden, dass die Telekommunikationsbranche einst in der Poleposition mit einem riesigen Vertrauensvorsprung in das Rennen um Cloud-Konsumenten gestartet war.

(ID:48364549)