Die Technologien rund um containerisierte und Cloud-native Applikationen schreiten in rasantem Tempo voran. Doch unsere aktuelle Service Management Prozesslandschaft ist zumeist noch nicht agil genug, um diese zunehmende Geschwindigkeit und damit einhergehende Komplexität entsprechend zu beherrschen. Auf der einen Seite wird ein rasantes Tempo in Sachen Time to Market gefordert, um am Markt attraktiv zu bleiben, andererseits müssen die angebotenen Services stabil funktionieren. Dieses Spannungsfeld – Agilität versus Stabilität – bringt viele Herausforderungen mit sich. Einer davon wollen wir uns heute widmen: der Configuration Management Datenbank, kurz CMDB.
Im klassischen ITSM Umfeld ist die CMDB das Herzstück einer Service-Management-Lösung, welche jeden Service entsprechend dokumentiert und mit der alle Service-Management-Prozesse integriert sein müssen. ITIL beschreibt ein Configuration Management System, eine Configuraiton Management Database als die zentrale Komponente des IT Service Managements. Die CMDB hält klassischerweise alle relevanten Informationen (Configuration Items, CIs) und deren Abhängigkeiten untereinander bereit. Dadurch können Servicebäume, Service Level Agreements (SLAs), Verrechnungsmodelle oder einfach nur ein Inventory über bestehende Assets gepflegt und dargestellt werden.
Die CMDB in agilen Modellen mit Kubernetes
Auch in agilen Modellen und Systemen hat die CMDB für uns keineswegs an Relevanz verloren, dafür aber an Komplexität zugenommen. Während die Entwicklung und das Design von technischen Services immer agiler und zusehends mit Micro-Service- und Container-Technologien realisiert werden, fordern unsere Kundinnen und Kunden nach wie vor sehr häufig den Betrieb dem ITIL-Framework folgend.
Das ist auch nachvollziehbar, denn ITIL bietet standardisierte Prozesse und Abläufe und gibt beiden Seiten eine gewisse Sicherheit in Bezug auf den Betrieb der Services – Service Management basierend auf ITIL hat sich bislang absolut bewährt. Um die Services entsprechend anbieten zu können, bedarf es also nach wie vor einer gut gepflegten CMDB: Hier stellen sich nun drei Fragen:
- Wie pflege ich eine CMDB richtig?
- Welche Informationen soll eine CMDB enthalten?
- Wie halte ich eine CMDB aktuell?
Konkret wollen wir hier auf das Thema der Micro Services, die in Containern (Stichwort Kubernetes) verpackt sind, eingehen. Micro Services auf der einen Seite, bieten den riesigen Vorteil der schnellen, entkoppelten Entwicklung von einzelnen Modulen. Wird in einem speziellen Bereich einer Applikation eine Änderung erforderlich, müssen die Software-Entwicklerinnen und -Entwickler nur den jeweiligen Micro Service adaptieren, der Rest bleibt unberührt.
Container, auf der anderen Seite, erlauben es, Änderungen an Micro Services schnell umzusetzen und vor allem auch einzelne Services schnell zu skalieren. Ist die Auslastung zum Beispiel am Sonntag um 03:00 Uhr morgens gering, läuft der jeweilige Service auf nur zwei Containern. Beginnt die Last zu steigen, startet das System (automatisiert) zusätzliche Container und verteilt die Last entsprechend.
Automatische Ressourcenanpassung in der CMDB
Wir sind also, sowohl was Versionierung als auch Skalierung und Ressourcenbedarf von Services angeht, extrem flexibel – doch wie bilden wir diese Konstellation nun sinnvoll in der CMDB ab?
Zunächst der wichtigste Punkt: Automatisiert! Die Reconciliation, also der Ist-/Soll-Abgleich, muss automatisiert passieren. Und defakto auch in Echtzeit, da sich Container-basierte Strukturen sehr dynamisch verändern können. Wir sprechen in diesem Fall von "Event-Driven Architecture", das ist ein Themengebiet, bei dem sich ITIL und DevOps bzw. SRE (Site Reliability Engineering – ein Software-Engineering-Ansatz für IT-Operations) treffen und gut harmonisieren.
Während wir in ITIL ein Event unter anderem als eine Änderung mit Auswirkung auf ein CI kennen, gibt es im DevOps-/SRE-Umfeld mehr und mehr Ansätze, die sich für Event-Driven-Applikationen aussprechen, also Applikationen oder Teile davon, die speziell auf Events reagieren. Ein Beispiel im CI/CD Umfeld ist ein "Pull-Request", also das Zusammenführen von neuen und bestehenden Quellcodes – ein Event, das eine Pipeline zum Erstellen und Ausrollen der Applikation anstößt.
Geht es um die CMDB, wollen wir also genau hier einhaken: wir benötigen Events, die uns darauf aufmerksam machen, dass es eine relevante Änderung gab, welche eine Auswirkung auf unsere CMDB hat.
Das wollen wir nun bei Änderungen in unserer CMDB sehen. In der klassischen IT ist der Inhalt einer CMDB mittlerweile ein „Straight Forward Approach“. Von den physischen Lokationen und Servern, über virtuelle Server und darauf installierten Applikationen ist hier relativ klar, was wir pflegen sollten. Doch bei sich stetig ändernden Infrastrukturen wird das ein wenig komplizierter: ist es wirklich notwendig, jeden einzelnen Container zu pflegen und jeden darunterliegenden Server? Warum reagieren wir nicht auf jedes Event, legen neue Container einfach als CI an und bauen CIs abgebauter Container ebenfalls ab?
Die Gründe sind relativ simpel: ein CI alleine in der CMDB ist nicht wertvoll. Wertvoll wird es durch die Abhängigkeiten, die wir dazu pflegen. Neben einem schnell anwachsenden Datenfriedhof sind wir also permanent mit diesen Abhängigkeiten konfrontiert.
Was, wenn ein noch nicht gelöster Incident mit eben diesem CI verknüpft ist oder ein nicht abgeschlossener Change? Es gibt hier jede Menge Paradoxe, die es zu vermeiden gilt – wir brauchen eine andere Lösung.
Die Lösung für einen fiktiven Business Services „Onlineshop“
Wir sind im Grundsatz davon überzeugt, dass es hier kein Richtig und kein Falsch gibt und wollen Ihnen unsere Best Practices aufzeigen.
Sieht man sich das Thema anhand eines fiktiven Business Services „Onlineshop“ an, sehen wir neben der physischen Infrastruktur die dafür notwendigen Micro Services:
- Front-End-Service für die Interaktion mit den Anwenderinnen und Anwendern
- Benutzer-Service für die Verwaltung meiner Kundschaft und Benutzerinnen und Benutzer
- Lager-Service für die Verwaltung meiner Produkte und Lagerbestände
- Einkaufskorb-Service für die Verwaltung der getätigten Käufe und Lieferungen
An jedem dieser Micro Services haften gewisse Meta-Informationen über Version, Verfügbarkeit, Abhängigkeiten und auch Schwellwertbereiche. Die Anzahl der Micro Services für diesen Onlineshop bleibt sehr stabil, es sei denn wir erweitern den Shop um zusätzliche Features. Für die CMDB also ein idealer Ausgangspunkt.
Die zugehörigen Meta-Informationen sind der dynamische Teil, hier kommt die Event-Driven-Architektur ins Spiel, bei der wir diese Meta-Informationen bei jeder Änderung automatisch in der CMDB aktualisieren.
Bei NTT DATA haben wir sämtliche Kompetenzen für solche Themen in unsere Technology Services Line konzentriert, so arbeitet unser Digital Service Management Team sehr eng mit unseren DevOps Teams zusammen. Wir können Ihnen die perfekte Lösung, von der standardisierten Lösung verschiedenster Discovery Mechanismen zur Erstellung einer CMDB bis hin zu customized Lösungen für Ihre individuelle Landschaft anbieten.
Sollten wir Ihr Interesse für dieses spannende Thema geweckt haben, kontaktieren Sie mich gerne direkt.
Für die technisch interessierten Leserinnen und Leser unter Ihnen gibt es einen detaillierten Blogbeitrag auf meinem persönlichen LinkedIn Profil.