Interne Entwicklerplattformen auf Azure architektonisch umsetzen: Das Fundament schaffen

Von Mirko Peters · 2026-08-13

Willkommen zurück im Begleit-Blog zu unserem Podcast! Im heutigen Deep Dive greifen wir ein Thema auf, das die Architekturdiskussionen in der gesamten Tech-Branche prägt: Internal Developer Platforms, kurz IDPs. Falls Sie unsere letzte Folge gehört haben, wissen Sie, dass wir darüber gesprochen haben, wie kognitive Last die Geschwindigkeit von Entwicklerteams still und leise ausbremst. Heute gehen

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

Willkommen zurück im Begleit-Blog zu unserem Podcast! Im heutigen Deep Dive greifen wir ein Thema auf, das die Architekturdiskussionen in der gesamten Tech-Branche prägt: Internal Developer Platforms, kurz IDPs. Falls Sie unsere letzte Folge gehört haben, wissen Sie, dass wir darüber gesprochen haben, wie kognitive Last die Geschwindigkeit von Entwicklerteams still und leise ausbremst. Heute gehen wir einen Schritt weiter. Wir zeigen Ihnen, wie Sie eine robuste, skalierbare und sichere IDP nativ auf Microsoft Azure aufbauen, und nutzen dabei moderne Cloud-Paradigmen, Containerisierungsstrategien und Infrastructure-as-Code-Prinzipien.

Die moderne Engineering-Organisation in Unternehmen steht vor einem Paradox. Die Cloud gibt Entwicklern eine bisher nie dagewesene Leistungsfähigkeit, gleichzeitig begraben wir sie unter operativer Komplexität. Sie verbringen mehr Zeit mit Netzwerktopologien, Konfigurationen für Identitäts- und Zugriffsverwaltung und Deployment-Pipelines als mit dem Schreiben von Geschäftslogik. Eine Internal Developer Platform löst dieses Problem, indem sie als kuratierte Abstraktionsschicht fungiert. Sie schränkt Entwickler nicht ein, sondern stärkt sie, indem sie Golden Paths bereitstellt, die schnell und sicher in die Produktion führen. Schauen wir uns an, wie Sie dieses Fundament auf Azure architektonisch umsetzen.

Einführung in Internal Developer Platforms auf Azure

Bevor wir uns in die technischen Details der Azure-Dienste vertiefen, klären wir, was eine IDP eigentlich ist und warum Azure sich besonders gut als Basis dafür eignet. Eine IDP ist keine einzelne Software, die Sie von der Stange kaufen. Sie ist eine produktisierte Sammlung interner Werkzeuge, Dienste und Infrastruktur-Workflows, die zu einem zusammenhängenden Entwicklerportal zusammengefügt werden. Sie liegt zwischen Ihren Entwicklern und der zugrunde liegenden Cloud-Infrastruktur und übersetzt abstrakte Entwickleranforderungen in sichere, konforme und produktionsreife Cloud-Ressourcen.

Azure bietet ein umfangreiches Ökosystem an Enterprise-Grundbausteinen. Werden diese rohen Bausteine jedoch direkt an Entwickler weitergegeben, führt das häufig zu Konfigurationsabweichungen, Sicherheitslücken und verwaisten Ressourcen. Wenn Plattform-Engineers eine IDP auf Azure aufbauen, können sie diese nativen Dienste in festgelegte, standardisierte Vorlagen kapseln. So kann ein Entwickler eine vollständig konfigurierte Microservice-Umgebung mit angebundener Datenbank und Caching-Schicht anfordern, ohne über tiefgehende Kenntnisse der Azure-Netzwerktechnik oder der rollenbasierten Zugriffssteuerung (Role-Based Access Control) zu verfügen.

Die zentralen Säulen einer modernen IDP

Beim Entwurf Ihrer Plattform sollten Sie Ihre Entscheidungen auf vier zentrale Säulen stützen: Selbstbedienung, Golden Paths, Abstraktion und Leitplanken. Ohne diese Säulen droht Ihre IDP zu einem weiteren Ticketsystem oder einer ungepflegten Wiki-Seite zu werden.

Selbstbedienung ohne operativen Mehraufwand

Selbstbedienung ist das Herzstück jeder IDP. In einer klassischen Umgebung reicht ein Entwickler, der eine neue Staging-Umgebung oder eine Cosmos-DB-Instanz benötigt, ein Jira-Ticket ein, wartet auf die Prüfung durch das Plattform-Team, wartet anschließend auf die Bereitstellung durch den Betrieb und hofft, dass die Konfiguration mit der Produktion übereinstimmt. Eine IDP auf Azure automatisiert diesen gesamten Lebenszyklus. Über ein zentrales Portal können Entwickler Self-Service-Workflows anstoßen, die Ressourcen innerhalb von Minuten bereitstellen und die Durchlaufzeit für Änderungen deutlich verkürzen.

Golden Paths und Abstraktionsschichten

Golden Paths sind festgelegte, unterstützte Wege, um Aufgaben innerhalb Ihrer Organisation zu erledigen. Sie nehmen keine Flexibilität weg, sondern beseitigen Reibungsverluste. Indem die komplexe Azure-Konfiguration hinter einfachen Konfigurationsdateien abstrahiert wird, etwa einem einzigen Anwendungsmanifest, können Entwickler festlegen, was sie bereitstellen möchten, während die IDP übernimmt, wie die Bereitstellung auf Azure erfolgt.

Azure-Dienste als native Infrastruktur nutzen

Eine IDP auf Azure aufzubauen bedeutet, die richtigen Basisdienste für Rechenleistung, Speicher, Netzwerk und Identität auszuwählen. Schauen wir uns an, wie Sie Plattformanforderungen auf native Azure-Dienste abbilden.

Identitäts- und Zugriffsverwaltung mit Microsoft Entra ID

Sicherheit beginnt bei der Identität. Microsoft Entra ID (früher Azure Active Directory) bildet das Sicherheitsfundament Ihres IDP. Wenn Sie das Portal Ihrer Plattform in Entra ID integrieren, können Sie Single Sign-On (SSO) erzwingen und Entwicklergruppen bestimmten Plattformfunktionen zuordnen. Mit Azure Managed Identities können Ihre bereitgestellten Anwendungen sicher auf andere Azure-Ressourcen zugreifen, etwa Azure Key Vault oder Azure SQL, ohne Anmeldeinformationen fest in Konfigurationsdateien oder Repositories zu hinterlegen.

Daten- und Speicherabstraktionen

Anwendungen brauchen Daten, aber Plattformteams sollten nicht jedes Mal von Hand Datenbanken bereitstellen müssen, wenn ein Team ein neues Projekt startet. Sie können Azure Service Operator for Kubernetes oder Azure-Resource-Manager-Vorlagen (ARM-Vorlagen), eingebettet in Self-Service-Workflows, nutzen, um verwaltete Dienste wie Azure Database for PostgreSQL, Azure Cosmos DB oder Azure Cache for Redis bei Bedarf bereitzustellen. Der IDP stellt sicher, dass diese Datenbanken mit Verschlüsselung im Ruhezustand, passenden Firewallregeln und standardmäßig aktivierten automatischen Sicherungen bereitgestellt werden.

Containerisierung und Orchestrierungsstrategien

Container sind die Lingua franca moderner cloudnativer Anwendungen. Einheitlich festzulegen, wie Anwendungen verpackt und ausgeführt werden, ist für einen erfolgreichen IDP unverzichtbar.

Azure Kubernetes Service als Compute-Engine

Für die meisten modernen Unternehmen dient Azure Kubernetes Service (AKS) als primäre Compute-Engine des IDP. AKS bietet die Skalierbarkeit, Portabilität und Orchestrierungsfunktionen, die nötig sind, um Microservices im großen Maßstab zu betreiben. Entwickler sollten jedoch keine rohen Kubernetes-YAML-Manifeste schreiben müssen. Ihr IDP sollte die Komplexität von Ingress-Controllern, Netzwerkrichtlinien und Persistent Volume Claims hinter übergeordneten Workload-Abstraktionen verbergen.

Container-Registries und Sicherheit der Lieferkette

Azure Container Registry (ACR) lässt sich nahtlos in AKS integrieren und ist ein zentraler Baustein Ihrer Container-Strategie. Ihr IDP sollte die Pipeline vom Code-Commit bis zum Erstellen des Container-Images automatisieren. Dabei können Sie Werkzeuge wie Microsoft Defender for Containers nutzen, um Images schon vor dem Deployment auf Schwachstellen zu prüfen, bevor sie überhaupt in einen Cluster gelangen. Wenn Sie ACR in Ihre Plattform-Workflows einbinden, stellen Sie sicher, dass in Produktionsumgebungen nur vertrauenswürdige, geprüfte Images bereitgestellt werden können.

Infrastructure-as-Code-Prinzipien für Platform Engineering

Infrastructure-as-Code (IaC) ist beim Aufbau eines IDP nicht verhandelbar. Jede Infrastrukturkomponente, die Ihre Plattform verwaltet, muss definiert, versioniert und über automatisierte Pipelines bereitgestellt werden.

Die Wahl Ihrer IaC-Werkzeuge im Azure-Ökosystem

Azure unterstützt eine breite Palette an IaC-Werkzeugen. Bicep ist die domänenspezifische Sprache von Microsoft für die deklarative Bereitstellung von Azure-Ressourcen. Sie bietet eine schlankere Syntax als klassische ARM-Vorlagen und unterstützt Azure-Funktionen nativ. Alternativ ist Terraform (oder OpenTofu) in Multi-Cloud- und Enterprise-Umgebungen weit verbreitet. Welches Werkzeug Sie auch wählen, Ihr IDP sollte diese Skripte vor Entwicklern verbergen und sie im Hintergrund ausführen, sobald eine Bereitstellungsanfrage genehmigt wurde.

Zustandsverwaltung und modularer Aufbau

Damit Ihre Plattform wartbar bleibt, sollten Sie eine Bibliothek wiederverwendbarer Infrastrukturmodule aufbauen. Erstellen Sie zum Beispiel ein Standardmodul „web-api-module“, das eine App-Service- oder AKS-Bereitstellung mit zugehöriger Datenbank und Überwachungsinstanz bündelt. Speichern Sie den IaC-Status sicher in Azure-Storage-Konten mit aktivierter Blob-Versionierung. So stellt Ihr Plattform-Engineering-Team einen verlässlichen Prüfpfad aller Infrastrukturänderungen über alle Abonnements hinweg sicher.

Sicherheits-Guardrails und Compliance einbetten

Ein verbreitetes Anliegen der Führungsebene bei der Einführung von Self-Service-Plattformen ist der Verlust der Kontrolle über Sicherheit und Compliance. Ein wirksamer IDP dreht diese Logik um: Sicherheit wird früher im Prozess verankert, und Guardrails werden direkt in die Plattform-Workflows integriert.

Azure Policy als automatisierter Durchsetzungsmechanismus

Azure Policy ist Ihr bester Verbündeter beim Entwurf von Plattform-Guardrails. Statt Ressourcen manuell zu prüfen, können Sie mit Azure Policy unternehmensweite Standards automatisch durchsetzen, etwa die Erstellung von Ressourcen auf bestimmte Azure-Regionen beschränken, Verschlüsselung für alle Speicherkonten verlangen oder bestimmte Netzwerk-Tags vorschreiben. Versucht ein Entwickler, eine Ressource bereitzustellen, die diese Richtlinien verletzt, erkennt der IDP dies in der Validierungsphase und liefert sofort eine Rückmeldung.

Geheimnisverwaltung und Integration von Key Vault

Fest einprogrammierte Geheimnisse sind eine dauerhafte Sicherheitslücke. Ihre IDP sollte eine sichere Verwaltung von Geheimnissen standardmäßig erzwingen. Integrieren Sie Azure Key Vault in Ihre Bereitstellungsworkflows, sodass Anwendungsgeheimnisse, API-Schlüssel und Verbindungszeichenfolgen zur Laufzeit sicher eingebunden werden, vollständig vor den Entwicklern und vor Quellcode-Repositories verborgen.

Aufbau des Self-Service-Entwicklerportals

All diese Grundelemente – Identität, Compute, IaC und Sicherheit – müssen in einer zentralen Oberfläche zusammengeführt werden: dem Entwicklerportal. Es ist die Benutzeroberfläche Ihrer IDP.

Einsatz von Backstage für Azure-zentrierte Portale

Open-Source-Frameworks wie Spotifys Backstage haben sich als De-facto-Standard für den Aufbau von Entwicklerportalen etabliert. Backstage ermöglicht es Ihnen, einen Softwarekatalog zu erstellen, Vorlagen (bekannt als Software-Templates) zu verwalten und Plugins zu integrieren. Sie können benutzerdefinierte Backstage-Plugins entwickeln, die direkt mit Azure-APIs kommunizieren. So können Entwickler Azure-Ressourcen bereitstellen, den Zustand von Diensten einsehen und Bereitstellungspipelines verfolgen – alles über ein einziges Dashboard.

Gestaltung einer intuitiven Entwicklererfahrung

Betrachten Sie Ihre Entwickler beim Entwurf des Portals als Kunden. Die Benutzererfahrung muss reibungslos sein. Ein Entwickler sollte das Portal aufrufen, die Vorlage „Microservice mit SQL-Backend“ auswählen, ein einfaches Formular mit dem Namen seines Dienstes und dem verantwortlichen Team ausfüllen und auf „Senden“ klicken. Innerhalb weniger Minuten sollte die IDP die Azure-Infrastruktur bereitstellen, das GitHub-Repository mit Boilerplate-Code erzeugen, die CI/CD-Pipeline konfigurieren und den Dienst im internen Katalog registrieren.

Erfolgsmessung und nächste Schritte

Eine IDP ist kein Projekt mit festem Enddatum, sondern eine fortlaufende Produktreise. Sobald Ihre Plattform live ist, müssen Sie ihre Wirkung messen, um die Investition zu rechtfertigen und die Entwicklererfahrung kontinuierlich zu verbessern.

Wichtige Kennzahlen im Blick behalten

Konzentrieren Sie sich auf Kennzahlen, die Entwicklungsgeschwindigkeit und Plattformstabilität widerspiegeln. Verfolgen Sie die Zeit bis zum ersten „Hello World“ für neue Entwickler im Unternehmen, die Bereitstellungshäufigkeit, die Änderungsfehlerrate und die mittlere Wiederherstellungszeit (MTTR). Führen Sie außerdem regelmäßig Umfragen zur Zufriedenheit der Entwickler durch, um zu erfahren, wo in Ihren Plattform-Workflows noch Reibungspunkte bestehen.

Wie es weitergeht

Fangen Sie klein an. Versuchen Sie nicht, am ersten Tag eine massive Unternehmensplattform aufzubauen. Wählen Sie einen einzelnen Anwendungsfall – etwa die Standardisierung von Container-Bereitstellungen oder die Automatisierung der Datenbankbereitstellung – und entwickeln Sie darum eine minimal funktionsfähige Plattform. Sammeln Sie Feedback von Ihren frühen Anwenderteams, verbessern Sie Ihre Golden Paths schrittweise und erweitern Sie die Fähigkeiten Ihrer Plattform nach und nach im gesamten Unternehmen.

Indem Sie Ihre Internal Developer Platform nativ auf Azure aufbauen, automatisieren Sie nicht nur Bereitstellungen, sondern schaffen einen Motor für nachhaltiges Wachstum im Engineering. Vielen Dank fürs Lesen. Schauen Sie unbedingt auch in die Podcast-Folge, für eine vertiefte Audiodiskussion zu diesem Thema. Viel Erfolg beim Architektieren!