DevOps-Tools auf AWS verwalten: 5 Schritte zu maximaler Effizienz

Wie vernetzt, betreibt und wartet ihr diese völlig unterschiedlichen Tools, damit sie zusammenarbeiten? Und wie gelingt das, ohne dass eure Cloud-Kosten explodieren?

Eure DevOps-Toolchain kann leicht zu eurem kritischsten System werden, denn alles läuft darüber. Fällt dieses System aus, könnt ihr nichts mehr irgendwo deployen.

Die Wartung hört nie auf. Daher gibt es heute wie morgen viele Möglichkeiten, dass etwas gründlich schiefläuft. Glaubt mir: Ich unterstütze Unternehmen seit vielen Jahren bei der Verwaltung ihrer DevOps-Toolchain und weiß, wo sie bei DevOps-Tools auf AWS Fehler machen.

Wenn ihr meine fünf folgenden Schritte befolgt, spart ihr euch und eurem Unternehmen bei der Wartung eurer Tools auf AWS viel Geld und Ärger.

Starten wir direkt mit dem ersten:

Schritt 1: Eure Cloud-Netzwerke und Funktionen technisch planen

Wie andere Systeme ist auch AWS nicht perfekt. Ihr habt Load Balancer, Subnetze und verschiedene Netzwerke, die miteinander kommunizieren müssen.

Ihr möchtet die Angriffsfläche eures Netzwerks begrenzen. Nicht jeder Service sollte überall für jeden sichtbar sein, daher richtet ihr verschiedene Bereiche ein.

Ein Beispiel

In AWS gibt es verschiedene Möglichkeiten, zwei Accounts miteinander zu vernetzen, damit zwei Teams in ihren jeweiligen Accounts arbeiten können. Einige davon sind gut, andere schlecht.

Ihr könntet eine Virtual Private Cloud verwenden, die zwei Accounts miteinander verbindet. Das Problem bei diesem Ansatz: Die Netzwerke kommunizieren zu viel miteinander. Den Datenverkehr könnt ihr nicht einfach kontrollieren. Wenn ihr das in großem Umfang umsetzt, kann alles vollständig zusammenbrechen. Alle Netzwerke kommunizieren miteinander.

Inzwischen gibt es dafür eine bessere Technologie, die wir einsetzen und die dieses Problem skalierbar löst: Transit Gateways. Neue Technologien wie diese entstehen ständig, um Probleme in der Cloud zu lösen.

Die wichtigsten Bereiche dieser Cloud-Netzwerke und Funktionen

Wenn wir über die technische Planung eurer Cloud-Netzwerke und Funktionen sprechen, sind diese Bereiche besonders wichtig:

• Benutzerzugriff: wie Benutzer auf euer System zugreifen.

• Internes System: wie das System selbst läuft und was sich darin befindet.

• Machine-to-Machine-Netzwerke: Möglicherweise habt ihr Komponenten, die beispielsweise Jenkins und GitLab für Deployments benötigen.

• On-Premise-Verbindungen: Auch wenn sie mit der Zeit weniger wichtig werden, müsst ihr vielleicht etwas mit eurer On-Premise-Umgebung verbinden.

Netzwerke bilden die Grundlage jeder Sicherheit. Setzt ihr sie richtig um, ist alles Secure by Design. Macht ihr es jedoch falsch, ist nichts mehr sicher, weil alles für jeden offen ist. Ganz gleich, was ihr tut: Wenn eure Netzwerke offen sind, könnt ihr das später nicht mehr beheben. Dann müsst ihr auch diese Verbindungen korrigieren, was bedeutet, dass ihr Dinge immer wieder neu schreiben müsst.

Wenn ihr es falsch macht, steigen eure Kosten in AWS und die Fehlersuche wird schwierig. Ihr werdet nie wissen, was das System beeinträchtigt hat.

Konkrete Empfehlungen

• Sichert eure Endpunkte! Schützt sie hinter Load Balancern und macht sie niemals direkt zugänglich.

• Erstellt Gruppen mit minimalen Zugriffsrechten.

• Erstellt Frameworks und Templates, die andere nutzen können, sowie vordefinierte Berechtigungsschemata.

• Führt kontinuierlich Scans und Tests durch, um herauszufinden, was noch offen ist.

• Macht Infrastructure-as-a-Code zu eurer Grundlage.

• Setzt nicht alles auf einmal durch – geht Schritt für Schritt vor, wenn ihr wisst, dass etwas funktioniert.

Sichert eure Endpunkte! Schützt sie hinter Load Balancern und stellt sie niemals direkt bereit.

Erstellt Gruppen mit minimalen Zugriffsrechten.

Erstellt Frameworks und Templates, die andere nutzen können, sowie fertige Berechtigungsschemata.

Führt kontinuierlich Scans und Tests durch, um herauszufinden, was noch offen ist.

Macht Infrastructure-as-a-Code zu eurer Grundlage.

Setzt nicht alles auf einmal durch – geht Schritt für Schritt vor, wenn ihr wisst, dass etwas funktioniert.

Schritt 2: Infrastructure-as-a-Code richtig umsetzen

Hier liegt euer Code bereits in eurem Git- (oder Nicht-Git-)Repository – eure Infrastruktur sollte am selben Ort liegen. Ihr möchtet nachvollziehen können, was sich geändert hat, wer die Änderung vorgenommen hat und welche Auswirkungen sie hat. So könnt ihr planen, verfügt über einen Audit Trail und könnt Dinge leichter reproduzieren.

Wenn ihr das falsch angeht, betreibt ihr ClickOps, klickt euch durch die UI und am Ende geht alles kaputt. Ihr wisst nicht, was geändert wurde, und könnt nicht einfach zu eurem IaaC zurückkehren.

In diesem Szenario kontrolliert eure Infrastruktur euch – nicht ihr die Infrastruktur. Wenn sie nicht versionskontrolliert ist, solltet ihr das System unveränderlich machen. Doch das ist es nicht.

Wichtige Bereiche von Infrastructure-as-a-Code

Ihr solltet eure gesamte Infrastruktur betrachten, aber größtenteils läuft alles auf Folgendes hinaus:

• Module: die Templates, die ihr wiederverwendet, denn ihr möchtet nicht alles neu schreiben – das führt zu Fehlern. Ihr könnt eigene Module erstellen, aber ich empfehle, die offiziellen zu nutzen. So können andere leichter ähnliche Templates erstellen.

• Klare Dateien: Standardisiert die Dateinamen und die Art, wie ihr alles deployt. Wenn ihr euch beispielsweise für Terraform entscheidet, verwendet nur Terraform und nicht zur Hälfte ein anderes System. Versucht nicht, zwei Sprachen in einem Team zu verwalten.

• Code Reviews: Setzt eine Form der Automatisierung ein und stellt sicher, dass sie im System bleibt. Terraform verwendet beispielsweise „States“, mit denen ihr während der Änderungen sehen könnt, was geändert wird. So verhindert ihr, dass ihr versehentlich etwas löscht.

• Upgrades: Euer IaaC kann sehr schnell veralten. Aktualisiert es entsprechend, damit ihr nicht bei einer alten Version landet, die nicht unterstützt wird oder schlicht nicht mehr funktioniert.

Wenn ihr das nicht tut, kann das allerlei Chaos verursachen. Euer IaaC ist etwas Lebendiges, das ihr kontinuierlich aktualisieren und weiterentwickeln müsst.

Das ist nicht einfach. Ihr dokumentiert eure gesamte Infrastruktur im Voraus. Statt euch auf Automatisierungen zu verlassen, müsst ihr definieren und festlegen, wie eure Infrastruktur aussehen soll. Von Anfang an müsst ihr entscheiden: „Das werden wir deployen“ und „So wird es aussehen“.

Praktische Tipps

Folgt soliden Coding Standards, statt dies als Skripting zu betrachten. Mit guten Coding Standards seid ihr mit eurem IaaC gut aufgestellt.

Schritt 3: Traffic und Migration planen

Wie ich in Schritt 1 erwähnt habe: Fehler beim Networking werden schnell teuer. Auch beim Traffic geht es um Networking: darum, was auf oberster Ebene hinein- und hinausgeht.

Wenn ihr viele Artefakte habt – beispielsweise 6 TB Daten – und ständig 2 TB in die Cloud hinein- und wieder herauszieht, steigen eure Kosten rasant. Das Speichern in der Cloud ist günstiger, aber das Abrufen aus der Cloud ist teuer.

Ihr müsst also überlegen: „Was versuche ich zu erreichen?“ und „Kann ich den Datenverkehr besser planen?“

Das betrifft auch die Migration, denn ihr müsst berücksichtigen: „Wie migriere ich Daten von On-Premise in die Cloud?“ Letztlich wird alles in der Cloud landen. Daher müsst ihr planen, wie ihr das möglichst kostengünstig und effizient umsetzen könnt.

Wichtige Bereiche bei Datenverkehr und Migration

Dabei gibt es viele kleinere Aspekte, aber konzentrieren wir uns auf die wichtigsten Bereiche, von denen ihr am meisten profitiert. Dazu gehören:

• Verbindungen und Integrationen: Welche habt ihr? Im heutigen DevOps seid ihr mit mehreren Punkten verbunden. Was deployt ihr, und was läuft durch das CI/CD-System? Was ist und was sollte in der Cloud sein? Und wenn etwas nicht in die Cloud gehört, braucht ihr dafür einen guten Plan.

• Zugriffsmanagement: Ihr braucht eine solide Methode, um zu entscheiden, wer worauf und wo Zugriff haben soll.

Verbindungen und Integrationen: Welche habt ihr? Im heutigen DevOps seid ihr mit mehreren Punkten verbunden. Was deployt ihr, und was läuft durch das CI/CD-System? Was ist und was sollte in der Cloud sein? Und wenn etwas nicht in die Cloud gehört, braucht ihr dafür einen guten Plan.

Zugriffsmanagement: Ihr braucht eine solide Methode, um zu entscheiden, wer worauf und wo Zugriff haben soll.

Wenn ihr euren Datenverkehr und eure Migration nicht plant, entstehen hohe, unnötige Kosten.

Außerdem riskiert ihr eine schlechte Reaktionsfähigkeit, und die User Experience leidet – wahrscheinlich genau das Gegenteil von dem, was ihr mit dem Wechsel in die Cloud ursprünglich erreichen wolltet. Statt Dinge zu vereinfachen, schafft ihr in der Cloud zusätzliche Komplexität und verlangsamt Prozesse.

Das Schwierigste an der Planung von Datenverkehr und Migration ist: Nun ja, wahrscheinlich habt ihr euch bisher nicht besonders intensiv damit beschäftigt. Es ist also keine Raketenwissenschaft, aber es ist neu. Und Neues ist schwieriger.

Praktische Tipps – ein einfacher 1-2-3-Prozess:

1. Analysiert zunächst, welche Integrationspunkte es gibt und wo sie sich befinden.

2. Schaut euch an, wie viele Daten betroffen sind – das könnt ihr messen.

3. Überlegt, was ihr erreichen wollt, was bei jeder Integration wichtig ist und wie ihr am einfachsten dorthin gelangt. „Können wir das einfach dorthin verschieben, und wirkt sich das auf die User Experience aus?“

Analysiert zunächst, welche Integrationspunkte es gibt und wo sie sich befinden.

Schaut euch an, wie viele Daten betroffen sind – das könnt ihr messen.

Überlegt, was ihr erreichen wollt, was bei jeder Integration wichtig ist und wie ihr am einfachsten dorthin gelangt. „Können wir das einfach dorthin verschieben, und wirkt sich das auf die User Experience aus?“

Schritt 4: Monitoring, Zugriff und Logs verwalten

Das ist ziemlich selbstverständlich, aber im Kern braucht ihr Kontrolle und Nachvollziehbarkeit in der Cloud. Ihr müsst wissen, was im System passiert. Wer hat wann worauf zugegriffen und was hat er getan? Dafür braucht ihr Logs und Zugriffsmanagement.

Und um zu wissen, ob etwas nicht funktioniert, braucht ihr auch Monitoring. Wenn ihr in die Cloud wechselt und beispielsweise ein Auto-Scaling-System nutzt, müsst ihr dieses Monitoring eingerichtet haben. Denn in der Cloud überwacht ihr nicht einfach nur etwas: Ihr nutzt Monitoring-Metriken, um den tatsächlichen Betrieb eurer Infrastruktur zu steuern.

Wenn ihr euer Monitoring nicht verwaltet, kann beispielsweise bei einem Großereignis der Service ausfallen, weil ihr nicht berücksichtigt habt, dass ihr ihn vor dem Ereignis hochskalieren müsst.

Wichtige Bereiche für Monitoring, Zugriff und Logs

Diese wichtigen Aktivitäten lassen sich einfach in zwei Bereiche unterteilen:

• Observability: Ihr beobachtet, wie die Dinge funktionieren.

• Nachverfolgbarkeit: Ihr findet heraus, wer was getan hat. Wenn das System zum Beispiel langsamer wird und ihr in den Nachverfolgbarkeits-Logs nichts findet, läuft im System wahrscheinlich etwas anderes, das eure Aufmerksamkeit erfordert.

Observability: Ihr beobachtet, wie alles funktioniert.

Nachverfolgbarkeit: Ihr findet heraus, wer was getan hat. Wenn das System zum Beispiel langsamer wird und ihr in den Nachverfolgbarkeits-Logs nichts findet, läuft im System wahrscheinlich etwas anderes, das eure Aufmerksamkeit erfordert.

Wenn ihr das nicht macht, wisst ihr schlicht nicht, ob euer System ausgefallen ist oder wer es beeinträchtigt hat. Ihr wisst auch nicht, welchen Sicherheitsbedrohungen ihr ausgesetzt seid.

Ein Vorteil der Cloud ist, dass ihr ein System mehrfach erneut bereitstellen könnt. Einige Aufgaben lassen sich jedoch nicht verwalten, wenn die Informationen nicht an anderer Stelle gespeichert sind. Ihr könnt das System nicht beobachten, wenn es ausgefallen ist, oder nachvollziehen, was unmittelbar davor passiert ist, weil ihr den fehlerhaften Teil bereits entfernt habt. Und wenn das System langsamer wird, könnt ihr nicht rechtzeitig reagieren, um es zu beheben, weil ihr es per Auto-Scaling bereits entfernt habt. Deshalb müsst ihr Metriken und Logs außerhalb des Systems speichern, um mögliche Probleme im System effizient zu debuggen.

Monitoring ist jedoch nicht einfach. Denn im Grunde habt ihr zwei Möglichkeiten:

1. Ihr habt viel zu viele Informationen

2. Ihr habt zu wenige Informationen

Ihr habt viel zu viele Informationen

Ihr habt zu wenige Informationen

Wenn ihr zu viele Informationen habt, werdet ihr nichts damit anfangen – wie bei einem 10.000-seitigen Buch, das ihr aus Angst gar nicht erst aufschlagt. Im Gegensatz dazu liefert euch ein 50-seitiges Buch nicht genug Informationen, damit es sich für euch lohnt.

Die Herausforderung besteht darin, die richtige Menge an nutzbaren Informationen zu erhalten, die euch nicht verwirrt.

Im Internet gibt es Unmengen an „Best Practices“, aber ich fasse es für euch anhand einiger einfacher, umsetzbarer Ratschläge zusammen:

Umsetzbare Ratschläge

• Der Trick besteht darin, mit „zu vielen“ Informationen zu beginnen und sie dann so lange zu reduzieren, bis ihr zu wenige habt. Anschließend erweitert ihr sie wieder, bis ihr herausfindet, wie viel „genug“ ist. Das ist ein Prozess von Versuch und Irrtum. Es gibt keine goldenen Regeln – ihr müsst also für jeden Einzelfall herausfinden, was funktioniert.

• Stellt sicher, dass ihr eure Endpoints überwacht. Wenn sie ausgefallen sind, stehen eure Services euren Nutzern nicht zur Verfügung – selbst wenn der Service bzw. Code funktioniert. (Das mögen Nutzer überhaupt nicht.)

Schritt 5: Laufende Wartung und Pflege sicherstellen

Ihr stellt eure Services nicht nur einmal bereit und lasst sie dann laufen. Ihr Betrieb verursacht immer laufende Kosten.

Zu diesen Kosten gehören beispielsweise Service-Support, Libraries und Systeme am Ende ihres Lebenszyklus, Integrationen und IP-Whitelisting – also verschiedenste laufende Wartungsaktivitäten, die für eure Infrastruktur erforderlich sind.

Wenn ihr eure IaaC einfach unverändert lasst, wird sie schnell veralten und irgendwann nicht mehr funktionieren.

Ihr braucht laufende Pflege, die Ressourcen erfordert. Die meisten dieser Anforderungen lassen sich mit AWS-Technologie erfüllen, aber ihr müsst sie dennoch verfolgen und verwalten. Und wie jede andere Technologie erreichen auch diese AWS-Lösungen irgendwann ihr jeweiliges Lebensende.

Wichtige Bereiche von Wartung und Pflege

Eure Verantwortlichkeiten für Wartung und Pflege lassen sich in die folgenden Bereiche unterteilen:

• Sicherheit: Einfach gesagt geht es darum, wie ihr eure Sicherheit laufend pflegt.

• Wartbarkeit/Zukunftssicherheit: Wie bei jeder IaaC müsst ihr sicherstellen, dass ihr weiterhin Änderungen an eurem System vornehmen könnt. Sobald es zu alt ist, könnt ihr es nicht einmal mehr aktualisieren.

• Kenntnisse über eure Software und Architektur: Ihr müsst wissen, was zu tun ist, damit sie funktionsfähig bleiben.

• Backups und allgemeines Datenmanagement: Stellt sicher, dass euer System gesichert wird und läuft und dass die Daten verfügbar sind, selbst wenn eine Region ausfällt.

• Monitoring: Auch das gehört zur Wartung. Jemand muss verfolgen, was die Monitoring-Daten aussagen, ob sie korrekt sind und ob etwas behoben werden muss.

Wenn ihr bei dieser Wartung versagt, habt ihr ein System, das jeder kennt, aber niemand anzufassen wagt. Wenn ihr versucht, eine Automatisierung auszuführen, funktioniert sie nicht mehr. Möglicherweise müsst ihr zurückgehen und untersuchen, was ihr vor sechs Jahren deployt habt, und euch auf zeitaufwendiges, kostspieliges Reverse Engineering einlassen. Dabei stellt ihr vielleicht fest, dass euch jemand seit einem Jahr gehackt hat.

Wir leben in einer Quartalswirtschaft. Wenn ihr für diese Wartungsarbeiten verantwortlich seid, entwickelt ihr keine neuen Features für euren Service und findet keine neuen Wege, Geld zu verdienen. Selbst wenn ihr die Wartung perfekt erledigt, zeigt sich das nicht direkt im EBITDA eures Unternehmens, auch wenn es sich langfristig darauf auswirkt. Was ihr tut, ist nicht glamourös und schafft im nächsten Quartal keinen Mehrwert.

Konkrete Empfehlungen

Für diesen laufenden Wartungsbedarf habt ihr im Wesentlichen drei Optionen:

• Outsourcing: Immer mehr Unternehmen vermeiden es, ihre Entwickler für diese Art von Arbeit einzuplanen, damit sie sich auf die Entwicklung der Services konzentrieren können, und lagern sie stattdessen aus. Sie schließen einen langfristigen Wartungsvertrag mit einem Unternehmen wie Eficode ab, das die Tools während der gesamten Vertragslaufzeit optimiert und wartet.

• Ein internes Wartungsteam: Dieses Team ist für sämtliche Wartungsarbeiten verantwortlich und verfügt über das entsprechende Budget.

• Gemeinsame Praktiken etablieren, die ihr konsequent befolgt: Wenn ihr etwas Neues erstellt, nutzt es standardmäßig etablierte, bewährte Praktiken aus anderen Bereichen. Dies ist die schwierigste der drei Optionen, denn ihr müsst sicherstellen, dass alles Neue abwärtskompatibel und alles Alte vorwärtskompatibel ist. Andernfalls erzeugt ihr ständig neue technische Schulden.

Fazit

Da draußen ist es ein echter Dschungel. Es gibt so viele DevOps-Tools, und die Cloud ist noch relativ neu und entwickelt sich ständig weiter.

Der Wartungsaspekt ist meist nicht der spannendste – wir konzentrieren uns lieber auf das Neue und auf das, was als Nächstes kommt. Doch wenn ihr den Fokus verliert, passieren schlechte Dinge. Dinge gehen kaputt und Geld verschwindet in einem dunklen Loch.

Wenn ihr meine fünf Schritte befolgt und darauf achtet, schützt ihr euch vor viel Schmerz – einem Schmerz, den viele Menschen in eurer Situation täglich erleben.