Vier Nischen. Und die Unterschiede darin.

Ein Etikett sagt wenig. Wer „Cloud Engineer" liest und aufhört zu fragen, vermittelt Zufallstreffer. Wir fragen weiter: welches Ökosystem, welche Werkzeuge, welche Denkweise. Erst dann passt ein Dossier zu einem Mandat.

Cybersecurity

Angriff, Verteidigung und Nachweis sind drei verschiedene Berufe.

Offensive Security (Penetration Testing, Red Team) denkt in Angriffspfaden. Defensive Security (SOC, Incident Response, Detection Engineering) denkt in Signalen und Reaktionszeit. GRC (ISO 27001, BSI IT-Grundschutz, NIS2) übersetzt beides in Nachweise, die Prüfer akzeptieren. Cloud-Security ist dazu ein eigenes Feld: Wer IAM in Azure härtet, hat selten dasselbe Profil wie ein Netzwerk-Pentester.

WORAUF WIR ACHTEN

• Zertifikate lesen wir als Sprache: OSCP erzählt von Praxis im Angriff, CISSP von Architektur und Verantwortung.
• KRITIS- und Konzernumgebungen verlangen anderes Arbeiten als Startups: Change-Prozesse statt Schnellschüsse.
• Wir fragen nach dem letzten Vorfall, nicht nur nach dem letzten Tool.

Cloud

Azure, AWS und Google Cloud sind drei Ökosysteme, nicht drei Logos.

Azure hängt am Microsoft-Stack (Entra ID, M365) und dominiert in DACH-Konzernen. AWS trägt die größte Servicebreite, vom Startup bis zum Enterprise. Google Cloud ist zu Hause, wo Daten und Machine Learning den Takt geben (BigQuery, Kubernetes-Herkunft). „Multi-Cloud" im Lebenslauf heißt selten: dreimal tief.

WORAUF WIR ACHTEN

• Zertifizierungspfade und Projektjahre pro Plattform, nicht die Logo-Liste.
• Infrastructure as Code als Handschrift: Terraform, Bicep oder CloudFormation verraten die Heimat-Plattform.
• Migration ist nicht Greenfield: Wer Legacy in die Cloud hebt, kann etwas anderes als wer auf der grünen Wiese baut.

DevOps

Pipelines bauen und Betrieb verantworten sind zwei Paar Schuhe.

CI/CD-Ketten (GitHub Actions, GitLab, Jenkins) sind das Handwerk. SRE ist die Haltung dahinter: Fehlerbudgets, Observability (Prometheus, Grafana, Datadog), Bereitschaftsdienst. Dazwischen liegt Kubernetes, mit eigenen Distributionen und eigenem Tiefgang.

WORAUF WIR ACHTEN

• On-Call-Erfahrung: Wer nachts geweckt wurde, baut tagsüber anders.
• Kubernetes in Produktion ist etwas anderes als Kubernetes im Tutorial.
• Werkzeuge wechseln, Prinzipien bleiben: Wir fragen nach dem Warum hinter der Pipeline.

Platform Engineering

Die Plattform ist ein Produkt. Der Kunde sitzt im eigenen Haus.

Interne Entwicklerplattformen (Backstage und Co., Golden Paths, Self-Service) verlangen Produktdenken: Roadmap, Nutzergespräche, Adoption. Das unterscheidet Platform Engineers von DevOps-Generalisten, auch wenn die Werkzeugkiste ähnlich aussieht.

WORAUF WIR ACHTEN

• Produktverständnis: Wer waren die internen Kunden, und woran wurde Erfolg gemessen?
• Adoption schlägt Architektur: Eine Plattform, die niemand nutzt, ist keine.
• Schnittstellenarbeit über Teamgrenzen: Kommunikation ist hier Kernkompetenz, kein Beiwerk.