Platform Engineering 101: Über klassische Ticketsysteme in Azure hinausdenken

Von Mirko Peters · 2026-08-13

Willkommen zurück, liebe Zuhörer und Leser, zu einem weiteren Deep Dive in die sich wandelnde Welt von Cloud-Architektur, Developer Experience und modernem DevOps. Wenn Sie unsere jüngste Podcast-Folge gehört haben, wissen Sie, dass wir uns ausführlich mit einem der frustrierendsten Engpässe in der modernen Softwarebereitstellung beschäftigt haben: dem klassischen IT-Ticketsystem. Sie kennen das P

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück, liebe Zuhörer und Leser, zu einem weiteren Deep Dive in die sich wandelnde Welt von Cloud-Architektur, Developer Experience und modernem DevOps. Wenn Sie unsere jüngste Podcast-Folge gehört haben, wissen Sie, dass wir uns ausführlich mit einem der frustrierendsten Engpässe in der modernen Softwarebereitstellung beschäftigt haben: dem klassischen IT-Ticketsystem. Sie kennen das Prozedere. Ein Entwickler braucht eine neue Datenbank, eine Staging-Umgebung oder eine einfache DNS-Änderung. Er öffnet ein Ticket. Das Ticket wartet in einer Warteschlange. Es wird priorisiert, zugewiesen, neu zugewiesen und schließlich, Tage oder sogar Wochen später, manuell umgesetzt. Bis diese Infrastruktur bereitsteht, ist der Sprint vorbei, der Schwung dahin und alle sind erschöpft.

In diesem begleitenden Blogbeitrag vertiefen wir die Kernthemen, die wir in der Folge besprochen haben. Wir zeigen, wie Organisationen, die Microsoft Azure nutzen, aus dieser aufreibenden manuellen Schleife ausbrechen können, indem sie die transformative Disziplin des Platform Engineerings einsetzen und robuste Internal Developer Platforms (IDPs) aufbauen.

Einleitung: Der Engpass klassischer Ticketprozesse in Azure

Lassen Sie uns ein vertrautes Bild zeichnen. Ihre Organisation hat ihre Workloads zu Microsoft Azure migriert. Sie haben die Cloud angenommen und nutzen Azure Kubernetes Service (AKS), Azure SQL, Cosmos DB und App Services. Auf dem Papier sind Sie modern. Schaut man jedoch genauer auf Ihre Arbeitsabläufe, behandeln Ihre Entwickler Azure genau so, wie sie früher den lokalen Serverraum behandelt haben: über eine Mauer aus Bürokratie und Ticket-Warteschlangen.

Wenn ein Team eine Ressource bereitstellen möchte, kann es das nicht einfach selbst tun. Leitplanken wurden als Hindernisse statt als Orientierungshilfen umgesetzt. Die Teams reichen ein Ticket bei der zentralen Plattform- oder Betriebsabteilung ein. Das erzeugt eine enorme kognitive Belastung und untergräbt die Agilität, die Cloud Computing eigentlich ermöglichen sollte. Azure bietet außergewöhnliche Geschwindigkeit und programmierbare Kontrolle, dennoch bleiben Entwickler oft davon abgeschottet. Das klassische Ticketsystem wirkt wie eine Innovationssteuer. Jede Anfrage erfordert menschliches Eingreifen, was zu menschlichen Fehlern, Missverständnissen und quälenden Verzögerungen führt. Wir müssen aufhören, Entwickler wie Kinder zu behandeln, denen man keine Infrastruktur anvertrauen kann, und sie stattdessen als eigenverantwortliche Gestalter betrachten, die Self-Service-Möglichkeiten benötigen, abgesichert durch automatisierte Leitplanken.

Was ist Platform Engineering und warum ist es wichtig?

Wie lösen wir dieses Problem also? Hier kommt Platform Engineering ins Spiel. In den vergangenen Jahren hat sich Platform Engineering als die maßgebliche Weiterentwicklung von DevOps etabliert. DevOps hat die Mauer zwischen Entwicklung und Betrieb in der Theorie eingerissen, in der Praxis haben viele Organisationen jedoch die gesamte betriebliche Last einfach auf die Entwickler abgewälzt. Von Entwicklern wurde plötzlich erwartet, Experten für Kubernetes, Terraform, Netzwerksicherheit und Azure-IAM-Richtlinien zu sein, und dabei gleichzeitig Geschäftslogik zu programmieren.

Platform Engineering erkennt, dass dieser Zustand nicht tragbar ist. Anstatt Entwickler zu Infrastrukturexperten zu machen oder sie in einer Ticket-Warteschlange warten zu lassen, behandelt Platform Engineering die Developer Experience als Produkt. Ein dediziertes Plattformteam baut eine Internal Developer Platform (IDP), die die zugrunde liegende Komplexität von Azure abstrahiert.

Warum ist das wichtig? Weil kognitive Belastung der stille Killer der Entwicklerproduktivität ist. Wenn Entwickler 40 Prozent ihrer Zeit mit Infrastrukturkonfigurationen, Compliance-Checklisten und dem Warten auf Genehmigungen verbringen, entwickeln sie keine Funktionen, die Kunden begeistern. Platform Engineering ist wichtig, weil es Teams wieder in einen Flow-Zustand versetzt. Es stellt sogenannte Golden Paths bereit, also vorab genehmigte, hochsichere, compliance-konforme Architekturen, die Entwickler mit einem einzigen Klick oder Befehl bereitstellen können.

Über manuelle Abläufe hinaus: Die Vision von Internal Developer Platforms

Um manuelle Abläufe in Azure wirklich hinter sich zu lassen, müssen wir unser Denken vom Verwalten von Infrastruktur auf das Bauen von Plattformen umstellen. Eine Internal Developer Platform ist nicht einfach ein einzelnes Tool, sondern eine zusammenhängende Schicht über Ihrer Azure-Cloud-Infrastruktur, die Dienste und Werkzeuge bündelt, um Software reibungslos auszuliefern.

Das Problem mit Ad-hoc-Skripten und Wild-West-Bereitstellung

Manche Organisationen stellen fest, dass Ticketing langsam ist, und verteilen daraufhin Mitwirkenden-Zugriff auf Azure-Abonnements, sodass Entwickler beliebige Ressourcen bereitstellen können. Das ist das andere Extrem, und es ist genauso verheerend. Schon bald haben Sie nicht verwaltete Ressourcen, explodierende Cloud-Rechnungen, massive Sicherheitslücken und keinen einheitlichen Weg, etwas zu überwachen oder zu aktualisieren. Es herrscht Wildwest.

Der optimale Punkt für eine IDP

Eine IDP schafft das perfekte Gleichgewicht. Sie bietet Self-Service-Funktionen und integriert gleichzeitig Sicherheit, Compliance, Kostenmanagement und Architekturstandards direkt in den Workflow. Entwickler erhalten die Eigenständigkeit, die sie sich wünschen, während Betriebs- und Sicherheitsteams die Governance und Compliance bekommen, die sie benötigen. Es ist ein Win-win-Szenario, das durch Automatisierung möglich wird.

Kernpfeiler einer Entwicklerplattform auf Azure

Wenn Sie Ihre Internal Developer Platform auf Microsoft Azure aufbauen, brauchen Sie eine solide architektonische Grundlage. Schauen wir uns die Kernpfeiler an, die eine Azure-basierte Plattform erfolgreich machen.

1. Infrastructure as Code (IaC) und Modulkataloge

Das Herzstück jeder Cloud-Plattform ist Infrastructure as Code. Im Azure-Ökosystem bedeutet das in der Regel Terraform, Bicep oder Azure Resource Manager (ARM)-Vorlagen. Es reicht jedoch nicht, nur Bicep-Dateien zu schreiben. Ihr Plattformteam muss einen kuratierten Katalog modularer, wiederverwendbarer und sicherer Vorlagen erstellen. Anstatt beispielsweise die Datenbankkonfiguration bei jedem Entwickler von Grund auf neu schreiben zu lassen, stellt die Plattform ein Azure-SQL-Modul bereit, das bereits Verschlüsselung auf Unternehmensniveau, eine korrekte Netzwerkintegration und vorkonfigurierte Sicherungsrichtlinien enthält. Der Entwickler gibt lediglich den Anwendungsnamen und die Stufe an.

2. Policy as Code mit Azure Policy

Governance kann nicht darauf beruhen, dass Menschen Kontrollkästchen abhaken. Sie muss automatisiert sein. Indem Sie Azure Policy und Azure Blueprints in Ihre Plattform integrieren, stellen Sie sicher, dass jede über die IDP bereitgestellte Ressource automatisch den regulatorischen Rahmenbedingungen und internen Unternehmensstandards entspricht. Versucht ein Entwickler, ein Speicherkonto ohne Verschlüsselung bei der Übertragung bereitzustellen, erkennt die Plattform dies sofort und lehnt es ab, bevor es Azure überhaupt erreicht.

3. Nahtlose CI/CD- und GitOps-Integration

Ihre IDP sollte nicht isoliert existieren. Sie muss nativ in Ihre Versionskontrolle und Bereitstellungspipelines integriert sein. Ob Sie GitHub Actions, Azure DevOps oder ArgoCD für GitOps verwenden: Die Plattform sollte die Pipeline vom Code-Commit bis zur Bereitstellung in Azure nahtlos orchestrieren. Entwickler sollten Umgebungen direkt aus ihren Pull Requests heraus starten und wieder herunterfahren können.

4. Einheitliche Observability und Überwachung

Was Sie nicht messen können, können Sie nicht steuern. Eine gute Plattform bietet Observability out of the box, indem sie Anwendungen direkt an Azure Monitor, Application Insights und Azure Log Analytics anbindet. Wenn ein Entwickler über die Plattform einen neuen Microservice bereitstellt, werden Protokollierung, Metriken und Tracing automatisch konfiguriert und verbunden, ohne dass eine manuelle Instrumentierung nötig ist.

Schnellere Lieferzeiten und weniger Reibung für Entwickler

Sprechen wir über die konkrete Wirkung dieser Architektur. Wenn Sie einen zweiwöchigen Ticketprozess durch ein Self-Service-Portal mit einer Bearbeitungszeit von zwei Minuten ersetzen, verändern sich die Kennzahlen dramatisch.

Time-to-Market und Bereitstellungshäufigkeit

Die Entwicklungsgeschwindigkeit steigt sprunghaft an. Funktionen, die früher in Staging-Umgebungen feststeckten, während sie auf manuelle Netzwerkkonfigurationen warteten, lassen sich nun sofort bereitstellen. Teams können für jeden einzelnen Pull Request kurzlebige Umgebungen erstellen, ihren Code in einer exakten Replik der Produktionsumgebung testen und sie nach dem Merge des PR wieder entfernen. Dieses Maß an Agilität ist in einer manuellen Ticketing-Welt unmöglich.

Vermeidung von Entwickler-Burnout

Die Zufriedenheit der Entwickler ist eine entscheidende Kennzahl, die zu viele Organisationen ignorieren. Ständiger Kampf mit Bürokratie, Warten auf andere Teams und die Bewältigung repetitiver Aufgaben mit geringem Mehrwert führen direkt zu Burnout und hoher Fluktuation. Indem Sie Reibungspunkte beseitigen und die lästigen Aufgaben automatisieren, schaffen Sie ein Umfeld, in dem sich Ingenieure kreativ, produktiv und wertgeschätzt fühlen. Zufriedene Entwickler schreiben bessere Software.

Bewährte Methoden für die Einführung von Platform Engineering in Ihrer Organisation

Eine Internal Developer Platform auf Azure aufzubauen klingt großartig, aber wie setzen Sie das um, ohne massive Störungen zu verursachen? Hier sind einige bewährte Methoden, die wir unseren Hörerinnen und Hörern sowie unseren Beratungskunden empfehlen.

Die Plattform als Produkt behandeln

Das ist die oberste Regel des Platform Engineering. Ihre internen Entwickler sind Ihre Kunden. Sie müssen Nutzerforschung betreiben, Feedback einholen, Dokumentation schreiben und die Plattform auf Basis ihrer Bedürfnisse laufend verbessern. Ist Ihre Plattform umständlich und schwer zu bedienen, suchen sich Entwickler Umgehungslösungen, und Ihre Initiative scheitert.

Klein anfangen mit einer Minimum Viable Platform (MVP)

Versuchen Sie nicht, am ersten Tag eine monolithische, alles umfassende Plattform zu bauen. Beginnen Sie mit einem einzelnen Anwendungsfall, der ein zentrales Problem löst. Automatisieren Sie zum Beispiel zunächst die Bereitstellung standardisierter Microservices auf Azure Kubernetes Service, inklusive integrierter Protokollierung und Datenbanken. Sobald das erfolgreich läuft und angenommen wird, erweitern Sie die Funktionen der Plattform schrittweise.

Den Schwerpunkt auf Entwicklerdokumentation und Portal-Erlebnis legen

Selbst die leistungsstärkste Backend-Automatisierung nützt nichts, wenn Entwickler nicht wissen, wie sie sie nutzen. Investieren Sie in ein Entwicklerportal. Tools wie Backstage von Spotify sind genau für diesen Zweck enorm populär geworden. Kombinieren Sie Backstage mit Azure-Integrationen, und Ihre Teams haben eine zentrale Anlaufstelle, um Dokumentation einzusehen, Servicekataloge zu durchsuchen und Self-Service-Aktionen auszulösen.

Fazit: Moderne Entwicklungsteams für die Zukunft stärken

Klassische Ticketsysteme sind Relikte einer vergangenen Zeit. Sie bremsen Innovationen aus, frustrieren technische Talente und schöpfen die eigentliche Stärke und Agilität der Cloud-Infrastruktur wie Microsoft Azure nicht aus. Wenn Sie Platform Engineering annehmen und durchdachte, sichere und automatisierte Internal Developer Platforms aufbauen, können Organisationen Engpässe beseitigen, eine absolut verlässliche Governance durchsetzen und das volle Potenzial ihrer Entwicklungsteams freisetzen.

Denken Sie daran: Das Ziel moderner Cloud-Architektur ist nicht nur, Ihre Server in das Rechenzentrum eines anderen zu verlagern. Es geht darum, Ihre Mitarbeitenden in die Lage zu versetzen, Mehrwert schneller und sicherer als je zuvor zu liefern. Vielen Dank, dass Sie diese Erweiterung des Blogbeitrags verfolgt haben. Abonnieren Sie unbedingt den Podcast, teilen Sie diesen Artikel mit Ihren Platform- und DevOps-Teams, und begleiten Sie uns beim nächsten Mal, wenn wir die neuesten Entwicklungen der Cloud-Technologie weiter erkunden!