Seit dem letzten Jahr hört man immer häufiger von Plattform
Engineering. Was ist das eigentlich und ist
das alter Wein in neuen Schläuchen hilft das letzten
Endes nur Beratungsfirmen zu neuem Umsatz oder bringt uns das
als Entwicklungsteam tatsächlich weiter?
In dieser Folge finden wir es raus.
Und damit herzlich willkommen zu einer Nigelnagelneuen Folge von
to do Cast, dem Developer Podcast mit dem wunderbaren
Malte Lantin und mit mir Robin Manuel Thiel.
Es ist schon die 3. Folge in diesem Jahr.
Wahnsinn. Januar hat wir haben am 1.
Januar die 1. Folge gemacht, das ist schon die
3. Folge dieses Jahres.
Krass, dass der Januar fast schon wieder rum ist.
Man ihn so verbringt, ne wenn es die ganze Zeit regnet, aber bei
dir ist ja schon Frühling, also siehst ganz entspannt aus oder
nicht? Ja, die meisten.
Nur zuhören kann das jetzt hier nicht.
Natürlich nicht sehen, aber bei mir ist schönes Wetter und ein
paar Palmen im Hintergrund. Grüße an alle, die das Video
gucken. Wir haben also ich hab mich
entschieden, dem kalten Januarwetter in München zu
entfliehen und wenn ihr das hier hört, dann bin ich gerade für
ein paar Tage auf Mallorca und wie der Malte schon festgestellt
hat, hier ist kein Schneeregen, sondern hier sind zumindest so
20 Grad und man kann echt gut draußen sitzen.
Allerdings muss man auch ein bisschen bangen, ob das Internet
hält. Das heißt hier, wenn ich jetzt
zwischendurch einfach weg sein sollte, dann muss der Malte
übernehmen, dann ist das Halt der, weil das Internet hier
ausgefallen ist. Ich bin hier in der Finca, die
hat nicht mal eine Adresse, das heißt, du kannst hier nicht mal
irgendwie ein Paket hinbestellen, wenn du Post
bestellt, hierhin bestellst, dann musst du dir unten in den
Ort ist oder elektronikladen, da kannst du dein Paket dann
abholen, das heißt, mit einer Internetleitung ist ja auch
nicht viel her, das heißt, wir haben hier so einen Router mit
einer sim Karte drin, drückt uns also die Daumen, dass das
funktioniert und ich habe auch natürlich mein reisepodcast
Setup mitgenommen. Ich hoffe aber, dass das für
euch trotzdem alles gut klingt hier heute.
Und wir das Thema Plattform Engineering mal beleuchten
können. Ihr hört also, uns hält nichts
davon ab, regelmäßig die Podcast folgen für euch aufzunehmen und
das Thema Plattform Engineering höre ich tatsächlich in Meeting
immer wieder. Just in dieser Woche war ich in
einem Termin, wo wir wieder das Thema hoch und runter diskutiert
haben, mittlerweile ist es ja auch in allen
Marktforschungsinstituten angekommen, dass das einer der
Megatrends in 2024 werden soll, was das Thema
Softwareentwicklung betrifft, wir haben es auch bei Gartner
gefunden, einer der großen Trends zum Thema.
Der Entwicklung in diesem Jahr. Von daher macht es glaube ich
Sinn, dass wir einfach mal darüber sprechen, was das
eigentlich ist. Und ich hatte es in dem Intro
schon angedeutet, vielfach ist es auch etwas, was wir schon
kennen und es setzt sich aus Komponenten zusammen, die wir
vielleicht auch schon seit Jahren im Einsatz haben und von
daher war es für mich am Anfang so, dass ich gedacht habe, warum
reden jetzt alle über Plattform Engineering, ist das nur ein
Buzzword, weil alles, was ich jetzt sehe, was sich dahinter
verbirgt, kenne ich eigentlich schon und was macht das Ganze
eigentlich so besonders und? Ich sagen ist es was neues?
Ja und nein, weil ich glaube einfach, diese Denkweise und die
Herangehensweise ist schon neu und hat sich erst über die
letzten ein 2 Jahre entwickelt. Das ist glaub ich viel, was wir
schon kennen, ne, also ganz kurze Plattform Engineering, das
wird ja auch oft irgendwie so Internal Developer Plattform
genannt und das hat ganz viele von den Dev ops Praktiken.
Es ist ja auch ganz oft so, dass irgendwie bestehende Dev Ops
Teams oder sowas in Unternehmen jetzt auf einer Plattform
Engineering Teams wird. Es hat ganz viel von Sri, also
von Side Reliability Engineering, es hat ganz ganz
viel von irgendwelchen Templates und irgendwelchen Standards die
wir ohnehin schon irgendwie in Unternehmen sehen und ich glaube
was Plattform Engineering diese Disziplin des Plattform
Engineerings jetzt tut. Ist das alles irgendwie jetzt an
einer Stelle zusammenzuführen? So fühlt es sich zumindest
irgendwie so ein bisschen an. Wie würdest du es denn
definieren, also bevor wir da jetzt schon ins Detail gehen,
lass uns doch beide mal eine kurze Definition machen, wie
würdest du denn, wenn dich jemand fragt malte, was ist
Plattform Engineering, wie würdest du antworten?
Für mich ist das eine Weiterentwicklung des ganzen dev
ops Themas. Wir haben vorher DEV Ops rein
mit Fokus auf den Entwicklungsprozess und den
Betrieb. Durch das Entwicklungsteam
selber betrachtet und jetzt kommen halt noch andere
Komponenten dazu, die wir vielleicht schon hatten.
Eine ganz wichtige Komponente ist da das Thema.
Developer Plattform mit Self Service wo ich als Developer mir
bestimmte Dienste selber konfigurieren kann, ohne dort
manuellen Aufwand zu erzeugen. Und dazu kommt halt wirklich die
Bereitstellungsplattform als Service, das heißt ich muss es
nicht mehr selber konfigurieren und damit habe ich den
Softwareentwicklungsprozess ergänzt um bestimmte Templates
und Vorlagen auf Basis der Betriebsplattform und ein
entsprechendes Portal, was es mir ermöglicht über alle diese
Schichten hinweg die Dinge im Self Service mir bereitzustellen
und zu managen und von daher kann ich, wenn ich ein neues
Projekt starte. Setup mir quasi in einem Portal
Zusammenklicken und sagen, OK ich möchte n neues Projekt
starten mit der und der Technologie und bekomme dann
irgendwie einen für mein Unternehmen vordefinierten
Goldenen Pfad bereitgestellt, auf dem ich dann meine
Entwicklung starten kann, ohne dass ich wirklich durch diese
komplexen Aufgaben gehen muss. Das ganze erstmal aufzusetzen,
die entsprechenden für mein Unternehmen geltenden Policies
zu implementieren etc. Das heißt, es spielen viele
Dinge rein, die es bisher schon gab, aber die teilweise noch
sehr fragmentiert waren, die kommen jetzt wirklich zusammen
in. Gemeinsam Plattformansatz für
den aber jetzt auch ein dediziertes Team verantwortlich
ist, diese Plattform auch bereitzustellen, weil ich
glaube, um diese Komplexität zu zu managen oder handhaben zu
können, braucht man Leute, die wirklich diesen Gesamtblick auf
alles haben und nicht wirklich diesen Fokus auf das eigene
Projekt, wie wir es vielleicht in Death Ops teilweise hatten.
Der wichtigsten Punkt dabei ist wirklich dieses Self Service.
Ne von irgendwelchen Standards und templates, also was ja was
man unter so einer Internet developer Plattform oder unter
so einem ja. So ein Plattform Engineering
Portal oder wie auch immer versteht ist dann ja wirklich,
dass es einfach. Fertige Richtlinien in der Firma
gibt wie Software gebaut, aber auch Betrieben und Gemonitort
und abgesichert und skaliert und aus welchen Komponenten sie
bestehen soll. Und das dafür ist n dezides Team
gibt nämlich dieses Plattform Engineering Team was mehr oder
weniger sowas wie Templates definiert, die aber darüber
hinausgehen, dass es einfach nur quasi Coding Templates sind,
dass man da, sondern dass man einfach eine Standardisierung
unternehmensweit findet, um auch zum Beispiel Geschwindigkeit zu
erhöhen, mit denen man in neue Projekte reingeht und fertige
Standards und Toolchains und App und man nennt das auch so gerne
so. Application Templates hat also
Generatoren, wie man es vielleicht auch der erste
Developer Welt von Yo man kennt, aber für halt mehr als nur Code,
das heißt ich möchte ein neues Projekt starten, Klick irgendwo
auf den Knopf und idealerweise fällt da raus ein fertiges
Getrippaututorial zum Beispiel auf Github gehostet.
Eine Ordnerstruktur, wie wir im Unternehmen unseren Code
strukturieren. Cictip Pipelines für unsere
Deployments vielleicht eine Lösung, wie wir Identity machen,
weil wir uns immer gegen irgendein Identity System
integrieren, Monitoring Tools, die direkt mit angebunden sind
Security, also Code Scanning, zum Beispiel direkt aktiviert
rbb oder sowas direkt drin, weil wir rollenbasiert haben.
Aber auch, wie wir zum Beispiel Cloud Komponenten haben.
Das heißt, ich kann, ich hab so n ich hab dieses Wort
Katalogisierung auch irgendwie viel gelesen, das heißt ich hab
irgendwie irgendwie nen Katalog aus Services.
Von denen ich wählen kann und sagen pass auf, ich brauch jetzt
ne Datenbank gut, bei unserem Unternehmen ist wird Postgress
in der und der Art und Weise betrieben, also dass man da
einfach Standards baut für Komponenten die wir im
Unternehmen haben und diese Standards in einer Plattform
bereitstellt, die mir dann quasi nicht nur mein eigenes Projekt
generiert, sondern auch so ein bisschen Invisibility überzeugt,
was es sonst noch für Projekte im Unternehmen gibt.
Und dazu kommen natürlich auch Themen, die vielleicht für mich
als Developer weniger sexy sind, aber die in größeren Unternehmen
dann erforderlich sind. Was?
Beispiel Ganze die ganzen Policies sind.
Es gibt vielleicht auf meinem Repository schon Policies rund
um das Thema erforderliche Pol request.
Wer sind die Reviewer, wer kann auf welche Informationen
zugreifen? Dann das Ganze wenn ich das auf
eine Cloud Plattform deploye ne welche Policies gelten
eigentlich für bestimmte Ressourcen in meiner Cloud
Plattform, wie müssen diese konfiguriert werden, in welche
Data Center Regionen kann überhaupt ein Service
bereitgestellt werden? Das sind ja alles fragen die ich
normalerweise. Reaktiv oder komplex in mir mir
aus der Dokumentation zusammensuchen müsste oder wo
ich ein Obst Team kontaktieren würde, mir so eine Plattform
bereitzustellen, die dann diese Policies vielleicht beherrschen,
aber wenn ich so einen Self Service Portal habe, was mir
wirklich Ende zu Ende von meinem Repository, in dem ich als
Developer arbeite, vielleicht sogar noch einen Schritt weiter
vorher von meiner Development Umgebung vorkonfigurierten
Development Umgebung mit allen dependencies die ich brauche
über das Repository hinweg bis wirklich zu der Plattform wo
die. Anwendung betrieben wird alles
schon bereitgestellt wird, muss ich mir, und das ist das Schöne,
über diese ganzen Richtlinien und Policies, die in meinem
Unternehmen gelten, eigentlich gar keine Gedanken mehr machen,
weil sie im Hintergrund schon für mich bereitgestellt wurden,
und ich bewege mich dann quasi in einem.
Ja, kontrollierten, sicheren Pfad, wo ich weiß, wenn ich da
meine Software entwickle auf dieser Plattform, dann erfülle
ich alle Anforderungen, bis hinzu dem Thema Security, weil
vielleicht schon bestimmte Code Scanning Pipelines in Place sind
ein. Durch das Template
bereitgestellt und das finde ich persönlich etwas, was
Development Teams auch viel Last abnimmt, weil ich glaube, die
Last auf den Development Teams ist in den letzten Jahren immer
mehr gestiegen. Ich glaube das Thema.
Ja, und das Thema Dev Ops oder Death Sacops ist ja in den
letzten Jahren in die Richtung gegangen, dass wir als
Development Team immer mehr Aufgaben bekommen haben.
Früher war es irgendwie so, der ich als Developer war für meinen
Code verantwortlich, ich hab in meiner Entwicklungsumgebung
gearbeitet, hab dann noch mit irgendwie mit ein 2 Kollegen
Schnittstellen gehabt und heutzutage habe ich nicht nur
komplexere Applikationen die aus unterschiedlichen Komponenten
bestehen, sondern ich bin plötzlich auch noch für den
Betrieb oder die Absicherung des Betriebs meiner Services
irgendwie verantwortlich, weil in Dev Ops ein Team nicht nur
für die Entwicklung, sondern auch für den Betrieb ihrer
Komponenten verantwortlich ist. Und damit ist natürlich die
Komplexität größer geworden, wir haben halt auch mit dem Ganzen,
das haben wir schon mal diskutiert, mit dem ganzen Shift
Left Ansatz das ganze Thema Security.
In den auch Anforderungsbereich oder in den
Verantwortungsbereich der Development Teams Reingeschoben.
Und das sind alles positive Dinge, weil damit können wir die
Qualität unserer Software erhöhen.
Es wird alles integrierter und wir haben weniger Probleme im
Nachgang, aber es sind einfach viel mehr Themen geworden und da
jetzt wieder ein bisschen dieser Komplexität rauszunehmen, indem
man das Ganze in einer gemeinsamen Plattform
zusammenfasst und soweit es denn geht automatisiert ist, glaube
ich etwas, was für uns die in Entwicklungsteams sind.
Eine starke Erleichterung, weil wir viele Dinge dann einfach gar
nicht mehr selber managen oder berücksichtigen müssen, weil es
für uns schon vorkonfiguriert wird.
Genau das ist ganz wichtig. Es geht nicht darum, irgendwie
die Entwickler jetzt zu gängeln und irgendwelche Standards
durchzusetzen, sondern vielmehr, dass halt nicht jedes Team das
Rad neu erfinden muss und dass man sich in dieser wahnsinnig
komplexen Welt einfach auch weniger Gedanken machen muss,
weil man eben Standards über das Unternehmen hinweg über mehrere
Development Teams hinweg sich einmal clever überlegt hat,
idealerweise natürlich beim Überlegen Standards unter
einbinden. Eben dieser Teams, aber dann
eben auch diese Standardisierung so erreicht, dass, und das finde
ich eigentlich ganz spannend, dass du auch.
Talente und Developer zwischen Teams natürlich auch mal oder
zwischen Projekten auch mal hin und herschieben können, weil du
weißt, das wird auf der anderen Seite beim Unternehmen jetzt
genauso gemacht wie bei mir im im im eigenen Projekt.
Und. Ne, da merkt man schon diese
ganzen Sachen, die wir Grad genannt haben.
Das ist ja keine wirklich neue Idee ne, sondern das das ne über
diese Plattform gebaut. Ich hatte mir mal hier auf
aufgeschrieben n Begriff der mir immer wieder untergekommen ist
den ich spannend fand Engineering Culture also es wird
eher eigentlich so ne Unternehmenswerte Kultur
geschaffen wie entwickeln wir Lösungen und ganz ich versuche
ganz ganz deutlich auch das Wort Coden zu vermeiden weil es um so
viel mehr geht das ganze Tooling drumherum, wir hatten es ja eben
alles genannt. Und ihr merkt schon, wenn wir
darüber erzählen, dass das ein Thema ist, was eigentlich eher
in einem Enterprise Umfeld relevant ist.
Also das ist ein Thema, was mir auch in Kundengesprächen
eigentlich immer nur unterkommt, wenn man wirklich von großen
Unternehmen spricht, die viele verschiedene developer Teams
haben, die vielleicht auch historisch gewachsen sind, weil
sie über Merger und Acquisition neue Firma übernommen haben,
dann wird irgendwie eine Firma aufgekauft, die bringen ihre
eigene Development Teams mit, die haben ganz anders Software
gebaut als die Firma bisher das getan hat oder ich hab noch
irgendwelche legiscy Projekte, die in meinem.
Rechenzentrum on Prem laufen, die ich jetzt irgendwie in die
Cloud migrieren möchte und dafür möchte ich vielleicht Standards
nutzen. Also ich hab selten Gespräche
über das Thema mit entweder Start UPS oder kleineren
Unternehmen oder mit Unternehmen, die ohnehin schon
so ein bisschen so Cloud Native groß geworden sind, sondern sich
ja ohnehin schon so fertige Komponenten für überlegt haben,
sondern das Thema ist halt eigentlich wirklich relevant,
wenn ich verschiedene Teams habe, wenn ich große Unternehmen
habe und es mir natürlich auch leisten kann, ein eigenes Team
dafür abzustellen, was diese Plattform.
Dann halt irgendwie managed, wo diese Regeln und Richtlinien.
Und Repositories und so weiter. Überhaupt dann zur Verfügung
stehen. Genau die Frage ist auch, wie
lange. Leben, Projekte und wie oft
werden neue Projekte gestartet? Ich mein, wenn du jetzt sagst,
ich arbeite in einem relativ stabilen Umfeld und dort
arbeiten wir auf Soundsoviel Repositories mit einer festen
Plattform, in der unser Service läuft, entwickeln wir regelmäßig
weiter, dann braucht man so etwas vielleicht gar nicht, aber
wenn tatsächlich in einem großen Unternehmen quasi tagtäglich
neue Projekte gestartet werden und immer und immer wieder die
gleichen Diskussionen starten, welchen Technologiestack nehmen
wir dann das ganze vielleicht noch in einem Teil manuellen
Prozess aufgesetzt werden muss oder vielleicht komplett manuell
da verliert? Natürlich so viel.
Developer Zeit oder Engineering? Zeit, weil man immer und immer
wieder die gleichen Fragen beantwortet und die gleichen
Prozesse durchläuft, dass sich natürlich so ein separates Team
für eine solche Plattform mit der ganzen Automatisierung, die
man im Hintergrund natürlich erstmal bauen und realisieren
muss, dann relativ schnell auszahlt, weil man da so viel
mehr Effizienz reinbringt. Und wenn du jetzt ein neues
Projekt starten willst und dann wirklich die Möglichkeit hast,
innerhalb von wenigen Minuten bis Stunden die komplette
Plattform bereitgestellt zu bekommen, dass du quasi deinen
ersten Code in den laufenden Betrieb deployen kannst, ohne
die Gedanken um das ganze Thema interne Compliance machen zu
müssen. Da hast du glaube ich, so viel
gewonnen, weil da einfach einfach so viel Zeit gespart
wird. Also ich glaube, wie du sagst,
das ist etwas, was ab einer bestimmten Unternehmensgröße
relevant wird und ich merke das jetzt in den Gesprächen mit den
Kunden, mit denen ich beruflich zu tun habe, dass bei immer mehr
dieser Unternehmen jetzt. Der der Denkprozesseinsetze sie
merken, ich brauch sowas, weil sie halt an einen Punkt gekommen
sind, wo einfach die Welt so komplex geworden ist und der
Wildwuchs so groß geworden ist, dass sie sagen, OK, wir müssen
klare leicht. Planken schaffen und wir müssen
es den Leuten leicht machen, diese Dinge zu befolgen, weil
was natürlich nicht funktioniert, ist, dass man
irgendwelche Dokumente, interne Checklisten aufsetzt und die
dann irgendwo ablegt und dann sagt, Liebe Development Team
Teams, Liebe Operation Teams, haltet euch bitte jetzt an
folgende Vorgaben was halt die Services betrifft und die
Richtlinien Policies und dann ist alles gut, da kann man sich
vielleicht irgendwie als Governance Team schlafen legen
und sagen ich habe meinen Job erledigt aber am Ende hilft das
Glaube ich niemanden und deswegen muss man das glaube
ich. In so eine technische Plattform
Gießen, um es tatsächlich auch allen möglich zu machen, diesen
Dingen zu folgen und damit halt diese Komplexität wieder so ein
bisschen einzugrenzen. Da geht ja auch schnell dann
sonst das Fingerpointing los. So haben wir also auch bei so
kleineren Projekten halt angefangen, dass wir dann
irgendwelche gesagt hast, Policies in irgendeinem Mark
Downfall gegossen haben und sobald dann irgendwie was
aufgehört, heißt es direkt ja wie hast du das einfach nicht
gelesen oder hast du deinen Rechner eben nicht entsprechend
aufgesetzt und bei so einer fertigen Development?
Die ganze Zeit im Kopf kann man das, so fand ich, eigentlich n
ganz schönen Gedanken, wieso früher in Visual Studio oder
sowas, wo du einfach so File New Project klickst.
Den Gedanken hatte ich eigentlich bei Plattform A
Engineering, dass du wie früher File New Project setzt, dir dein
komplettes Projekt irgendwie auf, vielleicht schon mit ein
bisschen beispielcode, vielleicht schon irgendwie mit
ner gewissen Ordnerstruktur, vielleicht auch schon mit einem
Git repository, nur bei einer internen Developer Plattform
noch mit viel viel viel mehr mit ner ganzen Toolchain drumherum,
mit cicity Prozessen, mit Security, mit Code Scanning, mit
Observability. Mit Identity mit den richtigen
Cloud Komponenten. Da spielt auch ganz viel
Infrastructure es Code eine Rolle, dass ich was direkt
irgendwie in Infrastructure es Code haben wir auch mal eine
eigene Folge zu gemacht beschreibe und dann einfach
fertig in meinem Repository liegen habe zusammen mit
Dokumentationen die vielleicht schon fertig ist oder wo ich
zumindest schon mal einen Ort habe wo ich die ablegen kann und
das standardisiert über alle Entwicklerteams alle Prozesse
hinweg, das ist eigentlich. Plattform Engineering.
Mhm und das Tolle ist, dass ja mittlerweile wirklich viele
Unternehmen da rein investiert haben und einige dieser
Unternehmen wirklich ihre Learnings auch in
Softwareprojekte gegossen haben, die sie als Open Source
bereitstellen. Das heißt, ich muss, wenn ich so
ein Plattform Engineering Ansatz verfolge, jetzt wirklich nicht
mehr bei 0 anfangen, ich sehe es bei vielen großen Konzernen,
dass sie sagen okay, wir haben so einen irgendwie speziellen
individuellen. Use Case Setup dass wir das
alles selber bauen, die haben vielleicht die Ressourcen, aber
viele andere, für die sind solche Open Source Projekte und
ich glaube das populärste für so eine Developer Plattform ist
Backstage von Spotify. Welches als Open Source bereit
steht und was es mir ermöglicht hier eine developer Plattform
mit Self Service aufzubauen. Spotify selber nutzt im
Hintergrund auch Git Hub und setzt das Ganze so um, dass
letzten Endes, wenn ich so ein Projekt dort in Backstage
konfiguriere in. Die frei auch sofort das
entsprechende Repository konfiguriert wird.
Die entsprechende Cloud Plattform mit den Services
bereitgestellt wird und das gleiche kann ich auch nutzen auf
Basis der Erfahrung und des Wissens die halt solche großen
Unternehmen wie Spotify über die letzten Jahre aufgebaut haben.
Genau. Backstage ist ganz geil
eigentlich. Das ist auch an die CNCF, die
Cloud Native Computing Foundation als Open Source
Projekt gespendet und übergeben worden und hat wirklich so nen
so nen Plattformkatalogansatz. Also man ist fast schon mehr ein
Framework wie einfach nur ein Tool, man muss es auch selber
hosten, es wird nicht für einen gehostet sondern ist irgendwie
ein Docker Container den man sich irgendwo hinstellt kann man
auch selber erweitern, ist am Ende des Tages auch nur eine
Projektanwendung die man mit selber erweitern kann, gibt auch
Dutzende Plugins für eigentlich jede Technologie.
Und die haben so ein bisschen so ein Katalogisierungsansatz, dass
ich also nicht nur mein Projekt da reinpflege, sondern auch alle
anderen Projekte, alle anderen Apps und Microservices, die
alle, die andere Entwicklerteams bauen, dass sie damit
aufgelistet werden, und das gibt mir nicht nur eine Übersicht
zwischen der Verbindung zwischen den Tools, ich kann nämlich
sehen, wer benutzt denn eigentlich schon diesen Service
und wie sind die miteinander verbunden, sondern ich habe
wirklich auch so eine so eine API discoverability also ich
kann. Ganz gut sehen welche Services
gibt es denn schon? Welche APIS werden denn
innerhalb meines Unternehmens schon angeboten, um vielleicht
auch einfach das Rad nicht neu erfinden zu müssen und meinen
eigenen Service schneller oder besser integriert einfach bauen
zu können, weil ich ja schon auf bestehendem Wissen aufbauen kann
und das ist ganz geil, weil das in Backstage so funktioniert,
dass ich einfach in mein Git repository so eine Kette loginfo
Datei reinlege, wo all die Informationen über mein Projekt
aufgelistet sind und. Eben hingeht.
Und wenn ich zum Beispiel Github benutze, meine ganze Github.
Org scannt nach Projekten, die diese Datei haben und dann
automatisch die in diese developer Plattform ongebordet
werden. Das heißt ich kann meine
bestehende Toolchain weiter verwenden.
Und mein Projekt taucht dann damit auf in Backstage.
Ich hab auch dann die Dokumentation in Backstage kann
sehen wer das wer das verwendet, wer ist dafür verantwortlich,
wann wurde das Geupdated. Ich sehe also auch in welchen
Teams welches Know-how wenn ich jetzt zum Beispiel sag ich
möchte hier ne Postcrestdatenbank einsetzen,
kann ich gucken wo die denn sonst noch in dieser fertigen
Konfiguration eingesetzt wird und vielleicht weiß ich nicht
ruf ich mal die Julia aus dem Nachbarteam an, weil die
scheinbar ja auch Postgress verwenden, wir haben denn die
oder jene Challenge gelöst. Und darüber hinaus verfügt eben
backstage dann auch über diese Templates.
Das ist auch ganz geil, ich hab wie Son Wizard beim installieren
wieso eine Eingabemaske, wo ich mich durchhang und hab also tec
Docs noch mit drin, eine Suche über Komponenten und Projekte
hinweg und ne ganze Menge Plugins.
Mhm und das coole ist, wenn man erst mal so was aufgesetzt hat.
Es ist natürlich n gewisser Aufwand erstmal dahin zu kommen,
aber am Ende profitieren natürlich alle, die dort in der
IT betroffen sind vor von einem solchen Ansatz, das heißt ich
als Development Team profitiere natürlich davon, weil ich
wirklich viel schneller neue Projekte starten kann.
Ich muss auch nicht mehr zwingenderweise Expertinnen und
Experten in dem ganzen Thema Infrastructure as Code im Team
haben, die Halt wissen wie man irgendwie Security Heart and
Cloud Infrastructure aufbaut, sondern ich bekomme hier die
entsprechenden Vorlagen, bekomme die Infrastruktur und kann
sicher sein, dass wenn ich dort meinen Service betreibe der
entsprechenden Policies. Entspricht das Ganze geht
schneller. Ich muss nicht irgendwo ein
internes Ticket aufmachen und dann warten, bis irgendjemand
für mich Sachen aufgesetzt hat, sondern das Ganze läuft
automatisiert durch und auf der anderen Seite haben natürlich
die Teams, die vorher oder aktuell für diese Infrastruktur
verantwortlich sind, einfach viel mehr Zeit, sich mit
strategischen Initiativen zu beschäftigen, zu schauen, okay
was sind neue Services, die wir den Leuten anbieten wollen und
können und die müssen nicht die ganzen Tag irgendwie damit
verbringen irgendwelche Tickets abzuarbeiten.
Ich habe es jetzt kürzlich wieder von einigen Unternehmen
gehört. Die tatsächlich irgendwie so n
Service Now Ticketsystem haben, wo man dann immer n Ticket
aufmachen muss, wenn man irgendwelche neuen Services
anbinden möchte oder bereitstellen möchte oder im
schlimmsten Fall ne shared E-Mail inbox, wo dann jedes
Jahr, jeden Tag dann irgendwie 3.
Renopement teams mir irgendwelche requests in meine
Inbox kippen und ich muss dann wieder loslaufen und immer und
immer wieder solche manuellen Schritte durchlaufen.
Ich glaube, es ist n gewisser Ramp erforderlich, das dauert,
man muss dafür Ressourcen bereitstellen, umso etwas
erstmal aufzubauen, man kann aber.
Glück auch auf die Erfahrung von anderen Unternehmen aufsetzen,
aber wenn man so etwas erst mal in Place hat, dann profitieren
am Ende irgendwie auch beide Seiten davon.
Und auch wenn wir in den letzten Jahren immer über Dev Ops
gesprochen haben, es gibt immer noch reine Ops Teams, die für
die Infrastruktur verantwortlich sind und ich glaube die haben
ganz andere Sorgen in jedem, in jedem ihrer Arbeitstage als
irgendwie wieder Infrastruktur für Neues Development Team
aufzusetzen und abzusichern, weil ich glaube gerade vor dem
Hintergrund. Jetzt kurz im Nebensatz erwähnt,
vorhin vor dem Hintergrund Security, wir reden immer mehr
über das Thema, so Application Security Cyber Security wird es
immer wichtiger, dass halt nicht nur Software sicher ist, nur
noch die Infrastruktur entsprechend richtig
konfiguriert und abgesichert ist.
Wir sehen es quasi tagtäglich, dass es irgendwelche Security
Incidents irgendwo gibt und ich glaube, wenn sich dann beide
Seiten da weniger Sorgen darüber machen müssen, weil das ist
zumindest bei mir immer so etwas, wenn ich irgendwas da
aufsetze. Denke ich immer.
Boah, ob das jetzt so wie es konfiguriert ist.
Richtig konfiguriert und abgesichert ist weiß ich gar
nicht, weil ich gar nicht Experte in dem Bereich bin.
Und dann nimmt man glaub ich auch den Leuten viel Last von
den Schultern. Von daher sehe ich das als super
spannenden Ansatz und ich sehe es halt wirklich bei immer mehr
Unternehmen. Mit mittlerer oder größerer
Größe. Also ich weiß nicht, ob man das
an der developer Anzahl festmachen kann, häufig sieht
man das bei Unternehmen mit 500 000 Developer, dass sie sich
darüber Gedanken machen. Ich weiß nicht wie da deine
Einschätzung absichert. Oder?
500 bis 1000 dass man da ab der Größenordnung 500 000 ich weiß
gar nicht, welche Unternehmen es mit 500 000 Developer gibt.
Nee, also ab der Größenordnung so 500 bis 1000 developer im
Unternehmen merke ich halt, das dauert dieser Gedankenprozess
eingesetzt ist und dass sie anfangen, diese Portale
aufzubauen. Bei kleineren Unternehmen muss
man das, glaube ich, sehr individuell entscheiden, ob sich
da der Aufwand lohnt. Es ist ja also vor allem das
Plattform Engineering. Ja glaube ich ne Gegenbewegung
ohne Reaktion auf das was du gerade beschrieben hast.
Diese gesteigerte Komplexität. Es gibt so Umfragen auch von von
großen Beratungshäusern zum Beispiel, die Halt einfach
rausgefunden haben, dass über die.
Jahre gerade mit dieser ganzen Dev Ops Death SEC Ops Motion
Engineering Teams immer weniger Code schreiben, also eigentlich
immer weniger Mehrwert schaffen und sich immer mehr mit den
ganzen Toolings drumherum mit Infrastruktur, Infrastructure,
Escode und mit den ganzen Security Sachen und mit
Observibility und dem Betrieb auseinandersetzen.
Und das willst du ja eigentlich als Unternehmen nicht.
Du willst ja eigentlich und da geht's es gibt dieses dieses
Trendwort Developer velocity können wir auch mal eine Folge
zu machen, gibt es einen super spannenden mckinsey Artikel zu
die versucht haben das zu messen und da sehr viel auch Gegenwind
bekommen haben ist glaube ich auch spannend mal für eine
Podcast Folge. Ne, diese ganze Komplexität
frisst einfach wahnsinnig viel Developer velocity und darauf
reagiert eigentlich Plattform Engineering, indem es diese
Standards schafft. Und da muss man natürlich auch
immer ne Balance finden. Also du hattest ja gerade
gesagt, ja, ich will nicht für jedes Tool irgendwie zu meinem
irgendwie ne E-Mail irgendwo an n Operations team schicken,
damit ich dann da hier doch doppelt meinen Server
bereitgestellt bekomme ne also wir beide arbeiten auch mit
Großkunden wo ein Server bereitstellen immer noch ne
Sache von mehreren Wochen bis Monaten ist und da muss man
glaube ich aber auch im Plattform Engineering so ein
bisschen die Balance finden zwischen.
Auf der einen Seite will ich natürlich trotzdem diesen
Developer Speed, diese Developer Velocity, die will ich
hochhalten und auf der anderen Seite will ich aber Security
haben. Ich will, ich will den Teams
trotzdem Flexibilität geben, dass sie die Tools und die
Technologien einsetzen, die am besten für die Lösung ihrer
Challenges geeignet sind und auf der anderen Seite will ich aber
Standardisierung haben. Ich will eine sehr hohe
Produktivität haben, ich will aber auch meine Kosten irgendwo
unter Kontrolle bringen und ich glaube diese Abwägung gibt es
trotzdem. Und wenn ich jetzt was brauche,
was es einfach in dieser Plattform nicht gibt, weil ich
jetzt sag, ich möchte keine Ahnung, ich sag jetzt einfach
mal, ich möchte jetzt serverless machen, weil ich glaube, dass
das das Beste ist für meine Applikation, und das gibt aber
diese Plattform gar nicht her oder diese interdeveloper
Plattform, dann kann ich natürlich überlegen, erlaube ich
meinen Developern dann auf eigene Faust loszugehen und wenn
das erfolgreich war, ziehe ich das in die Plattform mit rein
oder sage ich alles, was ihr verwendet muss auch aus dieser
Plattform kommen, und wenn es da kein Server ist gibt, dann
müssen wir halt noch eben warten, bis wir das da irgendwie
reingebacken bekommen haben. Diese Fragen muss man sich
trotzdem stellen, auch als Plattform Engineering Teams.
Wie weit will man da die Freiheit lassen, weil ich will
ja eben auch nicht frustrierte Developer haben, die nur dieses
eine Framework machen können, die nur auf diese eine Art und
Weise Code schreiben können, das will ich am Ende auch nicht und
trotzdem will ich diese Standardisierung, ich glaube
diese Frage löst das gar nicht unbedingt, sondern es gibt eher
nochmal Anlass über diese Frage genau nachzudenken und dafür
eben ja Richtlinien im Unternehmen zu etablieren.
Das ist ja auch höchst individuell, je nach Unternehmen
und Team. Und was ich vielfach in der
Praxis sehe, ist, dass durchaus beides erlaubt wird, dass man
sagt, okay, wir haben hier folgende Templates, es gibt halt
ex templates, aber wenn ich halt etwas brauche, was nicht
enthalten ist, dann kann ich diesen Weg gehen, aber.
Dann bin ich selber dafür verantwortlich, so in dem Sinne,
wenn du halt von dem gepflasterten Weg sagt man das
im deutschen Pave Path Abweichst ne, dann musst du dich selber
drum kümmern, dass du erfolgreich ans Ziel kommst und
dabei. Entsprechend alle internen
Richtlinien einhältst und da kann man sich dann natürlich
entscheiden oder muss sich manchmal entscheiden, welchen
weg man geht und ich glaub es gibt sehr valide Use Cases wo
man sagt OK, aus diesen Vorlagen.
Passt jetzt keiner auf mein Projekt, aber ich weiß genau,
ich muss es in folgender Art und Weise machen.
Da muss man halt sicherstellen, dass man trotzdem dort die
richtigen Einheiten, das ist ja auch fair und genau wie du
sagst, man will ja die Leute auch nicht zu sehr einschränken,
weil das natürlich auch ein Aspekt in dem ganzen Thema, so
Developer Velocity eine Rolle spielt, dass man den Leuten auch
die Werkzeuge und Tools gibt, die sie brauchen, das Ziel
möglichst gut zu erreichen. Klar, du kannst ja auch sagen,
Pass auf, wenn du dir ein neues Projekt erstellst, dann kriegst
du hier diesen Ort an meinem Cloud Provider der Wahl, da
kannst du rein deployen was du willst.
Aber es ist ein Ort, den wir von vornherein schon unser
Governance System angeboten haben, das heißt, auf dieser
Spielwiese gelten halt einfach bestimmte Spielregeln.
Und da kann man ja bei jedem Club weiter auch so Policies
hinterlegen. Ich kann sagen, du kannst da
machen was du willst, du kannst aber nichts unter einer Public
Adresse zum Beispiel veröffentlichen, das muss durch
eine provokant Prozess gehen oder du kannst bestimmte Arten
von virtuellen Maschinen, die wir einfach zu teuer sind oder
was weiß ich nicht provisionieren oder wenn du wenn
du mit Secrets arbeiten willst musst du die in einen Secret
Store legen und sowas also da kann man ja auch durchaus
Rahmenbedingungen geben aber ich stelle dir halt über dieses
Plattform Engineering über diese Plattform.
Einfach diese ne so ne subscription oder irgendwie so
ne ressourcengruppe oder irgendwie sowas bereit wo du
halt alles was duployen kannst was du möchtest.
Aber unter diesen gewissen Regeln.
Gut, wer braucht denn jetzt eigentlich Plattform
Engineering? Wir hatten es ja gerade schon
gesagt, so die meisten Kleinunternehmen, Startups,
Cloud Native Companies wahrscheinlich nicht.
Und wenn man es einführt, muss man sich natürlich auch die
Frage stellen. Ich hab ja nur, ich hab ja nen
Trade off. Ich muss wenn ich da dediziert n
Team n Engineering Team für Abstelle meine interne Developer
Plattform zu bauen. Dann zieht das natürlich
Ressourcen von meinem Engineeringzweig weg ne, weil
dann die Leute schreiben ja schon mal.
Er hatte keinen Code, die sind wahrscheinlich den ganzen Tag
damit beschäftigt, diese Plattform zu bauen und zu
pflegen und zu warten und zu erweitern.
Und auf der anderen Seite kann es aber sein, dass das meinen
anderen Engineering Teams dann in wahnsinnigen
Produktivitätsgewinnen gibt, weil sie sich über ganz viele
Dinge keine Gedanken mehr machen müssen und weil einfach Dinge
vereinheitlich sind. Und dabei ist es auch eigentlich
glaub ich egal, ob ich jetzt in einer Cloud in mehreren Clouds
unterwegs bin. Ich glaube, solange ich mehrere
developer Teams ab ner gewissen Größe hab, solange ich Legacy
Software habe oder irgendwas on Premises vorhanden ist oder
generell in meinem Unternehmen auf viele verschiedene Art und
weisen Software gebaut wird. Und auch betrieben wird und auch
abgesichert wird. Und auch Gemonitored wird.
Kann ich mir da mal Gedanken drüber machen?
Ich seh es aber abschließend eigentlich fast nur bei sehr
sehr großen Firmen wie du gerade eben auch schon gesagt hattest.
Von daher würd uns interessieren, wird in euren
Unternehmen schon Plattform Engineering praktiziert?
Gibt es bei euch einen Self Service Developer Portal?
Schreibt uns gerne zurück per E-Mail oder per Kommentar auf
Spotify. Würde uns auf jeden Fall super
interessieren, bei welcher Unternehmensgröße solche Trends
auch schon Fuß gefasst haben. Habt ihr darein investiert, ihr
müsst nicht euren Arbeitgeber nennen, uns würde es
interessieren wie viele Developer habt ihr, habt ihr so
eine developer Plattform? Verspannt, weil wir einfach
berufsbedingt größtenteils mit großen Konzernen arbeiten oder
halt in sehr kleinen und von daher der Bereich dazwischen
zumindest bei mir immer so n blinder Punkt ist.
Da würde mich wirklich interessieren, wie es bei euren
Arbeitgebern aussieht. Wir machen, wenn ihr uns auf
Spotify zugehört, zumindest mal eine Umfrage.
Und bei Spotify kann man unten unter der Folge aus Umfragen
machen, da können wir einfach mal abstimmen, das würde ich mal
machen. Weil vielleicht heißt es da
einfach bei euch nur anders. Wie gesagt, Plattform
Engineering, so ein Trendwort. Oft heißt das aber auch
irgendwie Internet Developer Plattform oder vielleicht heißt
es noch Site Relibility plus Depots oder wie auch immer oder
vielleicht nutzt ihr einfach yo man Generatoren ich glaube da
geht gar nicht darum ob das bei euch Plattform Engineering
heißt, ich glaube das ist mir gerade so ein bisschen diese
Buzzwordbegriff der den Hypecycle einmal durchläuft,
sondern ob ihr es macht. Wunderbar.
Damit sind wir am Ende dieser durchaus sehr spannenden Folge
angekommen, hat mir viel Spaß gemacht, ich hoffe, es war für
euch auch interessant, einfach mal das Thema von Anfang bis
Ende zu durchleuchten. Wie gesagt, gebt uns gerne
Feedback und wenn euch die Folge gefallen hat, lasst uns gerne
eine positive Bewertung auf einer der Podcast Plattformen
da. Wenn.
Was an der Folge hattet, freuen wir uns doch immer wahnsinnig,
wenn ihr uns nen Kaffee ausgebt. Dafür gibt es nen Link unten in
der Beschreibung zu Buy Meal Coffee.
Langsam müssen wir es auch nicht mehr gegen Glühwein eintauschen,
die Kaffeezeit geht wieder los, malte und ich freuen uns da
immer sehr und ansonsten hören wir uns in 2 Wochen wieder, denn
der todo Cast der Developer Podcast erscheint alle 2 Wochen
auf allen Podcast Plattformen. Bis dahin macht's gut, habt eine
gute Zeit und schreibt ganz viel Code.
Bis dahin. Tschüss.