Das DevOps-Pendel: Agilität vs. Kontrolle
Von: Cindy Blake am 2. August 2023
Die Verwaltung von Änderungen an Cloud-Ressourcen ist für viele technische Führungskräfte heute ein allgemeines Problem, trotz aller Fortschritte bei Tools und Praktiken wie GitOps. Denn in Wirklichkeit ist es einfach unmöglich, immer alles komplett abzuriegeln – wir leben nicht in einer Utopie ohne Zwischenfälle. Wenn Ihre technische Organisation verhindert, dass Änderungen über die Cloud-Konsole oder an Ihrer Infrastructure-as-Code (IaC) vorgenommen werden, ohne strenge GitOps-Praktiken oder Änderungsmanagementprozesse über CI/CD einzuhalten, dann haben Sie wahrscheinlich sehr frustrierte Entwickler – Entwickler die nicht in Echtzeit Fehler beheben oder debuggen können und bei einem realen Vorfall kaum Kontrolle haben.
Beim Ingenieurwesen kommt es, wie bei allem anderen im Leben, vor allem auf das Gleichgewicht an.
Die Pandemie hat eine völlig neue Denkweise und Praxis für die Verwaltung verteilter und hochschneller Technik und Abläufe geschaffen. Über Nacht mussten Unternehmen, die nicht auf Remote-Arbeitsweisen ausgelegt waren, ihre Geschäftstätigkeit auf eine globale, verteilte und asynchrone Weise fortsetzen, mit der sie nicht ganz vertraut waren. Dies erforderte eine neue Denkweise bei der Softwarebereitstellung – und beschleunigte die DevOps-Praktiken, die diese Bereitstellung unterstützen. Die Self-Service-Infrastruktur beseitigte Hürden für Entwickler, um eine kontinuierliche Leistung und Geschwindigkeit sicherzustellen.
Gleichzeitig kann Ihre Cloud nicht der Wilde Westen sein, in dem jeder eine maßgeschneiderte Infrastruktur erstellt. Die Verwaltung wird unmöglich und Fehlkonfigurationen können riskant sein. Leitplanken und Richtlinienautomatisierung sind zu einem heißen Thema geworden. Heute, da die Tech-Märkte schwach sind und die Cloud-Kosten steigen, scheint es einen wachsenden Trend zu geben, die Dinge wieder abzuriegeln, selbst auf die Gefahr hin, Entwickler zu frustrieren.
Dies wirft die Frage auf: Wie können Sie eine entlastete Infrastruktur für Ihre Entwickler erreichen und gleichzeitig Richtlinien und Best Practices für Compliance, Risiko und Kosten befolgen? Es gibt einen Weg, das Gleichgewicht zu finden.
Wie bei vielen Aspekten der Sicherheit haben wir gelernt, dass Benutzer letztendlich Wege finden, diese zu umgehen, wenn Einschränkungen und Barrieren zu hoch sind. Dies gilt auch für den Betrieb. Auch wenn es manchmal einfacher zu sein scheint, alles zu blockieren, als eine bessere und ausgewogenere Methode zu entwickeln, die es Entwicklern ermöglicht, schnell voranzukommen, schlägt dieser Ansatz letztendlich fehl. Dies ist genau die gleiche Entwicklung, die die Anwendungs- und Cloud-native-Sicherheitsbranche derzeit durchläuft. Alle angewandten Leitplanken und Kontrollen haben zu viel Reibung in den Entwicklungsprozessen erzeugt und werden von den Entwicklern letztendlich umgangen.
CloudOps kann viel aus den Umwälzungen lernen, die die Sicherheitsbranche heute durchmacht. Genauso wie die Point-in-Time-Sicherheit völlig nutzlos geworden ist, reichen auch Nicht-Echtzeit-Warnungen oder eventuelle Warnungen vor Infrastrukturabweichungen bei der Verwaltung einer kurzlebigen Cloud nicht mehr aus. Was wirklich benötigt wird, ist die gleiche Art von Echtzeit- und kontinuierlichem Scannen von Cloud-Assets und IaC, ähnlich dem, was wir durch Überwachung und Beobachtbarkeit auf unsere Systeme anwenden. Diese Lösungen wurden zu einem wesentlichen Rückgrat unseres Geschäfts, um den kontinuierlichen Betrieb und die Verfügbarkeit von Cloud-Diensten sicherzustellen.
Da wir uns für IaC und die damit verbundenen Vorteile einsetzen, ermöglicht „Everything-as-Code“ eine größere Agilität und Transparenz, sodass Sie automatisch Abhilfe schaffen können, ohne alles sperren zu müssen. Wie DevOps sagt: „Fail Forward und Fail Fast.“ Anstatt sich darauf zu konzentrieren, niemals einen Fehler zu machen, konzentrieren Sie sich darauf, wie Sie ihn sofort beheben können.
Durch einen kontinuierlichen Vergleich der tatsächlichen Cloud-Ressourcen mit ihrem Soll-Zustand über IaC und GitOps ist es möglich, Konfigurationsabweichungen und Richtlinienverstöße sofort aufzudecken, ähnlich wie bei jeder anderen Art von Sicherheitsverstoß oder größerem Systemausfall. Ausfälle und Zwischenfälle sind unvermeidlich. Es ist unrealistisch und sogar gefährlich, Systeme mit einem inhärenten zugrunde liegenden Design zu erstellen, das Sie daran hindert, während eines Ausfalls um 2:00 Uhr morgens etwas an der Cloud-Konsole zu ändern.
Bei einem gesperrten Ansatz müsste ein Entwickler während eines Produktionsvorfalls mit hohem Druck auf die Genehmigung des Änderungsmanagements warten, oft um 3:00 Uhr morgens (weil die Vorfallgötter sie immer mitten in der Nacht geschehen lassen) oder an einem Wochenende. Wir müssen nicht viel weiter blicken als den 40-minütigen und 440 Millionen US-Dollar schweren Zwischenfall mit Knight Capital, um zu verstehen, dass die Zeit manchmal nicht auf unserer Seite ist und dass eine Verzögerung schwerwiegende Folgen haben kann.
Cloud-Drift ist zu einem ebenso besorgniserregenden Problem geworden wie die Betriebszeit oder jeder andere geschäftskritische Aspekt des kontinuierlichen Geschäftsbetriebs. Aus diesem Grund müssen wir bei der Überwachung der Drift in Echtzeit dieselben Prinzipien anwenden wie bei unserer CPU und Auslastung. Auf diese Weise können Sie benachrichtigt werden, wenn Ihre Cloud und Ihr IaC nicht mehr aufeinander abgestimmt sind, und sogar Probleme erkennen, die in Echtzeit verhindert werden können. Sie können die Ticketerstellung und -eskalation automatisieren und außerdem in Echtzeit anhand von Abhilfevorschlägen prüfen, ob das Problem behoben werden muss, oder ein Ticket öffnen, um das Problem später zu beheben. Die Wahl sollte bei Ihnen liegen und nicht bei einem Administrator, der viel weniger Kontext zu den Systemen und den letztendlichen geschäftlichen Auswirkungen hat.
Einige Anbieter propagieren, Ihre Cloud in IaC zu kodieren und sie dann zu sperren, sodass Sie es nie wieder tun müssen. Das fühlt sich an wie ein Déjà-vu; Das haben wir definitiv schon einmal gehört. Es klingt stark nach dem JVM-Versprechen „Einmal schreiben, überall bereitstellen“, das nie ganz aufgegangen ist.
Wenn Sie diesen Weg einschlagen, geben Sie sich damit ab, niemals neue Cloud-Assets hinzuzufügen oder Ihre Cloud-Konfigurationen zu ändern. Wenn wir etwas über die Cloud gelernt haben, dann ist es, dass sie ein sich ständig bewegendes Ziel ist. (Lesen Sie, was Cloud Asset Management aus der Finanzwelt lernen kann – einer weiteren Branche im ständigen Wandel). Wenn das mit der JVM vor Jahrzehnten nicht funktioniert hat, wird es in einer dynamischen und sich ständig verändernden Umgebung wie der Cloud sicherlich nicht funktionieren. Das ist eine verrückte Reise.
Die Einschränkung von Agilität und Geschwindigkeit hat große Nachteile. Dies ist ein hart erarbeiteter Rat, den wir aus erster Hand von Tools wie der alten CMDB und Start-ups erfahren haben, die vergessen haben, dass die Cloud vergänglich ist – und möglicherweise der Grund, warum wir sie alle überhaupt nutzen! Wenn sich unsere Cloud also ständig verändert und ein sich ständig bewegendes Ziel ist, sollten unsere Tools dann nicht genauso aufgebaut sein, um Schritt zu halten? Lösungen, die für das sich schnell entwickelnde Cloud-native-Zeitalter entwickelt wurden, müssen kontinuierlich nach neuen, nicht verwalteten und geänderten Assets suchen und sicherstellen, dass ihre Cloud-Infrastruktur stets Richtlinien und regulatorischen Standards entspricht.
Sobald wir in der Lage sind, die Balance zwischen Agilität und Kontrolle zu finden, können wir die Vorteile von Geschwindigkeit und Sicherheit nutzen (wie die DORA-Forschung immer wieder zeigt), die den Maßstab für leistungsstarke Teams darstellen. Die Automatisierung des Cloud-Asset-Managements kann Governance, Richtlinien und Kontrolle bereitstellen und gleichzeitig die Geschwindigkeit und Agilität ermöglichen, die Engineering-Unternehmen heute benötigen.
Es gibt eine Minderheit von Leuten, die behaupten, dass sie sich keine Sorgen über eine Verschiebung der Cloud-Asset-Konfiguration machen, weil sie alles komplett gesperrt haben. An der Cloud-Konsole oder im IaC können keine Änderungen vorgenommen werden, ohne GitOps für strikte Änderungsmanagementprozesse über CI/CD durchlaufen zu müssen. Ich wette, sie haben glückliche Entwickler – nein!
Während der gesamten Pandemie mussten Unternehmen Entwickler glücklich machen, aus Angst, sie würden gehen. Daher setzte DevOps auf Hochtouren und strebte eine Self-Service-Infrastruktur für Entwickler an, um Geschwindigkeitsbarrieren zu beseitigen. Jetzt, da die Tech-Märkte deprimiert sind, ist es vielleicht einfacher, die Dinge abzuriegeln, auch wenn das das Risiko mit sich bringt, Ingenieure zu verlieren.
Da wir IaC und seine Vorteile begrüßen, müssen Sie nicht in der Steinzeit leben, in der alles abgeriegelt wird. Wie können Sie eine entlastete Infrastruktur für Ihre Entwickler erreichen und gleichzeitig Richtlinien und Best Practices für Compliance, Risiko und Kosten befolgen? Da ist ein Weg.
Die Lösung? Durch kontinuierliches Scannen Ihrer Cloud-Assets und Ihres IaC in Echtzeit mit kontinuierlichem Vergleich können Konfigurationsabweichungen und Richtlinienverstöße sofort aufgedeckt werden. Notfälle sind unvermeidlich. Es ist mutig/dumm/dumm zu glauben, dass Sie im Notfall nie etwas an der Cloud-Konsole ändern müssen oder dass ein Entwickler auf das Änderungsmanagement wartet, wenn die Produktion am Wochenende um 3:00 Uhr morgens ausfällt. Es passiert, und Sie müssen damit umgehen.
Abgelegt unter: Blogs, Continuous Delivery, Continuous Testing, DevOps-Kultur, DevOps in der Cloud, DevOps-Praxis, IT als Code. Markiert mit: devops, gitops, IaC, Incident Response, Self-Service