Um die Komplexität der heutigen Cloud-nativen Infrastruktur zu bewältigen, besteht ein zunehmender Bedarf an IT-Monitoring-Technologie, die oft als Observability bezeichnet wird. Als zentrale Bausteine dieses Trends entwickeln sich derzeit zwei anspruchsvolle Technologien rasant weiter: Monitoring-as-Code und Infrastructure-as-Code.
Sehen wir uns diese aufkommenden Technologien genauer an und betrachten wir, wie sie bei der Überwachung und Verwaltung komplexer Cloud-nativer Systeme helfen.
Siehe auch: Warum die Cloud Cloud-native bedeutet
Infrastructure-as-Code: eine softwaredefinierte IT-Grundlage
Beim Infrastructure-as-Code-Modell gibt es weiterhin physische Infrastruktur, sie tritt jedoch in Form eines deskriptiven Modells für softwaredefinierte Compute-, Speicher- und Netzwerkressourcen auf, die von Cloud-Anbietern.
bereitgestellt und anschließend ausgeliefert wurden. Bei IaC gibt es keine Kabel, Stecker, Hubs und Router; stattdessen werden „Verbindungstopologien“ durch Quellcodedateien definiert. Natürlich gibt es also Kabel und Leitungen, aber sie befinden sich im Rechenzentrum der Cloud, und der Code definiert , welche davon wir an welchem Tag, für welchen Workload und mit welchem Impedanzniveau und so weiter verwenden.
Während wir nun in die Cloud-native-Umgebung vordringen – angetrieben von Infrastructure-as-Code – und dabei die gesamte Container-Granularität von Kubernetes mitnehmen, müssen wir die zentrale Herausforderung weiterhin im Blick behalten und auf unerwartete Wendungen und Hindernisse achten. Damit kommen wir zu Monitoring-as-Code.
Monitoring-as-Code: Der Schritt von 1,0 zu 2,0
Die „ständig eingeschaltete Dashcam“, also Monitoring-as-Code (MaC), spielt eine zentrale Rolle bei der Verwaltung komplexer Systeme. Als enger Verwandter von Observability-as-Code (OaC) – jedoch nicht vollständig synonym damit – entwickelt sich MaC derzeit rasant von einer „einfachen“ Datensammlungsfunktion zu einem Bestandteil der höher angesiedelten Observability-Schichten, die moderne Multi-Cloud-Bereitstellungen kennzeichnen.
In einer Welt, in der DevOps, DevSecOps und AIOps allesamt dazu beitragen, die vergleichsweise neuen Rollen im Bereich Site Reliability Engineering (SRE) zu schaffen, wird zweifellos eine neue und weiterentwickelte Form der Überwachung erforderlich sein, wenn wir uns von statischen IT-Infrastrukturen zu den dynamischen Modellen von IaC bewegen.
Auf der grundlegendsten Ebene ist Monitoring-as-Code (MaC) eine Übung in der Datensammlung durch Software-Agenten, Plugins und einzelne Quellcodeelemente, die als „Exporter“ fungieren, um Daten auf Systemebene zu erfassen und an ein Repository weiterzuleiten. Das ist, wenn man so will, MaC 1,0.
Um MaC 2,0 und darüber hinaus zu gelangen, müssen wir über den Aufbau eines umfassenderen Observability-Lebenszyklus nachdenken und ihn mit Intelligenz, Diagnosefunktionen und erweiterten Fähigkeiten ausstatten, um ein Maß an automatisierter Fehlerbehebung zu erreichen – mit dem, was wir als kodifizierte reaktive Logik bezeichnen könnten. Einfach ausgedrückt: Die Grundbausteine von IT- und Cloud-Software verschieben sich.
„Einer der großen Technologietrends für 2022 wird die Integration von ‚Observability und Pipelines‘ als benachbarte Märkte sein“, sagte James Governor, Mitgründer des Technologieanalystenhauses RedMonk. „Tests verlagern sich nach links, aber auch nach rechts, in die Produktion. Softwarebereitstellungs-Pipelines sind inzwischen geschäftskritische Anwendungen. Wir beobachten, dass Observability-Anbieter enger mit Unternehmen zusammenarbeiten, die CI/CD- und Softwarebereitstellungs-Tools anbieten – um das Leben der Kunden einfacher zu machen.“
Governor zufolge liegen die beiden Arbeitsdisziplinen (oder Märkte) Observability und Softwarebereitstellung so dicht beieinander, dass sie zusammenwachsen und damit das ermöglichen, was wir als „progressive Bereitstellung“ bezeichnen können.
Siehe auch: AIOps-Trends
Anwendungsfälle für Observability-Technologie „as Code“
„Mit der Umstellung auf progressive Bereitstellung können wir uns auf Anwendungsfälle wie Blue-Green-Deployments, Canary-Releases, Feature-Flags und Dark Launches konzentrieren und progressive Rollouts für bestimmte Benutzergruppen durchführen, um den Explosionsradius zu begrenzen. Die Produktion wird damit Teil des Softwarebereitstellungs-Lebenszyklus“, erklärte Governor.
Er sagt, dass die „as-Code“-Revolution all dies vorantreibt und anspruchsvollere Pipelines und Erweiterungen ermöglicht, während Unternehmen ihre App-Bereitstellung modernisieren wollen – mit besseren Tests, mehr Automatisierung und integrierter Observability.
Zu den aktuellen Akteuren im Bereich Monitoring-as-Code gehört Sumo Logic mit seinem Open-Source-Projekt Sensu. Sensu wird als „Observability-Pipeline“ beschrieben, die Monitoring-as-Code in jeder Cloud bereitstellen soll, und verspricht, Monitoring-Tools zu konsolidieren und Lücken in der Observability über Datensilos hinweg mit automatisierter Diagnose und Selbstheilung zu schließen. Zusammengefasst unterstützt es das gesamte Spektrum moderner IT – von Bare Metal bis Kubernetes.
Sumo Logic übernahm das Sensu-Projekt im Juni 2021, und CEO Caleb Hailey sowie Mitgründer Sean Porter wechselten in Funktionen zum neuen Mutterunternehmen, die ihre Arbeit weiter voranbringen sollten. Das Duo konzipierte Sensu während der Arbeit an einem internen Projekt, das eine veraltete Nagios-Infrastrukturmonitoring-Installation für ein Cloud-Unternehmen zur Informationsarchivierung ersetzen sollte.
Ohne ihren Wert grundsätzlich absprechen zu wollen, benannte Porter selbst die MaC-1,0-Tools nach dem, was sie waren: Software-Agenten, die Systemdateiinformationen an Konfigurationsmanagement-Tools wie Puppet, Chef, Helm, Terraform, Ansible oder andere übertrugen. Er beschrieb dies als einen Vorgang, der dem Nachrüsten traditioneller Monitoring-Tools für das moderne DevOps-Paradigma gleichkommt.
Damit schließt sich der Kreis zu einem weiteren modernen Paradigma für die Implementierung von Anwendungsplattformen. Die CI/CD-Welt kann MaC tief in ihre Struktur integrieren, wenn wir sicherstellen, dass wir das weiterentwickelte MaC 2,0 in ihrem Kern einsetzen.
MaC 1,0 in CI/CD bedeutet, Monitoring-Tools zu verwenden, um die Betriebsgesundheit und das ordnungsgemäße Funktionieren von Anwendungen und zugehörigen Diensten zu testen. MaC 2,0 in CI/CD bedeutet, Monitoring-Tools mit kodifizierter reaktiver Logik zum Erstellen und Testen von Anwendungen einzusetzen. Und ihre Betriebsgesundheit in Live-Produktionsumgebungen zu automatisieren.
Mit zunehmender Nutzung von MaC 2,0 in modernen CI/CD-Umgebungen, die durch Technologien wie Kubernetes stark auf Containerisierung setzen, sowie von künstlicher Intelligenz, kann die „gemeinsame Verpackung“ von Containern uns ermöglichen, CI/CD in eine noch stärker formalisierte Pipeline zu erweitern.
Sumo Logics Porter bezeichnet diese Entwicklungen als den Übergang zu neuem neuem Infrastructure-as-Code – ein Begriff, der eindeutig einer Neuerfindung bedarf („Neo-IaC“, vielleicht). Dies gilt außerdem eindeutig auch dafür, wie wir CI/CD-Pipelines mit stärker auf den Betrieb ausgerichteten Funktionen erstellen – einschließlich integriertem Monitoring und integrierter Observability.
Die CI/CD-Pipeline genauer überwachen
Es ist wichtig, eine operativ intelligentere, reaktive und funktionale Continuous-Integration/Continuous-Delivery-(CI/CD-)Pipeline zu schaffen, die nicht einfach nur „ausführt und betrachtet“. Sie „sieht, versteht und reagiert“ auch, sodass diese neue IaC-Schicht dazu beitragen kann, ein System für die hoch anspruchsvollen Cloud-Dienste aufzubauen, die sogenannte High-Velocity-Cloud-native-Unternehmen benötigen.
„Monitoring-as-Code (MaC) löst ein Problem, das viele Projekte plagt: Unerwartete Probleme während der Vorproduktionstests oder bei Bereitstellungen bleiben unentdeckt. Wir verlieren Stunden damit, fehlschlagende Tests weiterlaufen zu lassen, verbringen dann noch mehr Zeit mit der Fehlersuche und verpassen natürlich die Gelegenheit, die Grundursache im Moment des Fehlers zu untersuchen“, erklärte Seng Phung-Lu, AVP für Site Reliability Engineering bei TD Bank.
Phung-Lu sagt, dass er und sein Team mit MaC-Tools, die gemeinsam mit einer Anwendung über eine einzige einheitliche Pipeline bereitgestellt werden, Probleme frühzeitig erkennen und vermeiden können, den Test- und CI/CD-Prozess – wie er selbst sagt – „manuell babysitten“ zu müssen.
Das ultimative Ziel: Kontinuierliches und vollständiges End-to-End-Monitoring
Der eigentliche Wert dieser aufkommenden Technologien könnte in einer neuen Definition dessen liegen, was wir unter End-to-End-Monitoring verstehen.
Früher bedeutete End-to-End-Monitoring Observability, die auf alles angewendet wurde – vom Betriebssystem (OS) und der Benutzeroberfläche (UI) des Geräts über die Compute-, Speicher- und Analysefunktionen bis hin zum Benutzer. Das neue End-to-End-Monitoring umfasst all das und zusätzlich die Fähigkeit, Monitoring über die gesamte Breite der Infrastruktur bereitzustellen, auf der all dies läuft.
Im positiven Kreislauf von MaC 2,0 innerhalb einer End-to-End-Neo-IaC-Umgebung beginnt sich eine neue symbiotische Beziehung zu entwickeln: Anwendungsmetriken werden als Reaktion auf Codeänderungen und neue Bereitstellungen automatisch erfasst und erkannt. Die fortschreitende Erweiterung des IT-Stacks profitiert von den „gelernten Fehlern“ (Fehlern bei der Codeausführung), die bereits aufgetreten sind, und der Stack selbst schöpft aus seiner eigenen evolutionären DNA.
Über den Autor:
Adrian Bridgwater ist ein führender Journalist, der über aufkommende Technologien berichtet.