Was ist Infrastructure as Code für NetOps?
Während DevOps-Ansätze zunehmend in den Netzwerkbetrieb vordringen, bringen sie eine neue Terminologie mit sich. Diese Umgangssprache kann für NetOps, die noch nie damit in Berührung gekommen sind, verwirrend sein und kann IT-Führungskräfte verunsichern, die unter Druck gesetzt werden, diese Methodik zu übernehmen.
Dazu gehört das Konzept der Infrastruktur als Code. In der Welt der Entwickler umfasst die Infrastruktur in erster Linie die Plattformen, Server und Containersysteme, auf denen Apps bereitgestellt und skaliert werden. Bei der Infrastruktur handelt es sich in erster Linie um Rechenleistung.
Auf der anderen Seite der Mauer befindet sich eine breitere, robustere Infrastruktur, die neben der Datenverarbeitung auch Speicher, Sicherheit und Netzwerke umfasst. Schließlich gibt es vier Operationen, und alle müssen synchron ablaufen, um eine kontinuierliche Bereitstellung zu erreichen und die Art von Optimierung zu ermöglichen, die sich IT- und Unternehmensleiter von der digitalen Transformation erhoffen. Das bedeutet, dass Infrastruktur als Code in der Produktion ein viel breiteres Spektrum an Systemen, Geräten und Diensten umfasst als in der Entwicklung. Eine App-Bereitstellung bedeutet im Allgemeinen, dass die Infrastruktur in jedem der vier Vorgänge in irgendeiner Weise berührt wird. Dies macht die Infrastruktur als Code in der Produktion etwas schwieriger, hat aber auch größere Auswirkungen auf Effizienz und Geschwindigkeit.
Der Grund hierfür ist, dass durch Automatisierung die Wartezeiten zwischen den Übergaben entfallen können, die allzu oft zu Ineffizienzen bei Bereitstellungen führen, insbesondere dann, wenn manuelle Prozesse mit Urlaubs-, Krankheits- und Mittagspausen kollidieren.
Es ist ein Gleichnis
Infrastruktur als Code ist ein Gleichnis; das bedeutet, dass wir unsere Netzwerk- und Anwendungsdienstesysteme nicht wirklich (zumindest nicht jetzt) in Code umwandeln möchten, den wir erstellen und dann bereitstellen. Für die meisten Unternehmensorganisationen wäre das ein Unding und würde die Stabilität und Zuverlässigkeit des Unternehmensnetzwerks beeinträchtigen. Wir möchten jedoch die Vorteile eines Systems nutzen, das Konfigurationen und Profile von den Systemen entkoppelt, auf denen sie ausgeführt werden.
Das bedeutet, Konfigurationen, Richtlinien und Profile von der Hardware oder Software zu trennen, auf der sie bereitgestellt werden.
Diese Sammlung wird dann als „Bereitstellungsartefakt“ betrachtet und kann wie Code behandelt werden. Das heißt, sie können in Repositories gespeichert und verwaltet, versioniert und überprüft werden. Sie können auf die gleiche Weise abgerufen, geklont und festgeschrieben werden, wie ein Entwickler Code von und zu einem Repository (wie Github) abruft, klont und festschreibt.
Wir sollten auch „Automatisierungsartefakte“ einbeziehen. Dies sind die Skripte und zugehörigen Dateien, die Automatisierungsaufgaben beschreiben, die zu Ihrem ausgewählten Automatisierungs-Toolkit gehören. Wenn das Ansible ist, sind es Playbooks. Wenn es vom Chefkoch kommt, ist es ein Rezept. Für Puppet ein Manifest. Oder es könnte sich einfach um ein einfaches altes Python-Skript handeln.
Für BIG-IP und eine zunehmende Anzahl netzwerkgehosteter Systeme umfasst dies auch Vorlagen (iApp), die möglicherweise komplexere oder standardisiertere Konfigurationen weiter beschreiben. Die Verwendung einer Vorlage kann hier von Vorteil sein, da sie Optionen und Anwendungsdienste unterstützen kann, die vom Kern-Toolset möglicherweise noch nicht unterstützt werden.
Automatisierungsartefakte bilden zusammen mit den Bereitstellungsartefakten die Sammlung, die wir „Infrastruktur als Code“ nennen. Es wird davon ausgegangen, dass Sie ein System bereitstellen und anschließend einen Automatisierungsprozess dafür ausführen können, um es nach Wunsch zu konfigurieren.
In Kombination mit einem anwendungsspezifischen Ansatz für Netzwerk- und Anwendungsdienste kann ein Infrastruktur-als-Code-Ansatz das Risiko häufiger Bereitstellungen drastisch reduzieren. Indem Konfigurationen isoliert und ihre Auswirkungen auf ein einzelnes System beschränkt werden, werden die Folgen einer fehlgeschlagenen Bereitstellung praktisch eliminiert. Dies wiederum ermöglicht die Entwicklung von Zeitplänen für einzelne Anwendungen, die besser auf die geschäftlichen Erfordernisse und Anforderungen der Benutzer abgestimmt sind.
Für Cloud-orientierte Organisationen kann die Einführung eines Infrastruktur-als-Code-Ansatzes die Reibungspunkte bei der Migration vom Rechenzentrum in die Cloud oder von Cloud zu Cloud reduzieren. Da die Konfiguration vom System entkoppelt ist, kann sie scheinbar auf einem ähnlichen System an anderer Stelle eingesetzt werden.
Es gibt viele gute Gründe, sich die Mühe zu machen, auf einen Infrastructure-as-Code-Ansatz umzusteigen, und nur sehr wenige gute Gründe, dies nicht zu tun. Infrastruktur als Code ist eine der vorteilhaftesten Möglichkeiten, das agile Netzwerk zu realisieren, das Organisationen benötigen, um in einer Multi-Cloud- und App-gesteuerten digitalen Wirtschaft erfolgreich zu sein.