Cloud & Infrastruktur: AWS-first mit Kubernetes, Kafka und Docker

Seit 2015 arbeite ich in jedem meiner Projekte mit AWS. In meiner aktuellen Rolle verarbeiten die Systeme, die ich mitverantworte, täglich mehrere hundert Terabyte an Daten. Diese Seite beschreibt, wie ich Infrastruktur dafür baue und betreibe: mit AWS als gemeinsamem Betriebskontext und mit Kafka, Kubernetes und Docker als eigenständigen Engineering-Praktiken.

AWS-first: eine bewusste Architekturentscheidung

„AWS-first“ ist für mich kein Bekenntnis zu einem Anbieter, sondern eine Abwägung. Wer heute Infrastruktur plant, kann zwischen zwei Wegen wählen: eine Cloud-übergreifende Abstraktionsschicht, die einen späteren Anbieterwechsel offenhält, oder die nativen Werkzeuge der Plattform, auf der die Systeme tatsächlich laufen. In meinen Projekten wird die Cloud-Unabhängigkeit aktuell nicht gebraucht. Eine zusätzliche Abstraktion würde deshalb vor allem Komplexität kosten, ohne einen konkreten Nutzen zu bringen.

Ich setze deshalb auf AWS-native Bausteine: CloudFormation für Infrastructure as Code, CodeBuild und CodePipeline für CI/CD, Cognito samt Azure-AD-Integration für Identity und QuickSight für das Reporting. Die Entscheidung ist nicht endgültig. Sie gilt, solange die Rahmenbedingungen gleich bleiben, und ich würde sie neu treffen, sobald ein echter Multi-Cloud-Bedarf entsteht – mehr dazu auf der Seite zu Terraform, das deshalb bewusst zurückgestellt ist.

AWS-Erfahrung als Softwarearchitekt: Betriebspraxis statt Folienwissen

Meine AWS-Erfahrung als Softwarearchitekt stammt aus über zehn Jahren produktivem Einsatz bei mehreren Arbeitgebern, nicht aus einem einzelnen Projekt. Den deutlichsten Beleg liefert das Datenvolumen meiner aktuellen Rolle: Täglich laufen mehrere hundert Terabyte durch die AWS-Datendienste, mit denen ich arbeite. In dieser Größenordnung fallen Fehler in Partitionierung, Kostenkontrolle oder Fehlerbehandlung schnell auf. Man lernt dort, Systeme so zu bauen, dass sie dauerhaft im Betrieb bestehen.

Mehrere Vorhaben aus früheren Projekten zeigen, wie diese Praxis aussieht. Erfahrung mit der Migration selbst betriebener Streaming-Infrastruktur auf Managed Services wie Amazon MSK, dazu mehr im Kafka-Abschnitt. Der Aufbau von BI-Lösungen mit AWS-Analysediensten wie Athena, Glue und QuickSight. Die Einführung von Single-Sign-on-Lösungen auf Basis von AWS-Diensten.

Infrastruktur entsteht dabei konsequent als Code. Seit 2016 setze ich CloudFormation in Kundenprojekten ein. Ressourcen werden nicht in der Web-Konsole zusammengeklickt, sondern versioniert, reviewt und über die CI/CD-Pipeline ausgerollt. So bleibt nachvollziehbar, warum eine Umgebung so aussieht, wie sie aussieht, und eine Umgebung lässt sich jederzeit identisch wieder aufbauen.

Kafka und AWS MSK: Erfahrung mit Event-Streaming im großen Maßstab

Apache Kafka ist für mich seit Jahren ein zentrales Werkzeug für ereignisgetriebene Architekturen, unabhängig davon, wo es läuft. Ich habe Kafka sowohl selbst betrieben als auch als gemanagten Dienst Amazon MSK eingesetzt. Die Praxis dahinter ist in beiden Fällen dieselbe: Topics sinnvoll schneiden, Datenflüsse zwischen Produzenten und Konsumenten entkoppeln und Streams so gestalten, dass nachgelagerte Systeme sie zuverlässig verarbeiten können.

In früheren Projekten habe ich selbst betriebene Kafka-Cluster auf Amazon MSK migriert, um den Betriebsaufwand zu senken, ohne die Streaming-Architektur anzufassen. Die Wartung des Clusters übernimmt dann AWS, die Architektur der Datenflüsse bleibt unverändert. Für mich ist das ein gutes Beispiel für die AWS-first-Abwägung. Gemanagte Dienste nehmen Routinearbeit ab, die Engineering-Entscheidungen bleiben beim Team.

Kafka ist ein zentraler Baustein der Datenpipelines, über die ein erheblicher Teil der täglich verarbeiteten Datenmengen läuft. Wer Streaming-Systeme dieser Größe betreibt, braucht auch Werkzeuge für den Fehlerfall, etwa um einzelne Nachrichten gezielt nachverfolgen zu können.

Kubernetes in der Praxis auf Amazon EKS

Kubernetes nutze ich vor allem als Amazon EKS und baue dabei auf meiner langjährigen AWS-Praxis auf. Bei EKS kümmert sich AWS um die Control Plane. Die eigentliche Arbeit liegt trotzdem beim Team, und damit bei mir: Node-Gruppen dimensionieren, das Netzwerk sauber in die VPC einbinden, IAM-Rollen definieren, Load Balancer konfigurieren und die Workloads selbst betreiben.

Kubernetes verstehe ich dabei als ein Glied in einer Kette. Docker liefert das Image, CloudFormation legt das Infrastruktur-Fundament, und Kubernetes übernimmt die Orchestrierung: Es verteilt die Container auf die Nodes, hält die gewünschte Zahl an Instanzen aufrecht und steuert Rollouts neuer Versionen. Jedes Glied hat eine klar abgegrenzte Aufgabe. Das macht die Kette als Ganzes verständlich und im Fehlerfall leichter zu analysieren. Die zugrundeliegende Domainschnitt-Praxis entscheidet dabei, wie viele Services unabhängig voneinander deployt werden müssen.

Docker-Container in der Praxis: vom Laptop bis in die Produktion

Docker gehört für mich zum Arbeitsalltag, ich nutze es täglich. Ich setze containerisierte Staging-Sandboxes ein, in denen sich Änderungen gefahrlos ausprobieren lassen, bevor sie eine echte Umgebung erreichen. Entwicklungsumgebungen werden dadurch reproduzierbar: Wer ein Projekt neu aufsetzt, bekommt dieselbe Umgebung wie alle anderen. Auch Redesigns sehe ich mir zuerst lokal in einem Container an, bevor sie live gehen.

Dockerfiles und Compose-Dateien behandle ich wie jeden anderen Code. Sie sind versioniert, werden geteilt und durchlaufen Reviews. Damit wird die Umgebung selbst Teil des Projekts und ist kein Wissen, das nur in einzelnen Köpfen steckt.

Gleichzeitig ist Docker der erste Schritt Richtung Plattform. Ein Image, das lokal läuft, läuft ohne Umbau auch auf EKS. Dort übernimmt der Cluster Skalierung, Self-Healing und Rollouts. Weil dasselbe Image auf dem Laptop, in Staging und in Produktion läuft, gibt es beim Deployment deutlich weniger Überraschungen.

Der rote Faden: eigenständige Praktiken, ein gemeinsamer Betriebskontext

Kafka, Kubernetes und Docker sind für mich keine AWS-Produkte, sondern eigenständige Engineering-Praktiken mit eigenen Prinzipien. Event-Streaming, Container-Orchestrierung und reproduzierbare Laufzeitumgebungen funktionieren auf jeder Plattform. AWS ist der Ort, an dem ich sie zusammenführe und betreibe: mit gemanagten Diensten wie MSK und EKS dort, wo sie Betriebsaufwand sparen, und mit CloudFormation und nativen CI/CD-Werkzeugen als verbindendem Fundament.

Die AWS-first-Strategie hält diesen Stack schlank. Jede Ebene nutzt die Werkzeuge der Plattform, auf der sie läuft, und keine zusätzliche Abstraktion muss mitgepflegt werden. Dass dieser Ansatz trägt, zeigt der Alltag: Täglich verarbeiten diese Systeme mehrere hundert Terabyte.