Transkript
Sven Johann Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Heute mit Tammo van Lessen zu Backstage. Hi Tammo. Wer bist du denn? Erzähl doch mal ein paar Worte.
Tammo van Lessen Ja, ich bin Tammo. Ich bin Principal Consultant bei INNOQ. Ich glaube, ich bin jetzt so seit zwölf Jahren bei INNOQ und habe schon alles Mögliche gemacht. Meine Schwerpunkte sind, glaube ich, Softwarearchitektur, kann man sagen. Ich habe mit SOA-Zeugs angefangen, bin jetzt bei Microservices gelandet und interessiere mich auch für die Überwachbarkeit und Betreibbarkeit von solchen Systemen.
Sven Johann Gut, genau. Und du hast dich auch mit Backstage beschäftigt, auch einen Vortrag gehalten, bei der, was war das, WJAX oder? Ja, ich hab’s wieder vergessen. Aber auch bei unserem Technology Day. Was ist überhaupt Backstage?
Tammo van Lessen Backstage ist ein Developer-Portal, kann man sagen, oder genauer gesagt ein Framework, mit dem man sich selber die Developer-Portale bauen kann. Und ich habe mir das angeguckt, weil das aus meiner Sicht Probleme löst, die wir an ganz vielen Ecken und Enden haben. Also in Kundenprojekten, aber teilweise auch bei uns selber höre ich immer so Fragen wie, wer maintained denn das Stück Software eigentlich?
Da läuft irgendwas nicht richtig. Wen muss ich jetzt anhauen, dass das wieder läuft? Wer ist zuständig? Wo liegt der Code? Wo kann ich den Bug Tracker finden, um da ein Issue reinzumachen? Mit wem muss ich darüber diskutieren, um irgendwelche Schnittstellen anpassen zu können? All solche Sachen.
Und wir diskutieren ja eigentlich immer ganz viel darüber, dass wir Softwarearchitekturen eher dezentralisieren wollen, also zerschneiden wollen und nicht mehr so monolithische Systeme haben wollen. Und in der Konsequenz bedeutet das ja aber auch, dass Dokumentation und diese ganzen Artefakte, die man um Software herum hat, breit verteilt sind. Und wie macht man die jetzt wieder zugänglich für die Allgemeinheit oder die Allgemeinheit innerhalb eines Unternehmens? Und da schien mir Backstage irgendwie Probleme zu lösen, deswegen habe ich mir das genauer angeschaut.
Sven Johann Wie muss ich mir das vorstellen? Ich stelle mir jetzt so Confluence vor, da gehe ich drauf und dann ist alles verlinkt, was ich suche.
Tammo van Lessen Vielleicht gehörst du ja zu denjenigen, die Confluence uneingeschränkt super finden. Ich höre da immer, sagen wir mal, kontroverse Meinungen zu. Aber eine Gemeinsamkeit gibt es halt. Das soll also der Go-To-Point sein. Eine zentrale Anlaufstelle, wo alle Informationen zusammenlaufen. Backstage hat so verschiedene Kernsäulen und das wichtigste davon ist der Softwarekatalog. Und genau wie der Name schon sagt, geht es darum, alle Komponenten, die man irgendwie in seinem Unternehmen baut, zu katalogisieren und zuzuordnen. Da gibt es ein Metamodell. Wenn du willst, können wir da noch ein bisschen tiefer einsteigen gleich.
Sven Johann Ja.
Tammo van Lessen Und das ist eigentlich der Einstiegspunkt. Also man kann es schon mal wie so eine Link-Sammlung betrachten. Es werden aber auch dann Bug-Tracker, Operations-Aspekte, Dokumentationen, APIs, Abhängigkeiten und sowas in diesem Katalog verwaltet und zugänglich gemacht.
Sven Johann Woher kommt Backstage überhaupt? Ist ja im Prinzip so eine Erfindung, was heißt Erfindung, aber ja, kommt von Spotify. Die haben das entwickelt.
Tammo van Lessen Genau, das ist nicht vom Himmel gefallen, sondern Spotify hat das entwickelt, um ihre eigenen Probleme zu lösen. Die sind ja auch drastisch gewachsen. Da kommen ja auch diese Ideen her mit Gilden und Tribes, also die Dinge, wie man Softwareentwicklungsorganisationen strukturieren kann. Und die waren irgendwann damit konfrontiert, dass sie genau das Problem hatten. Sehr, sehr viele Microservices, zwar auch Zuordnungen zu Teams, aber nicht die Zugänglichkeit über ein Portal und wollten die Developer Experience da erhöhen. Und haben dann eben Backstage erfunden, entwickelt, dann irgendwann open sourced und im März 2022 an die Cloud Native Computing Foundation submitted, oder wie man das nennen will, das ist jetzt da unter Inkubation und reift da vor sich hin.
Sven Johann Ja, nochmal kurz zurück zu diesem Software-Katalog. Also, wie würde ich mir das vorstellen? Also, wenn ich jetzt so an unser INNOQ-Problem denke, wir haben eine interne Anwendung, da habe ich einen Bug festgestellt und jetzt will ich den melden und jetzt würde ich zu unserem Backstage gehen und dann suche ich einfach nach dieser Software oder wie muss ich mir das vorstellen? Dann bekomme ich da alle Infos.
Tammo van Lessen Ja, genau. Also das eine ist so, wie benutze ich das? Das andere ist, wie befüllt sich der Katalog? Du gehst zu Backstage, dann gibt es erst mal so eine Übersicht, wo man direkt diesen Katalog sieht und browsen kann. Es gibt verschiedene Arten von “kinds”. Also, schon wenn man das Wort “kind” hört, fühlt man sich so ein bisschen an Kubernetes erinnert. Und das ist auch jetzt kein Zufall. Weil diese Katalog-Items werden, ich vermische das jetzt ein bisschen, die werden alle in YAML beschrieben. Sieht also ein bisschen aus wie so ein Kubernetes-Manifest.
Und genau, man kann dann diesen Katalog browsen. Es gibt aber auch eine Suchfunktion, die natürlich alles, was das System kennt, also Dokumentation, diesen Katalog, die Templates und sowas, indiziert und über die Suche zugänglich macht. Wenn du jetzt also da ein Ticket aufmachen willst, dann suchst du nach diesem System oder was du glaubst, wie das System heißt. Und der Suchindex ist dann hoffentlich schlau genug, dir das relativ schnell anzuzeigen. Dann klickst du da drauf und siehst es dann direkt: Wer ist denn der Owner? Welches Team? Und da sind dann Kontaktinformationen, idealerweise E-Mail-Adressen von dem Team oder einzelne Leute. Man kann sich dann da auch lustig so durchhangeln und sieht dann, welche Komponenten managen die denn sonst noch so und für welche Schnittstellen sie die verantwortlich. Aber genau, ist eben auch dann Link zum Bug-Tracker und dann kannst du da dein Ticket aufmachen.
Sven Johann Okay, also ich würde jetzt sozusagen, wenn ich jetzt an so eine normale Servicelandschaft denke, ich interessiere mich für, keine Ahnung, vielleicht die Suchkomponente oder für Produktdetails, gehe ich da drauf. Und dann sehe ich auch zu welcher Domäne, also da gibt es ein Team und dieses Team hat auch noch andere, entwickelt vielleicht auch noch andere Services. Also man hat so praktisch so eine Trace, also man kann sich so durchhangeln, vielleicht so eine Graph-like Structure vielleicht sogar, ja. Ah, okay.
Tammo van Lessen Richtig, genau. Das wird auch tatsächlich schön als Graph angezeigt. Wir können uns ja mal diese Catalog Entities ein bisschen genauer angucken. Das übergeordneteste Konzept ist eine Domain. Das ist, glaube ich, so das, was wir sonst allgemein auch als Domäne bezeichnen würden. Die Domäne, die kann wiederum aus verschiedenen Systemen bestehen. Und das muss man jetzt vielleicht noch dazu wissen, wenn ich das in YAML irgendwie beschreibe, also da meine Domainstruktur sozusagen, Domainmodell beschreibe, ich kann auch immer noch, auch wie bei Kubernetes, da Labels und Annotationen dranhängen.
Und das hilft mir halt, diesen Graph so aufzubauen und mit Metadaten anzureichern, die nicht unbedingt Teil dieses festen Metamodells sind. Also das heißt, auch dort kann ich noch bestimmte Aspekte, die irgendwie zu meiner Organisation passen, jeweils dazugehören. Das gilt eigentlich für alle Entities. Genau, in den Domänen verwaltet sozusagen oder in einer Domäne zugehörig sind halt verschiedene Systeme.
Und diese Systeme wiederum bestehen aus Komponenten und Ressourcen. Komponenten sind so das, was wir typischerweise als ein Stück Software bezeichnen. Das kann so ein Self-Contained System sein oder irgendwelche anderen Microservices oder von mir aus auch ein fettes System. Es kann aber auch eine Data Pipeline oder ein Batch Job sein. Und ich habe aber auch noch Ressourcen. Das kann jetzt der Server sein, auf dem das tatsächlich läuft oder EC2-Instanzen, irgendwelche Cloud-Komponenten, Datenbanken, S3 Buckets, solche Dinge.
Und zwischen denen habe ich also auch wieder Abhängigkeiten. Also das heißt, ich kann diesen Katalog eben aufbauen. Und dann so Dinge rausfinden, wie auf dem Host laufen also die fünf Services jetzt im etwas traditionellen Hosting-Modell. Oder kann rausfinden, da kann ich dann zum Beispiel wieder mir Typen oder Annotationen so was hinzuziehen, dass ich gucken kann, bei welchen Hyperscalern läuft denn was zum Beispiel. Und so kann ich mir ein relativ komplexes Metamodell oder Domain-Katalog-Modell aufbauen, da verschiedene Informationen hinterlegen und ableiten. Genau, und diese Komponenten wiederum, also die kann ich auch typisieren.
Es gibt so ein paar Standardtypen, also z.B. Datenbanken, S3 Buckets und Clusters, also das, was es bei den Ressourcen gibt. Und bei den Components sprechen wir von Services, Libraries oder Webseiten. Ich vermute, dass das irgendwie das Modell ist, was bei Spotify so klassifiziert ist. Das kann man aber eben auch erweitern.
Sven Johann Hm. Hm, hm.
Tammo van Lessen Und die Komponenten stellen jetzt typischerweise auch noch APIs zur Verfügung oder konsumieren welche. Und das vervollständigt jetzt sozusagen diesen Graph bzw. macht aus dem Baum einen Graph, weil ich eben auch noch festhalte, dass keine Ahnung, Komponente A, API A und B zur Verfügung stellt und Komponente B konsumiert dann eine davon. Und so kann ich mich eben auch langhangeln und rausfinden, wie sind dann da diese Abhängigkeitsgraphen, wer hängt von wem ab. Oder an wen muss ich mich wenden, wenn, also mir sagt einer hier, um das und das zu erreichen, musst du diese API anbinden, und dann kann ich mich von da aus durchhangeln. Wer stellt die denn zur Verfügung?, welche Qualitätseigenschaften sind damit verbunden?, das kann ich damit rein annotieren, wo finde ich die Doku?, etc.
Sven Johann Okay.
Tammo van Lessen Und da gibt es eben auch wieder die Typen. Also Standard ist OpenAPI, AsyncAPI, gRPC und GraphQL. Und da gibt es dann meistens auch schon Plugins und Support, um das dann hübsch zu visualisieren, dass man also direkt so eine Swagger-UI mit dazu bekommt, um die OpenAPI-Endpoints ausprobieren zu können, solche Dinge. Und nicht zuletzt gibt es dann eben noch Gruppen und User und diese Ownership-Beziehung von all diesen Komponenten. Und darüber wird sozusagen die Verbindung in die Organisation getragen.
Sven Johann Ja, also du … Du hast mich ja als Confluence-Fan geoutet. Bin ich vielleicht gar nicht. Also da würde ich jetzt schon mal so einen größeren Vorteil gegenüber Confluence sehen. Bei Confluence musst dir alles selbst überlegen. Über so ein größeres Unternehmen … Kriegst halt dir auch nie so wirklich konsistent hin. Hier kann man auch sagen, es gibt eine Vorgabe, das sind so Standarddinge und da kann sich jeder, wenn sich dann jeder einigermaßen dran hält, das macht auch alles so Sinn, dann haben wir eigentlich eine ganz gute Übersicht und einen Einstiegspunkt für die Software, die in unserer Organisation läuft.
Tammo van Lessen Genau, das ist die Idee. Erstens, wie du sagst, Confluence, da hast du maximal einen Baum und der ist auch nicht typisiert und kannst da Plain Text hinterlegen. Und hier gibt es eine gewisse Struktur vor, mit diesem Metamodell. Kann man erweitern, kann man wahrscheinlich auch komplett umbauen, aber ich finde, der Startpunkt ist schon mal gar nicht so schlecht. Und jetzt kommt noch ein, wie ich finde, total wichtiger Punkt, weil die Frage ist ja, wie wird dieser Katalog jetzt eigentlich befüllt? Ich habe schon gesagt YAML. Aber es ist eben nicht so, dass ich jetzt an einer Stelle hingehe und ein gigantisches YAML erstelle, wo ich das alles hinterlege.
Sondern die Idee ist, dass das dezentral in dem System hinterlegt ist. Natürlich habe ich bestimmte Sachen, die ich zentral mal anlegen muss, wie z.B. die Benutzergruppen und User, und da gibt es z.B. auch Integrationen, mit denen ich das aus einem Active Directory oder einem Okta oder einem GitLab oder aus GitHub-Gruppen einfach schon mal direkt rein synchronisieren kann.
Das heißt, dass ich das nicht alles von Hand pflegen muss. Domänen würde ich vielleicht auch möglicherweise noch von Hand pflegen, aber das Interessante ist ja eigentlich, das, was wir sonst ja auch immer predigen, ist, die Dokumentation möglichst eng beim Code zu halten. Und hier ist es eben so, dass diese YAML-Datei, in der diese Kataloginformationen hinterlegt werden, mit in die Repositories der jeweiligen Komponenten hinterlegt werden.
Sven Johann Nice.
Tammo van Lessen Und dann läuft eben so ein Crawler los, wenn ich das einmal konfiguriert habe und grast alle Repositories ab und synchronisiert das eben in diesen Kataloggraphen rein. Und das finde ich halt spannend, weil da können wir wieder was über Confluence sagen. Das Problem ist ja oft, dass es da irgendwelche Seiten gibt, die halt nie wieder angefasst worden sind, weil die Leute, die für die Pflege zuständig waren, vergessen haben, dass es diese Seite überhaupt noch gibt. Und das versucht man halt so ein bisschen bei Backstage zu mitigieren dadurch, dass die Daten, diese Informationen direkt in dem Repository liegen und man vielleicht auch an der einen oder anderen Stelle durch Automatisierung oder Definition of Done oder wie auch immer dafür sorgen kann, dass das auch direkt dann dort angepasst wird.
Sven Johann Ja. Ich habe schon ewig lang kein EAM-Tool mehr benutzt, aber so Enterprise Architecture Management Tools, wenn ich die immer benutzen sollte (in einem früheren Leben), hat es mich halt immer genervt. Ich habe hier einen Ort für unsere Software und ich muss aber gleichzeitig noch so ein paar Informationen in diesem komischen EAM-Tool da pflegen und da habe ich immer doppelt arbeiten, habe ich nie Lust drauf und dann kriege ich halt nie besonders viel Pflege und so denkt halt auch jeder, der da irgendwelche Sachen einträgt und schon ist dieses Tool halt völlig nutzlos. Also benutzt halt keiner, weil die Informationen da drin veraltet sind oder einfach schlecht gepflegt. Ich mag jetzt hier einen Haufen Unsinn erzählen, aber so ist halt meine Erfahrung damit. Und jetzt höre ich halt raus, naja, da hat scheinbar Spotify von gelernt und sagt halt, wir crawlen einfach diese Informationen von der wahren Quelle sozusagen.
Tammo van Lessen Ja, genau. Also es gibt da sicher Überschneidungen inhaltlich und thematisch. Was ich ja auch erlebe, ist bei so EAM-Themen, dass sowas eher dann vorgegeben wird. Also irgendjemand hat da ein Modell, der seiner Sicht auf die Wahrheit erstellt und ob das dann aber am Ende auch die echte Realität ist. Deswegen finde ich eigentlich diesen Ansatz ganz schön, dass man nicht so upfront moduliert, sondern das eher bottom-up hoch propagiert in Backstage und dann da eben dann ein Graph daraus wird. Und halt einfach dadurch, dass ich sage, hier ist eine Komponente und ich konsumiere die in die API, klinkt sich das halt automatisch ein, dass ich eine Verbindung zu dieser anderen Komponente habe.
Sven Johann Ja, du hast Open API, Async API und so erwähnt. Da denke ich so automatisch an TechDocs. Das ist ja auch so einer der Core-Pillars ist. Was muss ich mir darunter vorstellen? Ist das sowas wie arc42 plus Tutorials plus Open API?
Tammo van Lessen Nee, da sagen Sie nicht so richtig viel dazu. Also, erstmal APIs sind quasi First Class Citizens und über Plugins kann man die sich direkt über so einen Reiter dann visualisieren lassen. Da müssen wir auch gleich nochmal da drauf kommen, dass das halt eigentlich kein Produkt ist, sondern dass es ein Framework ist, was ich mir zusammencustomise, mit allen Vor- und Nachteilen sozusagen. Genau, TechDocs ist eigentlich relativ frei. Man kann sagen, das ist so eine Art Static Site Generator, der dir deine Doku rendert. Da spielen sie eben auch mit dezentral-zentral, also die Idee ist, die Docs as Code dezentral in deinen Repositories liegen zu lassen. Sie holen sich das aber zentral, bauen das dort und rendern das in dieses System rein, schaffen es in den Suchindex rein. Und man kann dann da auch die Templates und was weiß ich was irgendwie anpassen. Das sagt aber jetzt nichts dazu, wie du deine Dokumentation strukturierst. Aber das könnten wir vielleicht als Überleitung zu den Software-Templates nehmen, das ist auch so ein Core Pillar, es sei denn du hast noch Fragen zu TechDocs.
Sven Johann Ja, vielleicht nur der eine Punkt: Ich stelle mir das halt so vor, ich habe meinen arc42 und das würde ich einfach wie gehabt in Confluence, also in meinem Repository von meinem Service würde ich das arc42 pflegen und dann lädt praktisch Backstage das einfach.
Tammo van Lessen Ja, genau. Also eben nicht einfach, sondern du musst in dem YAML-File, was deine Katalogentität da beschreibt, noch reinschreiben. Irgendwo hier liegen die Docs. Und dann holt er sich die da und kriegt auch selber die Updates mit und baut das dann automatisch.
Sven Johann Genau, genau.
Tammo van Lessen Das kann man, glaube ich, hinterfragen, was jetzt cooler ist, ob ich jetzt selber in meiner Pipeline die Dokumentation schon baue. Das machen die jetzt halt für mich. Das hat sozusagen den Vorteil, du musst dich überhaupt gar nicht mehr darum kümmern, du schmeißt da einfach Markdown-Files rein. Und na, da gibt es noch irgendwelche Hilfen oder sowas und dann musst du dich aber nicht noch darum kümmern, dass das auch richtig gebaut wird.
Sven Johann Ich sehe halt den, also der Charme daran finde ich ist, ich denke die meisten Entwickler, wir wollen unsere Doku in Markdown im Repository haben und jetzt vielleicht nicht unbedingt in Confluence haben. Aber Confluence hat halt den Vorteil High Accessibility, würde ich mal sagen, für alle. Also jeglicher Stakeholder kann da reingucken. Und so ein bisschen hätte man das Problem gelöst. Also wir können Doku in Markdown in Git pflegen, aber auch mein Projektleiter, dem kann ich einen Link schicken und sagen, hier, guck mal. Da.
Vielleicht noch eine Frage zu den Tech-Docs. Also, ich habe jetzt meinen Service X, keine Ahnung, meine Produktdetailseite oder wie auch immer. Da kann ich das pflegen. Wie würde ich jetzt so Makro-Architektur oder so Governance-Architektur, Governance-Themen, wo würden die da landen? Governance Repository?
Tammo van Lessen Naja, also out of the box jetzt nicht, also zumindest nicht für Komponenten. Was, glaube ich, gehen würde, ist, dass ich das auf so einer System- oder Domänenebene beschreibe und dann die gleichen Mechanismen benutze, dass ich einfach TechDocs auf so eine übergeordnete Entität hänge.
Sven Johann Du hattest Search gesagt. Ich glaube, das können wir relativ schnell abfrühstücken. Also diese Backstage Search ist auch ein Core Pillar. Aber das ist im Grunde genommen nur ein Index, oder? Also da steckt, keine Ahnung, Elastic Search dahinter und da wird automatisch indiziert.
Tammo van Lessen Das ist jetzt keine besondere Magie noch dahinter, außer dass es versucht, dir möglichst gute Ergebnisse zu liefern.
Sven Johann Okay, du hattest The Golden Path und Software-Templates erwähnt. Was ist das?
Tammo van Lessen Richtig. Genau, also die Idee von den Software-Templates oder vielleicht beim Golden Path ist es eben so, dass man sagt, lasst uns nicht einfach alles neu erfinden, wir versuchen euch bestimmte Dinge einfach schon mal vorzugeben. Wenn ihr das macht, macht ihr schon mal nichts falsch. Also man kann das ja immer so ein bisschen kritisch hinterfragen, wenn es unternehmensweite Regeln gibt, irgendwie Problem X muss immer auf die Art und Weise gelöst werden, dann stellt sich heraus, Problem X ist eigentlich doch komplizierter und das passt dann am Ende gar nicht, aber man darf da nicht abweichen. Also so ist es nicht gedacht, sondern es ist eher gedacht, startet doch mal damit, dann macht man nichts falsch. Um das erreichen zu können, versuchen Sie, mit Software-Templates das Bootstrapping von neuen Projekten zu erleichtern. Das war die Brücke, die ich vorhin schlagen wollte. Wenn du z.B. sagst, wir wollen alles mit arc42 dokumentieren. Du kannst zum Beispiel ein arc-42-Template direkt in so ein Scaffolding-Template für neue Projekte mit reinbauen. Und wenn du dann ein Projekt startest, geht das so. Und das haben sie tatsächlich ganz nett gelöst. Also man kann so Templates, die benutzen Cookie Cutter. Das ist so ein Python-Teil, mit dem man relativ komplexe Templating-Aufgaben lösen kann, also mit mehreren Dateien und Verzeichnissen und Pipapo, die alle bestimmte Benamungen haben sollen.
Und haben so eine ganz hübsche UI gebaut und natürlich auch das passende YAML dazu, mit der ich so einen Wizard beschreiben kann, welche Fragen man alle ausfüllen muss, um so ein Projekt dann zu scaffolden. Und genau, so ein Beispiel wäre halt, dass du halt in deinem Softwarekatalog Templates hast für einen neuen Microservice in Go und einen in Node und einen in Java und was weiß ich, mit Spring Boot oder mit irgendwas anderem.
Und dann markieren sie einen davon als den Golden Path. Und dann kannst du da eben auswählen, brauche ich eine Datenbank, brauche ich keine Datenbank, dann wird mit zusätzlicher Code generiert oder eben nicht. Die Doku kommt dann da mit rein. Es wird auch diese Katalogsbeschreibung direkt mit rein generiert.
Das heißt, wenn ich jetzt zum Beispiel einen neuen Microservice bauen will, navigiere ich durch diesen Katalog, suche mir einen raus, klicke fünfmal, fülle das alles aus und dann läuft halt sofort die ganze Maschinerie los. Also CI/CD, also es wird, nein, erst mal vorne anfangen, es wird ein Repository angelegt, da wird dieses gerenderte Template reingelegt, es wird im Katalog registriert, die CI/CD Pipelines werden eingerichtet, laufen los. Und du hast eigentlich, je nachdem, wie weit du das treibst, direkt schon deployed das System und kannst dann anfangen, da deine Veränderungen dran zu machen, je nachdem, wie viel Dir das Scaffolding sozusagen schon vorgegeben hat.
Sven Johann Also die ganze Klempnerei, die eigentlich einen Haufen Zeit kostet. Also, wie mache ich Logging? Wie mache ich Monitoring? Wie machen wir Remote Calls? Wie machen wir Persistence-Konfigurationen? Ja, wie du sagst, Deployment, Quality Gates in Pipelines, wie auch immer. Ja, all das wird da schon gemacht. Ja, ich muss sagen, ich finde das super, super angenehm. Also, ich bin großer Freund davon. Bei einem Kunden von uns, da haben wir so eine Analyse gemacht: wo krankt es denn im Unternehmen, was so Developer Productivity angeht? Oder eigentlich allgemein Productivity. Dann gab es einen Haufen Interviews und so weiter und so weiter. Einer der großen Punkte, der dabei rauskam, war Onboarding.
Also, Onboarding ist ein Riesenproblem. Die Leute brauchen immer ewig lange, bis sie irgendwie bereit sind, mit irgendwas zu beginnen und überhaupt zu verstehen, was wichtig ist und was unwichtig ist. Und wenn du einen neuen Service schreiben willst, dann dauert es auch immer Ewigkeiten. Und da haben wir auch gesagt, die Lösung kann eigentlich nur so ein Service-Template sein. Und da habe ich noch gar nicht … Also, dass hier Spotify so was macht, das war mir damals noch gar nicht bewusst. Und als ich das gesehen habe, dahaben wir auch gedacht, das ist eigentlich genau das, was wir wollen. Also willst du irgendwie sagen, hier, klick. Also vielleicht mal so ein bisschen was ausfüllen und dann zehn Minuten später ist halt dein Dummy-Service in, vielleicht nicht unbedingt in Produktion, aber schon mal in so einer Demo-Umgebung oder Integration-Umgebung. Und fertig ist die Laube. Dann kannst du halt anfangen, über Fachlichkeit nachzudenken. Aber diese ganze Klempnerei hat sich halt erledigt.
Tammo van Lessen Genau. Also es ist wahrscheinlich nicht für alle Unternehmen, was, aber ich glaube für alle, die so eine gewisse Reife und Stabilität erreichen wollen oder eine gewisse Standardisierung anstreben, ist das, glaube ich, sehr super.
Sven Johann Ja, also ich muss auch dazu sagen, ich habe auch einen längeren Podcast mit, wie heißt er denn nochmal?
Sven Johann Richardson mit Nachname auf jeden Fall. Ich verlinke es in den Show Notes. Vorname vergessen gemacht. Ja, da haben wir übrigens diskutiert. Also ein wichtiger Punkt ist, wie hältst du diese Dinger eigentlich konsistent? Also wir machen so ein Template, weil wir glauben, das ist gut.
Also, so sollte man es tun, es ist aber nur ein Template, jeder kann es irgendwie verändern. Hat Spotify oder bei Backstage gibt es da Ideen, wie man praktisch so Veränderungen in diesen Templates zurückspielt an die Template-Bereitsteller? Also, weil Teams, die das Template nutzen, haben vielleicht auch bessere Ideen, wie man es lösen kann.
Tammo van Lessen Also habe ich nichts drüber gelesen, aber als die, die mit Gilden arbeiten, würde ich mir sofort vorstellen, dass es halt so eine Art Architektur oder Entwicklergilde gibt, die sich zusammensetzt und solche Dinge, dann versucht zu strukturieren und anzupassen.
Sven Johann Okay, gut. Also ich hätte jetzt keine Fragen mehr zu den Service Templates. Wobei, doch fällt mir gerade noch eine ein. Also weiß nicht, ob du es eben erwähnt hast, aber man kann natürlich mehrere Service-Templates haben. Also ich kann jetzt sagen, ich habe so einen normalen Service. Ich kann auch irgendwie so ein Data Processing Dingens haben. Also, es kann für unterschiedliche Problemfälle ganz unterschiedliche Templates geben.
Tammo van Lessen Genau, und du kannst die Dinge auch beschreiben und dann auch über die Suche auffindbar machen und verschiedene Ausprägungen und Vor- und Nachteile oder sowas an Dokumentationen irgendwie mit da dran packen. Also in deren Beispielen ist es auch so, dass es allein für normale Microservices verschiedene Varianten mit verschiedenen Programmiersprachen gibt, mit einem präferierten Modell.
Du kannst da also theoretisch Hunderte von Templates haben und dann ist die Kunst da die richtige herauszufinden, um mit der dann zu starten.
Sven Johann Ja, also meine Erfahrung ist oder unsere Erfahrung ist lieber nur, also mit so wenig wie möglich starten. Also wir hatten auch mal so einen Kunden, die haben, wir hatten Go, Node und Spring. Dann haben wir versucht, genau diese drei Service-Templates anzubieten und wir sind gar nicht mehr hinterher gekommen. Und dann hatte ich irgendwann mal so einen Vortrag von Netflix gesehen, die gesagt haben, wir machen eigentlich bei diesen Service-Templates immer nur Java und jetzt so langsam holen wir mal auf und Python und Go kann man so einigermaßen benutzen, aber ist halt noch nicht so pralle. Dann habe ich gedacht, okay, wenn Netflix das noch nicht mal so hinkriegt, dann bleiben wir lieber auch bei einem. Okay, ja. Gibt es sonst noch irgendwas Interessantes, weil ich vergessen habe zu fragen, zu Service Templates?
Tammo van Lessen Nee, ich glaube, also eigentlich ist das ja auch ein relativ simpler Ansatz, aber halt ein sehr mächtiges Werkzeug, weil man so unglaublich viel an Wissen da reinstecken kann und auch viele Fragestellungen einfach vorwegnehmen kann. Niemand muss sich mehr Gedanken darüber machen, ob man Maven oder Gradle nimmt, weil es einfach dann schon da ist und irgendwie das Richtige tut. Und dann muss man halt damit leben und meistens klappt das ja dann auch ganz gut.
Sven Johann Ja, genau. Ich finde ja, der Vorteil ist, dass man nicht unbedingt damit leben muss. Der Christian Deger hat das mal so schön erzählt, wie die das bei autoscout gemacht haben. Die sagen halt einfach, du hast so ein so einen Pfad, der durch den Wald führt. Und wenn du diesem Pfad folgst, also das ist ein Service-Template, wenn du diesem Pfad folgst, dann geht alles total schnell. Wenn dir der Pfad nicht passt, dann kannst du den halt anpassen. Und dann musst du halt, dann muss vielleicht durch den Wald, dann dauert halt alles viel länger. Aber wenn das für dich die richtige Entscheidung ist, dann hast du immer noch die Freiheit dazu.
Tammo van Lessen Richtig, genau. Und das würden wir auf keinen Fall wollen, dass man gezwungen wird, irgendwas Blödes zu tun. Aber vielleicht wird man unterstützt, dabei schon mal von Anfang an was Gutes zu tun.
Sven Johann Ja. Genau, das auf jeden Fall. Okay, du hattest erwähnt. Das Spotify, Spotify, das Backstage im Prinzip so ein Framework ist, was ich selbst customisieren muss. Wie würde ich loslegen?
Tammo van Lessen Richtig. Genau. Genau, das ist nämlich tatsächlich ganz spannend. Wenn man sich das erste Mal das anguckt, dann denkt man ja, okay, ich lad mir irgendwo so einen Docker-File runter und ein Docker-Image und starte dann einen Container und hab dann da direkt was laufen. Das ist dann überraschend, dass das gar nicht so ist. Sondern es gibt so ein Command Line Tool, mit dem man ein neues Backstage-Projekt startet.
Und was das aber halt eigentlich macht, ist, dass das dir ein neues React-Projekt erstellt, was eben mit diesem ganzen Backstage-Gramm schon vorkonfiguriert ist. Und das zieht sich halt so durch. In dem Moment, wo du das einmal gemacht hast, hast du halt dein eigenes Developer-Portal.
Und die haben zwei Mechanismen, wie du dann immer wieder Updates machen kannst, weil deren Sachen, das sind alles irgendwelche Plugins, die dann geupdatet werden und die sich da so reinziehen. Aber sozusagen ab dem Moment, wo du einmal dieses Projekt aufgesetzt hast, geht das in deine Verantwortung über. Also du musst jetzt nicht glauben, dass die, keine Ahnung, die ändern irgendwas und du machst ein Update und dann ist sozusagen, es liegt alles in deren Verantwortung, sondern es liegt dann in deiner.
Und das hat halt viele Vor- und Nachteile. Die Vorteile sind, du kannst es dir halt auch so zusammenbauen, wie das halt zu deinem Unternehmen passt. Also, du kannst eine bestimmte Ansicht vielleicht auch für nicht-technische Stakeholder da reinbauen. Du kannst irgendwie Integration mit irgendwelchen Umsystemen, die nur du hast, über irgendwelche Links oder Buttons an bestimmten Stellen herstellen. Du kannst ganz eigene Plugins reinbauen. Du kannst eigene Tabs und so darin unterbringen. Aber du musst es halt auch pflegen. Das muss man sich sozusagen immer vor Augen halten. Es ist nicht so dieses, ich zähle das einmal wie vielleicht ein Confluence und dann läuft das, sondern du musst eigentlich auch Entwickler dafür haben, die sich darum kümmern, die das aktuell halten.
Man muss ja daran denken, dass das auch relativ viele Permissions sozusagen kennt, weil das ja alle Repositories abcrawlen muss, plus das Active Directory oder irgendwelche Datenbanken. Wenn man sowas jetzt offen ins Netz stellt, dann will man auch jemanden haben, der sich darum kümmert, dass da, falls es irgendwelche Sicherheitslücken gibt, die dann auch schnell gepatcht werden. Also man muss schon irgendwie damit rechnen, dass man Leute hat, die sich darum kümmern. Es ist ein bisschen so ähnlich. Ich hatte das ein paar Mal, dass irgendwelche Kunden kamen und sagten, ich will dieses Qualitätszeugs da lernen. Könnt ihr da mal Workshops oder Schulungen machen? Und dann hat man so nachgefragt, wie viel seid ihr denn eigentlich?
Ein Team von sechs und dann muss man halt eigentlich ehrlich sein, dass wenn sie das dann halt wirklich durchziehen und machen, von den sechs Leuten wahrscheinlich anderthalb in Zukunft damit beschäftigt sind, diese Cluster zu pflegen und die Infrastruktur zu warten und so. Also was Ähnliches muss man hier, glaube ich, auch denken. Also ich glaube, man kann das auch in kleineren Unternehmen gut einsetzen und pflegen und in größeren Unternehmen, die Abteilungen haben, die sich um Developer Experience kümmern ist das, glaube ich, eine gute Sache.
Also, jetzt kann man natürlich sagen, seid ihr bescheuert, so was überhaupt dann vorzuschlagen und einzusetzen? Der Punkt ist, ich glaube, man will unbedingt so Developerportale haben. Und sie selber zu bauen, ist halt noch ein viel, viel größerer Aufwand. Und da bringt halt Backstage halt eigentlich so eine Art Komponentenkatalog mit, aus dem du dir halt cool dein Developerportal zusammenbauen kannst.
Sven Johann Ja, also ich glaube auch, dass man das haben will. Also wahrscheinlich, wenn wir in fünf Jahren hier sitzen und fünf Jahre Backstage Erfahrung haben, sehen wir es vielleicht ein bisschen anders. Aber der Zustand jetzt hier mit Confluence und irgendwie Mund-zu-Ohr-Propaganda, wie auch immer. Also du findest nichts, du musst ständig irgendwo nachfragen. Das ist irgendwie schon gerade bei größeren Firmen echt schwierig. Apropos größere Firma, also wir wollen das haben.
Tammo van Lessen Ja.
Sven Johann Wie führe ich das denn ein? Also weil es gibt, sagen wir bei uns standardmäßig, es gibt vielleicht schon ein Repo mit Service Templates. Es gibt einen Haufen Dokumentationen in Confluence zum Beispiel. Wie würde ich da loslegen, das so auf dem Brown Field einzuführen?
Tammo van Lessen Ja, ich glaube, die Schwierigkeit ist, erstmal einen Champion dafür zu finden, dass man das auch wirklich tun darf. Ich glaube, was es ein bisschen leichter macht, ist halt dieser etwas dezentralere Ansatz. Ich kann mir vorstellen, dass man damit viele Entwickler dafür gewinnen kann, dass das cooler ist, ihre Dokumentationen, ihre Daten bei sich zu haben. Also ich kenne das von den Docs as Code Tools, die dann irgendwie das umständlich nach Confluence wieder pushen können, damit man sozusagen da die Unternehmensvorgabe erfüllt, obwohl man den Kram da maintain, wo man ihn eigentlich gerne haben will.
Ich könnte mir vorstellen, dass man da ganz gut evangelisieren kann, dass die Leute das gut finden, das dann bei sich zu haben. Ja, genau, aber grundsätzlich wie bei allen solchen Einführungsvorhaben, die so zentral und dezentral Einschnitte erfordern, muss man auf jeden Fall irgendwie Stakeholdermanagement betreiben und wirklich Leute haben, die dafür brennen und das auch dann haben wollen und sich auch der Konsequenzen bewusst sind, dass man das auch ein bisschen maintainen muss.
Sven Johann Ja, also ich muss sagen, zu meiner Freude, auch bei vielen Kunden von uns, ist ja DevEx, also Developer Experience, ein beachtetes Thema. Also da hätte ich jetzt schon so das Gefühl, da findet man jemanden. Ich weiß halt nur nicht, wie man in größeren Firmen einführen könnte. Inkrementell geht wahrscheinlich auch, oder? Also dass ich erst mal in einer Gruppe loslege und dann…
Tammo van Lessen Natürlich, genau. Wenn man halt nur einen Service hat, dann ist das vielleicht ein bisschen übertrieben. Aber genau, wenn man so ein paar hat, also in der kleineren Gruppe ist das durchaus vorstellbar. Und ich glaube auch für so vielleicht so Enterprise-Architektur-Abteilungen, die progressiv unterwegs sind, kann das vielleicht auch eine Motivation sein, sowas einzusetzen und so einen unternehmensweiten Service-Katalog aufzumachen.
Sven Johann Peu à peu das ausrollen.
Tammo van Lessen Also ich glaube ja, dass das auch so eine Dynamik entfalten kann, wenn man irgendwann kapiert, ich muss in mein Repository nur so eine YAML-Datei legen und plötzlich tauche ich hier in diesem Katalog auf und die Leute finden mich und auch die Dokumentation wird für mich einfacher, dann kriegt man das auch hin.
Ich würde auch eher mal klein starten und dann das wachsen lassen, als jetzt da von oben par ordre du mufti zu sagen, jetzt machen wir das so. Vielleicht muss man irgendwann so ein Meet in the Middle haben, wenn man es wirklich global ausrollen will. Aber ich glaube, dass das auch nicht, also in großen Konzernen gibt es wahrscheinlich viele Backstage-Installationen und jeder hat da so seine Bubble, spricht auch nichts dagegen.
Sven Johann Habe ich irgendwas vergessen noch zu fragen, was du denkst, ist noch erwähnenswert?
Tammo van Lessen Ja, vielleicht über Plugins haben wir noch nicht geredet. Also ich habe ja vorhin schon gesagt, alles sind Plugins. Und es gibt inzwischen eine relativ große Community, die Backstage Plugins baut. Zum Beispiel auch für ADRs. Das finde ich noch ganz nett. Die kannst du sozusagen entweder dokumentieren in deinem, was heiße ich, im richtigen arc42 Kapitel.
Man kann aber auch madr oder sowas benutzen und das direkt im Repository ablegen und dann gibt es Plugins, die das dann nochmal hübsch auffinden und nochmal hübsch raus rendern. Es gibt Plugins, die die Cloudkosten berechnen und einem irgendwelche Tipps geben. Man kann selber Plugins bauen, mit denen man sich den Zustand von den Data Pipelines anzeigt, oder keine Ahnung, wie viel Lagging ich in meinem Kafka habe, oder solche Aspekte kann man dann noch ganz hübsch in sowas auch anzeigen.
Und genau, da würde ich auf jeden Fall mal mir diesen Katalog oder Marketplace angucken. Also Spotify selber bietet inzwischen auch kommerziell ganz coole und ganz gereifte Plugins an. Und damit kann man halt schöne Governance-Aufgaben machen. Also zum Beispiel gibt es eins, mit dem kann man so Unternehmensziele oder sowas festhalten, wie wir wollen irgendwie alles auf Python 3 migrieren und dann kannst du halt so Watcher loslaufen lassen, die halt durch alle Repositories gehen und gucken, ja, welche Python-Version ist das? Und dann kriegst du so ein hübsches Dashboard, wo du siehst, ah, keine Ahnung, wir haben jetzt irgendwie 68 Prozent sind jetzt schon migriert und der Rest noch nicht. Und im Vormonat war es noch so und so. Und da gibt es dann so Belohnungssysteme oder so Compliance Dashboards. Also da gibt es tatsächlich ganz coole Sachen, die man sich entweder dazu kaufen kann oder die es Open Source gibt, die man sich einfach noch so mit reinklicken jetzt nicht, aber rein installieren kann in seine Backstage Installation.
Sven Johann Das hört sich auf jeden Fall interessant an. Wenn du sagst, es gibt diesen Marketplace, fällt mir gerade noch was ein. Muss ich das selbst, muss ich das zwingend immer selbst betreiben oder bietet Spotify neben dem Marketplace auch die Saas-Lösungen an?
Tammo van Lessen Es gibt natürlich gehostete Lösungen. Ich kenne da Rowdy und ich glaube, Red Hat hat da auch was im petto. Das muss man sich halt überlegen, ob man das will. Also man gibt dem System halt ziemlich viele Informationen und Credentials. Und ja, genau, das muss jeder für sich selber abwägen, ob das jetzt eine gute Idee ist, das so zu machen oder nicht.
Sven Johann Wahrscheinlich nicht. Okay
Tammo van Lessen Vielleicht, ja. Ansonsten würde ich einfach vorschlagen, es einfach mal auszuprobieren. Es ist wirklich nur ein Kommandozeilen Enter entfernt. Und dann hat man direkt irgendwie da schon mal was laufen. Also das, was dann so out of the box erzeugt wird, da kann man schon relativ schnell und viel mit rumspielen. Da liegen halt diese YAML-Dateien dann nicht in anderen Reportstories rum, sondern in einem Beispielverzeichnis. Da kann man dann mit Copy-Paste ein bisschen experimentieren und solche Dinge ausprobieren. Also die Schnellstart- oder Out-of-the-Box-Experience ist da schon echt nett. Also das wäre meine Empfehlung. Einfach mal ausprobieren.
Sven Johann Wenn ich dann praktisch nach dem Ausprobieren sage, ja, will ich jetzt ein bisschen größer ausprobieren, so diese Betreibbarkeit von dem Ding, ist das dann, du sagst, das ist React, also dann habe ich einfach meine zwei Anwendungen, meine Elastics, also meine zwei Instanzen und da muss ich noch mein, die Search Engine, die muss ich noch zusätzlich installieren, also wie muss ich mir das betrieblich vorstellen?
Tammo van Lessen Nee, ich glaube, da fällt am Ende dann doch dein Docker-Container bei raus, den du nutzen kannst. Also in der einfachsten Ausbaustufe ist auch dann nur so eine SQLite-Datenbank drin. Das würde man dann, glaube ich, irgendwann relativ schnell auf Postgres übertragen. Und ich meine, die Suchmaschine ist irgendwie direkt schon irgendwie eingebettet. Ein bisschen aufwendiger sind diese Tech-Docs-Renderer, weil er da auch nochmal Docker-Container hochfahren will, in denen er dann die Tech-Docs baut jeweils. Genau, aber sonst ist das ist das relativ standardisiert und man kann das dann in sein Kubernetes Cluster oder wir haben es auch auf Heroku laufen, relativ einfach zur Ausführung bringen. Ja.
Sven Johann Ja super, dann bedanke ich mich auf jeden Fall für unser Gespräch und unseren Zuhörern fürs Zuhören und würde sagen bis zum nächsten Mal. Ciao, ciao.
Tammo van Lessen Ja, vielen Dank dir auch. Bis zum nächsten Mal.