Die Digitalisierung schreitet voran, Anwendungen werden komplexer und mit ihnen die Anforderungen an Teams, die sie entwickeln und betreiben. Begriffe wie „Platform Engineering“, „Internal Developer Platform“ oder „Self-Service Infrastructure“ tauchen immer häufiger auf. Große Tech-Unternehmen zeigen, wie mächtig eine gut gebaute Plattform sein kann: Entwickler arbeiten schneller, unabhängiger und sicherer. Doch lohnt sich dieser Aufwand für jedes Unternehmen? Hier geht's zum zweiten Teil unserer Blogreihe "Wie viel Plattform passt zu mir?" Nachdem wir im dritten Teil ein Verfahren kennengelernt haben, wie man Plattform-Komponenten iterativ entwickelt und worauf es ankommt, damit man die ideale Abstraktionsgröße erreicht, möchten wir im letzten Teil einen Blick in die Zukunft wagen und betrachten, welche Möglichkeiten das Platform Engineering künftig bieten wird.

Viele Unternehmen sind noch damit beschäftigt, eine Plattform zu implementieren, die Mehrwerte für ihre Entwickler bringt. Es gibt jedoch einige Big Player, die schon länger Platform Engineering betreiben und uns einen Einblick geben, wohin sich eine Plattform entwickeln kann.
Wie in vielen anderen Bereichen wird auch im Platform Engineering Künstliche Intelligenz (KI) künftig nicht mehr wegzudenken sein. Sie kann in verschiedenen Bereichen eingesetzt werden.
Heute definieren wir häufig starre Regeln in unseren Metriken, die Warnungen oder Alarme auf Basis bestimmter Schwellenwerte oder Muster auslösen. Dies ist aufwendig und fehleranfällig, etwa durch vergessene oder falsch konfigurierte Alarme. Eine trainierte KI hätte den Vorteil, dass sie nicht pro System definiert ist, sondern global Metriken analysiert und intelligent alarmiert. Darüber hinaus ist es denkbar, dass die KI bei bestimmten Fehlerfällen Erstmaßnahmen bei einem Incident automatisch übernimmt – z. B. das Neustarten eines Systems, das Aktualisieren der Status Page oder das Bereitstellen von Logs und Traces.
Neben der Analyse von Metriken, was eher den Infrastruktur-Bereich abdeckt, kann Plattform-KI auch dazu eingesetzt werden, Code direkt auf Best Practices zu analysieren. Das betrifft stärker die Developer-Experience-Seite des Platform Engineerings. Denkbar ist ein Agent des Platform-Teams, der sowohl mit Architektur- als auch mit Coding-Best-Practices trainiert ist und kontinuierlich den Quellcode scannt, um Entwicklern Hinweise zu geben, wie sie ihren Code an die Unternehmensrichtlinien anpassen können. Grundlage für solche Funktionen sind gut dokumentierte Guidelines und Best Practices.
Ein weiterer wichtiger Bestandteil des Platform Engineerings ist die Implementierung einer Internal Developer Platform, über die Entwickler Zugriff auf Plattformressourcen erhalten. Während dieser Zugriff heute meist über Web-Frontends oder direkt per API erfolgt, werden in Zukunft KI-gestützte Chatbots hinzukommen, über die Entwickler ihre Aufgaben noch schneller erledigen können.
Mögliche Anfragen, die der Chatbot eigenständig bearbeiten könnte, wären zum Beispiel:
Die Szenarien sind vielfältig: Während zunächst eher lesende Aufgaben unterstützt werden, ist zu erwarten, dass KI künftig auch schreibende Aufgaben übernehmen wird – etwa das automatische Bereitstellen einer Testumgebung.
Ein weiterer Trend ist die zunehmende Ausrichtung von Plattformen als eigenständige Produkte. Je höher die Akzeptanz einer Plattform ist, desto stärker wirkt sie sich auf Produktivität, Mitarbeiterzufriedenheit und Talentbindung aus.
Damit das gelingt, muss eine Plattform wie ein Produkt gedacht und betrieben werden. Entsprechend müssen auch die Rollen und Tätigkeiten besetzt werden, die für ein professionelles Produktmanagement erforderlich sind.
Mit klarem Produktmanagement, Nutzerfeedback, relevanten KPIs und kontinuierlicher Verbesserung werden Plattformen professioneller und nachhaltiger entwickelt.
Gerade in der Einführung einer Internal Developer Platform stehen Akzeptanz und Produktivitätsgewinn der Entwickler im Vordergrund. Sobald dieses Ziel erreicht ist, kann der Fokus stärker auf Sicherheit und Governance gelegt werden.
So können Sicherheitsrichtlinien nahtlos in allen Plattformkomponenten umgesetzt werden. Wenn etwa CI/CD-Pipelines der Plattform verwendet werden, lassen sich Security-Checks direkt integrieren. Außerdem kann die deployte Software kontinuierlich überprüft werden, da sie über die Internal Developer Platform betrieben wird.
Die Integration von Multi-Cloud- und Hybrid-Cloud-Umgebungen gewinnt zunehmend an Bedeutung. Plattformen müssen immer häufiger heterogene Systeme und Infrastrukturen unterstützen und dennoch eine konsistente und einfache Entwicklererfahrung bieten.
Self-Service-Funktionalitäten werden dabei weiter ausgebaut, sodass Entwickler mehr Kontrolle und Flexibilität bei Infrastruktur und Deployments erhalten.
Im besten Fall ist es für den Entwickler abstrahiert, ob sein Service in AWS, Azure oder einer Private Cloud (z. B. mit OpenStack) läuft. Er kann seinen Service deployen, Logs, Traces und Metriken einsehen und hat ggf. Zugriff auf die Datenbank.
Mit steigender Automatisierung wird es immer einfacher, Infrastruktur und temporäre Umgebungen für verschiedene Stakeholder bereitzustellen. Das ist einerseits ein Produktivitätsgewinn, führt aber auf der Infrastrukturseite oft zu höheren Kosten.
Im ersten Schritt müssen daher Infrastrukturkosten den jeweiligen „Verbrauchern“ zugeordnet werden, damit die Plattform nicht als pauschaler Kostenfaktor gilt, sondern als Dienstleistung, die auch von den Produktteams „bezahlt“ wird.
Selbst wenn der Produktivitätsgewinn die höheren Kosten rechtfertigt, entsteht dadurch ein zusätzlicher Hebel, um Kosten, oder aus Marketing-Sicht: „Ressourcenverbrauch und CO₂-Emissionen“ zu optimieren.
So kann man z. B. unterschiedliche Ressourcen für verschiedene Stages bereitstellen (eine Dev-Stage benötigt keine voll replizierte Datenbank). Automatisierungen können zudem nicht genutzte Infrastruktur identifizieren und herunterfahren – etwa nachts oder am Wochenende.
Platform Engineering bietet enormes Potenzial. Die Internal Developer Platform wird der zentrale Dreh- und Angelpunkt für Produktteams sein, um ihre Services zu betreiben.
Deutlich wird auch: Eine Plattform muss schrittweise aufgebaut werden, da viele Funktionalitäten voneinander abhängen.
Man kann keine KI-Integration aufbauen, die Entwickler auf Best-Practices hinweist, wenn noch keine Best-Practices definiert sind.
Wer heute nicht in eine stabile Plattform investiert, wird später nicht die Komfortfunktionen nutzen können und verliert damit den technischen Anschluss, was sich direkt auf die Wettbewerbsfähigkeit des Unternehmens auswirkt. Dabei spielt es keine Rolle, wie groß das Unternehmen ist: Auch kleine Teams können sich eine sinnvolle Plattform aufbauen und echten Mehrwert schaffen.
Viele Unternehmen sind noch damit beschäftigt, eine Plattform zu implementieren, die Mehrwerte für ihre Entwickler bringt. Es gibt jedoch einige Big Player, die schon länger Platform Engineering betreiben und uns einen Einblick geben, wohin sich eine Plattform entwickeln kann.
Wie in vielen anderen Bereichen wird auch im Platform Engineering Künstliche Intelligenz (KI) künftig nicht mehr wegzudenken sein. Sie kann in verschiedenen Bereichen eingesetzt werden.
Heute definieren wir häufig starre Regeln in unseren Metriken, die Warnungen oder Alarme auf Basis bestimmter Schwellenwerte oder Muster auslösen. Dies ist aufwendig und fehleranfällig, etwa durch vergessene oder falsch konfigurierte Alarme. Eine trainierte KI hätte den Vorteil, dass sie nicht pro System definiert ist, sondern global Metriken analysiert und intelligent alarmiert. Darüber hinaus ist es denkbar, dass die KI bei bestimmten Fehlerfällen Erstmaßnahmen bei einem Incident automatisch übernimmt – z. B. das Neustarten eines Systems, das Aktualisieren der Status Page oder das Bereitstellen von Logs und Traces.
Neben der Analyse von Metriken, was eher den Infrastruktur-Bereich abdeckt, kann Plattform-KI auch dazu eingesetzt werden, Code direkt auf Best Practices zu analysieren. Das betrifft stärker die Developer-Experience-Seite des Platform Engineerings. Denkbar ist ein Agent des Platform-Teams, der sowohl mit Architektur- als auch mit Coding-Best-Practices trainiert ist und kontinuierlich den Quellcode scannt, um Entwicklern Hinweise zu geben, wie sie ihren Code an die Unternehmensrichtlinien anpassen können. Grundlage für solche Funktionen sind gut dokumentierte Guidelines und Best Practices.
Ein weiterer wichtiger Bestandteil des Platform Engineerings ist die Implementierung einer Internal Developer Platform, über die Entwickler Zugriff auf Plattformressourcen erhalten. Während dieser Zugriff heute meist über Web-Frontends oder direkt per API erfolgt, werden in Zukunft KI-gestützte Chatbots hinzukommen, über die Entwickler ihre Aufgaben noch schneller erledigen können.
Mögliche Anfragen, die der Chatbot eigenständig bearbeiten könnte, wären zum Beispiel:
Die Szenarien sind vielfältig: Während zunächst eher lesende Aufgaben unterstützt werden, ist zu erwarten, dass KI künftig auch schreibende Aufgaben übernehmen wird – etwa das automatische Bereitstellen einer Testumgebung.
Ein weiterer Trend ist die zunehmende Ausrichtung von Plattformen als eigenständige Produkte. Je höher die Akzeptanz einer Plattform ist, desto stärker wirkt sie sich auf Produktivität, Mitarbeiterzufriedenheit und Talentbindung aus.
Damit das gelingt, muss eine Plattform wie ein Produkt gedacht und betrieben werden. Entsprechend müssen auch die Rollen und Tätigkeiten besetzt werden, die für ein professionelles Produktmanagement erforderlich sind.
Mit klarem Produktmanagement, Nutzerfeedback, relevanten KPIs und kontinuierlicher Verbesserung werden Plattformen professioneller und nachhaltiger entwickelt.
Gerade in der Einführung einer Internal Developer Platform stehen Akzeptanz und Produktivitätsgewinn der Entwickler im Vordergrund. Sobald dieses Ziel erreicht ist, kann der Fokus stärker auf Sicherheit und Governance gelegt werden.
So können Sicherheitsrichtlinien nahtlos in allen Plattformkomponenten umgesetzt werden. Wenn etwa CI/CD-Pipelines der Plattform verwendet werden, lassen sich Security-Checks direkt integrieren. Außerdem kann die deployte Software kontinuierlich überprüft werden, da sie über die Internal Developer Platform betrieben wird.
Die Integration von Multi-Cloud- und Hybrid-Cloud-Umgebungen gewinnt zunehmend an Bedeutung. Plattformen müssen immer häufiger heterogene Systeme und Infrastrukturen unterstützen und dennoch eine konsistente und einfache Entwicklererfahrung bieten.
Self-Service-Funktionalitäten werden dabei weiter ausgebaut, sodass Entwickler mehr Kontrolle und Flexibilität bei Infrastruktur und Deployments erhalten.
Im besten Fall ist es für den Entwickler abstrahiert, ob sein Service in AWS, Azure oder einer Private Cloud (z. B. mit OpenStack) läuft. Er kann seinen Service deployen, Logs, Traces und Metriken einsehen und hat ggf. Zugriff auf die Datenbank.
Mit steigender Automatisierung wird es immer einfacher, Infrastruktur und temporäre Umgebungen für verschiedene Stakeholder bereitzustellen. Das ist einerseits ein Produktivitätsgewinn, führt aber auf der Infrastrukturseite oft zu höheren Kosten.
Im ersten Schritt müssen daher Infrastrukturkosten den jeweiligen „Verbrauchern“ zugeordnet werden, damit die Plattform nicht als pauschaler Kostenfaktor gilt, sondern als Dienstleistung, die auch von den Produktteams „bezahlt“ wird.
Selbst wenn der Produktivitätsgewinn die höheren Kosten rechtfertigt, entsteht dadurch ein zusätzlicher Hebel, um Kosten, oder aus Marketing-Sicht: „Ressourcenverbrauch und CO₂-Emissionen“ zu optimieren.
So kann man z. B. unterschiedliche Ressourcen für verschiedene Stages bereitstellen (eine Dev-Stage benötigt keine voll replizierte Datenbank). Automatisierungen können zudem nicht genutzte Infrastruktur identifizieren und herunterfahren – etwa nachts oder am Wochenende.
Platform Engineering bietet enormes Potenzial. Die Internal Developer Platform wird der zentrale Dreh- und Angelpunkt für Produktteams sein, um ihre Services zu betreiben.
Deutlich wird auch: Eine Plattform muss schrittweise aufgebaut werden, da viele Funktionalitäten voneinander abhängen.
Man kann keine KI-Integration aufbauen, die Entwickler auf Best-Practices hinweist, wenn noch keine Best-Practices definiert sind.
Wer heute nicht in eine stabile Plattform investiert, wird später nicht die Komfortfunktionen nutzen können und verliert damit den technischen Anschluss, was sich direkt auf die Wettbewerbsfähigkeit des Unternehmens auswirkt. Dabei spielt es keine Rolle, wie groß das Unternehmen ist: Auch kleine Teams können sich eine sinnvolle Plattform aufbauen und echten Mehrwert schaffen.