beawolf - Fotolia
Deklarativ oder imperativ: Grundzüge des Konfigurations-Managements
Tools zum Konfigurations-Management lassen sich in deklarative und imperative Lösungen einteilen. Die größeren Vorteile bieten deklarative Tools.
Fast alle Versuche, die Unternehmens-IT CAPEX-effizienter zu machen, schlagen sich in höheren OPEX-Ausgaben nieder. Die offensichtliche Lösung für dieses Problem liegt in der Automatisierung von Anwendungs-Lebenszyklen, wodurch sich die manuelle Tätigkeit bei der Softwarebereitstellung sowie die Anzahl kostspieliger Fehler bei der Verwaltung virtueller Umgebungen reduzieren lassen.
DevOps-Tools scheinen wie gemacht für diese Automatisierungsaufgaben. Selbst in der ursprünglichen Form als Werkzeug zur Anwendungsbereitstellung und zur Integration von Entwicklung und IT-Betrieb waren DevOps-Lösungen schon ein Schritt vorwärts, weg von der Arbeit mit grundlegenden Betriebssystem-Skripten. Mit der zunehmenden Bedeutung von Virtualisierung und Cloud Computing hat sich der DevOps-Ansatz dann aber erst so richtig weiterentwickelt.
Konfigurations-Management ermöglicht DevOps-Prozesse über Entwicklung, Test und Operations hinweg. Dabei gibt es zwei verschiedene Ansätze: imperatives und deklaratives Konfigurations-Management. Der deklarative Ansatz ist dabei klar dem imperativen vorzuziehen, was sich mit Blick auf den Markt und die größeren Vorteile klar belegen lässt.
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.
Weitere Artikel zum Konfigurations-Management:
Konfigurations-Management mit Ansible
Lizenzierung, Support und Architektur von Chef
Skalierbares Konfigurations-Management mit Salt
Überblick über Puppet
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!
