Bei jedem Technologietrend gibt es Begriffe, die so schnell mit Hype überladen werden, dass sie praktisch unbrauchbar werden. Cloud war anfangs ein solcher Begriff. In gewisser Weise ist er es immer noch. Bei DevOps dauerte es mehrere Jahre, bis sich die Bedeutung geklärt hatte (sofern das überhaupt der Fall ist). Maschinelles Lernen und KI surfen derzeit barfuß auf der Hype-Welle und zeigen keinerlei Anzeichen, in absehbarer Zeit davon abgeworfen zu werden.
Dicht dahinter folgt „as Code“.
Plötzlich ist alles „as code“. Der Markt kann gar nicht genug von „as code“ bekommen, auch wenn die meisten Marktteilnehmer nicht einmal den Unterschied zwischen C, C++ und C# kennen. „As code“ ist zur Antwort auf das Leben, das Universum und den ganzen Rest geworden. Es gibt kein Problem, das sich nicht mit „as code“ lösen ließe, und alle machen mit.
Wenn Begriffe ohne klare Abgrenzung oder eindeutige Definitionen in den Raum geworfen werden, ist es wichtig, kurz innezuhalten und sicherzustellen, dass zumindest *unsere* Definitionen eindeutig sind. Es wäre schön, wenn es ein Normungsgremium gäbe, auf dessen Definition im RFC-Stil man sich berufen könnte, doch das gibt es nicht. Am ehesten kommt dem noch das NIST nahe – und wir haben gesehen, wie gut es ihm gelungen ist, das Cloud-Dilemma aus der Welt zu schaffen.
„As Code“ umfasst mehr als nur Infrastructure as Code (IAC). Aiman Najjar von Pythian hat einen hervorragenden Überblick über die aktuelle Infrastructure-as-Code-Landschaft verfasst. Zwar bin ich nicht seiner Meinung, dass Container eine eigene Ebene bilden sollten (aus Sicht der Netzwerk- und Anwendungsdienste handelt es sich lediglich um Infrastruktur) und dass Jenkins dort nicht hingehört, doch insgesamt bot sein Blog eine ausgezeichnete Möglichkeit, die Zusammenhänge zwischen den verschiedenen „As Code“-Ebenen zu verstehen und die passenden Tools den jeweiligen Aufgaben zuzuordnen. Zudem konzentrieren sich die meisten Diskussionen über Infrastructure as Code auf Continuous Delivery – also auf die Pipeline, die eine Anwendung erstellt, testet, integriert und für den Produktivbetrieb freigibt. Dies ist nicht derselbe Prozess wie Continuous Deployment, bei dem die freigegebene Anwendung zusammen mit den erforderlichen Netzwerk- und Anwendungsdiensten in einer Produktionsumgebung bereitgestellt wird.
HINWEIS In der idealen App-Welt sind die Bereitstellungs- und Deployment-Pipelines zusammengeführt. Doch die meisten von uns leben (noch) in der App-Realität, in der Produktions- und Entwicklungsumgebungen voneinander getrennt sind und jeweils unterschiedliche Anforderungen und Einschränkungen gelten. Daher müssen wir diese Trennung berücksichtigen, wenn wir die Pipeline automatisieren.
Es gibt drei klar voneinander abgegrenzte Ebenen, die den Besonderheiten der IT und der Deployment-Pipeline Rechnung tragen. An erster Stelle steht dabei die inhärente Komplexität der Umgebung. Die gerade Linie vom Client zur Anwendung, die wir in Netzwerkdiagrammen zeichnen, täuscht niemanden. Unter der Haube passiert schlicht viel mehr, als wir mit der uns zur Verfügung stehenden Zeit (und Geduld) in einem Diagramm darstellen können.
Die Vielfalt der Pipeline selbst – die sowohl speziell entwickelte Hardware als auch auf handelsüblicher Standardhardware (COTS) bereitgestellte virtuelle und containerbasierte Software umfasst – ist ebenfalls ein Grund dafür, den „As Code“-Ansatz in separate Schichten zu unterteilen. Zwar lässt sich modernere Hardware mit einem As-Code-Ansatz verwalten, doch ältere (gemeinsam genutzte) Hardware kann sich nahezu unmöglich in diesen Prozess integrieren lassen. Eine Trennung der Schichten, die den Bereitstellungsprozess selbst genauer abbildet, kann daher eine Möglichkeit bieten, sowohl ältere als auch moderne hardwarebasierte Lösungen zusammen mit softwarebasierten Diensten in die Pipeline einzubeziehen.
Ziel ist es, einen durchgängigen IT-Stack aufzubauen, der anwendungsspezifische Bereitstellungspläne und -architekturen in einer Multi-Cloud-Umgebung unterstützt. Da die Bereitstellung jedoch nur den Anfang des aktiven Lebenszyklus einer Anwendung darstellt, ist eine vierte Ebene erforderlich, die sich auf den Betrieb nach der Bereitstellung konzentriert. Diese ergänzt die drei Kernschichten für die Bereitstellung und Einbindung der Infrastruktur, die Konfiguration und Verwaltung von Diensten sowie die Bereitstellungspipeline.
Die Liste der Tools ist nicht als vollständig anzusehen. Es gibt viele weitere Tools und Toolsets. So wissen wir beispielsweise aus mehreren Umfragen und Studien, dass die Mehrheit der NetOps für die Automatisierung von Netzwerk- und Anwendungsdiensten maßgeschneiderte Python-Skripte bevorzugt. Außerdem wissen wir, dass Netzwerkautomatisierungssysteme und -Stacks wie Cisco ACI, VMware NSX, OpenStack und Red Hat OpenShift beliebte Mittel sind, um viele Funktionen im Continuous-Operations-Stack umzusetzen. In der Abbildung ist schlicht nicht genug Platz, um jedes Tool aufzunehmen. Daher wurde eine Auswahl berücksichtigt, die auf der Beliebtheit der Tools bei DevOps basiert. Der Grund dafür ist, dass die Standardisierung über die gesamte Bereitstellungs- und Deployment-Pipeline hinweg eine wesentliche Voraussetzung für den Erfolg sein wird. Zudem spricht vieles dafür, die in Ihrem Unternehmen bereits vorhandenen Fähigkeiten und Fachkenntnisse im Umgang mit den Tools zu nutzen, die am häufigsten zur Implementierung von „as Code“-Bereitstellungspipelines eingesetzt werden. Anzumerken ist, dass ich keine Tools für „Operations as Code“ aufgeführt habe, da viele davon maßgeschneidert (benutzerdefinierte Skripte) oder spezifisch für die Technologie eines bestimmten Anbieters sind – zumindest vorerst.
HINWEIS „Operations as Code“ ist das IT-Pendant zum Geschäftsprozessmanagement (Business Process Management, BPM). Mit BPM werden Geschäftsprozesse automatisiert. Einige BPM-Ansätze konzentrieren sich ausschließlich auf ganz bestimmte Arbeitsabläufe, während andere die gesamte Kundeninteraktion vom Kauf über die Zahlung bis hin zur Lieferung abdecken. „Operations as Code“ ist heute noch eine junge Praxis in der IT. Sie muss sich jedoch zu einem Management betrieblicher Prozesse weiterentwickeln, damit Unternehmen von der Optimierung dieser Prozesse ebenso profitieren können, wie sie gelernt haben, die Vorteile von BPM zu nutzen.
Continuous-Operations-Stack
Infrastruktur als Code (IaC)
Ob in der Cloud oder im Rechenzentrum – es gibt immer ein Netzwerk, das konfiguriert werden muss. Selbst höher angesiedelte Dienste (die auf den Schichten 4–7 arbeiten, auch als Anwendungsdienste bezeichnet) benötigen für ihren Betrieb gewisse Kenntnisse der Netzwerktopologie. Einige davon müssen möglicherweise aktiviert (d. h. lizenziert) werden, wenn Sie eine völlig neue Pipeline bereitstellen. Infrastructure as Code ist notwendig, um einen Self-Service-Ansatz für die Bereitstellung zu ermöglichen, denn ohne die entsprechende Infrastruktur (Software und Dienste) gibt es nichts, was konfiguriert werden könnte, und keine Umgebung, in der eine Anwendung bereitgestellt werden könnte.
Verantwortlichkeiten: Infrastruktur-Onboarding, Lizenzierung, Bereitstellung
Konfiguration als Code (CaC)
Dies ist ein von der Konfiguration getrenntes Thema. Bei der Konfiguration geht es konkret darum, Richtlinien und Verhaltensweisen für den jeweiligen Dienst festzulegen. Eine Konfiguration kann bei jeder größeren Anwendungsaktualisierung erneut erforderlich sein – möglicherweise auch bei jeder kleineren Aktualisierung. Bei sicherheitsrelevanten Diensten kann sie zudem kurzfristig notwendig werden, um einen bestimmten Dienst zu patchen, zu aktualisieren oder auf eine neue Version zu bringen. Configuration as Code ist entscheidend, um anwendungsspezifische Bereitstellungspläne und -pipelines zu unterstützen und die Isolierung der Datenpfade einzelner Anwendungen durchzusetzen, die für die Stabilität der gesamten Produktionspipeline wichtig ist.
Verantwortlichkeiten: Service-Konfiguration, -Upgrade und -Patching
Pipeline als Code (PaC)
Dann gibt es noch den übergreifenden Prozess, der die gesamte Anwendung und ihre Services von Anfang bis Ende definiert. Dabei handelt es sich um die vollständige Pipeline, die als ausführbarer Prozess in Code abgebildet ist und das Deployment automatisch steuert. Pipeline as Code ist das Bindeglied zwischen IaC und CaC und führt beide zu dem zusammen, was wir als Deployment-Pipeline bezeichnen. In der Pipeline lassen sich die größten Geschwindigkeits- und Effizienzsteigerungen erzielen, da sie Wartezeiten zwischen den erforderlichen Prozessschritten beseitigt.
Verantwortlichkeiten: Automatisierung des Bereitstellungsprozesses automation
Operations as Code (OaC)
Diese Ebene ist die fortlaufende Betriebsebene. Hier finden Überwachung und Alarmierung, automatische Skalierung und Erkennung statt. Auf dieser Ebene geht es darum, Betriebsprozesse in einem System abzubilden, das sie selbstständig ausführen kann. Die automatische Skalierung gehört zu den am häufigsten kodifizierten Betriebsprozessen und umfasst mehrere Systeme. Doch auch die Erfassung von Telemetriedaten zur Analyse ist ein Betriebsprozess, der Aufmerksamkeit erfordert. Gleiches gilt für mögliche Maßnahmen auf Grundlage dieser Telemetriedaten, die (automatische) Anpassungen zur Optimierung des Datenpfads oder der Anwendungsleistung ermöglichen. Diese Betriebsprozesse verfügen über eine eigene Konfiguration und kommen nach Abschluss des Bereitstellungsprozesses zum Einsatz.
Verantwortlichkeiten: Automatisierung operativer Workflows automation
Die Betrachtung von Continuous Deployment aus der Perspektive des Continuous Operations Stack ermöglicht einen strategischen Ansatz zur Automatisierung der Produktionspipeline. Durch die Trennung der Ebenen und Verantwortlichkeiten lässt sich die äußerst anspruchsvolle Aufgabe, IT-Abläufe zu automatisieren, leichter so angehen, dass der von vielen Unternehmen gewünschte und von den Fachbereichen zunehmend geforderte Self-Service-Ansatz ermöglicht wird. Zudem eröffnet dies über Operations as Code einen Weg hin zu Continuous Operations – eine notwendige Weiterentwicklung beim Einsatz von Automatisierung in der IT.
Nun mag dies vielleicht nicht der „einzig wahre Weg“ sein, die mit der Deployment-Pipeline verbundenen Automatisierungsmaßnahmen zu betrachten. Aber es ist eine mögliche Sichtweise, die es den Marktteilnehmern ermöglicht, klar zu kommunizieren, was sie leisten und was nicht.
Das bedeutet, dass Sie genau wissen, was ich meine, wenn ich von „Infrastructure as Code“ oder „Configuration as Code“ spreche, insbesondere im Hinblick auf Produkte von F5.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...