Deklarativ oder imperativ: Grundzüge des Konfigurations-Managements

Imperatives und deklaratives Konfigurations-Management

Imperatives Konfigurations-Management ist eine direkte Weiterentwicklung des Skriptings: Operations-Teams entwickeln dabei Deployment-Befehle in einer Art Programmiersprache. Dieser Ansatz funktioniert ganz gut bei der Anwendungsbereitstellung im eigenen Rechenzentrum, wo es vor allem um das Deployment der Anwendungen geht. Probleme mit bestimmten Applikationen werden dabei manuell gelöst.

Das deklarative Konfigurations-Management dagegen definiert das erwartete Resultat, nicht die hierfür nötigen Schritte. Im IT-Betrieb wird es immer wichtiger, sich von der bloßen Bereitstellung einer Anwendung hin zum umfassenden Application Lifecycle Management (ALM) zu bewegen. Diese neuen Anforderungen werden wesentlich besser durch ein Konfigurations-Management adressiert, das mit einem Idealzustand der erfolgreich bereitgestellten Anwendung startet. Beim deklarativen Konfigurations-Management steht also das Resultat des Bereitstellungsprozesses im Mittelpunkt, weil ja eben der richtige Betriebszustand im Zentrum der Aufmerksamkeit stehen sollte.

Beim deklarativen Modell analysiert das Konfigurations-Management-Tool den aktuellen Systemzustand und gleicht ihn mit dem anvisierten Endzustand ab, um anschließend automatisch alle notwendigen Schritte zur Erreichung dieses Ziels einzuleiten. Damit muss das Operations-Team nicht mehr jeden einzelnen möglichen Zustand einer Anwendung kennen und auf dieser Basis die nötigen Schritte definieren. Im Gegensatz dazu muss beim imperativen Konfigurationsmodell jeder einzelne Weg von falschen Konfigurationszuständen hin zum gewünschten Soll-Zustand vorgegeben werden, was schwer zu planen und in immer komplexeren Umgebungen fast nicht mehr zu realisieren ist.

Deklarative DevOps-Konzepte sind auf dem Vormarsch

Bei all dem ist es wenig verwunderlich, dass sich sogar einst eher imperative Tools mehr und mehr in Richtung deklarativem Konfigurations-Management entwickeln. Chef ist eines der bekanntesten imperativen Tools, wurde aber kontinuierlich um Modularität und Support für das Lifecycle-Management erweitert. Diese Veränderung hat Chef im Grunde zu einem deklarativen Tool gemacht – allerdings weniger mit einem Zielzustand, sondern eher mit Funktionen zum Suchen dieses Ziels. Um riesige Skript-Bibliotheken zu vermeiden, wurden die Funktionen zur Erreichung des gewünschten Zustandes einfach modularisiert, egal von welchem Zustandspunkt aus man startet.

Dieser Prozess funktioniert über die Wahrnehmung externer Ereignisse. Aber auch das deklarative Konfigurations-Management beruht auf dieser Event-Registrierung. Events sind für deklarative DevOps-Tools Signale dafür, dass etwas vom gewünschten Zielzustand abweicht, und bei imperativen Tools aktivieren sie Skripte oder den Zielzustand suchende Funktionen. Die Erwähnung von Events geht in der Softwareentwicklung fast immer einher mit gewünschten Zuständen, also mit den äußeren und inneren Bedingungen einer Applikation zum jeweiligen Event-Zeitpunkt.

Architekturen mit Beziehungen zwischen Zustand und Ereignissen sind vom Prinzip her immer deklarativ, weil sie ein System mit eingebauten Instruktionen aufsetzen, wie mit Ereignissen und Zustandsabweichungen umzugehen ist. Das Event-Handling ist so gesehen eine Bestätigung deklarativer Prozesse.

An ALM scheiden sich deklarative und imperative Tools

Das imperative Konfigurations-Management kümmert sich von einem starken Continuous-Delivery-Standpunkt aus um das Application Lifecycle Management. Die große Schwäche imperativer Tools gegenüber dem deklarativen Konfigurations-Management zeigt sich an der Schwierigkeit, die veränderte Anwendungsstruktur auch in den DevOps-Tools wahrzunehmen. Wenn ein Tool aktiv wird, um den gewünschten Systemzustand sicherzustellen, sich dieser Zielzustand aber jetzt aufgrund des Konfigurations-Management-Tools verändert, wie lange benötigt dann das DevOps-Tool, um diese Veränderung zu verarbeiten? Der Fokus auf Continuous Delivery bringt das imperative Konfigurations-Management mit dem am schwierigsten zu lösenden Problem des deklarativen Ansatzes zusammen.

Das deklarative Modell bietet einige Vorteile, und jeder ALM-Prozess setzt insgeheim auf diese Vorteile. Das Ziel der Softwareautomatisierung ist das einfachere Lifecycle-Management. Es ist nun mal einfacher, den Zielzustand einer Anwendung zu definieren und die Software den Rest erledigen zu lassen. Einfach ist immer besser.

Damit ist natürlich nicht gesagt, dass jede IT-Abteilung ihre imperativen DevOps-Tools los werden sollte. Imperative Tools entwickeln sich ja ebenfalls weiter, womit sich auch mit imperativen Tools mittlerweile recht überzeugende deklarative Systeme aufbauen lassen. Damit können IT-Abteilungen ihre vorhandenen Tools sehr schnell auf Anwendungsveränderungen einstellen.

Aber auch deklarative Tools entwickeln sich natürlich weiter. Das OASIS-Protokoll TOSCA (Topology and Orchestration Specification for Cloud Applications) beispielsweise ist ein deklaratives Modell, das sich in eine imperative Richtung bewegt. Es unterstützt zunehmend speziellere Anwendungsfälle und wird modularer, genau wie dies imperative Tools schon immer waren.

DevOps wird immer komplexer, insofern wachsen deklarative und imperative Tools immer weiter zusammen – aber sie tun dies mit einer klar deklarativen Schlagseite. Mit der steigenden Bedeutung des Internets der Dinge werden die Vorteile des einfachen, auf den Zielzustand ausgerichteten Ansatzes deklarativer Modelle immer offenkundiger werden.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!