Wie IaC zusammen mit Composable Infrastructure funktioniert
Durch die große Flexibilität beim Zusammenstellen von Ressourcen ist Composable Infrastructure die optimale Grundlage für den Einsatz von IaC in der Anwendungsbereitstellung.
Ein großer Vorteil von Composable Infrascture ist, dass sie sich durch die modulare Architektur gut für den Einsatz gemeinsam mit Infrastructure as Code (IaC) eignet. Dabei handelt es sich um eine Methode zum automatischen Bereitstellen und Konfigurieren von Ressourcen anhand von Definitionsdateien.
Infrastruktur als Code hilft IT-Abteilungen bei der Bewältigung von Herausforderungen, die mit der Bereitstellung moderner Anwendungen einhergehen und die mit traditionellen Infrastrukturansätzen nur schwer zu bewältigen sind.
Durch die Kombination von Infrastructure as Code mit einer Composable Infrastructure müssen Administratoren IT-Ressourcen nicht mehr manuell bereitstellen und konfigurieren, um Anwendungsanforderungen zu erfüllen. Dies trägt dazu bei, Kosten zu senken, die Zeit bis zur Markteinführung zu verkürzen und die Konsistenz zwischen den Umgebungen zu fördern.
Doch bevor IT-Teams mit dem Implementieren von IaC auf einer Composable-Plattform beginnen, sollten sie verstehen, wie Infrastruktur als Code funktioniert und wie sie sich in das Gesamtbild einfügt.
Die Vorteile von Infrastruktur-als-Code verstehen
Infrastructure as Code kommt Entwickler- und Administratorenteams zugute, da sie die automatische Bereitstellung von Technologie-Stacks durch Software ermöglicht. Das funktioniert über maschinenlesbare Definitionsdateien, die mit höheren Codiersprachen erstellt werden. Entwicklerteams können ihre Anwendungen mit solchen Definitionsdateien zusammen erstellen, um eine automatische Bereitstellung auf sie angepasster Ressourcen zu gewährleisten. Außerdem können sie die IaC- und die Anwendungsdateien im selben Versionierungs-Repository speichern.
Entwickler und Administratoren können IaC zum Bereitstellen und Konfigurieren einer breiten Palette von Rechen-, Speicher- und Netzwerkressourcen, einschließlich Virtueller Maschinen (VMs) und VPNs, verwenden. Sie können außerdem die Installation von Software wie Datenbanksystemen automatisieren und Sicherheitseinstellungen wie Zugriffskontrollen automatisch überprüfen oder anpassen lassen. Definitionsdateien sind nicht dasselbe wie Skripte, wie sie viele IT-Abteilungen verwenden, um sich wiederholende, statische Schritte zu automatisieren.
Wenn sie Definitionsdateien erstellen, geben die Entwickler an, welche Ressourcen zur Unterstützung der Anwendung erforderlich sind. Definitionsdateien können überprüfen, ob eine Umgebung ordnungsgemäß konfiguriert ist, angeben, wie die Umgebung einzurichten ist, oder eine Kombination aus beidem.
Tools, die IaC unterstützen, verwenden die Dateien dann zur Bereitstellung und Konfiguration. Als Teil dieses Prozesses unterstützen die Tools auch Operationen wie Orchestrierung und Überwachung. IaC leistet also mehr als die einfache Automatisierung mit Skripten und trägt dazu bei, den Betrieb während des gesamten Lebenszyklus einer Anwendung zu rationalisieren.
IaC-Tools verwenden in der Regel eine Push- oder Pull-Methode zum Bereitstellen und Verwalten von Ressourcen. Bei der Push-Methode sendet ein zentralisierter Controlling-Server die Informationen an die Ressourcen, die konfiguriert werden müssen.
Bei der Pull-Methode fordern die Ressourcen die Konfigurationsinformationen vom steuernden Server an. Viele Tools verwenden standardmäßig die eine oder die andere Methode, unterstützen aber prinzipiell beide. Ansible ist beispielsweise standardmäßig auf das Push-Modell eingestellt, kann aber auch für die Verwendung des Pull-Modells konfiguriert werden.
Infrastruktur-als-Code-Tools verfolgen in der Regel einen deklarativen oder imperativen Ansatz. Einige Tools unterstützen beide Modelle. Der deklarative Ansatz konzentriert sich auf das beabsichtigte Ergebnis und überlässt es der IaC-Software, die zum Erreichen des gewünschten Zustands erforderlichen Schritte zu bestimmen.
Der imperative Ansatz definiert eine Folge von Befehlen, die das Tool ausführen muss, um den gewünschten Zustand zu erreichen. Zum Beispiel ist das Automatisierungswerkzeug Chef in erster Linie ein imperatives Werkzeug, unterstützt aber auch deklarative IaC.
Sowohl das Push- und Pull-Modell als auch das deklarative und das imperative Modell haben jeweils ihre Vor- und Nachteile und werden kontrovers diskutiert. Organisationen, die IaC-Tools anschaffen wollen, sollten die Unterschiede zwischen diesen Ansätzen vollständig verstehen und wissen, welche davon am besten zu ihrer Umgebung passen.
Dabei sind die Ansprüche der Anwendungen, die sie ausführen wollen, den Grad an Fachwissen, über den sie verfügen, und die Technologien, die sie bereits verwenden, wichtige Entscheidungsfaktoren.
Vorteile von DevOps und Infrastruktur-als-Code
IaC kann eine Reihe von Vorteilen bieten, insbesondere wenn es um DevOps geht. Tatsächlich betrachten viele DevOps-Teams IaC als einen wesentlichen Bestandteil zur Rationalisierung des Betriebs, da sie sich nahtlos in die kontinuierliche Integrations- und Bereitstellungs-Pipeline (Continuous Integration/Continuous Deployment, CI/CD) einfügen kann (siehe Abbildung 2), so dass während der gesamten Entwicklungs-, Test-, Staging- und Bereitstellungsphase konsistente Anwendungsumgebungen zur Verfügung stehen.
Die IaC-Konfigurationsdateien befinden sich zusammen mit den Anwendungsdateien in der Versionenkontrolle. Das schützt nicht nur die IaC-Dateien, sondern trägt auch dazu bei, die Bereitstellung der Infrastruktur und die Anwendungsentwicklung zu einem einheitlicheren Prozess zu verbinden. Die Versionenkontrolle gewährleistet eine konsistentere Anwendungsumgebung über alle Einsatzbereiche hinweg und bietet gleichzeitig den Vorteil einer sicheren Quellenkontrolle, Transparenz, mehr Klarheit bei Zuständigkeiten und vollständige Rückverfolgbarkeit aller Änderungen.
Darüber hinaus kann IaC die Risiken reduzieren, die von Cyberattacken, Naturkatastrophen oder Personalwechsel ausgehen, da der Bereitstellungsprozess in den IaC-Definitionsdateien selbst dokumentiert ist, die zusammen mit den Anwendungsdateien bereitgehalten werden. Zu den möglichen Vorteilen von Infrastructure as Code gehören auch Kosteneinsparungen, da sie den Zeit- und Arbeitsaufwand für die Bereitstellung der Infrastruktur reduziert und gleichzeitig zu einer besseren Auslastung der Ressourcen beiträgt als bei herkömmlichen Ansätzen.
All diese Vorteile können Unternehmen jedoch nur ausschöpfen, wenn sie über die zusätzlichen Fähigkeiten und Werkzeuge für die Implementierung verfügen. Unter Umständen kann die schnell ansteigende Komplexität Mitarbeiter überfordern. Fehler können sich schnell über Umgebungen hinweg ausbreiten und viele der Vorteile von IaC untergraben. Menschliche Fehler bedeuten ein großes Risiko bei manuellen Änderungen am System und gefährden Anwendungsbereitstellungen.
Organisationen, die IaC in ihre Prozesse integrieren wollen, müssen sicherstellen, dass sie verstehen, wie es funktioniert, und sich durch entsprechende Schulung der Teilnehmer angemessen auf die Implementierung vorbereiten.
Konvergente Rechenzentren und IaC
Die Auswahl der richtigen Werkzeuge ist für einen erfolgreichen IaC-Einsatz entscheidend. Aber das ist nicht alles. Eine Organisation muss auch über die Infrastruktur verfügen, um IaC verwenden zu können.
In der Vergangenheit benutzten Unternehmen in Rechenzentren meist mehrschichtige Architekturen zum Hosten und Bereitstellen von Anwendungen (siehe Abbildung 3). Dieser Ansatz war jedoch nicht flexibel, ineffizient und führte zu einer schlechten Ressourcenauslastung.
Obwohl Virtualisierung dazu beitrug, die Verwaltung zu rationalisieren und die Ressourcen besser auszulasten, änderte sie wenig an der grundlegenden Natur des mehrschichtigen Ansatzes.
Als moderne Anwendungen ihren Weg in das Rechenzentrum fanden, brachten sie größere Komplexität mit sich. Sie erforderten schnellere Implementierungen und dynamischere Arbeitsabläufe. Unternehmen mussten ihre Architekturen anpassen, um das leisten zu können.
Konvergente Infrastruktur trug dazu bei, die Belastung der IT zu reduzieren, aber sie wies viele Probleme auf, die bereits im traditionalen Rechenzentrum auftraten, zum Beispiel Over-Provisioning und mangelnde Flexibilität. Hyperkonvergente Infrastruktur (Hyper-converged Infrastructure, HCI) half dabei, einige dieser Probleme zu überwinden, indem sie einen softwaredefinierten Ansatz in die Infrastruktur einbrachte, aber der Mangel an Flexibilität und Over-Provisioning sorgten immer noch häufig für Beschwerden. Bei letzterem schaffte disaggregierte HCI einige Erleichterungen, erreichte jedoch nicht das erforderliche Maß an Agilität.
Eine Composable Infrastructure bietet mehr Flexibilität und eine effizientere Ressourcennutzung als konvergente Systeme. Sie abstrahiert durch eine Software-defined Umgebung die physischen Ressourcen und stellt sie als eine Reihe einheitlicher Dienste dar.
Benutzer können diese Ressourcen dann dynamisch zusammenstellen und neu zusammensetzen, um Anwendungsanforderungen zu erfüllen, unabhängig davon, ob sie auf Bare-Metal-Systemen, in Containern oder in VMs laufen. Intelligente Software verwaltet die Infrastruktur, weist Ressourcen zu und automatisiert die Bereitstellung von Diensten.
Durch die Disaggregation der physischen Ressourcen und deren Darstellung als Dienste bietet Composable Infrastructure eine äußerst flexible Umgebung und Unternehmen, die moderne Workloads ausführen, eine Reihe von Vorteilen.
Die zusammensetzbare Architektur kann schwankende Anforderungen besser berücksichtigen und Ressourcen effizienter nutzen. Sie kann auch mehr verschiedene Typen von Workloads ausführen, sogar auf Bare-Metal, was die Abhängigkeit von bestimmten Hypervisoren aufhebt. Darüber hinaus muss eine Composable Infrastructure nicht für die Workloads vorkonfiguriert werden, da die Ressourcen nach Bedarf zusammengestellt werden, und die integrierte Automatisierung und Orchestrierung den Verwaltungsaufwands reduziert.
All diese Merkmale machen Composable Infrastructure zum logischen Partner für IaC. Manchmal verwenden Unternehmen sogar den Begriff Infrastructure as Code, wenn sie eigentlich Composable Infrastructure meinen, weil die beiden Konzepte so eng miteinander verbunden sind. Das ist jedoch irreführend.
Besser ist es, Composable Infrastructure als eine Erweiterung von IaC zu betrachten. Sie liefert eine softwaredefinierte Infrastruktur, die physische Ressourcen mit wenig bis gar keinem menschlichen Eingriff automatisch steuert und Aufgaben der Bereitstellung, Konfiguration und Verwaltung durchführt. Systeme mit einer Composable-Architektur bieten auch eine umfassende Management-API, die es Tools von Drittanbietern ermöglicht, mit der Umgebung zu kommunizieren. All das ist ideal für Infrastructure as Code.
IaC und Composable Infrastructure
Durch die Verwendung von IaC gemeinsam mit einer Composable Infrastructure verfügen DevOps-Teams über eine Reihe flexibler Bausteine für das Zusammensetzen und den Umbau von Ressourcen nach Bedarf. Dadurch können IT-Profis die Infrastruktur so implementieren, dass sie ihre Workloads optimal hosten können.
Sie erstellen dafür IaC-Konfigurationsdateien, welche die Anforderungen der Anwendung definieren. Die IaC-Tools stellen dann anhand dieser Dateien in der Composable Infrastructure Ressourcen zusammen.
Tools für Infrastructure as Code haben eine Schnittstelle mit der Verwaltungs-API der Infrastruktur, die eine Vielzahl von Aufgaben wie Suche, Inventarisierung, Bereitstellung, Diagnose und Aktualisierung ausführen kann.
Mit IaC und einer Composable Infrastructure können DevOps-Teams jeden Teil der Umgebung über Code steuern und so sicherstellen, dass ihre Anwendungen immer über die benötigten Ressourcen verfügen, während sie zeitgleich viel Verwaltungsaufwand einsparen, der mit dem physischen Management der einzelnen Komponenten einhergeht.
Gemeinsam können Infrastructure as Code und Composable Infrastructure ein System bilden, das die ideale Grundlage für moderne Workloads bietet.
