Die Arbeit in einer schnelllebigen DevOps-Umgebung bringt viele Herausforderungen mit sich. Das kann ich bezeugen. Ich habe vor kurzem in einem Unternehmen gearbeitet, in dem DevOps-Praktiken eine zentrale Säule bei der Lieferung neuer Kunden sind.

Wenn Sie in der DevOps-Branche arbeiten, werden Sie zustimmen, dass es sich um ein schnelles Geschäft handelt, das sich häufig ändert, und dass der Schlüssel zum Erfolg eine starke Anpassung ist. In den letzten zehn Jahren hat sich DevOps durchgesetzt, was wiederum SecOps, GitOps, CloudOps, ITOps und DevSecOps (und viele weitere Varianten) hervorgebracht hat.

In diesem Beitrag werden wir uns jedoch insbesondere mit DevOps befassen.

Die Einführung von DevOps-Praktiken hat für jedes Unternehmen viele Vorteile. Viele sehen DevOps als eine Möglichkeit, die Markteinführung zu beschleunigen oder neue Produkte schnell auf den Markt zu bringen (ohne Qualitätseinbußen).

Die Kunden, mit denen ich zusammenarbeite, egal ob es sich um Start-ups oder große Unternehmen handelt, profitieren von meiner Expertise. Das Ziel ist es, die Gesamtkosten für die Entwicklung neuer Produkte und Dienstleistungen zu senken, indem einige der Ineffizienzen und der Aufwand für komplexe Arbeitsabläufe beseitigt werden. All dies bildet den DevOps-Lebenszyklus.

Viele der Kunden, mit denen ich zusammenarbeite, wollen ihre Produkte modernisieren. Und mit der richtigen Anleitung und Expertise begleite ich sie auf diesem Weg, indem ich Lösungen einsetze, die auf soliden und sicheren DevOps-Praktiken beruhen.

Bevor wir in die DevOps-Kultur eintauchen, untersuche ich mit unseren Kunden, ob sie für die Anpassung bereit sind, indem wir die aktuelle Lieferumgebung bewerten. Dies hilft zu verstehen, ob das Team, die Tools, die Architekturen und die Kultur angemessen auf die Umstellung vorbereitet sind, um ihre Anwendungen auf die nächste Stufe zu bringen.

Viele Unternehmen sind bereit, das zeigt sich besonders bei Start-ups. Ihre Anwendungen sind in der Regel zustandslos und wurden mit neuen Anwendungs-Frameworks entwickelt und können auf Microservices aufgebaut werden. Manchmal sind die Teams jedoch zu beschäftigt oder es fehlt ihnen einfach der nächste Mitarbeiter mit der für AWS erforderlichen Expertise. An dieser Stelle kommt mein Firemind als Advanced AWS Consulting Partner ins Spiel.

Ich spreche oft mit Kunden, die eine Anwendung haben, die sie von einem typischen ALB-, EC2- oder Datenbank-Stack (auf einer 3-Tier-Architektur) wegbewegen möchten. Sie möchten in der Regel zu Microservices mit einer soliden Pipeline für schnelle, iterative und sichere Implementierungen in einer Produktionsumgebung wechseln.

Ich sehe einen bekannten Trend bei vielen Unternehmen, die von diesem typischen System, ja sogar von Legacy-Architekturen auf Microservices umsteigen (und wo immer möglich auf Managed Services). Die Teams wollen jetzt IAC, Microservices und CICD-Pipelines, um zu modernisieren, aber auch, um AWS die schwere Arbeit machen zu lassen, während sich ihre Mitarbeiter auf das Produkt konzentrieren können.

Unten sehen Sie eine Illustration, die verdeutlicht, was ich typischerweise für immer mehr Kunden mit Terraform aufbaue.

Ein Application Load Balancer wird verwendet, um die Last zwischen den beiden Aufgaben auszugleichen. Die Pipeline erkennt Änderungen am Image, das in ECR gespeichert ist, und verwendet CodeDeploy, um den Datenverkehr an einen Fargate-Cluster weiterzuleiten und bereitzustellen.

CodeDeploy verwendet einen Listener, um den Datenverkehr an den in der Build-Datei angegebenen Port des aktualisierten Containers umzuleiten. Die Pipeline ist auch so konfiguriert, dass sie einen Quellspeicherort wie GitHub verwendet, wo die ECS-Aufgabendefinition gespeichert ist.

Die Continuous-Delivery-Pipeline erstellt und verteilt automatisch Container-Images, wenn der Quellcode geändert oder ein neues Basis-Image in ECR hochgeladen wird.

Diese Architektur verwendet die folgenden Artefakte:

– Eine Docker-Image-Datei, die den Containernamen und den Repository-URI des ECR-Image-Repositorys angibt.

– Eine ECS-Aufgabendefinition, die den Namen des Docker-Images, den Containernamen, den Namen des ECS-Dienstes und die Konfiguration des Lastausgleichs auflistet.

– Eine CodeDeploy AppSpec-Datei, die den Namen der ECS-Aufgabendefinitionsdatei, den Namen des Containers der aktualisierten Anwendung und den Container-Port angibt, an den CodeDeploy den Produktionsverkehr umleitet. Sie kann auch optionale Netzwerkkonfigurationen und Lambda-Funktionen angeben, die Sie während der Ereignis-Hooks im Bereitstellungslebenszyklus ausführen können.

Diese Illustration dient lediglich der Veranschaulichung, um einen Überblick über das zu geben, was ich für meine Kunden immer häufiger aufbaue. In einem realen Einsatz hätte ich jedoch mehrere Konten für verschiedene Phasen des Produktlebenszyklus – Entwicklung, Test, Phase, Produktion – und würde eine Vielzahl anderer Dienste für operative Exzellenz, Sicherheit, Zuverlässigkeit, Leistungseffizienz, Kostenoptimierung und Nachhaltigkeit nutzen.

Ich erlebe bei meinen Kunden, dass sie den Wunsch haben, auf Microservices umzusteigen und dabei eine Vielzahl von Managed Services zu nutzen, die alle gleichzeitig daran arbeiten, ihr ultimatives Ziel der Automatisierung durch DevOps-Praktiken zu erreichen.