Wie hält man in einer sich ständig wandelnden Tech-Landschaft Schritt? Welche Rolle spielen Fachkonferenzen, neue Tools und Community-Meetups für den Alltag in der Softwareentwicklung? Und wohin entwickelt sich der Bereich DevOps, wenn plötzlich alle über Platform Engineering sprechen?
Fachkonferenzen, Meetups & Community
Jürgen: Jasmin, du bist regelmäßig auf Konferenzen und Meetups unterwegs. Was sind deine Favoriten?
Jasmin: Ich versuche, einen guten Mix aus großen Konferenzen und lokalen Community-Events zu besuchen. Bei den großen Formaten sind das etwa die KubeCon oder die Kubernetes Community Days. Die bringen natürlich viele internationale Perspektiven. Aber die kleineren Formate sind oft spannender – etwa das Vienna DevOps Meetup von Squer, das Vienna DevOps and Security Meetup oder das recht neue Platform Engineering Vienna, das von Dynatrace organisiert wird.
Jürgen: Wie unterscheiden sich große Konferenzen wie die KubeCon von diesen Meetups?
Jasmin: Die KubeCon ist mit etwas mehr als 12.000 Teilnehmern natürlich ein sehr großes Event. In Amsterdam 2023 waren die Säle teilweise überbucht und es war dann nur möglich, über Live-Stream teilzunehmen. Die Kubecon Experience ist dennoch einmalig, denn es ist für jeden etwas dabei. Spannende Keynotes und Talks, unzählige Networking Möglichkeiten sowie Projektstände mit Demos und Swags. Besonders hervorzuheben sind die Co-Located Events, die immer einen Tag vor der eigentlichen Kubecon stattfinden. Inspirierende Talks zu bestimmten Themenbereichen, 2025 z.B. der Platform Engineering Day oder der Cloud Native + K8s AI Day, und viele Show-and-Tell Sessions runden den Start zur Kubecon ab.
Meetups auf der anderen Seite sind mit 30 bis 80 Teilnehmern eher überschaubar. Es gibt zwei oder drei Talks, dazwischen Networking, Pizza, Kaffee – das ist nahbarer und regional. Die Kubecon ist sehr wertvoll, um internationale Trends und Entwicklungen in der Community zu beobachten. Regionale Events sind ebenso essentiell, um zu verstehen, wie diese globalen Trends auf den lokalen Markt wirken und vor allem, um unsere Position im Wettbewerb besser zu verorten.
Jürgen: Welche Themen werden dort konkret behandelt?
Jasmin: Die Themen sind breit gefächert, aber Tools sind dominant. Es geht oft um Use Cases bestehender Tools, z. B. wie Gitops mit FluxCD realisiert wird oder warum wir unseren Code immer up to date halten wollen. Ein großes Thema ist auch Observability, also Open Telemetry, Metriken, Logs, Traces. Es geht auch um Software Supply Chain Security – etwa um Image Signing oder die Sicherheit von IoT-Geräten. Ich habe einmal einen Talk einer PhD Studentin der TU Wien gesehen, die gezeigt hat, wie leicht Sicherheitslücken im IoT-Bereich ausgenutzt werden können – unglaublich spannend!
Security, Automation und der Wandel der Tool-Landschaft
Jürgen: Wie präsent ist das Thema Security in der DevOps-Community?
Jasmin: Das Bewusstsein wird immer mehr gestärkt. Der Fokus liegt hier auf Application-Security, vor allem wie die Software Supply Chain bestmöglich abgesichert werden kann. Teil unseres Stacks ist auch ein komplexes Netzwerk von Abhängigkeiten, wobei eine vollständige manuelle Überprüfung jeder Komponente mit hohem Aufwand verbunden ist. Die Gefahr liegt in der potenziellen Integration kompromittierter Pakete, wie wir gerade wieder am Beispiel der GitHub Action tj-actions/changed-files sehen. Wir nutzen diese Action. Solche Vorfälle zeigen, dass selbst bei vertrauenswürdigen und weit verbreiteten Tools plötzlich Sicherheitslücken auftreten können. Dank der Open-Source Community wurde die Schwachstelle schließlich schnell entdeckt und adressiert.
Jürgen: Das sehen wir ja auch oft in Software-Projekten. Da werden Libraries geladen, deren weitere Entwicklung unbedarfte Software-Entwickler nicht mehr anschauen. (Bei uns nicht) Ich frage mich oft: Wie sicher ist das eigentlich?
Jasmin: Genau, da kommt Automation ins Spiel. Bei uns übernimmt Renovate einen großen Teil der automatisierten Updates. Es prüft kontinuierlich, ob neue Versionen von Libraries verfügbar sind, erstellt PRs und merged sie – allerdings nur, wenn Sicherheitschecks und Tests durchgelaufen sind. Wir nutzen zum Beispiel npm audit, um Schwachstellen zu identifizieren. Dieser Prozess läuft vollautomatisch als Teil des PRs.
Jürgen: Und wenn’s keine ausreichende Testabdeckung gibt?
Jasmin: Dann ist das ein Problem. Renovate prüft nur die vorhandenen Status-Checks. Wenn die fehlen oder unzureichend sind, geht ein Update durch, das unter Umständen etwas kaputt macht. Deshalb ist Testqualität ein zentraler Punkt jeder Automatisierung. Automation funktioniert nur, wenn der Unterbau stabil ist.
Telemetrie und Observability in der Praxis
Jürgen: Was steckt hinter dem Schlagwort „OpenTelemetry“?
Jasmin: OpenTelemetry ist ein Open-Source-Projekt, das einen standardisierten Ansatz für das Sammeln von Telemetriedaten aus Anwendungen und Infrastrukturen bietet. Es geht darum, was die Applikation meldet: Welche Metriken, welche Logs, welche Traces. Prinzipiell kann man damit jeden Request von Anfang bis Ende durch alle Services verfolgen. Dazu kommt Alerting – also wann, wie oft und über welche Kanäle bekomme ich Benachrichtigungen, wenn etwas nicht funktioniert.
Jürgen: Und das funktioniert bei großen Systemen?
Jasmin: Jein. Bei wenigen Clustern ist das überschaubar. Bei vielen Clustern ist eine zentrale Observability oft notwendig. . Da gibt es eigene Lösungen, wie man Telemetriedaten zentral und skalierbar auswertet.
Der Wandel: Von DevOps zu Platform Engineering
Jürgen: Du hast vorhin gesagt, Platform Engineering sei das neue große Thema. Was unterscheidet das von DevOps?
Jasmin: Platform Engineering denkt Infrastruktur ganzheitlich. DevOps war oft auf Tools und Prozesse fokussiert – Platform Engineering kümmert sich zusätzlich um das ganze „Drumherum“: Infrastruktur, Kosten, Skalierung, Developer-Portale. „Vor drei Jahren wollte man noch alle Developer zu Kubernetes bringen – heute merkt man: Die Komplexität ist zu hoch.“
Jürgen: Gibt’s konkrete Lösungen?
Jasmin: Ja, sogenannte Self-Service-Plattformen. Der Developer füllt ein Formular aus: „Ich brauche ein Bucket mit diesen Spezifikationen“ – klickt auf OK – und im Hintergrund läuft eine Pipeline, die alles provisioniert. Das nennt man Infrastructure as a Service, oder kurz: IaaS. „Ich dachte ja, ich hätte den Begriff erfunden, aber den gibt’s wirklich.“
Zusammenarbeit, Trennung, Verständnis
Jürgen: Ich sehe es kritisch, wenn sich Developer:innen und Infra-Leute zu weit voneinander entfernen. Gute Entwickler:innen müssen verstehen, was im Backend passiert – und umgekehrt.
Jasmin: Unbedingt. Ich glaube nicht, dass man als Developer:in gut sein kann, wenn man sagt: Ich hab meine Klasse geschrieben – der Rest interessiert mich nicht. Gerade im Web-Bereich muss man wissen, wie ein Hochlastsystem funktioniert, wie Caching wirkt, was Security bedeutet.
Jürgen: Ich habe schon Frontend-Code gesehen, in dem sensible Daten via GET-Request verschickt wurden – inklusive Sozialversicherungsnummer in der URL. Technisch funktioniert das, aber es ist katastrophal. Und sowas passiert, wenn das Verständnis für Infrastruktur fehlt.
Jasmin: Oder wenn Datenbank-Zugänge im Klartext auftauchen – entweder im Code oder in den Logs. Wir haben schon beides gesehen.
Blick in die Zukunft
Jürgen: Du beobachtest die Szene seit Jahren. Wohin entwickelt sich dein Bereich in den nächsten zwei bis drei Jahren?
Jasmin: Ganz klar: Plattformen. Platform Engineering, Developer Self-Service, Infrastructure as a Service – alles geht dahin, dass Prozesse automatisiert, abstrahiert und skalierbar werden. „Der Developer soll Infrastruktur so einfach nutzen können wie eine Software – ohne sie selbst zu bauen.
Jürgen: Gibt’s ein Erlebnis der letzten Zeit, das dich besonders beeindruckt hat?
Jasmin: Die Führung durch das Rechenzentrum von NTT in Wien war großartig. „Die verwenden ein Gas, das dem Feuer den Sauerstoff entzieht. Die löschen nicht – die dämpfen aus. Die Sicherheitsstandards dort sind extrem hoch, das war wirklich beeindruckend. Organisiert wurde das von NextLayer – die kennen wir ja gut.
