Application und die CD-Pipeline
Wie jede Technologie, die die Diskussionen in Rechenzentren dominiert, leidet DevOps derzeit unter Definitionsmüdigkeit. Eigentlich denke ich, dass es mittlerweile an Erschöpfung liegt, aber die Grenze zwischen beidem ist schwer zu ziehen. Es genügt zu sagen, dass DevOps ebenso weit davon entfernt ist, eine allgemein akzeptierte Definition zu haben wie Cloud und SDN.
Die Besonderheit von DevOps besteht jedoch darin, dass die damit verbundenen Konzepte häufig verwechselt und vermischt werden. CD kann beispielsweise als die Bedeutung von „Continuous Delivery“ oder „Continuous Deployment“ verstanden werden. Diese beiden sind nicht dasselbe und sollten weder verwechselt noch vermengt werden. Puppet Labs hat den Unterschied in einem Blog-Beitrag hervorragend veranschaulicht:
Sie werden feststellen, dass der entscheidende Unterschied darin besteht, ob die Bereitstellung in der Produktion „manuell“ (kontinuierliche Bereitstellung) oder „automatisiert“ (kontinuierliche Bereitstellung) erfolgt.
Der Punkt ist, dass in diesem kleinen orangefarbenen Kästchen mit der Aufschrift „In Produktion bringen“ eine Menge Arbeit steckt, die automatisiert werden muss. Dabei handelt es sich nicht nur um die Bereitstellung der App und ihrer Abhängigkeiten (Datenbanken, andere Dienste, Infrastruktur usw.). Es geht auch darum, alle Netzwerk- und Application bereitzustellen, die erforderlich sind, um diese Application dem Endverbraucher bereitzustellen . Hier kommen Application ins Spiel und die Application (im Sinne der Produktion, nicht im Sinne der Entwicklung) wird in die Continuous-Deployment-Pipeline integriert.
Um den Schritt „In der Produktion bereitstellen“ innerhalb der Continuous-Deployment-Pipeline zu automatisieren, müssen viele bewegliche Teile bereitgestellt, konfiguriert und getestet werden. Dies umfasst alles von grundlegenden Netzwerk- und Sicherheitsdiensten (wie Firewalls) bis hin zu Verfügbarkeitsdiensten (Lastausgleich) und Leistungsdiensten (Beschleunigung, Caching usw.). Im Durchschnitt nutzen Organisationen 11 verschiedene Application , um ihren Bedarf an schnellen, sicheren und verfügbaren Applications zu decken. Jedes muss bereitgestellt (bereitgestellt und konfiguriert) werden und einige sind von der Bereitstellung anderer abhängig.
Jeder dieser Dienste (das ist wie das St. Ives-Rätsel, für diejenigen unter Ihnen, die mitspielen) hat eine unterschiedliche Anzahl von Eigenschaften, die konfiguriert werden müssen, Optionen müssen auf „true“ oder „false“ gesetzt, Algorithmen ausgewählt, Routen eingerichtet usw. werden.
Mit anderen Worten: Die Umstellung von „manuell“ auf „automatisch“ ist bei weitem nicht so einfach, wie es klingt.
Was hält das Netzwerk auf?
Ein erhebliches Hindernis bei der Automatisierung dieser Prozesse sind die Unterschiede zwischen gemeinsam genutzten und pro App verfügbaren Komponenten. Infrastruktur als Code ist im Bereich der App-Infrastruktur möglich, gerade weil wir einer Application Infrastruktur (wie einen Webserver oder einen Load Balancer) widmen können. Das bedeutet, dass die Konfigurationsdatei so etwas wie ein Mikrodienst ist: Sie ist lokalisiert und darauf ausgerichtet, Dienste für eine Application bereitzustellen.
Wenn wir in die Welt der Netzwerke und App-Dienste wechseln, ist dies nicht immer der Fall. Ein Router oder Switch beispielsweise ist dafür ausgelegt, Konnektivitäts- und Weiterleitungsdienste für mehrere Applications bereitzustellen. Das bedeutet, dass Konfigurationsdateien notwendigerweise mehrere Applications umfassen. Obwohl die Versionierung hier hilfreich sein kann, bleibt die Tatsache bestehen, dass Konfigurationen sehr stark an ein Gerät und nicht an eine App gebunden sind. Dasselbe gilt für App-Dienste und -Sicherheit.
Obwohl es also schön und gut ist, dass wir uns alle in Richtung einer Welt bewegen, in der die API die CLI ist, müssen wir uns auch mit der Notwendigkeit auseinandersetzen, ein Pro-App-Paradigma (oder, wenn Sie so wollen, App-zentriertes Paradigma) zu unterstützen, in dem Konfigurationen auf Pro- Anwendungsbasis verwaltet werden können.
Dies bedeutet, dass wir uns entweder in Richtung einer Netzwerkarchitektur im Microservices-Stil bewegen müssen, in der die Dienste für jede App einzeln bereitgestellt und konfiguriert werden. Dies kann entweder die Form dedizierter „Geräte“ (virtuell oder Hardware, der Formfaktor ist für die Zwecke dieser Diskussion irrelevant) oder app-spezifischer Konfigurationen wie Vorlagen annehmen.
Sind wir schon da?
Mit deklarativen Modellen für die Bereitstellung und Verwaltung, die APIs nutzen, um Vorlagen (das ist Infrastruktur als Code) auf Anwendungsbasis bereitzustellen, kommen wir diesem Ziel näher, aber so weit sind wir noch nicht. Es bleibt noch viel zu tun, um herauszufinden, wie die für eine erfolgreiche kontinuierliche Bereitstellung erforderliche Automatisierung orchestriert werden kann.
Wenn wir den Schritt „Bereitstellung in der Produktion“ durchführen möchten, der für den Abschluss der Umstellung von der kontinuierlichen Bereitstellung zur kontinuierlichen Bereitstellung entscheidend ist, müssen Netzwerk, Infrastruktur, App-Dienste und Sicherheitssilos einbezogen werden, wenn wir von „manuell“ auf „automatisch“ umsteigen möchten. Und das bedeutet mehr Arbeit auf der Automatisierungsebene sowie die übergreifende Orchestrierung, die erforderlich ist, um die Prozesse vollständig zu automatisieren, die letztendlich die kontinuierliche Bereitstellung in die Produktion überführen.