Deklarative vs. imperative Modelle für das Konfigurationsmanagement: Was ist wirklich besser?

Als eine Gruppe von Konzepten hat sich DevOps auf mehrere prominente Themen konzentriert, darunter kontinuierliche Softwarebereitstellung, Automatisierung und Konfigurationsmanagement (CM). Diese integralen Bestandteile bilden oft die Säulen der DevOps-Bemühungen eines Unternehmens, auch wenn andere größere Teile wie übergreifende Best Practices und Richtlinien noch erprobt und getestet werden. Da DevOps ein relativ neues Paradigma - Bewegung - Methodik - [hier Ihr eigenes Etikett einfügen] ist, müssen die Standards dafür noch kodifiziert und in Stein gemeißelt werden. Unternehmen müssen Tools und Ansätze identifizieren, die für ihre Anwendungsfälle am besten geeignet sind, und werden sie je nach Erfolg entweder beschwören oder verunglimpfen.

In Bezug auf CM ist es eine Selbstverständlichkeit, dass eine bestimmte Methodik für ein Unternehmen funktionieren kann, für ein anderes jedoch nicht. Selten erzeugen unterschiedliche Ansätze jedoch so viel Dissens wie die deklarativen und imperativen Modelle für CM. Die immer wiederkehrende Debatte darüber, was überlegen ist, hat auf beiden Seiten treue Anhänger gefunden und verdient eine genauere Betrachtung.

Definieren von deklarativen und imperativen Modellen

Die Unterschiede zwischen dem deklarativen und dem imperativen Modell lassen sich in einem Satz zusammenfassen: Der Imperativ konzentriert sich auf das Wie und der Deklarativ auf das Was. Im Kontext der Softwareentwicklung bedeutet deklarative Programmierung, Code zu schreiben, um zu beschreiben, was das Programm tun soll, im Gegensatz dazu, wie es es tun sollte. Die eine beschreibt, was passieren muss; Die Details, um dies zu erreichen, bleiben dem System überlassen. Im Gegensatz dazu geht es bei der imperativen Programmierung darum, Code zu schreiben, der expliziten Schritten folgt, um ein Problem zu lösen, eine Aufgabe zu erledigen oder ein gewünschtes Ergebnis zu erzielen. Es geht darum, dem System genau zu sagen, wie es etwas tun soll, in der Erwartung, dass das gewünschte Ergebnis erzielt wird.

Imperative/deklarative Konstrukte werden auch auf IT-Domänen wie CM übertragen. Tatsächlich wird der Ansatz eines bestimmten CM-Tools stark von der zugrunde liegenden Sprache beeinflusst, auf der es aufgebaut wurde (die wiederum von Natur aus entweder zwingend oder deklarativ ist).

Puppet zum Beispiel ist deklarativ: Der Systemadministrator beschreibt einen gewünschten Endzustand und das Tool versucht, ihn zu erreichen. Die domänenspezifische Sprache (DSL) wird verwendet, um allgemeine Beschreibungen des gewünschten Serverstatus zu erstellen, im Gegensatz zu Anweisungen und Aktionen, die ausgeführt werden sollen. Manifeste - Marionettendateien, die Konfigurationsinformationen enthalten - können beliebig oft verwendet werden, um die gleichen Ergebnisse zu erzielen. Wenn der gewünschte Endzustand bereits erreicht ist, ignoriert Puppet das betreffende Element einfach. Der Benutzer muss sich nur um den gewünschten Endzustand des zu konfigurierenden Systems kümmern, nicht um die Abfolge der Schritte, die erforderlich sind, um dorthin zu gelangen.

Dieser Eintrag beschreibt einen Endzustand, der eine Datei namens /tmp/test123 mit dem Inhalt "This is a test " enthält. Wenn eine übereinstimmende Datei (und Inhalte) auf dem Zielsystem gefunden werden, geht Puppet davon aus, dass der gewünschte Endzustand bereits erreicht wurde. In der Folge muss man sich keine Sorgen mehr machen, dass das Manifest dieses Stück mehrmals ausführt.

Im Gegensatz dazu ist Chef (Puppets Erzfeind) unerlässlich. Benutzer definieren Befehle und ihre Ausführungsreihenfolge in Konfigurationsanweisungen, die als Rezepte bezeichnet werden und zur einfacheren Verwaltung wiederum in Rezeptbüchern organisiert werden können.

Dieses Rezept sucht auf dem Zielknoten nach JDK 7 - falls vorhanden, installiert Chef OpenJDK 7. Ist dies nicht der Fall, wird eine Warnung ausgegeben. Beachten Sie, dass Chef-Rezepte als sequenzielle Listen von Befehlen strukturiert sind, im Gegensatz zu Marionetten-Manifesten, die nur Beschreibungen der gewünschten Endzustände enthalten.

Ein wachsender Trend unter den CM-Anbietern ist es, ihre Angebote für beide Modelle zu öffnen und damit die Herzen beider Lager zu gewinnen. Selbst Tools wie Chef, die in erster Linie von Natur aus unerlässlich sind, können deklarativ eingerichtet werden.

Im Gegensatz zum vorherigen Beispiel beschreibt das obige Rezept einen gewünschten Endzustand, anstatt eine Reihe von Befehlen aufzulisten, die ausgeführt werden sollen.

Welches Modell ist also besser für CM? Um diese Frage zu beantworten, muss man sich für das Wer und Was qualifizieren. Angesichts des aktuellen Buzz-Levels und der Akzeptanzrate von DevOps ist es keine Überraschung, dass Experten immer ausgefeilter werden: Die Gespräche über DevOps haben sich von dem, was es ist, zu der Art und Weise entwickelt, wie man es macht. Und wie das geht, hängt davon ab, wen Sie fragen.

Analysieren wir die Debatte daher aus drei Perspektiven: der eines Programmierers, eines Systemadministrators und eines Full-Stack-Entwicklers.

Der Programmierer, der leidenschaftlich gerne effizienten, strukturierten und leicht verständlichen Code schreibt, ist nicht der größte Fan von deklarativen Modellen, die unhandliche Abstraktionen verwenden. Er ist es gewohnt, mit for-Schleifen, bedingten Anweisungen, Variablen und dergleichen zu diktieren, wie etwas geschehen soll. Die Geschäftslogik der Software, an der er arbeitet, ist meist zwingender Natur.

Beste Lösung: Imperative CM-Tools wie Chef

Der Systemadministrator führt gerne einen engen Betrieb, und das aus gutem Grund: Wenn die Infrastruktur ausfällt, kommt das Unternehmen zum Stillstand. Er ist ein Bash-Zauberer, beherrscht Python und Perl und zieht es vor, sie zu verwenden, anstatt neue Sprachen wie Ruby zu lernen. Er bevorzugt das deklarative Modell gegenüber dem imperativen Modell, ist sich aber der Herausforderungen bewusst, die es bei der Verwaltung dynamischer Cloud-Infrastrukturen mit sich bringt.

Beste Lösung: Hybride CM-Tools wie Ansible oder SaltStack

Der Full-Stack-Entwickler kann den Stack mit Leichtigkeit durchlaufen und liebt die Idee, die Infrastruktur auf Code zu abstrahieren. Sie ist ein Ruby/RoR-Ninja und ein Fan von Chef und Puppet. Sie weiß die Vorzüge jedes Modells zu schätzen; Für sie ist es bei beiden Arten von Tools so, dass sie kontinuierlich qualitativ hochwertige Software schneller, effizienter und weniger fehleranfällig entwickelt und veröffentlicht.

Beste Passform: Beide Modelle. Puppet, Chef und SaltStack sind praktikable Optionen.

Beachten Sie, dass unser Programmierer genauso wahrscheinlich ein Python-Profi sein könnte und daher sehr gut mit Ansible umgehen kann (dessen Module in Python geschrieben sind). In jedem Fall ist die Abstimmung der IT-Fähigkeiten eines Unternehmens auf das geeignete Modell/Tool ein pragmatischer Ansatz, um festzustellen, welches besser geeignet ist. Wenn sich ein Unternehmen mit traditioneller Softwareentwicklung mit Programmierern an der Spitze beschäftigt, ist ein unverzichtbares Tool möglicherweise die beste Wahl. Ein schnelllebiges SaaS-Unternehmen mit einem Zeitplan für kontinuierliche Rollouts wird die Flexibilität und Skalierbarkeit einer gut implementierten deklarativen CM-Lösung zu schätzen wissen. Ein Geschäft, das auf Ruby schwört und noch dazu über das Know-how verfügt, kann sich dafür entscheiden, mit bestimmten Werkzeugen zu "kochen" und sich damit über die Modelldebatte hinwegsetzen.

Ein wichtiger Punkt, den Sie sich merken sollten, ist, dass sowohl deklarative als auch imperative Modelle fehlbar sind: Ersteres erfordert das Vertrauen, dass die gewünschten Zustände erreicht wurden (mit wenigen Mitteln zur Überprüfung), während letzteres eine komplizierte Fehlerbehebung erfordert, wenn etwas schief geht. Beide Modelle können in bestimmten Edge-Szenarien problematisch sein. In der Folge sollte kein einzelnes Tool als A und O für CM implementiert werden, unabhängig davon, welcher Ansatz gewählt wurde. Die gewählte Lösung sollte stattdessen nur einen Teil der CM-Toolchain umfassen, während eine andere sie als Overwatch abrundet und sicherstellt, dass alle CM- und Automatisierungstools wie erwartet funktionieren.

UpGuard dient diesem Zweck: Durch die Bereitstellung vollständiger Systemtransparenz durch robuste Scan-, Überwachungs- und Vergleichsfunktionen schließt unsere Plattform die entscheidende Lücke zwischen der Erwartung, dass Ihre Systeme/Umgebungen auf eine bestimmte Weise sind, und der tatsächlichen Überprüfung, ob sie diese Erwartungen erfüllt.

Kurz gesagt, konkurrierende Anbieter, die um Verstand und Marktanteile wetteifern, werden sich leidenschaftlich für den jeweiligen Ansatz ihres Angebots einsetzen. Obwohl die Debatten um deklarative/imperative Modelle im kommerziellen CM-Bereich ein neues Maß an Intensität und Inbrunst annehmen, ist die Wahrheit, dass viele Werkzeuge Qualitäten aus beiden besitzen - auch wenn sie möglicherweise stärker auf einem Modus basieren. Daher ist es vielleicht nützlicher, sich das deklarative und das imperative Modell als ein Spektrum von Möglichkeiten vorzustellen, wobei die jeweiligen Lösungen näher an beiden Enden liegen.

Quellen

• https://searchitoperations.techtarget.com/news/2240187079/Declarative-vs-imperative-The-DevOps-automation-debate
• https://sharknet.us/2014/02/15/automated-configuration-management-language-choice/
• https://devops.com/approaches-to-application-release-automation/
• https://networkenhancers.blogspot.com/2014/10/what-is-difference-between-declarative.html
• https://cloudn1n3.blogspot.com/2014/11/from-devops-to-puppet-part-2.html
• https://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/
• https://ifireball.wordpress.com/2015/01/03/comparison-of-puppet-and-ansible/
• https://docs.saltstack.com/en/latest/ref/states/ordering.html