Als Code: Der Continuous-IT-Stack
Bei jedem Technologietrend gibt es Begriffe, die schnell so sehr gehypt werden, dass sie praktisch nutzlos werden. Am Anfang war Cloud einer davon. In gewisser Weise ist das immer noch so. Es hat mehrere Jahre gedauert, DevOps zu klären (falls das überhaupt der Fall ist). Maschinelles Lernen und KI surfen derzeit barfuß auf der Hype-Welle und es gibt keine Anzeichen dafür, dass sie bald aussterben werden.
Dicht dahinter folgt „as code“.
Plötzlich ist alles „wie Code“. Der Markt kann nicht genug von „als Code“ bekommen, auch wenn die meisten den Unterschied zwischen C, C++ und C# nicht erkennen. „Als Code“ ist die Antwort auf das Leben, das Universum und den ganzen Rest geworden. Es gibt kein Problem, das sich nicht „als Code“ lösen lässt, und jeder macht es.
Wenn mit Begriffen ohne Grenzen oder klare Definitionen um sich geworfen wird, ist es wichtig, dass wir innehalten und sicherstellen, dass uns *unsere* Definitionen klar sind. Es wäre schön, wenn es ein Normungskomitee mit einer Definition im RFC-Stil gäbe, auf die man zurückgreifen könnte, aber das gibt es nicht. Das NIST ist uns am nächsten und wir haben gesehen, wie gut sie das Cloud-Dilemma lösen konnten.
„As-Code“ ist mehr als nur Infrastruktur als Code (IAC). Aiman Najjar @ Pythian hat einen großartigen Überblick über die aktuelle Infrastruktur-als-Code-Landschaft geschrieben . Ich bin zwar nicht der Meinung, dass Container eine eigene Ebene darstellen sollten (aus der Perspektive der Netzwerk- und Anwendungsdienste handelt es sich lediglich um Infrastruktur) und Jenkins dort nicht dazugehört. Insgesamt war sein Blog jedoch eine hervorragende Möglichkeit, die Beziehung der „As Code“-Ebenen zu verstehen und die richtigen Tools für die richtige Aufgabe zuzuordnen. Außerdem konzentrieren sich die meisten Diskussionen zu „Infrastructure as Code“ auf die kontinuierliche Bereitstellung – also die Pipeline, die eine App erstellt, testet, integriert und für die Produktion freigibt. Dies ist nicht derselbe Prozess wie die kontinuierliche Bereitstellung , bei der es darum geht, die veröffentlichte Anwendung zusammen mit den erforderlichen Netzwerk- und Anwendungsdiensten in einer Produktionsumgebung bereitzustellen.
HINWEIS: In der App-Utopie werden die Liefer- und Bereitstellungspipelines zusammengeführt. Aber die meisten von uns leben (immer noch) in der App-Realität, in der Produktion und Entwicklung getrennte Umgebungen mit unterschiedlichen Anforderungen und Einschränkungen sind. Daher müssen wir diese Trennung berücksichtigen, wenn wir Automatisierung auf die Pipeline anwenden.
Es gibt drei unterschiedliche Ebenen, die die der IT und der Bereitstellungspipeline innewohnenden Eigenheiten abdecken. Der wichtigste Grund hierfür ist die der Umgebung innewohnende Komplexität. Die gerade Linie vom Client zur App, die wir in Netzwerkdiagrammen zeichnen, täuscht niemanden. Unter der Haube passiert einfach viel mehr, als wir zeitlich (und geduldig) in Diagrammen darstellen können.
Die Vielfalt der Pipeline selbst – die sowohl speziell entwickelte Hardware als auch virtuelle und containerbasierte Software umfasst, die auf COTS bereitgestellt wird – bietet auch den Anstoß für das Aufteilen und Zerlegen des Codes in einzelne Schichten. Während modernere Hardware über einen As-Code-Ansatz verwaltet werden kann, kann es nahezu unmöglich sein, ältere (gemeinsam genutzte) Hardware in den Prozess zu integrieren. Durch die Trennung der Schichten, um den Bereitstellungsprozess selbst genauer widerzuspiegeln, können sowohl ältere als auch moderne hardwarebasierte Lösungen zusammen mit softwarebasierten Diensten in die Pipeline aufgenommen werden.
Das Ziel besteht darin, einen kontinuierlichen IT-Stack aufzubauen, der Bereitstellungspläne und Architekturen für einzelne Apps in einer Multi-Cloud-Umgebung unterstützen kann. Und weil die Bereitstellung nur den Anfang des aktiven Lebenszyklus einer Anwendung darstellt, ist eine vierte Ebene erforderlich, die sich auf Vorgänge nach der Bereitstellung konzentriert. Dies kommt zu den drei Kernebenen hinzu, die die Bereitstellung und Einarbeitung der Infrastruktur, die Konfiguration und Verwaltung von Diensten sowie die Bereitstellungspipeline abdecken.
Die Liste der Tools ist nicht als vollständig anzusehen. Es gibt noch viele weitere Werkzeuge und Werkzeugsätze. Beispielsweise wissen wir aus mehreren Umfragen und Untersuchungen, dass die Mehrheit der NetOps maßgeschneiderte Python-Skripte für die Automatisierung von Netzwerk- und Anwendungsdiensten bevorzugt. Und wir wissen auch, dass Netzwerkautomatisierungssysteme und -Stacks wie Cisco ACI, VMware NSX, OpenStack und Red Hat OpenShift beliebte Mittel zur Implementierung vieler Funktionen im Continuous-Operations-Stack sind. Da in der Abbildung einfach nicht genug Platz ist, um alle Tools aufzunehmen, wurde eine Auswahl basierend auf der Beliebtheit der Tools bei DevOps aufgenommen. Dies liegt daran, dass die Standardisierung der gesamten Bereitstellungs- und Implementierungspipeline ein wesentlicher Erfolgsfaktor ist und es kaum ein Argument dagegen spricht, die in Ihrem Unternehmen vorhandenen Fähigkeiten und Fachkenntnisse mit den am häufigsten verwendeten Tools zur Implementierung von Bereitstellungspipelines „als Code“ zu nutzen. Bemerkenswerterweise habe ich keine Tools für „Operationen als Code“ aufgelistet, da viele davon – zumindest im Moment – maßgeschneidert (benutzerdefinierte Skripts) oder spezifisch für eine Anbietertechnologie sind.
HINWEIS: Operations as Code ist das IT-Äquivalent zum Business Process Management (BPM). Mit BPM werden Geschäftsprozesse automatisiert. Einige BPM konzentrieren sich ausschließlich auf sehr spezielle Arbeitsabläufe, andere decken die gesamte Dauer einer Kundeninteraktion vom Kauf über die Zahlung bis zur Lieferung ab. „Operations as Code“ ist in der IT heute noch eine junge Praxis, muss sich aber zu einem operativen Prozessmanagement weiterentwickeln, wenn Unternehmen in der Lage sein sollen, aus der Optimierung operativer Prozesse auf die gleiche Weise Kapital zu schlagen, wie sie es bei BPM gelernt haben.
Kontinuierlicher Operations-Stack
Infrastruktur als Code (IaC)
Egal ob in der Cloud oder im Rechenzentrum, es muss immer ein Netzwerk konfiguriert werden. Sogar für die Ausführung höherwertiger Dienste (auf den Schichten 4 bis 7 ausgeführte Dienste, auch Anwendungsdienste genannt) sind gewisse Kenntnisse der Netzwerktopologie erforderlich. Wenn Sie eine brandneue Pipeline bereitstellen, muss eines davon möglicherweise aktiviert (d. h. lizenziert) werden. Infrastruktur als Code ist erforderlich, um einen Self-Service-Ansatz für die Bereitstellung zu ermöglichen, da ohne die vorhandene Infrastruktur (Software und Dienste) nichts vorhanden ist, wofür eine App konfiguriert oder bereitgestellt werden kann.
Verantwortlichkeiten: Infrastruktur- Onboarding, Lizenzierung, Bereitstellung
Konfiguration als Code (CaC)
Dies ist ein anderes Problem als die Konfiguration, bei der es insbesondere um die Notwendigkeit geht, Richtlinien und Verhalten speziell für den betreffenden Dienst zu konfigurieren. Die Konfiguration muss möglicherweise bei jedem größeren Anwendungsupdate erneut durchgeführt werden. Es kann auch bei jedem kleineren Update erneut auftreten. Bei sicherheitsrelevanten Diensten kann es im Notfall erforderlich sein, einen bestimmten Dienst zu patchen, zu aktualisieren oder aufzurüsten. Die Konfiguration als Code ist von entscheidender Bedeutung für die Unterstützung von Bereitstellungsplänen und Pipelines für einzelne Apps sowie für die Durchsetzung der Isolierung von Anwendungsdatenpfaden, die für die Gewährleistung der Stabilität der gesamten Produktionspipeline wichtig ist.
Zuständigkeiten: Servicekonfiguration , Upgrade und Patch
Pipeline als Code (PaC)
Dann gibt es den übergreifenden Prozess, der die gesamte Anwendung und ihre Dienste von Anfang bis Ende definiert. Es handelt sich um die gesamte Pipeline, und sie ist in einem ausführbaren Prozess kodifiziert, der die Bereitstellung automatisch steuert. Pipeline as Code ist die Verbindung zwischen IaC und CaC, die diese zusammenhält und das beschreibt, was wir eine Bereitstellungspipeline nennen. In der Pipeline lassen sich die größten Geschwindigkeits- und Effizienzgewinne erzielen, da hier Wartezeiten zwischen den im Prozess erforderlichen Schritten entfallen.
Verantwortlichkeiten: Automatisierung des Bereitstellungsprozesses
Operationen als Code (OaC)
Diese Schicht ist die laufende Betriebsschicht. Hier finden Überwachung und Alarmierung, automatische Skalierung und Erkennung statt. In dieser Schicht geht es uns darum, Betriebsprozesse in einem System zu kodifizieren, das in der Lage ist, sie selbstständig auszuführen. Die automatische Skalierung ist einer der am häufigsten kodifizierten Betriebsvorgänge und umfasst mehrere Systeme. Doch auch das Erfassen von Telemetriedaten zu Analysezwecken ist ein weiterer Betriebsvorgang, der Aufmerksamkeit erfordert, ebenso wie die auf Grundlage dieser Telemetriedaten möglichen Maßnahmen, die (automatische) Anpassungen zur Optimierung des Datenpfads oder der Anwendungsleistung ermöglichen. Diese Betriebsabläufe haben ihre eigene Konfiguration und kommen nach Abschluss des Bereitstellungsprozesses zum Einsatz.
Aufgaben: Automatisierung operativer Arbeitsabläufe
Die Betrachtung der kontinuierlichen Bereitstellung aus der Perspektive des kontinuierlichen Betriebsstapels kann einen strategischen Ansatz zur Automatisierung der Produktionspipeline bieten. Durch die Trennung der Ebenen und Verantwortlichkeiten lässt sich die äußerst schwierige Aufgabe der Automatisierung von IT-Aufgaben leichter angehen und zwar auf eine Weise, die den von vielen Organisationen gewünschten und von der Geschäftswelt zunehmend geforderten Self-Service-Ansatz ermöglicht. Darüber hinaus ermöglicht es einen Weg zum kontinuierlichen Betrieb über Operationen als Code, was eine notwendige Weiterentwicklung bei der Nutzung der Automatisierung in der IT darstellt.
Nun ist dies möglicherweise nicht die einzig richtige Möglichkeit, die mit der Bereitstellungspipeline verbundenen Automatisierungsbemühungen zu betrachten. Aber es ist eine Möglichkeit und sie bietet dem Markt die Möglichkeit, klar zu kommunizieren, was er tut oder nicht tut.
Das bedeutet, dass Sie sicher sein können, was ich meine, wenn ich von Infrastruktur als Code oder Konfiguration als Code spreche, insbesondere in Bezug auf F5-Produkte.