In einem IT-System ist jede Komponente ein Knoten in einem mehr oder weniger komplexen Netzwerk. Eine Umgebungsübersicht ist ein zentraler Anlaufpunkt für die Betriebsorganisation, aber auch für Entwickler und Tester. Sie beinhaltet Informationen über die Version jeder Komponente, welche Komponente wie oft als Instanz existiert, wie viel Speicher sie verwendet oder wie ihr aktueller Zustand ist. Abhängig von der gewählten Architektur zeigt so eine Übersicht noch viele weitere Merkmale.

Motivation

Je komplexer ein Produkt oder je mehr Teams an der Entwicklung beteiligt sind, desto mehr Umgebungen werden benötigt. Jedes Team braucht mindestens eine Entwicklungsumgebung und eine weitere Umgebung zur Integration mit den Ergebnissen der anderen Teams. Dort finden zum ersten Mal automatisierte Tests statt. Für den integrierten Test des Produktinkrementes gibt es in der Regel zwei Testumgebungen mit einem Aufbau wie die Produktionsumgebung. Eine Testumgebung hat eine “echte” Datenversorgung. Die zweite Testumgebung wird für die automatisierte Ausführung von Regressionstests oder zur Durchführung von Lasttests benötigt. Bei agiler Software-Entwicklung wird das Reagieren auf Veränderung höher bewertet als das Befolgen eines Plans. So steht es wenigstens im agilen Manifest unter Punkt 4. Der Aufbau der Umgebung für ein Produktinkrement wird sich gerade bei “jungen” Projekten häufig ändern. Darum ist die Herstellung und vor allem Pflege einer aktuellen Übersicht für alle eingesetzten Umgebungen eine echte Herausforderung.

Abgrenzung

Die Umgebungsübersicht ist kein Werkzeug für das Monitoring des IT-Systems. Auch wenn grundlegende Statusinformationen über die Komponenten Teil der Betrachtung sind, ist es weder angedacht, diese für Überwachungszwecke zu detaillieren noch sie mit irgendwelchen Automatismen zu versehen. Sie darf auch nicht mit einem Dashboard verwechselt werden, das den aktuellen Zustand des IT-Systems zeigt. So ein Dashboard visualisiert bestimmte Kennzahlen, die für einen störungsfreien Betrieb signifikant sind. Ein Dashboard wird jedoch nie alle Komponenten des IT-Systems zeigen.

Komponentenüberblick

Die Beschreibung der Systemstruktur mit den Bausteinen Domain, Service, Event und Entity geben Komponenten und Datenstrukturen eindeutige Namen. Die Seiten im Wiki enthalten wissenswerte Fakten über die verwendeten Technologien und Besonderheiten einer Komponente oder die Spezifikation einer Datenstruktur als Teil der Schnittstelle, die eine Komponente besitzt. Testfälle, Konfiguration, Readme-Dateien und Seiten im Wiki sind zusammengenommen alles, was es über eine Komponente zu sagen gibt, vereint durch einen gemeinsamen Namen.

Der Komponentenüberblick wird im Wiki gepflegt. Für die Abbildung wird in der Medienbibliothek eine Seite angelegt. Oft erkennen Entwickler erst durch die grafische Visualisierung der Topologie ihres IT-Systems kritische Pfade oder gefährliche Rückkopplungen im Zusammenspiel der Komponenten. Viele Kreuzungen bei den Datenflüssen decken versteckte Abhängigkeiten auf. Komplexe Komponenten werden sichtbar.

 

Mit dem Confluence-Addon Draw.io ist eine interaktive Abbildung möglich. Ein Klick auf einen in blauer Farbe hervorgehobenen Text öffnet die entsprechende Service-Seite im Wiki für weitere Details.

Der Überblick zeigt Komponenten und Datenflüsse mit einer sehr einfachen Bildsprache, die nur wenige Elemente hat.

Wichtig ist, dass der Komponentenüberblick unabhängig ist von der Umgebung, auf der ein Produktinkrement installiert und wird und läuft. In der Darstellung haben aus diesem Grund umgebungsspezifische Informationen keinen Platz.

Umgebungsübersicht

Diese Lücke in der Dokumentation schließt die Umgebungsübersicht. Aufbauend auf dem Komponentenüberblick möchte der Betreiber einer Umgebung wissen, welche Version, wie viele Instanzen und welchen Zustand jede Komponente der Umgebung hat. Die Schwierigkeit dabei ist, dass diese Informationen im Code oder in Skripten für das Deployment der Komponenten stecken. Eine zusätzliche Dokumentation im Wiki wäre maximal redundant. Eine dauerhafte Pflege ist für das Team fehleranfällig, weil es in der Regel an der Möglichkeit, manchmal sogar am Willen zur Prüfung so einer Dokumentation fehlt. Darum ist eine Umgebungsübersicht technisch gesehen eine Zusammenstellung von «Informationsdiensten» einer Umgebung, in der ein Produktinkrement installiert ist.

Eine Service-Registry ist so ein Informationsdienst mit einem zentralen Verzeichnis von Instanzen der Komponenten eines IT-Systems.

Consul pflegt ein zentrales Diensteverzeichnis und überwacht Knoten und Dienste über lokal auf den jeweiligen Knoten ausgeführte Agenten. Für jeden registrierten Dienst stellt Consul einen Key-Value-Store für Konfigurationsdaten bereit. Zur Abfrage des Diensteverzeichnisses stell Consul ein REST-API bereit. Mit dem optionalen Consul Template werden Konfigurationsdateien von Diensten zur Laufzeit aktualisiert.

Eureka ist Teil des Netflix-Universum und verwaltet dynamisch Dienste in der AWS-Cloud. Ist ein Dienst nicht mehr verfügbar, wird er aus dem Verzeichnis entfernt. Außerdem können sich mehrere Instanzen eines Dienstes unter dem gleichen logischen Namen registrieren; Eureka übernimmt die Lastverteilung zwischen den Instanzen. Dienste werden durch die Interaktion zwischen Eureka-Client und -Server gefunden. Der Server sammelt die Informationen über die registrierten Dienste und stellt zur Abfrage des Verzeichnisses ein REST-API bereit.

Verteilte Anwendungen, speziell aus dem Hadoop- und Netflix-Universum, verwenden Zookeeper zur Speicherung, Verteilung und Aktualisierung wichtiger Konfigurationsinformationen. Zookeeper bietet eine Dateisystem-ähnliche Schnittstelle, die zentral und repliziert auf mehreren Knoten verfügbar ist.

Spring Cloud ist eine Sammlung verschiedener Ansätze, um die Herausforderungen von verteilten Systemen, wie sie bei der Entwicklung von Microservices entstehen, besser zu meistern. Spring Cloud setzt auf Spring Boot auf. Spring Cloud bietet eine recht einfache Möglichkeit zur Absicherung einer Anwendung mit OAuth2.

Spring Cloud Config stellt eine Lösung für die Konfiguration einer Microservices-Architektur dar. Es bietet ein zentralisiertes Konfigurationsmanagement, so dass alle im Netzwerk verteilten Microservices zentral konfiguriert werden können.

Netflix ist ein Pionier der Microservices-Architekturen und stellt viele Technologien für den Aufbau solcher Systeme zur Verfügung, z.B. Eureka, Hystrix, Ribbon, Feign oder Zuul. Spring Cloud Netflix integriert diese Technologien.

Spring Cloud Bus dient dazu, Anwendungen mit einem asynchronen Mechanismus zu verbinden. Intern nutzt Spring Cloud Bus das AMQP-Protokoll und als Implementierung RabbitMQ.

Das Service-API einer installierten Komponente ist ein weiterer Informationsdienst, der den aktuellen Status und Metriken liefert. Der Status zeigt an, dass eine Komponente innerhalb normaler Parameter funktionsfähig ist. Zu den wichtigsten Metriken zählen der aktuelle Speicherbedarf, die Nutzung von Threads oder anderer wichtiger Ressourcen eines Prozesses.

Mit Spring Boot können autonome (englisch: self contained) Java Anwendungen im Spring-Universum erstellt werden. Die erstellten Programme beinhalten alle benötigten Komponenten und Bibliotheken. Spring Boot Actuator ergänzt eine Reihe von fertigen REST-API für eine simple Statusabfrage (englisch: health check) oder erweiterbare Metriken.

Sehr hilfreich für den Betreiber einer Umgebung ist die genaue Kenntnis des Service-API. Die Komponente stellt selbst eine Dokumentation der verfügbaren Funktionen als Informationsdienst bereit.

Mit Swagger kann ein REST-API einfach und schnell zu dokumentiert werden. Das REST-API wird mit einer speziellen JSON-API-Datei spezifiziert. Zu Swagger gehört eine Benutzeroberfläche auf Basis von HTML/JavaScript. Zusätzlich bietet die Swagger die Möglichkeit, ein REST-API direkt zu testen.

Spring REST Docs kombiniert handgeschriebene Dokumentation mit automatisch erzeugten Fragmenten eines REST-API. Die mit Asciidoctor generierten Dokumente werden mit Spring Boot von der Komponente selbst bereitgestellt.

Datenstrukturen an den Schnittstellen von Komponenten werden in der Regel durch ein Schema technisch spezifiziert. Dabei geht es nicht nur um eine formale Beschreibung der Daten, sondern auch um Themen wie sprachunabhängige Serialisierung oder Schema-Evolution, d.h. beim Lesen der Daten kann eine andere Version des Schemas benutzen werden als beim Schreiben. Eine Schema-Registry ist ein Informationsdienst, der alle im Produkt verwendeten Schemas in der Umgebung bereitstellt.

Mit dieser sicherlich nicht vollständigen Liste von Hilfsmitteln können wir viele Informationen über die Komponenten des IT-Systems «online» in der Umgebung bereitstellen. Eine produktspezifische Zusammenstellung dieser Online-Dokumentation ist der Umgebungsübersicht. Bei der Gestaltung der Startseite ist es hilfreich, sich am Komponentenüberblick zu orientieren.

Fazit

Wichtige Ziele einer Betriebsorganisation sind stabiler Betrieb, schnelle Fehlerbehebung bei Störungen und bedarfsgerechte Erweiterung des IT-Systems. Mit einer aktuellen Übersicht über die Produktionsumgebung kann sie die notwendigen Aufgaben leichter organisieren. Entwickler und Tester profitieren von einer korrekten Übersicht über die nicht-produktiven Umgebungen. Mit dem Ansatz, die Übersicht direkt aus der lauffähigen Umgebung zu bilden, indem die Komponenten direkt aktuelle Daten liefern, haben wir automatisch die größtmögliche Sicherheit, die richtigen Informationen zur Umgebung zu bekommen. Gleichzeitig haben wir den geringsten Aufwand bei der Pflege, weil kaum separate Dokumentation notwendig ist.

  • Der Komponentenüberblick und die verknüpften Bausteine Domain, Service, Event und Entity aus der Produktdokumentation bilden den formalen Rahmen.
  • Die Service-Registry liefert den Status, die Konfiguration und Metriken jeder technischen Komponente.
  • Jede Schnittstelle einer Komponente wird von der Komponente standardisiert als Service-API dokumentiert. Datenstrukturen befinden sich zusätzlich als Schema in der Schema-Registry.
  • Weitere spezielle Informationen über die Komponente werden als Online-Hilfe von der Komponente individuell bereitgestellt.

Es gibt keine schlüsselfertige Lösung für eine Umgebungsübersicht. Ein kreatives Team kann mit Sicherheit eine angemessene Lösung finden, für das Team, aber auch für die Betriebsorganisation. Ganz im Sinn agiler Software-Entwicklung.