Von UX-Umfragen zum Backstage-MVP zur ganzheitlichen Developer Experience bei Puzzle

In unserem letzten Blogpost «Platform Love: DevEx & Platform Engineering» haben wir gezeigt, wie Platform Engineering Verantwortlichkeiten klärt, Abhängigkeiten reduziert und Raum für Innovation schafft. Dabei geht es längst nicht nur um Entwickler:innen. Wir sprechen von einer ganzheitlichen Platform Experience, die alle internen Anwender:innen umfasst – von Devs und Infrastruktur-Expert:innen bis hin zum Management.

Doch wie wird das in der Praxis konkret? Das CNCF Platform Engineering Maturity Model betont, dass erfolgreiche Plattformen durch iterative Weiterentwicklung, klare Rollen und enge Zusammenarbeit entstehen. Wir haben diesen Ansatz mit einem «eat your own dog food» -Experiment überprüft. Unsere UX-Expert:innen nahmen gemeinsam mit den Platform-Devs die OpenShift-Plattform bei Puzzle unter die Lupe. Dabei gewannen sie überraschende Erkenntnisse.

Aufbauend auf unseren Erfahrungen zeigen wir nun, wie sich diese (Developer) Platform Experience mithilfe von Developer Portals weiter optimieren lässt. Solche Portale bündeln Discovery, Self-Service und Transparenz in einem zentralen Software-Katalog und fungieren so als wichtige Schnittstelle zu bestehenden Tools, Prozessen und Informationen. Erfahrt im folgenden Beitrag, wie wir mit diesem Ansatz bei Puzzle Komplexität reduzieren möchten und unsere IT-Landschaft nachhaltig transformieren.

DISCLAIMER: Dieser Blogpost dient nicht als abschliessende Entscheidungsgrundlage und geht bewusst nicht auf weitere, inhaltlich nicht erwähnte Alternativen wie Port, Humanitec oder die Platform Plane ein. Vielmehr beschreibt dieser unseren Weg zum Aufbau eines Developer Portals mit getätigten Überlegungen, Learnings, Integrationen, u.A.

Unsere Reise beginnt…

Developer Portals sind wahrlich keine Neuerscheinung. Sie haben sich als Antwort auf den wachsenden Bedarf an Transparenz und Self-Service Funktionalitäten in zunehmend komplexen IT-Landschaften entwickelt. Ursprünglich wurden sie aus internen Initiativen grosser Unternehmen heraus entwickelt – insbesondere im Zuge der Einführung von Microservices, Continuous Integration und DevOps –, um eine effizientere Zusammenarbeit und eine bessere Nutzung interner APIs und Tools zu ermöglichen.

In den Anfangstagen dienten oft interne Wikis oder simple Dashboards, um Informationen über Services, Verantwortlichkeiten und Dokumentationen zusammenzutragen. Mit der Zeit wuchs jedoch der Anspruch: Entwickler:innen forderten eine zentrale Anlaufstelle, die nicht nur als reines Nachschlagewerk fungiert, sondern aktiv bei der Servicebereitstellung und dem Betrieb unterstützt – von der automatisierten Bereitstellung von Infrastruktur bis zur transparenten Darstellung von Abhängigkeiten und Ownership.

Das Puzzle-Techboard wie auch die interessierten Engineers haben bereits in Vergangenheit mit diversen Lösungen in Richtung Developer Portal experimentiert. Gleichwohl kann man das Aufkommen der Platform Engineering-Initiative sowie die letztjährige KubeCon + CloudNativeCon Europe in Paris mit den Co-Located Events (Platform Engineering Day & BackstageCon) für uns als Startschuss der Reise sehen. Verschiedene Keynotes, wie bspw. diejenige von Samantha Coffman (Spotify) zu «Boosting Developer Platform Teams with Product Thinking», weckten die Begeisterung.

Unser Einführungsprozess: Von der ersten Version bis zur Integration

Welchen Weg schlagen wir nun ein? Die Entscheidung für eine bestimmte Lösung hängt, wie meist, von Faktoren wie dem vorhandenen Technologie-Stack, bestehenden Kompetenzen und individuellen Anforderungen und Bedürfnissen ab.

Aufgrund der Open Source-Strategie von Puzzle, dem breiten Expertenwissen und Interesse in Cloud Native Technologien wie fundierter Erfahrung in Node.js und React gerieten Backstage und der darauf aufbauende Red Hat Developer Hub in unseren Fokus.

Wir entschieden uns, mit einer Backstage-Instanz zu starten. Dies beruht auf mehreren Überlegungen und Erfahrungswerten. Einerseits verfügen wir über ausreichend interne Entwicklungsressourcen und dem nötigen Know-how. Andererseits ermöglicht uns die aktive Open-Source-Community, von kontinuierlichen Innovationen zu profitieren und flexibel auf sich verändernde Anforderungen oder interne Bedürfnisse zu reagieren. Weiter bildet das in Backstage erarbeitete Wissen die solide Basis. Sollten wir in Zukunft auf den Red Hat Developer Hub umsteigen, können wir nahtlos darauf aufbauen, da dieser im Kern auf Backstage basiert. Hierbei wird ein ähnlich getätigter Integrations-Ansatz wie bei Kubernetes und OpenShift verfolgt.

Die in unserem DevEx-Research identifizierten Probleme passten ebenfalls erstaunlich gut zu den Pain Points, die Backstage in seiner Entstehungsgeschichte beschreibt – etwa Fragen wie «Welches Team verantwortet diesen Service?» oder «Wo finde ich die Dokumentation?».

Los geht’s… erste Version auf unserem OpenShift-Cluster

Nach dem Entscheid für Backstage haben wir Ende August 2024 eine erste, noch minimalistische Backstage-Instanz auf unserem OpenShift-Cluster ausgerollt – noch bevor die eigentliche interne Umfrage bei den Entwickler:innen abgeschlossen wurde. Diese «leere» Version diente zu Beginn als Experimentierfeld und ermöglichte erste Tests mit der Architektur, den nötigen CI/CD-Pipelines und den grundlegenden Funktionen von Backstage.

Weiter wurde im September 2024 das interne Single Sign-on (SSO) auf Basis von Keycloak als primären Authentication-Provider angebunden. Das klappte zwar relativ reibungslos, jedoch fiel unser Start genau in die Phase, in der das neue Frontend- und Backend-Plugin-System bei Backstage stabilisiert worden ist. Auch die Dokumentation zur Anbindung externer OpenID Connect (OIDC)-Provider war noch nicht aktualisiert, sodass wir uns für zusätzliche Informationen durch diverse offene Pull Requests «hangeln» mussten.

Nichtsdestotrotz, lief kurz darauf hin eine funktionierende, SSO-fähige Backstage-Instanz, die bereit für weitere Integrationen war.

Im November 2024 kündigte die Cloud Native Computing Foundation & Linux-Foundation eine offizielle Zertifizierung zum Certified Backstage Associate an. Parallel etablierte die Linux Foundation mit dem Kurs Introduction to Backstage: Developer Portals Made Easy (LFS142) einen kostenfreien Einführungskurs. Diese Kurse resp. Zertifizierung bilden eine solide Wissensbasis zu Backstage wie Developer Portals und waren sehr wertvoll für den weiteren Ausbau unserer Instanz. Bis jetzt haben vier Members diese Zertifizierungen erhalten.

Backstage als Aggregator: Schrittweise Integration unserer Services

Ab Januar 2025 wurde mit den verschiedenen, weiteren Integrationen unserer Services begonnen:

LDAP-Anbindung

Eine der wichtigsten Funktionen von Backstage ist es, Informationen aus unterschiedlichen Quellen an einer zentralen Stelle zu bündeln. Wir haben als Erstes unsere Nutzer- und Gruppenverwaltung angebunden. Unser LDAP (auf Basis von OpenLDAP) liefert die relevanten Daten, sodass den Benutzer:innen im Backstage-Software-Katalog automatisch ihre Teams und Rollen zugeordnet werden. Da SSO- und LDAP-Usernamen identisch sind, funktioniert die Verknüpfung auch hier reibungslos. Dieser Ansatz ist ein echter Mehrwert, denn so entsteht nebenbei auch eine Art Organisations-Explorer, der allen Members Einblick in die Organisation- und Teamstrukturen gibt.

GitLab-Integration

Als Nächstes haben wir GitLab eingebunden, um unsere Projekte mitsamt Ownern und Dokumentationen sichtbarer zu machen. Aus Gründen der Security und Compliance wollten wir Backstage nicht globale Lese-Rechte auf unser gesamtes GitLab geben. Stattdessen wurde mit «puzzle-backstage» ein dedizierter Service-User erstellt. Dieser kann von den jeweiligen Teams genau dort – ob Gruppe oder innerhalb eines Repositories – hinzugefügt werden, wo sie Backstage nutzen möchten.

Bei GitLab-Projekten, die «puzzle-backstage» eine Rolle mit ausreichenden Rechten (z.B. Reporter oder höher) geben, kann Backstage dann das catalog-info.yaml entdecken und die relevanten Services in seinen Katalog übernehmen. Weitergehend wollen wir ausserdem das GitLab-Plugin nutzen, um Issues direkt in Backstage anzuzeigen.

Branding und TechDocs

Bei der Oberflächen-Anpassung von Backstage waren wir positiv überrascht: Mit minimalem Aufwand (per Custom-Material-Theme) konnten wir das Standard-Layout und Farben in ein Puzzle-Branding überführen.

Die erste Integration von GitLab-Projekten hat schnell gezeigt, dass wir unsere Puzzle-Backstage-Instanz mit eben dieser Instanz selbst dokumentieren möchten – ganz im Sinne von «eat your own dog food». So entsteht ein zentraler Ort, an dem alle Informationen zur Konfiguration, zu technischen Entscheidungen und zu Best Practices zu finden sind.

Um dies technisch zu unterstützen, haben wir die TechDocs-Funktion aktiviert, um Dokumentationen (basierend auf MkDocs) direkt in Backstage darzustellen. Momentan werden diese im Hintergrund in einem S3-Bucket abgelegt. Für den aktuellen Umfang unserer Projekte reicht das vollkommen aus – ein komplexeres Setup ist derzeit nicht notwendig.

Weitere Meilensteine und nächste Schritte

Verbesserung User Experience und interne Tech-Adoption

Wie eingehend und im Blogpost Platform Love: DevEx & Platform Engineering angesprochen, ist ein neues Tool nur so gut und effizient, wie es von den Usern benutzt und gehandhabt wird. Sprich die internen User, über ganz Puzzle hinweg, müssen kontinuierlich und über den Integrationsprozess hinweg begleitet und informiert werden, damit die Tool-Adoption erfolgreicher geschieht.

Dies schaffen wir einerseits durch unsere UX-Expert:innen, die qualitative Umfragen (bspw. über Nutzungsmuster oder Wünsche und Herausforderungen von Benutzer:innen ermitteln und validieren) durchführen. Kombiniert mit quantitativen Umfragen (bspw. mittels Backstage KPIs) lassen sich die Faktoren der User-Experience ebenfalls eruieren und verbessern. Mit internen Gefässen, wie bspw. einem Tech Kafi oder auf dem internen Newsportal, schaffen wir weitere Kommunikationsmöglichkeiten über ganz Puzzle hinweg. Backstage selbst liefert Strategien resp. Best Practices zur Tech-Adoption innerhalb einer Unternehmung, welche für uns ebenfalls eine spannende Grundlage bieten.

Community

Zum kontinuierlichen Wissensaufbau gehört nebst der internen Implementierung und Integration sowie der genannten Zertifizierung, natürlich auch die aktive Teilnahme innerhalb der Backstage Community. Sei es via Discord-Channel, als Contributor oder an Konferenzen und Meetups wie etwa der KubeCon + CloudNativeCon Europe in London vom April 2025, an welcher ebenfalls zahlreiche Members vertreten sein werden.

Dank der langjährigen Partnerschaft und Zusammenarbeit mit Red Hat sind wir ebenfalls am Puls der Zeit zum enterprise-grade Red Hat Developer Hub und dessen Weiterentwicklung.

Auch bei unseren Bestandeskund:innen und Partner:innen werden Developer Portals immer wie relevanter. Gemeinsame Meetups und Events sorgen für eine innovative Community innerhalb der Schweiz. Untenstehend am Beispiel des tim&koko Lunchbag-Events bei der Post IT, wo wir die Backstage-Reise erstmalig ausserhalb der eigenen vier Wände präsentieren durften.

Platform Engineering

Abschliessend… Für Software Engineers, DevOps- und Platform Engineers sowie IT-Führungskräfte: Wir stellen die (Developer) Platform Experience ins Zentrum unseres Platform Engineering-Ansatzes und sorgen dank Backstage, als zentrales Developer Portal, zu dessen nachhaltigen Verbesserung.