„Eine Plattform ist ein Produkt, die Entwickler-Teams sind die Kunden“

Platform Engineering mit Backstage

Im folgenden Interview berichten Marc Schnitzius und Pascal Sochacki von ihren ersten Erfahrungen mit Backstage als Platform-Engineering-Lösung.

Marco Paga: Marc, Pascal, ihr habt eine Sicht auf Platform Engineering, die ihr gerne mit uns teilen wollt.

Marc Schnitzius: In dem Projekt, in dem ich aktuell mit Pascal bin und generell in Projekten ist man oft in der folgenden Situation: Die Firma schneidet neue Domänen und startet Teams, die alle Services programmieren sollen. Da läuft viel parallel, und es gibt eine ganze Menge Tools, die theoretisch jeder beherrschen müsste, um die Services deployen zu können. Daher kommt der Gedanke, die Hemmnis, die dadurch entsteht, und die kognitive Last zu reduzieren – man muss erst viel lernen, hat eine lange Ramp-up-Phase, muss viele Tools beherrschen – und eine Plattform zu bauen, die das Ganze einfacher macht. 

MP: Das heißt, der Kunde hatte schon viel gemacht, man konnte also schon viele Tools nutzen, musste dann immer nur ein gewisses Konzert „abfeuern“, damit man wirklich einen neuen Service an den Start bringen konnte?

MS: Tatsächlich gab es einige Tools. Aber für die Software, die geschrieben werden sollte – sie wollten mehr in Richtung Microservice-Architektur gehen – kamen einige neue Tools dazu. Das war das eigentliche Problem: der Umstieg von den bekannten, vielen Tools, die ein Dev-Team auch schon relativ langsam gemacht haben, zu vielen neuen Tools, die die Dev-Teams noch langsamer gemacht haben. Keiner will langsame Teams. Deshalb kam der Gedanke, eine „Paved Road“ zu bauen, mit der die Software schnell von der Idee in die Umsetzung kommt.

Maximilian Mayer: Aber ihr habt wohl kaum gesagt: „Wir machen jetzt Backstage“, sondern es wird ein Prozess gewesen sein, oder?

MS: Auf jeden Fall. Der Prozess dauerte etwa ein dreiviertel Jahr, bis wir zu Backstage gekommen sind. Zuerst haben wir umgestellt von Jenkins auf GiLab CI, haben Kubernetes-Infrastruktur aufgebaut, in dem Fall in der IONOS-Cloud. Es war ein reguliertes Umfeld, deswegen war ein DSGVO-konformer Cloud-Anbieter wichtig. Wir haben viele Terraform-Module geschrieben und erst einmal den Prozess modelliert, wie wir was automatisieren wollten. Am Ende kam ein guter Prozess heraus, für den man aber immer noch eine Anleitung brauchte, was wo zu tun ist. Es gab immer noch eine relativ hohe Hemmschwelle in den Entwicklerteams, diese Plattform zu nutzen, denn: Was Terraform war, was Kubernetes war, wie man deployt, was man kaputt machen konnte usw., war alles nicht klar. Dann kamen wir auf den Gedanken, dass wir ein Frontend für unsere Plattform brauchten, das genau den Prozess, den wir modelliert hatten – neuen Service schnell starten, deployen, monitoren – nochmal abstrahiert und zugänglicher macht.

MP: Mit „neuen Service starten“ meinst du, dass ein Team damit anfängt, einen neuen Microservice aufzusetzen und dann unterstützt wird dadurch, dass es ein eigenes Git-Repo bekommt, ein CI-System für das Projekt, dass Kubernetes-Ressourcen erzeugt werden ...

MS: ... Security Compliance usw. Alles, was man in eine Pipeline packen kann, sollte einfach schon da sein. Dinge, die normalerweise erst später im Projekt kommen, z. B. Security Scanning, ist darin von Anfang an enthalten. Das ist der DevOps-Gedanke: schnell Feedback zu geben, wo es ein Problem gibt, und es direkt zu adressieren.

MP: Ihr habt also bei den Basics angefangen: erst einmal alles automatisiert, dargestellt, sodass man darauf aufsetzen kann. Das ist auch ein Learning: dass man erst die Basics einbeziehen muss, bevor man die weiteren Abstraktionsschichten nutzen kann, und auch gewinnbringend. Ich kann ja nicht einfach ein Plattform-Tool nutzen, wenn ich dahinter noch kleine Snowflake-Server habe, die manuell gewartet werden. 

MS: Genau. Es ist sehr wichtig, alles iterativ anzugehen. Eine Plattform ist im besten Fall ein Produkt, und die Kunden des Plattform-Teams sind die Entwickler-Teams. Ein Produkt kommt meistens nicht mit einem großen Knall daher, sondern iterativ und im besten Fall so, dass man sich immer wieder vergewissert, ob es noch dem Kundenbedürfnis entspricht. 

Als wir schon fast ein Jahr im Projekt waren, haben wir gesehen, wie die Prozesse sind, wie Leute arbeiten, wie die Teams funktionieren, worauf es ankommt, wo es scheitert, wo Bottlenecks sind. Wir haben erst mal modelliert und angefangen zu automatisieren. Am Ende haben wir dem Produkt ein Gesicht gegeben, ein UI.

MP: Und das Gesicht könnte in eurem Fall Backstage sein?

MS: Genau. Hier kam Pascal ins Spiel. 

„Eine Plattform ist im besten Fall ein Produkt, und die Kunden des Plattform-Teams sind die Entwickler-Teams.“

Backstage

Pascal Sochacki: Ich betreibe Backstage seit zwei, drei Monaten und versuche es für uns zu entwickeln, damit wir ein schönes UI für unsere Plattform haben.

Hier muss ich kurz ausholen und erklären, was überhaupt Backstage ist und woher es kommt: Seit zwei Jahren ist es in der CNCF [Cloud-Native Computing Foundation], wurde von Spotify als Open Source bereitgestellt und bei Spotify schon länger eingesetzt. Es ist ein Service-Katalog für große Firmen mit mehreren Teams, die mehrere Services entwickeln, damit ich einen Ort habe, an dem ich alle Informationen finde, die ich für mein tägliches Doing als Entwickler brauche. Es geht darum, zu erfahren, welche Services es um mich als Entwickler herum noch gibt, damit ich z. B. keinen Service schreibe, den es vielleicht schon gibt. Oder welche APIs es gibt, die ich eventuell von anderen Teams konsumieren kann. Oder wenn ich einen neuen Service starten will, der schon so konfiguriert sein soll, dass er auf der zentralen Plattform laufen kann, ohne dass ich viel durchlesen und konfigurieren muss. Es bringt auch ein großes Plug-in-System mit sich, d. h. wenn ich in meiner Plattform schon verschiedene Tools verwende, kann ich sie dort wunderschön integrieren. 

MP: Backstage bietet mir also die Transparenz, die ich brauche. Ich habe verschiedene Services, OpenAPI Specs usw. Wie kann ich das als Entwickler pflegen? Muss ich da immer auf die Oberfläche und klicke mich durch, oder wie kommen die Daten rein?

PS: Es gibt mehrere Möglichkeiten. Ich habe ein Git-Repo, und dort liegt die catalog-info.yaml. Die hat ein gewisses Schema, was genau dieses Repo darstellt. Dann kann man entweder die URL Backstage übergeben, und es checkt sie ein; oder man kann sich über Plug-ins einen „Crawler“, wie ich es nennen würde, schreiben, der über alle Git-Repos geht, die er findet. Wenn er die catalog-info.yaml findet, registriert er diese und sie ist danach in Backstage vorhanden. Es gibt also keine Hürde, weil ich niemanden bitten muss, meinen Service zu registrieren, sondern das sollte jeder selbst tun.

MP: Also sehr zugänglich. Was ich oft beim Kunden sehe, ist, dass es ein System gibt, das man pflegen könnte, aber das ist oft sehr veraltet. Daher klingt das sehr gut, dass man bei Backstage mehrere Möglichkeiten hat, es aktuell zu halten.

MM: Backstage ist glaube ich nicht das einzige Tool [dieser Art] auf dem Markt, aber es legt den Fokus sehr stark auf Platform Cataloguing. Mir fallen andere Tools ein, die so etwas Ähnliches anbieten, einige davon habe ich schon bei Kunden gesehen, aber das war immer eine ziemliche Fummelei. Wie hat Spotify mit Backstage Akzeptanz erreicht? Denn daran scheitert es meistens: Das Tool kann noch so cool sein – wenn es niemand benutzen möchte, hat man verloren. Deshalb bin ich neugierig: An welchem Punkt holt Backstage die Entwickler ab, dass es tatsächlich eine hohe Akzeptanz erreicht?

PS: Schwierige Frage, die wir für unser Projekt auch noch nicht ganz beantwortet haben. Wir sind gerade noch dabei, alle Teams in Backstage zu registrieren. Leuten zu sagen: „Hey, macht das jetzt bitte!“ ist immer schwierig. Man muss ihnen einen Benefit versprechen. Man könnte sie mit Dokumentation locken – das klingt vielleicht komisch, aber Backstage gibt einem die Möglichkeit, seine Dokumentation zu pflegen, als Code im Repo. So habe ich es geschafft, ein Team onzuboarden. 

„Ab einer gewissen Größe ist es sinnvoll, Leute an Bord zu haben, die nur das tun: das Ganze als Produkt denken.“

MM: Man muss die Leute aus ihrer Komfortzone herauslocken in eine neue Komfortzone. Wenn die Hürde dann gering ist, umso besser. 

MS: Ab einer gewissen Größe ist es sinnvoll, Leute an Bord zu haben, die nur das tun: das Ganze als Produkt denken. Das ist auf jeden Fall ein Learning für uns.

Es ist auch immer schwierig, wenn schon Software vorhanden ist und man schauen muss, ob alles zueinander passt oder ob die Services von ihrer Architektur her so verteilt sind, dass man jedes Mal ganz individuell handeln muss. Wenn es keine Schnittmenge gibt, wird es schwierig. 

MM: Was sind weitere Learnings aus dem Projekt? Dinge, die ihr beim nächsten Mal anders machen werdet?

MS: Ich bin, wie gesagt, seit etwas über einem Jahr in dem Projekt. Als ich dazu kam, lief das Ganze schon ein halbes Jahr. Zu dem Zeitpunkt waren hauptsächlich Entwickler von codecentric in dem Projekt. Das Bottleneck war immer beim Operations-Team. Daher war die Idee, dass ich mit ihnen spreche und sie enable, ihnen zeige, wie Automatisierung funktionieren kann. Es war ziemlich schnell klar, dass nicht einer eine Plattform baut und das Problem weg ist. Ein Learning war, alles ganzheitlich zu denken, nicht nur in der Domäne Operations, sondern sich zu fragen, wie sie arbeiten, was deren Wertschöpfungskette ist. So kamen wir zu der Erkenntnis, dass eine Plattform Sinn machen würde, da die Firma viele Teams zusammenstellte und anfing, viele Services zu programmieren. Spätestens da wurde klar, dass man ein Team brauchen würde, das das Ganze treibt. Es gibt ja nicht nur die Leute, die die Plattform bauen, sondern am besten je nach Größe auch ein eigenes Team oder zumindest eine Gruppe, die Enablement-Rollen in den Teams besetzen kann. Das kommt aus dem Team-Topologies-Gedanken: Steram-Aligned-Teams, Enablement-Teams und eben ein Plattform-Team.

„Man muss Backstage sehen wie normale Software, die upgegradet werden muss, wo Abhängigkeiten upgedatet werden müssen.“

MP: Wenn man es auf die Wertschöpfungskette der Teams bezieht, macht es ja auch Sinn, das so aufzusetzen. Auf der einen Seite hat man ein Team, das sich um die Plattform kümmert und Leute, die in die Teams hineingehen und fragen, was deren aktuelle Needs sind, wo es klemmt, wo es mehr Transparenz braucht. Damit man die Plattform auch als Produkt leben lässt und nicht im schlimmsten Fall „abwirft“ und abwartet, was passiert.

MS: Ein Operations-Team denkt erst mal gar nicht in Produkten. Es denkt in Infrastruktur: Wenn im Monitoring etwas rot wird, behebt man das, und dann geht es weiter. Sie denken nicht in Zyklen. 

MP: Nochmal zu Backstage: Ist es ein „Free Lunch“, d. h. wenn ich meine ganzen darunter liegenden Prozesse automatisiert habe, IaC-Tools verwende, werfe ich dann einmal Backstage ab und es läuft immer, oder wie sieht Tag 2 aus?

PS: Anders als andere Projekte bei der CNCF ist Backstage Software, die ich von Grund auf kompiliere und deploye. Ich habe selber den TypeScript-Code in der Hand und muss meine Änderungen vornehmen. Wenn ich Plug-ins hinzufüge, ist das ein npm-install und ich habe das Modul in meinem Backstage und muss es noch in meinen Code einbauen. Das heißt, man muss es sehen wie normale Software, die upgegradet werden muss, wo Abhängigkeiten upgedatet werden müssen. Deshalb ist es etwas anstrengender als andere Tools, die man normalerweise in dem Umfeld benutzt. 

MM: Vermutlich ist es deswegen auch weniger für Ops-Teams geeignet, sondern eher für Personen, die einen Softwareentwickler-Hintergrund haben.

PS: Das würde ich auch sagen. Das ist das Spannende und Schwierige an Backstage: Du kannst zu keinem Ops-Team gehen und sagen: Benutz das bitte.

MM: Eine wichtige Information. Denn wenn man so ein Tool einsetzt, das eine Plattform bietet, neigt man dazu, es den Ops-orientierten Leuten aufs Auge zu drücken. Denn da könnte der erste Fehler in der Implementierung entstehen. 

MS: Wir kennen das aus der DevOps-Bewegung: Ein Ops-Team bekommt neue Tools, und dann soll es ein DevOps-Team sein. Es ist eine Illusion zu glauben, dass es reicht, ein Operations-Team in „DevOps“ umzubenennen, dann vielleicht noch in „SAE-Team“, dann in „Plattform-Team“. Das wird nichts.

MP: Was gibt es sonst noch zu Backstage zu sagen?

MS: Wir können noch darüber sprechen, wann es überhaupt Sinn macht, sich darüber Gedanken zu machen, Backstage zu nutzen und wie man anfängt. Wenn wir ein Plattform-Team haben und jemanden, der an Backstage „schraubt“, es eigene Software ist, ist es auch immer ein Investment. Wann lohnt es sich?

Die kognitive Last von Entwicklern kann man beispielsweise mit einfachen Umfragen messen: Wie schwierig ist es, ein Test Environment aufzusetzen? Man kann die Zeit messen. So lässt sich der Bedarf offenlegen. Neben Test Environments kann man fragen, wo die Ownership liegt. Wenn sie beim Dev-Team liegt, sind diesem alle Prozesse klar? Wen muss ich informieren, wenn es außerhalb der Geschäftszeiten einen Ausfall gibt? Wie laufen Restores ab? Viele Dinge außerhalb der fachlichen Anforderungen an ein Dev-Team kann man gut messen, damit den Bedarf an dem Thema generell transparent machen und tracken, ob sich diese Metrik vielleicht mit Einführung der Plattform verringert. 

MP: Das heißt, man kann damit die Investition rechtfertigen, wenn ich das Ganze auf eine Zeitachse legen kann. Habt ihr für euch ein Template mit einigen Faktoren ausgearbeitet?

MS: Daran arbeiten wir gerade – es transparenter zu machen. Wir hätten es von Anfang an machen sollen. Man kann schnell transparent machen, wie viel schneller man geworden ist, welches Problem man gelöst hat. Eine Zahl, die höher oder niedriger ist, sagt mehr aus als ein Ticket, auch über die eigene Domäne hinaus, wo es gar kein fachliches Verständnis gibt. 

MP: Seid ihr selber transparent im Sinne von „Dogfooding“, insofern, als ihr das Platform Engineering auf der Plattform selber darstellt? Wenn ich als interessierter Entwickler wissen möchte, was ihr gerade macht, worauf ihr den Fokus legt, wo kann ich das direkt in Erfahrung bringen?

MS: Ein Plattform-Team arbeitet eigentlich nicht anders als ein Software-Team. Im besten Fall gibt es einen Scrum-Zyklus, ein Board, ein Backlog, ein Review. Genau diesen Prozess implementieren wir gerade. Dadurch, dass unser Team gewachsen ist, wird dies erst möglich.

MP: Haltet uns gern auf dem Laufenden. Vielen Dank, dass ihr euch die Zeit genommen habt, so offen mit uns darüber zu sprechen. 

Dieses Gespräch führten Marc, Pascal, Marco und Max im Rahmen unseres Podcasts SoftwerkerCast. Weitere Folgen unter https://www.codecentric.de/softwerkercast. 

Marc Schnitzius ist DevOps und Infrastructure Consultant bei codecentric in Frankfurt. 

Pascal Sochacki ist IT Consultant bei codecentric in Nürnberg. Sein aktuelles Fokusthema ist Backstage.

Maximilian Mayer arbeitet als APM Consultant für die codecentric AG. Er hat viele Erfahrungen als Linux-Admin und im DevOps-Umfeld gesammelt. Neben Automatisierung interessiert er sich für Ruby-Entwicklung. Motorräder und alte Autos zählen zu seinen Leidenschaften.

Marco Paga entwickelt Software aus Leidenschaft. Gerne arbeitet er im Team an der Lösung komplexer Probleme. In der Vergangenheit hat er dabei erfolgreich Legacy-Applikationen modernisiert, um diese auf geänderte Herausforderungen vorzubereiten. Alle Beteiligten auf diesem Weg mitzunehmen und für neue Technologien zu begeistern – das ist für ihn selbstverständlich.