Zeit für NetOps, Continuous Deployment einzuführen

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Continuous Deployment muss nicht bedeuten, dass jede Änderung jedes Mal sofort bereitgestellt wird. Aber irgendwo muss man damit anfangen.

CI/CD (Continuous Integration/Continuous Delivery) ist die Domäne der Entwickler. Es ist das übergreifende Modell zur Beschleunigung der Bereitstellung – wobei dies für diejenigen, die den Begriff aus einem aktiveren, nutzerbezogenen Kontext kennen, eigentlich „bereit für die Bereitstellung“ bedeutet.

Das bedeutet nicht, dass NetOps CI/CD ignorieren kann. Ganz im Gegenteil. Es bedeutet aber auch nicht, dass NetOps jedes zur Bereitstellung freigegebene Release sofort bereitstellen muss. Die Häufigkeit, mit der Apps „bereit für die Bereitstellung“ sind, kann überwältigend sein – insbesondere dann, wenn Ihre App-Entwickler Continuous Delivery perfektioniert haben, NetOps die Kunst des Continuous Deployment jedoch noch nicht ganz beherrscht. Es besteht aber durchaus Spielraum für häufigere Bereitstellungen, die sich für Entwickler und das Unternehmen in manchen Fällen sicherlich wie Continuous Deployment anfühlen werden.

Das Geheimnis liegt in der Unterscheidung zwischen „kleineren Änderungen“ und „größeren Änderungen“ an einer Anwendung.

Die NetDevOps-Umfrage vom Herbst 2016 ergab, dass kleinere Änderungen wesentlich häufiger in die Produktionsumgebung eingespielt wurden, als oft angenommen wird. Fast 51 % der Befragten spielen kleinere Änderungen mehrmals täglich in die Produktionsumgebung ein. Mehr als jeder Dritte spielte ein- bis fünfmal pro Monat größere Änderungen ein, während ein weiteres Drittel angab, größere Änderungen seltener als einmal im Monat vorzunehmen.

Leider ist nicht näher definiert, was unter „größeren“ und „kleineren“ Änderungen zu verstehen ist. Wie so oft sind solche relativen Bezeichnungen jedoch nicht nur branchen- oder unternehmensspezifisch, sondern häufig sogar anwendungsspezifisch. Dennoch scheint eine beträchtliche Anzahl – etwas mehr als die Hälfte – sehr regelmäßig größere Änderungen in der Produktionsumgebung bereitzustellen.

Das bedeutet, dass wir im Großen und Ganzen kleine Schritte in Richtung Continuous Deployment machen. Allerdings ist die Bereitstellung einer brandneuen Anwendung nicht dasselbe wie die Bereitstellung von Updates für eine bestehende Anwendung. Selbst wenn wir neue Netzwerk- oder Anwendungsdienste hinzufügen, unterscheidet sich dies auf der Skala des „Störungspotenzials“ noch erheblich von der Bereitstellung einer völlig neuen Anwendung.

Gehen wir also vorerst davon aus, dass brandneue Anwendungen mehr Abstimmung und Planung erfordern. Damit bleiben immer noch die Anwendungen, die mit Sicherheit den Großteil der produktiv eingesetzten Anwendungen ausmachen, als potenzielle Kandidaten für Continuous Deployment übrig. Eine Möglichkeit, dies zu fördern, besteht darin, „kleinere“ und „größere“ Änderungen in einen gewissen Kontext zu setzen im Hinblick auf ihre Auswirkungen auf Produktionsumgebungen.

Kleinere Änderungen könnten auf solche beschränkt werden, die sich intern auf die App auswirken, beispielsweise Änderungen an der Logik. Dazu könnten Patches oder Upgrades des App-Stacks (Webserver, App-Server usw.) sowie der unterstützenden App-Infrastruktur gehören. Grundsätzlich wirken sich kleinere Änderungen nur auf die App aus. Sie erfordern keine Änderungen am Netzwerk oder an den App-Diensten, die diese App bei ihrer üblichen Nutzung bereitstellen und absichern.

Größere Änderungen wären demnach solche, die sich auf Komponenten im Netzwerk oder auf App-Dienste auswirken, welche die App unterstützen. Größere Änderungen können Anpassungen an einer Bereitstellungsrichtlinie (Komprimierung einschalten, ja?) oder die Einbindung eines neuen Dienstes erfordern, etwa URL-Filterung oder die Überprüfung von Anfragen, um die Ausnutzung einer kürzlich entdeckten Schwachstelle zu verhindern. Diese Änderungen gelten als größere Änderungen, da sie sich auf eine breitere Palette von Produktionssystemen auswirken, die wiederum möglicherweise auch andere Anwendungen beeinträchtigen.

Möglicherweise entwickeln Sie sogar ein differenzierteres Bewertungssystem, das die Auswirkungen auf externe Dienste berücksichtigt. Ein neuer Dienst ist wahrscheinlich mit größeren Beeinträchtigungen verbunden als eine Anpassung an einem bestehenden Dienst. Die Implementierung einer neuen Richtlinie erfordert mehr Aufmerksamkeit als eine geringfügige Aktualisierung einer bestehenden Richtlinie.

Sobald Sie sich auf das zu verwendende „System“ geeinigt haben, fällt es wesentlich leichter, kleinere Änderungen bei Bedarf zuzulassen. Im Grunde gehen Sie damit zu Continuous Deployment über, indem Sie die Bereitstellung von Anwendungen für die Produktionsumgebung freigeben, solange davon ausgegangen wird, dass die potenziellen Auswirkungen im Falle eines Fehlers minimal sind. Kleine Änderungen, geringes Risiko. Zumindest ist das die Annahme.

Dadurch können kleinere technische Änderungen, die möglicherweise erhebliche geschäftliche Auswirkungen haben, schneller zu den Nutzern gelangen. Denn in großen, traditionellen Unternehmen werden solche Änderungen oft ausgebremst. Selbst eine kleine Änderung an der Benutzeroberfläche kann aufgrund von Terminkonflikten und Entscheidungen der Änderungskontrollgremien, die auf Projektprioritäten oder internen Machtverhältnissen beruhen, wochenlang – oder noch länger – aufgehalten werden. Und das, obwohl diese kleine Änderung das Benutzererlebnis verbessern und dadurch die Konversions- oder Kundenbindungsrate erhöhen könnte. Wenn diese kleine Änderung nur die App betrifft, es sich also um eine „kleinere“ Änderung handelt, ist die IT-Politik dann wirklich ein Grund, sie aufzuhalten?

Continuous Deployment ermöglicht nicht nur technisch automatisierte Übertragungen in die Produktionsumgebung, sondern bedeutet auch, traditionelle Strukturen abzubauen, die die Prozesse verzögern, mit denen festgelegt wird, wann Anwendungen und Updates in die Produktionsumgebung gelangen (das ist Kultur).

Durch die Festlegung gemeinsamer Kriterien zur Unterscheidung zwischen „kleineren“ und „größeren“ Updates – also zwischen Änderungen, die sich potenziell auf Systeme außerhalb der App auswirken können, und solchen, bei denen dies nicht der Fall ist – können Unternehmen Continuous Deployment für bestimmte Änderungen ermöglichen, ohne zusätzliche Risiken einzugehen oder die Produktionsumgebung zu destabilisieren. Und möglicherweise wirkt sich das sogar positiv auf das Geschäft aus – dann gewinnen alle.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

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