Kundenreferenz: IDP Azure Energie in zwölf Monaten

Constantin Budin, Cloud- und Platform-Engineer bei Pexon Consulting | 8 Min. Lesezeit | 16.09.2026

Das hier ist keine Anleitung. Es ist der Bericht aus einem Mandat, in dem Pexon Consulting mit der ista SE eine IDP Azure Energie aufbaut: eine Internal Developer Platform auf Microsoft Azure für Entwicklungsteams im Self-Service. Sieben Engineers, Start im Mai 2023, das Mandat läuft. Nach zwölf Monaten waren 25 Teams produktiv onboarded, Time-to-Market neuer Features minus 20 Prozent.

ista-Produkte intern, Plattform-Naht bei uns

ista SE rechnet Heizkosten, Warmwasser und verbrauchsabhängige Nebenkosten gesetzeskonform ab. Dafür läuft eine der großen IoT-Geräteflotten Europas. Das operative Hauptgeschäft trägt ein Abrechnungssystem, das über Jahrzehnte gewachsen ist und den laufenden Betrieb hält. Parallel entstehen digitale Produkte: EcoTrend für die Verbrauchsvisualisierung, einfachSmart, MinuteView. Die brauchen kurze Iterationen, Cloud-Fläche und Observability, ohne den Abrechnungsbetrieb zu unterbrechen.

Genau das ist die Teilung. Produkt und Fachlichkeit bleiben bei ista. Billing, EcoTrend, AI, Customer Care, DSP – das sind ista-Teams. Was wir geliefert haben und weiter liefern, ist die Fläche, auf der diese Teams Umgebungen, Pipelines und Security-Defaults im Self-Service bekommen. Pexon sitzt nicht daneben mit Folien. Sieben Leute arbeiten als Teil des zentralen DevOps- und Platform-Teams.

So eine Teilung ist in Konzernen mit vielen Produktteams oft der saubere Schnitt: die Domain bleibt intern, die prüfbare Plattform kommt von Leuten, die Landing Zones, Templates und Onboarding täglich bauen. Ohne diese Teilung schreibt jedes Team seinen eigenen Weg. Mit ihr skaliert das Platform-Team nicht linear mit jedem neuen Produkt.

ista hat Cloud-First auf Azure gesetzt, Single Cloud, Landing-Zone-Muster, native Services. Tooling bewusst SaaS-First, wo der Selbstbetrieb nichts gewinnt. Weniger Operations-Wissen gebunden, schnellere Updates, eine Entwickler-Erfahrung statt fünf. Die Plattform muss Teams abdecken, die schon cloud-native arbeiten, und Teams, die klassische Lieferwege mitbringen. Beides ist der Auftrag, nicht ein Restposten.

Was IDP Azure Energie konkret hieß

Eine IDP Azure Energie in diesem Mandat ist keine Portal-Folie. Es ist ein Golden Path: CI/CD-Templates, Artifact Registry, Container-Runtime, Secret-Management, Compliance-Defaults. Neue Teams provisionieren ihre Umgebung in Minuten bis Stunden, nicht in Wochen. Security sitzt im Onboarding, nicht in der Checkliste danach.

Sieben Entscheidungen haben das Mandat getragen.

1. Azure als Single Cloud, klare Landing Zones, native Integration. Kein Multi-Cloud-Pfad parallel, weil die kognitive Last dann wieder bei den Produktteams landet.
2. SaaS-First beim Tooling, On-Premise nur wo der Betrieb es verlangt. Weniger eigene Runtime, mehr Zeit für Templates und Onboarding.
3. Terraform für die Migration zentraler Workloads von On-Premise nach Azure. Die Fläche ist Infrastructure-as-Code, nicht Klickpfad.
4. Docker und Kubernetes als Container-Runtime, Workloads je Team getrennt, Plattformdienste gemeinsam. Multi-Team-Tenancy ohne dass jedes Team einen eigenen Cluster erfinden muss.
5. GitLab CI mit vorkonfigurierten Pipeline-Templates. Build, Test, Deploy, Security-Scan laufen über denselben Golden Path. Teams können Workloads isoliert betreiben, nicht die Pipeline neu erfinden.
6. Security out-of-the-Box: gehärtete Container-Runtime, Secret-Management, Compliance-Defaults für Mess- und Eichgesetz und DSGVO. Die Plattform erzwingt den Rahmen, sie empfiehlt ihn nicht.
7. DORA-Metrics als Plattform-KPI, zentral erhoben: Deployment Frequency, Lead Time for Changes, MTTR, Change Failure Rate. Dazu Adoption, Self-Service-Quote, Time-to-First-Deploy. Der Head of Platform steuert damit Velocity, nicht nur Tickets.

# Golden Path: Team-Pipeline inkludiert das Plattform-Template.
# Security-Scan und Deploy-Gates kommen mit, nicht als Nachtrag.
include:
  - project: platform/ci-templates
    file: /golden-path.yml
    ref: v3

Plattform-Komponenten entstehen in Bash, Go, C#, JavaScript und Java, je nachdem was die Integration braucht. Observability läuft plattform-zentral über Team-Grenzen. Den konkreten Provider nennen wir hier nicht, weil er im Mandat variiert. Der Punkt ist Ownership: ein Hub, den jemand besitzt, nicht fünf Tools ohne Adresse.

Den Rahmen, den wir sonst als Platform-Engineering-Beratung schneiden, haben wir hier im ista-Tenant umgesetzt. Das hier ist das Mandat, nicht das Produktblatt.

Als 25 Teams auf der Plattform liefen

Der Sprung in diesem Mandat war nicht der erste Terraform-Apply. Der Sprung war, dass nach zwölf Monaten 25 ista-Entwicklungsteams produktiv auf der Plattform waren, darunter Billing, EcoTrend, AI, Customer Care und DSP.

Ab da gilt ein anderer Maßstab. Ein Template für zwei Pilotteams ist ein Workshop. Ein Golden Path für 25 Teams ist Betrieb. Onboarding muss wiederholbar sein. Security-Defaults müssen halten, ohne dass jedes Team neu verhandelt. DORA-Zahlen müssen über Team-Grenzen vergleichbar sein, sonst steuert niemand.

Das ist nach der ersten Adoptionswelle der normale nächste Schritt, kein Sonderfall. Die Nähte haben gehalten, weil sie schon da waren: Azure als eine Cloud, Terraform als Wiederholbarkeit, GitLab-Templates als Lieferweg, Defaults im Onboarding, DORA als gemeinsame Sprache. Was dazukam, war das schrittweise Onboarding weiterer Teams und das Coaching interner ista-Engineers. Kein Plattform-Neubau unter Zeitdruck.

Der geplante Vollausbau liegt bei rund 50 Teams, Zielkorridor Q4/2024 bis Q2/2025. Die Plattform ist darauf geschnitten, ohne dass das Platform-Team linear mitwächst. Pexon bleibt im Dienst-Modell: Features, Bug-Fixes, Onboarding, Hands-on. Interne ista-Engineers werden mitgenommen, nicht ersetzt.

Was am Ende stand

Nach den ersten zwölf Monaten war die Plattform produktiv. 25 Teams onboarded. Time-to-Market neuer Features um 20 Prozent kürzer. Self-Service-Onboarding in Minuten statt Wochen. DORA-Metrics liegen als Plattform-Standard. Der Abrechnungsbetrieb läuft weiter, die digitalen Produkte iterieren auf derselben Fläche. Das Mandat ist nicht abgeschlossen. Der Rollout Richtung rund 50 Teams läuft, Komponenten kommen weiter dazu.

Drei Dinge würde Pexon in einem vergleichbaren Mandat wieder so machen. Single Cloud, nicht Multi-Cloud als Einstieg. Templates und Defaults im Onboarding, nicht als Policy-PDF danach. DORA zentral, bevor jemand Velocity aus dem Bauch steuert.

Wer die Guardrails hinterherzieht, baut die Plattform zweimal. Einmal als Portal, einmal als Betrieb. Die zweite Runde ist die teure.

Pexon Consulting hat das Hands-on gebaut, im Kunden-Tenant, mit Azure-Leuten die selbst in Pipeline und Code stehen. 80 Mitarbeitende in Deutschland, Microsoft Partner, ISO 27001. Der technische Stand in diesem Bericht ist der, den Pexon nach zwölf Monaten im laufenden Mandat hält.

Wer selbst Dutzende Entwicklungsteams auf Azure stellen will und ahnt, dass Time-to-First-Deploy heute an Ticket-Ketten hängt: Bringen Sie den Tenant mit, eine ehrliche Team-Zahl, und ob Compliance erzwungen werden soll oder nur dokumentiert. Dann können wir sagen, ob IDP Azure Energie in dieser Form passt oder ob bei Ihnen ein anderer Schnitt sitzen muss.

Nächster Schritt

Das Mandat läuft. Wenn Sie vor einem ähnlichen Aufbau stehen, gehen wir die Naht an Ihrem Tenant und Ihrer Team-Zahl durch, nicht an dieser Story.

Multi-Tenancy und Isolation im Cluster-Betrieb

Wenn 25 heterogene Teams auf einer gemeinsamen Kubernetes-Infrastruktur arbeiten, entscheidet die Isolation über Stabilität und Compliance. Ein unbedachter Job im Abrechnungsumfeld darf weder die Performance der kundennahen Portale beeinträchtigen noch Zugriff auf fremde Datenspeicher erhalten. Bei der IDP Azure Energie wurde deshalb von Beginn an auf logische Mandantentrennung auf Namespace-Ebene gesetzt, anstatt für jede Fachabteilung separate Cluster hochzuziehen. Das reduziert operative Fixkosten und hält den Wartungsaufwand zentral.

Die Umsetzung stützt sich auf strikte Resource Quotas und Limit Ranges pro Namespace. Jedes Produktteam erhält klar definierte CPU- und Memory-Budgets für Entwicklungs- und Produktionsumgebungen. Damit wird verhindert, dass speicherintensive Berechnungen im Abrechnungskontext Nachbar-Pods verdrängen. Network Policies riegeln den Datenverkehr zwischen den Namespaces standardmäßig ab. Ein direkter Pod-zu-Pod-Verkehr über Teamgrenzen hinweg ist untersagt; Kommunikation erfolgt ausschließlich über definierte Schnittstellen und Ingress-Routen.

Für die Berechtigungssteuerung greift die Plattform auf Azure Active Directory Gruppen zurück, die über RBAC direkt an Kubernetes-Rollen gebunden sind. Entwickler erhalten Lesezugriff auf ihre Arbeitsbereiche und Logs, während schreibende Zugriffe auf Cluster-Ebene ausschließlich über standardisierte CI/CD-Pipelines erfolgen. Lokale Cluster-Admin-Rechte existieren für Produktteams nicht. Dieser Schnitt garantiert, dass Änderungen an Workloads reproduzierbar im Git verbleiben und betriebliche Audits für gesetzliche Vorgaben ohne manuelle Protokollprüfung bestehen können.

Versionierung und Rollout der Pipeline-Templates

Die Pflege zentraler CI/CD-Templates für Dutzende Entwicklungsteams birgt das Risiko von Engpässen, sobald Plattformänderungen ausgerollt werden. Wenn ein neues Security-Gate oder ein Compiler-Update unangekündigt Pipeline-Läufe blockiert, sinkt die Akzeptanz des Golden Path schlagartig. Die Plattformarchitektur setzt deshalb auf ein versioniertes Veröffentlichungsmodell für alle GitLab-CI-Komponenten, das Entwicklerteams Stabilität garantiert und dem Plattform-Team planbare Migrationskorridore eröffnet.

Templates werden über semantische Versionierung in einem dedizierten Git-Repository bereitgestellt. Teams binden Templates mit festen Versions-Tags ein und sind dadurch vor unerwarteten Änderungen im laufenden Betrieb geschützt. Das Plattform-Team stellt neue Prüfschritte, wie erweiterte Container-Scans oder geänderte Deploy-Schritte, zunächst in Minor-Releases bereit. Major-Versionen mit potenziell brechenden Änderungen durchlaufen vorab eine Erprobungsphase mit ausgewählten Serviceteams, bevor sie für die gesamte Organisation freigegeben werden.

Veraltete Template-Versionen erhalten