Wie bei jeder Technologie, die die Diskussionen rund um Rechenzentren dominiert, herrscht auch bei DevOps derzeit eine gewisse Definitionsmüdigkeit. Eigentlich würde ich inzwischen eher von Erschöpfung sprechen, doch die Grenze zwischen beidem ist schwer zu ziehen. Es genügt zu sagen, dass DevOps von einer allgemein anerkannten Definition ebenso weit entfernt ist wie Cloud und SDN.
DevOps zeichnet sich jedoch dadurch aus, dass auch die zugrunde liegenden Konzepte häufig verwechselt und miteinander vermengt werden. So kann CD beispielsweise für „Continuous Delivery“ oder „Continuous Deployment“ stehen. Diese beiden Konzepte sind nicht dasselbe und sollten weder verwechselt noch miteinander vermengt werden. Puppet Labs hat den Unterschied in einem Blogbeitrag:
Der entscheidende Unterschied besteht darin, ob die Bereitstellung in der Produktionsumgebung „manuell“ (Continuous Delivery) oder „automatisiert“ (Continuous Deployment) erfolgt.
Tatsache ist, dass hinter dem kleinen orangefarbenen Kästchen mit der Aufschrift „In der Produktionsumgebung bereitstellen“ ein erheblicher Arbeitsaufwand steckt, der automatisiert werden muss. Dabei geht es nicht nur um die Bereitstellung der Anwendung und ihrer Abhängigkeiten (Datenbanken, andere Dienste, Infrastruktur usw.). Es geht auch um die Bereitstellung aller Netzwerk- und Anwendungsdienste, die erforderlich sind, um diese Anwendung für den Endnutzer bereitzustellen. Hier kommen Anwendungsdienste ins Spiel, und hier wird die Anwendungsbereitstellung (im Sinne des Produktivbetriebs, nicht der Entwicklung) Teil der Continuous-Deployment-Pipeline.
Um den Schritt „Bereitstellung in der Produktionsumgebung“ innerhalb der Continuous-Deployment-Pipeline zu automatisieren, müssen zahlreiche Komponenten bereitgestellt, konfiguriert und getestet werden. Dazu gehören Dienste für grundlegende Netzwerkfunktionen, Sicherheit (z. B. Firewalls), Verfügbarkeit (Lastausgleich) und Leistung (Beschleunigung, Caching usw.). Im Durchschnitt nutzen Unternehmen 11 verschiedene Dienste zur Anwendungsbereitstellung, um ihren Bedarf an schnellen, sicheren und verfügbaren Anwendungen zu decken. Jeder einzelne Dienst muss bereitgestellt (provisioniert und konfiguriert) werden, wobei einige von der Bereitstellung anderer Dienste abhängig sind.
Jeder einzelne dieser Dienste (das ist ein bisschen wie das Rätsel von St. Ives, für alle, die mitraten) weist unterschiedlich viele Merkmale auf, die konfiguriert werden müssen. Optionen müssen aktiviert oder deaktiviert, Algorithmen ausgewählt, Routen eingerichtet werden usw. …
Mit anderen Worten: Der Wechsel von „manuell“ zu „automatisch“ ist bei Weitem nicht so einfach, wie es klingt.
Was hält das Netzwerk auf?
Ein wesentliches Hindernis bei der Automatisierung dieser Prozesse liegt in den Unterschieden zwischen gemeinsam genutzten und anwendungsspezifischen Komponenten. Infrastructure as Code ist im Bereich der Anwendungsinfrastruktur gerade deshalb möglich, weil wir einer Anwendung dedizierte Infrastruktur (wie einen Webserver oder Load Balancer) zuweisen können. Dadurch ähnelt die Konfigurationsdatei gewissermaßen einem Microservice: Sie ist lokal begrenzt und darauf ausgerichtet, Dienste für eine einzelne Anwendung bereitzustellen.
Wenn wir uns jedoch in die Welt der Netzwerke und Anwendungsdienste begeben, ist dies nicht immer der Fall. Ein Router oder Switch ist beispielsweise gezielt darauf ausgelegt, Konnektivitäts- und Weiterleitungsdienste für mehrere Anwendungen bereitzustellen. Das bedeutet, dass Konfigurationsdateien zwangsläufig mehrere Anwendungen umfassen. Eine Versionierung kann hier zwar hilfreich sein, doch in der Praxis sind Konfigurationen sehr eng an ein Gerät und nicht an eine Anwendung gebunden. Dasselbe gilt für Anwendungsdienste und Sicherheit.
So begrüßenswert es auch ist, dass wir uns alle auf eine Welt zubewegen, in der die API die CLI ist, müssen wir zugleich der Notwendigkeit Rechnung tragen, ein anwendungsbezogenes (oder, wenn Sie so wollen, anwendungszentriertes) Paradigma zu unterstützen, bei dem Konfigurationen für jede Anwendung einzeln verwaltet werden können.
Das bedeutet, dass wir uns hin zu einer Netzwerkarchitektur im Stil von Microservices bewegen müssen, in der Dienste für jede Anwendung separat bereitgestellt und konfiguriert werden. Dies kann entweder in Form dedizierter „Geräte“ erfolgen (virtuell oder als Hardware; die Bauform spielt für diese Diskussion keine Rolle) oder durch anwendungsspezifische Konfigurationen wie Vorlagen.
Sind wir schon so weit?
Wir kommen dem Ziel näher: Deklarative Modelle für die Bereitstellung und Verwaltung nutzen APIs, um Vorlagen anwendungsspezifisch bereitzustellen (das ist Infrastructure as Code). Doch ganz so weit sind wir noch nicht. Es bleibt noch viel zu tun, um herauszufinden, wie sich die für eine erfolgreiche kontinuierliche Bereitstellung erforderliche Automatisierung orchestrieren lässt.
Die Silos für Netzwerk, Infrastruktur, Anwendungsdienste und Sicherheit müssen einbezogen werden, wenn wir beim Schritt „Bereitstellung in der Produktionsumgebung“, der für den vollständigen Übergang von Continuous Delivery zu Continuous Deployment entscheidend ist, von „manuell“ zu „automatisch“ übergehen wollen. Das bedeutet mehr Arbeit auf der Automatisierungsebene sowie bei der übergreifenden Orchestrierung, die erforderlich ist, um die Prozesse vollständig zu automatisieren, die letztlich das Continuous Deployment in der Produktionsumgebung ermöglichen.
Ü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 ...