Marco investierte 2021 sechs Monate in Puppet und Chef. Er baute ein komplettes Konfigurationsmanagement für seinen Arbeitgeber auf, dokumentierte jeden Schritt und war stolz auf das Ergebnis. Zwei Jahre später suchte er einen neuen Job. Von 30 Stellenanzeigen erwähnten 27 Terraform, drei Ansible, keine einzige Puppet. Er musste bei null anfangen.
Die Toollandschaft bewegt sich schnell. Was vor drei Jahren Standard war, kann heute Nische sein. Gleichzeitig gibt es Technologien, die seit Jahren stabil bleiben und absehbar nicht verschwinden werden. Dieser Artikel sortiert die Landschaft nach Relevanz für den Arbeitsmarkt 2026 und unterscheidet zwischen dem, was man beherrschen muss, dem, was sich lohnt, und dem, was man getrost ignorieren kann.
Das Fundament: Linux, Netzwerke, Scripting
Bevor irgendein Tool zum Einsatz kommt, braucht ein Infrastrukturingenieur drei Grundlagen: Linux-Administration, Netzwerkverständnis und mindestens eine Scriptsprache. Das klingt banal. In der Praxis scheitern Berufseinsteiger häufiger an fehlenden Linux-Kenntnissen als an mangelndem K8s-Wissen.
Linux ist das Betriebssystem hinter fast jeder Infrastruktur. Über neun Zehntel aller Webserver laufen auf Unix-basierten Systemen [1]. Wer Prozesse nicht versteht, Dateiberechtigungen nicht lesen kann und systemd nicht kennt, wird an Container-Debugging scheitern. Denn hinter jedem Pod läuft ein Linux-Prozess, und wenn etwas nicht funktioniert, landet man früher oder später auf der Shell.
Ein konkretes Beispiel: Ein Pod startet nicht, K8s zeigt CrashLoopBackOff. Der erste Reflex vieler Einsteiger ist, kubectl describe pod abzusetzen und die Events zu lesen. Oft reicht das nicht. Mit kubectl exec und einer Shell im Container prüft man Dateiberechtigungen (ls -la), laufende Prozesse (ps aux), Netzwerkverbindungen (ss -tlnp) und DNS-Auflösung (nslookup). Wer diese Linux-Basics nicht beherrscht, starrt auf K8s-Fehlermeldungen, ohne die eigentliche Ursache zu finden. Häufige Probleme wie falsche UID/GID-Mappings in Container-Images, fehlende Capabilities oder Read-only-Dateisysteme löst man ausschließlich mit Linux-Wissen.
Netzwerke sind das zweite Fundament. TCP/IP, DNS, Load Balancing, Firewalls, Subnetting. K8s-Networking mit CNI-Plugins, Service Meshes und Ingress-Controllern setzt all das voraus. Wer nicht weiß, was ein CIDR-Block ist, wird eine VPC-Konfiguration in HCL-Code nicht debuggen können.
Welche Scriptsprache sollte man zuerst lernen?
Python und Bash sind die beiden Scriptsprachen, die praktisch jede Stellenanzeige verlangt. Bash für schnelle Automatisierung auf der Shell, Python für komplexere Aufgaben: API-Integrationen, Custom Operators für K8s, Datenverarbeitung für Monitoring-Pipelines. Wer nur eine Sprache lernen will, sollte mit Python anfangen. Die Sprache deckt mehr Anwendungsfälle ab und ist auch außerhalb der Infrastrukturwelt gefragt.
Go gewinnt an Bedeutung, weil viele cloudnative Tools darin geschrieben sind (K8s, Terraform, Prometheus). Pflichtprogramm ist es noch nicht. Aber wer K8s-Operator entwickeln oder an CNCF-Projekten mitarbeiten will, kommt an Go kaum vorbei. In der DACH-Region nennen Stellenanzeigen auf StepStone deutlich häufiger Python und Bash als Go. Go taucht in etwa jeder sechsten Stellenanzeige auf, Python in fast zwei Drittel [11].
Container: Docker und Kubernetes
Docker hat Container populär gemacht. Das Prinzip ist einfach: Eine Anwendung mit allen Abhängigkeiten in ein standardisiertes Paket verpacken, das überall gleich läuft. In der Stack Overflow Developer Survey 2024 gaben knapp sechs von zehn der professionellen Entwickler an, Docker zu nutzen [2]. Für Infrastrukturspezialisten ist Docker nicht optional, sondern Grundvoraussetzung.
Kubernetes orchestriert Container im großen Maßstab. Laut CNCF Annual Survey 2024 nutzen oder evaluieren über neun Zehntel der befragten Organisationen K8s, vier Fünftel setzen es produktiv ein [3]. Managed Services wie EKS, AKS und GKE haben die Einstiegshürde gesenkt. Trotzdem bleibt K8s komplex. Networking, Storage, RBAC, Pod Security Standards: Die Lernkurve ist steil und endet nie.
Braucht man Kubernetes wirklich?
Ja und nein. Nicht jedes Projekt braucht Container-Orchestrierung. Ein einzelner Service mit 500 Requests pro Minute läuft auf einem einfachen Docker-Compose-Setup oder einer Serverless-Plattform günstiger und einfacher. Aber die überwältigende Mehrheit der Stellenanzeigen setzt K8s-Kenntnisse voraus. Selbst wenn man in einem Projekt ohne Orchestrierung landet, erwartet der Arbeitgeber, dass man es kann.
Welcher Managed-Kubernetes-Service passt?
In der Praxis betreibt kaum jemand K8s selbst auf Bare Metal. Managed Services nehmen den schwersten Teil der Arbeit ab: Control Plane, etcd-Cluster, API-Server-Updates. Amazon EKS dominiert den Markt mit geschätzt zwei Fünfteln aller Managed-K8s-Installationen. Die Integration in AWS-Dienste (IAM, ALB, EBS, CloudWatch) funktioniert reibungslos, und die meisten IaC-Module sind auf EKS optimiert.
Azure AKS ist in der DACH-Region die stärkste Alternative. Unternehmen wie die Deutsche Telekom, Siemens und Bosch setzen auf Microsofts Plattform als primäre Plattform, und AKS profitiert von dieser Bestandsinfrastruktur. Der Vorteil: Microsoft Entra ID (ehemals Azure Active Directory) als Identity-Provider, enge Integration mit Microsofts DevOps-Dienst und ein Preismodell, bei dem das Control Plane kostenlos ist. GKE gilt unter Container-Spezialisten als technisch beste Implementierung, was wenig überrascht, denn Google hat K8s ursprünglich entwickelt. Autopilot-Modus, Service Mesh (Istio-basiert) und native Workload-Autoscaling machen GKE besonders attraktiv für Teams, die maximale Automatisierung wollen.
Meine Empfehlung für Einsteiger: Mit dem Service anfangen, der zum Hyperscaler des Arbeitgebers passt. Die K8s-Konzepte sind identisch, nur die Peripherie unterscheidet sich (Ingress-Controller, Storage-Klassen, IAM-Integration). Wer privat lernt und keine Vorgabe hat, fährt mit GKE am besten, weil die Einrichtung am wenigsten Boilerplate erfordert.
Podman als Docker-Alternative gewinnt im Enterprise-Umfeld an Boden, besonders seit Red Hat es als Standard in RHEL positioniert. Für die tägliche Arbeit ändert sich wenig. Die Container-Images sind identisch, die CLI ist weitgehend kompatibel. Wer Docker beherrscht, findet sich in Podman innerhalb eines Tages zurecht.
Infrastructure as Code: Terraform und die Alternativen
Infrastructure as Code (IaC) ist das Herzstück moderner Infrastrukturarbeit. Statt Ressourcen manuell in Webkonsolen zusammenzuklicken, beschreibt man sie in Code, versioniert sie in Git und rollt sie automatisiert aus. Reproduzierbar, nachvollziehbar, reviewbar.
Terraform von HashiCorp dominiert dieses Feld seit Jahren. Die Registry listet über 3.000 Provider für AWS, Azure, GCP, Cloudflare, Datadog und hunderte weitere Dienste [4]. Die Sprache HCL (HashiCorp Configuration Language) ist deklarativ und relativ leicht zu lernen. IBM schloss die Übernahme von HashiCorp im Februar 2025 für 6,4 Milliarden Dollar ab [5]. Die langfristigen Auswirkungen auf das Tool-Landschaft sind noch unklar, aber die Marktdominanz ist vorerst ungefährdet.
Die Lizenzänderung des IaC-Tools zu Business Source License im August 2023 hat Alternativen gestärkt. OpenTofu, ein Community-Fork unter der Linux Foundation, bietet volle Kompatibilität mit bestehenden IaC-Modulen [6]. Pulumi erlaubt Infrastructure as Code in echten Programmiersprachen (Python, TypeScript, Go) statt in HCL. Crossplane verfolgt einen K8s-nativen Ansatz und verwaltet Infrastrukturressourcen als Custom Resources.
Was bedeutet die IBM-Übernahme für Terraform?
IBM schloss die Übernahme von HashiCorp im Februar 2025 ab. Der Preis: 6,4 Milliarden Dollar. Die Community reagierte gespalten. Einerseits hat IBM eine Geschichte darin, Open-Source-Projekte zu unterstützen (Red Hat, Eclipse). Andererseits erinnern sich viele an die Stagnation von Projekten wie IBM Cloud Functions und Watson-APIs nach vielversprechendem Start.
Für die tägliche Arbeit mit dem IaC-Tool hat sich bisher wenig geändert. Die Releases kommen weiterhin regelmäßig, die Provider-Entwicklung läuft stabil. Das eigentliche Risiko liegt in der Preisgestaltung für die gehostete Variante und Enterprise. Einige Großunternehmen haben bereits den Wechsel vollzogen: Fidelity Investments migrierte im April 2025 über 50.000 State-Dateien auf OpenTofu. Der Wechsel war laut öffentlichen Berichten überraschend reibungslos, weil die Syntax identisch ist und bestehende Module ohne Anpassung funktionieren. Auch europäische Unternehmen, die auf langfristige Planbarkeit Wert legen, schauen sich OpenTofu zunehmend an.
Meine Empfehlung: Das HCL-Werkzeug zuerst lernen. Die Marktdominanz ist zu groß, um sie zu ignorieren. OpenTofu als Backup kennen, falls die IBM-Übernahme das Anbieterumfeld negativ beeinflusst. Ansible für Konfigurationsmanagement ergänzend dazunehmen. Pulumi und Crossplane beobachten, aber nicht als Hauptinvestition.
CI/CD: Wie Code in Produktion kommt
Continuous Integration und Continuous Delivery bilden das Rückgrat jeder modernen Softwareauslieferung. Der Entwickler pusht Code in ein Repository, eine Pipeline baut automatisch, testet und deployt. Im Arbeitsalltag verbringt man einen erheblichen Teil der Arbeitszeit mit dem Design, der Optimierung und der Fehlerbehebung dieser Pipelines.
GitHub Actions hat Jenkins als beliebtestes CI/CD-Tool überholt. Weil Actions direkt ins Repository eingebettet sind, entfällt die separate CI-Server-Verwaltung komplett. Die YAML-basierte Konfiguration ist intuitiv, der Marketplace bietet tausende vorgefertigte Actions. Laut JetBrains Developer Ecosystem Survey 2024 nutzen fast zwei Drittel der Befragten GitHub Actions für persönliche Projekte und zwei Fünftel in Unternehmen [7]. GitLab CI folgt mit starker Verbreitung in europäischen Unternehmen, besonders dort, wo selbstgehostete Instanzen bevorzugt werden.
Wie sieht eine gute Pipeline konkret aus?
Eine typische CI/CD-Pipeline für einen Microservice durchläuft fünf Stufen. Zuerst Lint und statische Analyse: Code-Qualitätstools wie SonarQube oder einfache Linter prüfen Syntax und Konventionen in unter 30 Sekunden. Dann folgen Unit-Tests und Integration-Tests, idealerweise parallel, um die Gesamtlaufzeit kurz zu halten. Stufe drei baut das Container-Image, taggt es mit dem Git-SHA und pusht es in eine Registry (ECR, ACR, Harbor oder GitHub Container Registry). Stufe vier scannt das Image auf Sicherheitslücken mit Tools wie Trivy oder Grype. Die letzte Stufe deployt automatisch in eine Staging-Umgebung und wartet auf manuelle Freigabe für Produktion.
Eine gute Pipeline läuft in unter zehn Minuten durch. Das klingt nach einer willkürlichen Grenze, hat aber einen konkreten Grund: Nicole Forsgren und das DORA-Team zeigten in ihren State-of-DevOps-Berichten wiederholt, dass Teams mit kurzen Deployment-Zyklen signifikant seltener Incidents verursachen [12]. Pipelines über 30 Minuten frustrieren Entwickler und verleiten dazu, Commits zu bündeln (was das Risiko erhöht).
Jenkins bleibt der Elefant im Raum. Veraltet im Vergleich zu modernen Alternativen, aber in tausenden Enterprise-Umgebungen tief verankert. Wer bei einem DAX-Konzern anfängt, wird mit hoher Wahrscheinlichkeit Jenkins-Pipelines warten müssen. Das ist kein Nachteil: Jenkins-Erfahrung signalisiert Arbeitgebern, dass man mit Legacy-Systemen umgehen kann, und davon gibt es in der Realität mehr als genug.
GitOps: Warum Git die Single Source of Truth wird
GitOps dreht das Deployment-Modell um. Statt Pipelines, die auf Cluster pushen, synchronisiert ein Controller im Cluster den gewünschten Zustand aus einem Git-Repository. ArgoCD ist das beliebteste Tool dafür, Flux die Alternative. Laut CNCF Annual Survey 2024 setzen 77 % der Befragten GitOps bereits ein [8]. Wer ArgoCD oder Flux produktiv nutzt, berichtet von schnellerem Rollback und besserer Nachvollziehbarkeit.
Die Stärke von GitOps liegt in der Auditierbarkeit. Jede Änderung an der Infrastruktur ist ein Git-Commit mit Autor, Zeitstempel und Review. Für regulierte Branchen wie Fintech oder Gesundheitswesen ist das ein erheblicher Vorteil, weil Compliance-Audits deutlich einfacher werden.
Hyperscaler: Welcher Anbieter lohnt sich?
AWS führt den globalen Markt der Hyperscaler mit knapp drei Zehnteln Marktanteil, gefolgt von Microsoft Azure mit einem Fünftel und GCP mit gut einem Achtel (Stand Q3 2025) [9]. In der DACH-Region verschiebt sich dieses Bild deutlich zugunsten von Azure, weil viele Unternehmen bereits auf Microsoft 365, Active Directory und Dynamics 365 setzen. Microsofts Plattform wird dann zur logischen Erweiterung der bestehenden Infrastruktur.
Konkrete Beispiele zeigen das Muster. Volkswagen betreibt seine Industrial Platform auf AWS, kooperiert aber parallel mit Microsoft für Office-Workloads. Die Deutsche Bank migrierte große Teile ihrer IT auf GCP und Microsofts Plattform in einer Multi-Anbieter-Strategie. SAP, als größter europäischer Softwarekonzern, unterstützt alle drei Hyperscaler für SAP HANA, setzt aber intern stark auf Azure und AWS. Für Bewerber in der DACH-Region lohnt sich ein Blick auf die Jobbörsen: Bei Automobilzulieferern und Versicherungen taucht Microsofts Plattform in fast jeder zweiten Stellenanzeige für Infrastrukturrollen auf.
Lohnt sich eine Multi-Anbieter-Strategie wirklich?
Die ehrliche Antwort: meistens nicht. Mehrere Anbieter gleichzeitig klingt auf Konferenzfolien überzeugend, erzeugt in der Praxis aber erheblichen Mehraufwand. Jede Plattform hat eigene IAM-Konzepte, Netzwerk-Primitives und Monitoring-Tools. Ein Team, das AWS und Azure gleichzeitig produktiv betreiben muss, braucht doppeltes Know-how und doppelte Toolchains.
Für die Karriereplanung bedeutet das: AWS-Kenntnisse bieten die breiteste Basis, weil die meisten Stellenanzeigen AWS erwähnen. Azure lohnt sich besonders für den Enterprise-Bereich in Deutschland. GCP ist die kleinste der drei Plattformen, hat aber starke Nischen: K8s (GKE gilt als Referenzimplementierung), Data Engineering (BigQuery) und Machine Learning. Wer sich für eine Plattform entscheiden muss, sollte sich an der Branche des Wunscharbeitgebers orientieren, nicht an globalen Marktanteilen.
Observability: Sehen, was in Produktion passiert
Monitoring misst bekannte Werte, Observability ermöglicht es, unbekannte Probleme zu diagnostizieren. Die Unterscheidung klingt akademisch, ist aber praktisch relevant: Monitoring sagt, dass die CPU bei 95 % liegt. Observability zeigt, welcher Request in welchem Service den Engpass verursacht.
Prometheus für Metriken und Grafana für Visualisierung bilden den Open-Source-Standard. Beide sind CNCF-Projekte und in K8s-Umgebungen allgegenwärtig. Für Logging hat sich der ELK-Stack (Elasticsearch, Logstash, Kibana) etabliert, wobei OpenSearch als Fork nach der Elastic-Lizenzänderung an Boden gewinnt. Distributed Tracing mit Jaeger oder Tempo ergänzt das Bild für Microservice-Architekturen.
Was kostet Observability in der Praxis?
Ein typisches Setup für ein mittelgroßes K8s-Cluster (50 Nodes, 200 Pods) sieht so aus: Prometheus mit Thanos für Langzeitspeicherung, Grafana für Dashboards, Loki für Logs und Tempo für Traces. Alle vier Komponenten sind Open Source. Die Infrastrukturkosten beschränken sich auf Compute und Storage, typischerweise 500 bis 1.200 Euro monatlich beim jeweiligen Anbieter. Der eigentliche Aufwand steckt in der Wartung: Updates, Kapazitätsplanung, Alerting-Regeln pflegen. Ein bis zwei Personentage pro Monat sind realistisch.
Kommerzielle Alternativen wie Datadog, New Relic und Dynatrace bieten All-in-One-Plattformen mit weniger Betriebsaufwand. Datadog hat sich in den letzten Jahren als Marktführer positioniert [10]. Der Nachteil: Kosten. Bei großen Deployments erreichen Datadog-Rechnungen schnell fünfstellige Monatsbeiträge. Für dasselbe 50-Node-Cluster rechnet man bei Datadog mit 5.000 bis 12.000 Euro pro Monat (Infrastructure Monitoring, APM, Log Management zusammen). New Relic bietet ein nutzungsbasiertes Modell ab 0,40 Dollar pro GB Ingested Data. Dynatrace, stark verbreitet bei österreichischen und deutschen Großunternehmen (das Unternehmen stammt aus Linz), berechnet nach Host-Units und liegt preislich zwischen Datadog und dem Open-Source-Stack.
Viele Unternehmen fahren eine Mischstrategie: Prometheus und Grafana für Infrastrukturmetriken, einen kommerziellen Anbieter für APM und Tracing. Das halte ich für den pragmatischsten Ansatz. Open Source deckt vier Fünftel der Anforderungen ab, und nur für das fehlende Fünftel (End-to-End-Tracing, AI-gestützte Anomalieerkennung) zahlt man einen kommerziellen Anbieter.
Wie bleibt man bei der Tool-Flut auf dem Laufenden?
Die CNCF Landscape umfasst über 1.000 Einträge, und jeden Monat kommen neue hinzu. Kein Mensch kann alle kennen. Die effektivste Strategie: den stabilen Kern beherrschen und dann gezielt Spezialisierungen hinzufügen, die der eigene Arbeitgeber oder Zielarbeitgeber tatsächlich einsetzt. Stellenanzeigen auf StepStone und LinkedIn nach konkreten Tool-Nennungen filtern gibt einen besseren Kompass als die neueste Hype-Liste auf Reddit.
Konferenzen wie die KubeCon Europe, DevOpsCon München oder die CNCF-Konferenzen in der DACH-Region helfen, Trends einzuordnen, ohne jedem nachzulaufen. Podcasts wie „Kubernetes Podcast from Google“ oder „DevOps Paradox“ liefern wöchentliche Updates in kompakter Form, die man auf dem Arbeitsweg hören kann, ohne dafür Abendstunden opfern zu müssen. Der CNCF End User Technology Radar zeigt regelmäßig, welche Tools tatsächlich in Produktion ankommen und welche beim Experimentieren bleiben.
Fazit
Die Toollandschaft 2026 hat einen stabilen Kern: Linux, Docker, K8s, Terraform, CI/CD (GitHub Actions oder GitLab CI), AWS als bevorzugter Hyperscaler, Prometheus und Grafana. Wer diesen Stack beherrscht, erfüllt die Anforderungen von über vier Fünfteln der Stellenanzeigen.
Was über diesen Kern hinausgeht, ist Spezialisierung: GitOps mit ArgoCD für K8s-Deployments, Pulumi für programmatische IaC, Service Meshes für Microservice-Kommunikation, FinOps-Tools für Kostenoptimierung. Wertvoll, aber nicht zwingend zum Einstieg.
Marcos Fehler aus der Einleitung lässt sich vermeiden: Technologien nach Arbeitsmarktnachfrage auswählen, nicht nach persönlicher Vorliebe. Stellenanzeigen auf StepStone und LinkedIn geben einen besseren Kompass als Blogposts über „die Zukunft der Branche“. Das spart Monate verschwendeter Lernzeit.
Wer den Einstieg plant, sollte eine klare Reihenfolge einhalten. Zuerst Linux und Networking, weil ohne dieses Fundament alles Weitere auf Sand gebaut ist. Dann Docker und K8s, weil sie in praktisch jeder Stellenanzeige auftauchen. IaC kommt als Drittes, gefolgt von CI/CD. Erst danach lohnt sich die Spezialisierung auf Observability, GitOps oder Sicherheitsthemen. Wer diese Reihenfolge umkehrt und mit ArgoCD anfängt, bevor er einen Linux-Prozess debuggen kann, wird im Vorstellungsgespräch scheitern.
Teil 3 dieser Serie zeigt die konkreten Einstiegswege: Welche Ausbildung lohnt sich, was bringen Zertifizierungen und wie baut man ein überzeugendes Portfolio auf?
Quellen
[1] W3Techs: Usage Statistics of Operating Systems for Websites, März 2026 (https://w3techs.com/technologies/overview/operating_system)
[2] Stack Overflow Developer Survey 2024: Most Popular Technologies (https://survey.stackoverflow.co/2024/)
[3] CNCF Annual Survey 2024: Kubernetes Adoption (https://www.cncf.io/reports/)
[4] HashiCorp Terraform Registry (https://registry.terraform.io/)
[5] IBM: Acquisition of HashiCorp, Februar 2025 (https://newsroom.ibm.com/)
[6] OpenTofu: Open-Source Terraform Fork (https://opentofu.org/)
[7] JetBrains Developer Ecosystem Survey 2024: DevOps (https://www.jetbrains.com/lp/devecosystem-2024/)
[8] CNCF GitOps Microsurvey 2024 (https://www.cncf.io/reports/)
[9] Synergy Research Group: Cloud Infrastructure Market, Q3 2025 (https://www.srgresearch.com/)
[10] Gartner Magic Quadrant for APM and Observability, 2025 (https://www.gartner.com/)
[11] StepStone Gehaltsreport IT & DevOps 2025, Auswertung der meistgenannten Technologien in DevOps-Stellenanzeigen (https://www.stepstone.de/)
[12] DORA State of DevOps Report 2024: Accelerate (https://dora.dev/research/)