Folge 72: Veit Joseph zu Shift Left

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Falko und Luca unterhalten sich mit Veit Joseph von der DATEV. Er befaßt sich dort mit der systematischen Umsetzung und Weiterentwicklung von Qualitätssicherung und Teststrategien.

Mit ihm verhandeln wir shift left, was es bedeutet und wie man es umsetzt. Weiter sprechen wir über Testpyramiden und Test-Eistüten, und vor Allem die Wandlung von QS als Abschnitt des Prozesses zu QS als intrinsischer Eigenschaft des Prozesses.

In dieser Podcast-Episode wird der Fokus auf die „Shift Left“-Bewegung in der DevOps-Praxis gelegt, die für eine frühere Einbeziehung der Qualitätssicherung im Entwicklungsprozess steht. Veit Josef, ein Requirements Engineer, erklärt die Notwendigkeit dieser Verschiebung und diskutiert die technischen und organisatorischen Herausforderungen, insbesondere in Bezug auf Teststrategien und Teamdynamiken. Es wird betont, dass erfolgreiche DevOps eine ausgewogene Berücksichtigung von Entwicklung, Betrieb und Qualitätssicherung erfordert, um effiziente und effektive Ergebnisse zu erzielen.

Inhalt

  • Einführung und Hintergrund des Gastes, Veit Josef
  • Persönliche Definition von DevOps durch Veit Josef
  • Diskussion über den Blogpost „Shift Left, nie mehr schlaflos in DevOps“
  • Bedeutung und Umsetzung von „Shift Left“ in der Qualitätssicherung
  • Veränderungen in DevOps durch Cloud-Native-Anwendungen
  • Herausforderungen und Lösungsansätze im Kontext von On-Premise- und Cloud-Anwendungen
  • Bedeutung von DevOps-Praktiken für größere Unternehmen
  • Diskussion über Testing-Strategien, inklusive Testpyramide und Test-Eistüte
  • Integration von Qualitätssicherung in alle Phasen der Softwareentwicklung
  • Rolle von verschiedenen Teammitgliedern im Shift-Left-Prozess
  • Auswirkungen von Shift Left auf Teamstrukturen und -prozesse
  • Diskussion über den Einfluss von Tools und Technologien in DevOps
  • Die Notwendigkeit von Kommunikation und Zusammenarbeit zwischen Entwicklungs- und Betriebsteams

Shownotes

Veits ursprünglicher Artikel

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Heute haben wir als Thema, warum die DevOps 8 links beginnen muss.
Also die Unendlichkeit beginnt links, habe ich mir erklären lassen.
Zu Gast dafür, um uns das zu erklären, haben wir Veit Josef, der Requirements Engineer ist bei der Dativ
und sich da allerhand Gedanken zu dieser Art von Topologien gemacht hat.
Veit, willkommen. Schön, dass du da bist.
Ja, schön, dass ich da sein darf. Danke für die nette Anmoderation.
Es stimmt übrigens nur zum Teil.
Ich bin aktuell Requirements Engineer bei der Dativ.
Also ja, da habe ich als Requirements Engineer angefangen.
Ich hatte vorher vor der Dativ noch ein bisschen Background, vielleicht auch als Product Owner oder Application Manager
und bin jetzt mittlerweile aber seit, naja, zwei Jahren folge ich einer neuen Passion, die da heißt
Qualitätssicherung und vor allem Qualitätssicherung von Online- oder von Cloud-Native-Anwendungen.
Und das vielleicht kurz noch zur Einordnung einer zentralen Position bei der Dativ.
Also ich bin nicht direkt in einem der…
Ja, es sind doch irgendwie 250 plus minus x Produkte, die wir so im Portfolio haben.
Nicht in einem dieser Entwicklungsteams, sondern ja, wie gesagt, in einer zentralen Position.
Und wir sehen viele der Produkte und vor allem der neueren Entwicklungen an uns vorbeikommen, zwangsläufig.
Und bei diesem vielen Vorbeikommen kriegt man viel mit und will aber auch viel mitgeben.
Und genau da bewege ich mich gerade ein bisschen.
Sehr schön.
Dann bevor wir uns als eigentliches Thema machen.
Wir haben ja eine Tradition in diesem Podcast, dass wir jeden Tag…
…den Gast nach seiner persönlichen Definition von DevOps fragen.
Und das Schöne daran ist, dass jeder Recht hat.
Insofern, Veit, was ist denn deine persönliche Definition von DevOps?
Ich weiß gar nicht, ob ich jetzt überrascht tun soll oder ob ich eigentlich weiß, dass diese Frage auf mich zukommt.
Also ich würde mich tatsächlich so ein bisschen an der Lexikon oder vielleicht auch an der Wikipedia-Definition halten wollen.
Also ein Team wird durch Nutzung oder gemeinsame Nutzung von Werkzeugen, Entwicklungswerkzeugen im weitesten Sinne und auch Vorgehen,
aber auch die Infrastruktur und Prozesse, die es vielleicht schon gibt, die sie aber dann gemeinsam nutzen, in die Lage versetzt,
Gesamtverantwortung für die Entwicklung und den Betrieb eines Produkts zu übernehmen.
Und neben den Vorteilen, die man sich damit erkauft, also sowas wie, ich kann Software und Produkte kontinuierlicher, schneller und stabiler entwickeln,
werden dabei noch, und das habe ich jetzt ganz oft schon gemerkt, vor allem in so größeren Unternehmen,
wie Data, würde ich jetzt sagen, einfach mal…
Zumindest in die Mitte der Bandbreite einordnen, kann mit so einem Vorgehen oder mit DevOps an sich auch ganz gut so gewachsene Organisationsstrukturen,
man spricht ja da gerne auch von Silos, nicht niederreißen, aber zumindest denen ganz gut begegnen und die Hürden ein bisschen tiefer setzen.
Und auch so, weil ich gerade Prozesse angesprochen habe, so bürokratische Verkrustungen so ein Stück weit auch auflösen.
Auch dabei hilft es.
Sehr schön. Und insofern, wir haben dich eingeladen, weil wir an einem Blogpost von dir vorbeigekommen sind,
den wir recht interessant fanden, der da hieß Shift Left, nie mehr schlaflos in DevOps.
Erzähl doch mal, was war denn dein Witz dabei?
Ja, so witzig ist es vielleicht gar nicht, aber DevOps, zumindest in der Dativ, ist, soweit ich es beurteilen kann,
also es ist, glaube ich, nicht die erste DevOps-Welle, die durch die Dativ gleitet, aber zumindest eine ganz große jetzt.
Und das spielt uns in der zentralen QS auf der einen Seite in die Karte, auf der anderen Seite geht das so ein bisschen vor allem aus unserer zentralen Anspruchshaltung,
muss man schauen, dass man nicht die Ziele, die wir verfolgen, damit irgendwie so ein bisschen dagegen schießt, sage ich mal.
Und bei uns, so meine Beobachtung, war es ganz oft so, dass man sehr gerne neue Wellen ganz oben reitet und sich erst mal darauf konzentriert,
was bringt denn jetzt diese neue Orientierung oder diese zusätzliche Orientierung?
Ich muss vielleicht davor wegschicken noch, die Dativ befindet sich gerade in einem relativ großen Change, sage ich mal.
Was unser Portfolio anbelangt, also diese 250 plus X-Produkte, die ich vorhin mal angesprochen habe,
die sind hauptsächlich On-Premise-Anwendungen, also die bei unseren Kunden und Kundinnen, Kanzleien größtenteils, Steuerberater installiert werden
und die natürlich großen Release-Zügeln unterliegen, da kommt mal da im halben Jahr oder einem Jahr eine CD oder eine DVD raus.
Und jetzt ist man aber der Meinung und der gleichen Meinung bin ich auch, dass wir ganz viele unserer Anwendungen oder Prozesse,
in die Cloud heben müssen, um es jetzt mal ganz einfach zu beschreiben.
Und da ist DevOps natürlich, sage ich mal, bietet ein ganz reichhaltiges Portfolio an Dingen und Methoden und Vorgehensweisen, die das möglichst gut unterstützt auch.
Aber wie ich gesagt habe, Dinge, die ich beobachte, sind, wenn etwas vielleicht neu ist oder man es gerade irgendwie hoch hält und vielleicht auch hoch jubelt,
ich will nicht gegen DevOps schießen, aber das führt oft dazu, dass man sich auf diese neuen Sachen vor allem einschießt.
Okay, was?
Diese schöne neue DevOps-Welt. Jetzt haben wir auch Ops in der Entwicklung mit drin.
Jetzt können wir auch über Dinge reden wie, weiß ich nicht, jetzt schmeiße ich mal ein paar Begriffe um mich,
A-B-Testing, Kern-Release, Blue-Green-Deployment und was mir alles verbindet, vor allem mit der rechten Seite der DevOps 8,
Monitoring as a Service und solche Geschichten.
Und vergiss dabei oftmals, bewusst oder unbewusst, dass wir ja auch, das ist ja eine 8 und ich habe ja nicht umsonst gesagt, die beginnt links,
dass wir halt eine linke Seite auch haben.
Und da vielleicht in der Vergangenheit geprägt durch, wie wir aufgestellt waren mit On-Premise-Anwendungen, Dinge getan haben,
die uns in der neuen Welt, will ich es mal benennen, also in der Online-Welt, so nicht mehr funktionieren und so auch nicht mehr helfen würden.
Und wenn wir uns jetzt nur auf den rechten Teil konzentrieren würden, dann würden wir den linken noch mehr außer Acht lassen und wir würden in eine Schieflage geraten.
Weil ich glaube schon, ich nenne es immer gerne das System DevOps, dass das ein System ist, das nur funktioniert, wenn wir die beiden Seiten irgendwie,
und das hat ganz unterschiedliche…
Die Perspektive, wenn die beiden Seiten möglichst in Balance halten.
Und eine Balance entsteht eben mal nicht, wenn ich mich nur auf eine Seite konzentriere und die andere vielleicht so ein bisschen neben links liegen lasse,
sondern ich muss schon schauen, dass ich da im Gleichschritt marschiere, sozusagen.
Um noch den Bogen zu spannen zu dem Titel.
Ich wollte damit zeigen, ich habe natürlich mich eines besonders schwarzen Szenarios bedient, sage ich mal.
Nämlich, wenn man jetzt irgendwie, okay, jetzt haben wir auch Betrieb, den wir verantworten.
In unserem Produktentwicklung.
Was passiert denn eigentlich, wenn die Hotline klingelt oder wenn irgendwelche Monitoring-Systeme anschlagen, irgendwelche Alerts aufpoppen,
weil wir Dinge detektiert haben, Fehlnutzung oder Fehlersituationen.
Wir müssen ja damit umgehen und im Zweifel, wann passieren die Dinge?
Ja, nicht um Dienstag irgendwie 14 Uhr, wo noch alle in Kraft und Saft sind, sondern im Zweifel am Wochenende.
Und irgendjemand erwischt es, der hat heute das Notfall-Handy irgendwie neben dem Bett liegen und muss reagieren.
Und damit uns solche Situationen nicht passieren oder dass wir eine gute Strategie haben, um mit solchen Situationen, wenn sie denn passieren, umgehen zu können,
wollte ich sagen, lass uns erstmal links auch investieren, damit wir eben das Risiko, dass rechts irgendwas schiefläuft, minimieren können.
Beziehungsweise gute Vorgehensweisen haben, um da rechts auch agieren zu können.
Und so ist es zu dem Titel gekommen.
Aber jetzt müssen wir, ich glaube, jetzt müssen wir nochmal einen Schritt zurück machen und unsere Hörer so ein bisschen einsammeln.
Wovon wir hier eigentlich die ganze Zeit reden, von irgendwelchen Achten mit links und rechts und so.
Es geht natürlich um diese berühmte liegende Acht, dieses Unendlichkeitssymbol, das ganz gerne verwendet wird in der DevOps-Literatur.
Und das hat logischerweise zwei Seiten, eine linke und eine rechte.
Und auf der rechten Seite vor Ort ist DoFight, diese ganzen Dinge, Release, Deployment, Monitoring, Ops.
Also auch das, wenn man…
Wenn man es sich linear vorstellen würde und nicht als liegende Acht, dann würden wir auch sagen, das ist halt so das Strom ab.
Also das Richtige, das Betriebsseitige.
Und auf der linken Seite steht bei dir dann so Dinge wie Code und Plan und Test und Build.
Also die Dinge, die traditionell eher so in Richtung der Entwicklungswelt gehen.
Also vielleicht mit der Grenze da, wo das Produkt zum Kunden übergeht, sage ich mal.
Das ist vielleicht die rechte Seite und davor, das ist die linke Seite, ja.
Genau. Und die Prämisse deines Artikels ist ja wohl die, dass…
erfolgreich sein zu können in einer DevOps-Welt, man seinen Fokus mehr auf diese linke Seite legen muss,
dass man bereits früher in diesem DevOps-Wertstrom auf Qualität achten muss, für Qualität sorgen muss.
Habe ich das so richtig wiedergegeben?
Ja, ist natürlich unfair, weil wir reden ja über eine Acht und dazu sagen, ich muss irgendwie…
Wo ist denn eigentlich der Anfang in der Acht und warum muss ich da denn beginnen?
Aber ja, das ist letztendlich die Aussage.
Vielleicht noch ein bisschen differenzierter, wenn ich nicht ein gutes Level oder eine gute Qualität auf dem Bereich habe,
der eben vor einem Release ist, in der Planungsphase, in der Implementierungsphase, auch in der Testphase,
dann werde ich auf der rechten Seite im Monitoring und im Weitläufigen in der Operations halt meine Probleme bekommen.
Ja, das ist ganz interessant.
Auch insofern, als Falk und ich uns heute Vormittag zusammengesetzt haben, um ein Call for Papers zu beantworten,
der DevOps Enterprise Summit, wo es um genau sowas ging, da haben wir so ein bisschen Rückschau gehalten auf Kunden von uns
und wie deren Erfahrungen so waren und was wir irgendwie als Gemeinsamkeit, egal wie groß oder klein der Kunde ist
oder in welcher Branche er sich bewegt, wenn diese Ausgangs…
Wie soll ich sagen?
Wenn keine Klarheit besteht bereits beim Losmarschieren, dann kommt halt hinten auch nur irgendwas sehr Unscharfes,
im Zweifelsfall sehr Instabiles und womöglich auch nicht besonders Werthaltiges dabei,
weil es ist ja nicht so, dass man sich da so ein bisschen in die Hand nehmen kann,
weil es ist ja nicht so, dass man sich da so ein bisschen in die Hand nehmen kann,
und man muss ganz ehrlich sagen, das ist natürlich jetzt nichts Neues,
das haben die DevOpsler sich jetzt nicht irgendwie ausgedacht oder sowas,
sondern, meine Güte, das ist halt irgendwie so ein Klassiker, das sind halt so Sprüche wie Garbage in, Garbage out,
oder das sind Dinge, die aus Richtung Lean kommen, aus Richtung Toyota Produktionssystem kommen,
wo ja auch schon von vornherein gesagt wurde, daher kommt hier dieser Begriff Shift Left,
je früher man für Qualität sorgen kann, desto mehr wird man Strom ab davon profitieren.
Ja, eine Fehlzeit.
Eine Fehlüberlegung bereits in der Spezifikationsphase aufzudecken und zu sagen,
naja, das war jetzt irgendwie unüberlegt, das zu korrigieren braucht nur einen Federstrich,
dann spezifiziere ich es halt um, zack, bumm, fünf Minuten später ist das Ding erledigt,
während wenn in der Kehrseite das erst auffällt, wenn das Produkt beim Kunden ist und der Kunde sagt,
was soll ich denn damit, ja, dann ist es natürlich irgendwie blöd,
dann habe ich potenziell, so wie du beschrieben hast, viele Monate in den Sand gesetzt,
bis die DVD endlich mal beim Kunden ist und dann bringt sie nichts und dann habe ich keinen Wert geliefert,
und alle haben irgendwie reichlich Torte im Gesicht.
Genau, und vielleicht noch als Ergänzung, du hast ja schon gesagt, das ist alles ein alter Hut,
also da wäre ich keinem mehr hinterm Ofen vorloggen, wenn ich sage,
Dinge, die uns später auffallen, sind teurer.
Wir in der Dativ, also ich will nicht sagen, dass wir irgendwie anfangen, Dinge neu zu erfinden oder so,
das müssen wir nicht tun, also es gibt genügend Standards, Vorgehensweisen, wie meinetwegen Shift Left,
auch wie DevOps, die müssen wir nicht tun.
Das ist eine große Herausforderung.
Aber ich glaube schon, dass wir in der Dativ mittlerweile eine Reife erreicht haben,
die uns nicht nur an den Punkt bringt, solche Dinge nutzen zu können,
sondern auch an den Punkt gebracht hat, zu sagen, okay, und was müssen wir aber aus den Dingen tun,
wie müssen wir sie adaptieren, um sie verwenden zu können,
dass sie in unsere Gegebenheiten, in unsere Anforderungen passt.
Und das ist bei einem Shift Left, den treiben wir vielleicht nicht weiter,
aber wir führen ein paar Perspektiven noch expliziter aus, wenn ich die mal kurz erwähne,
also so Dinge wie, wir sprechen ganz gern auch mal vom Shift Left Left,
also der Shift Left sagt, ja, verlagere die Aktivitäten, die QS-Aktivitäten nach vorne in deinem Zyklus,
entwicklungsbegleitend, aber neben diesem entwicklungsbegleitenden Testen ist es uns noch explizit wichtig,
dass wir auch Dinge in der Planphase QS-Aktivitäten dort ansiedeln,
heißt im Detail, BDD, 3MU-Gespräch sind da so Stichworte, dass eben auch eine QS-Perspektive bei der Definition von Anforderungen,
oder von vor allem testbaren Anforderungen eben auch mit reingebracht wird.
Also das ist uns ganz wichtig, dass wir diese Anspruchshaltung verfolgen,
aber auch so Dinge wie, das schwingt ja auch mit, aber wir sagen es nochmal explizit, Komplexität reduzieren.
Also das frühe entwicklungsbegleitende Testen, vor allem mit isolierten Testobjekten,
das reduziert nun mal die Abhängigkeiten, die man sich bei verteilten Architekturen unweigerlich auflegt.
Und wenn ich da von isolierten Testobjekten spreche,
dann meine ich eben nicht nur irgendwie die isolierte Klasse im Unit-Test,
sondern eben auch das autonome Testen von Microservice in der eigenen Anwendung,
Frontend gegen Backend, das automatisierte Testen von Schnittstellen,
das Testen von Gesamtanwendungen, wo ich dann Zweit- und Drittdienste,
die ich per Abhängigkeit mir angebunden habe, irgendwie durch Service-Virtualisierung isoliere.
Also auch das ist uns ganz wichtig über solche Dinge, die in so einem Shift-Left drinstecken,
aber die wir halt explizit machen.
Und das meine ich mit Adaptieren und auf unsere Gegebenheiten und Anforderungen auch schwingen.
Ein Stück weit anpassen.
Was bedeutet denn Shift-Left für einzelne Teammitglieder?
Also auch noch ein bisschen Kontext.
Der Dativ ist es ja so, dass wir, ich sag mal, Rollen sehr ausgeprägt nutzen in Entwicklungsteams.
Also es gibt eben nicht nur den PO, den Scrum Master, sondern Entwicklungsteams,
sondern es gibt den Test-Ingenieur, es gibt den Security-Ingenieur, es gibt den Architekten,
es gibt den UX-Designer, es gibt den User-Researcher.
Und das ist natürlich kontraproduktiv.
So ein bisschen, wenn wir, Stichwort, wir verteilen QS-Aktivitäten nach vorne im Entwicklungsprozess,
wenn wir diese Aktivitätenverteilung immer nur an einer Person festmachen würden
oder an einer Rolle festmachen würden.
Weil, was wir in der Dativ schon auch propagieren, ist das Stichwort Whole-Team-Quality.
Sprich, es ist nicht mehr eine Person, eine Rolle im Team verantwortlich für QS,
geht jetzt noch weniger als vorher, weil es ist nicht mal, okay, ich warte, bis Entwicklung fertig ist
und dann teste ich.
Sondern es müssen ganz viele Dinge auch vorher und entwicklungsbegleitend passieren.
Sondern ein ganzes Team ist verantwortlich für die Qualität seines Produkts,
für die Qualitätssicherung, fürs Testen des Produkts.
Und das hat natürlich ganz unterschiedliche Auswirkungen für die einzelnen Personen im Team.
Für jemanden, der eher auf der Business-Seite ist, sich um Anforderungen kümmert,
der sollte sich möglichst früh auch in die Position begeben, sich auseinandersetzen zu wollen
mit Programmierung, also mit dem Software-Ingenieur und mit dem Test-Ingenieur,
um eben, wie ich es vorhin beschrieben habe, auch testbare Anforderungen zu haben.
Eben nicht nur seine Anforderungen über den Zaun zu werfen und wird schon sich jemand drum kümmern
und das auch testen, sondern von vornherein sich Gedanken zu machen,
wie wir sie dann auch umsetzen und testen können.
Für einen Software-Ingenieur heißt das natürlich, er ist nicht nur stupide am Programmieren.
Dinge wie TDD sind noch ein Stück weit wichtiger, noch höhere Ansprüche an Entwickler,
auch auf Qualität zu achten.
Und für den Test-Ingenieur heißt es, so ist mein Dafürhalten vor allem in einem moderneren Online-Entwicklungsumfeld,
er wird auch ein Stück weit sich technischer orientieren müssen.
Es geht nicht mehr nur darum, da ist jemand, der spezifiziert Testfälle und hat eine Checkliste und testet manuell,
sondern es geht vor allem darum, Stichwort auch BDD, Stichwort Clue-Code erzeugen,
Stichwort Code-Implementierung, Programmierung, Testfälle auch lesen zu können.
Also, dass auch die Menschen, die in der Disziplin Test-Ingenierung unterwegs sind, ein Stück weit technischer werden.
Also, es hat für jeden auch unterschiedliche Auswirkungen.
Das Mantra, was über allem schweben sollte, ist,
was ich vorhin schon gesagt habe, Whole-Team-Quality.
Also, jeder ist verantwortlich am Ende für die Qualität des Produktes.
Bis hin zum Product-Owner, der sich, und das passiert hier und da doch nochmal,
eben nicht so leicht aus der Verantwortung rauskommt im Sinne von Funktionalität vor Qualität.
Also, auch da muss natürlich ein Stück weit Umdenken stattfinden.
Also, Qualität vor Funktionalität, wenn man den letzten Satz zumindest nochmal aufgreift.
Das können wir uns nicht leisten, Veit.
Nicht schwarz oder weiß.
Leider ist es ja, wie so oft im Leben immer,
die Grautöne, aber das Ganze unterliegt natürlich schon irgendwie einer Kosten-Nutzen-Abwägung.
Aber man muss halt einfach auch feststellen,
dass mit der schönsten Funktionalität,
wenn die nicht mit der entsprechenden Qualität geliefert wird,
dann bringt mir das Ganze nichts.
Also, in mir schlägt ein ganz tiefes Herz für so Dinge wie die ISO 25010,
Softwarequalitäten oder Qualitäten in Softwareprodukten,
Qualitätsanforderungen, Qualitätsszenarien.
Sowas ist mir ganz wichtig.
Und deswegen würde ich immer sagen, ja, ja, Qualität vor Funktionalität,
aber am Ende kauft der Kunde ganz oft eben auch erst,
mal nur Funktionalität und setzt dann schwer drauf,
dass die Qualität auch stimmt.
Stichwort irgendwie Kano-Modell, Basis- und Leistungsmerkmale.
Da erwartet er einfach, dass die in eine entsprechende Qualität kommen.
Aber wenn wir sie nicht liefern können,
dann zerschellen die Erwartungen an der Realität.
Auch schade.
Zumal es da ja auch das zweite Argument gibt,
wenn du entsprechende Qualität entwickelst,
dann kannst du es dir überhaupt erlauben,
in dieser Geschwindigkeit Funktionalität bereitzustellen.
Also wollt ihr jetzt sagen,
wir haben Qualität und Funktionalität und das soll funktionieren?
Hilft ja nix.
Muss es nur gut verkaufen, ne?
Ja, da sagst du was Wahres, glaube ich, Veit,
weil ganz häufig, deswegen habe ich ja vorhin so sarkastisch gesagt,
das können wir uns nicht leisten.
Qualität ist viel zu teuer.
Der Wert von Qualität erschließt sich halt vielleicht nicht auf den ersten Blick.
Ich meine, jeder mag natürlich gerne Produkte, die gut funktionieren,
aber dann ist dir das Hemd doch irgendwie näher als die Hose
und sagst, nee, nee, das Feature muss jetzt noch zur Tür raus.
Das müssen wir jetzt noch in den Sprint reinkriegen irgendwie.
So was kann man schon mal machen, dass man technische Schulden aufbaut,
dass man vielleicht auch organisatorische Schulden oder sowas aufbaut an der Stelle.
Aber man muss halt wissen, was man sich damit so gerade einfängt.
Da führt halt irgendwie kein Weg dran vorbei, ist mein Eindruck.
Ja, und technische Schulden werden nie weggehen.
Es wird nicht ohne gehen.
Aber du musst handlungsfähig bleiben.
Du brauchst Handlungsoptionen, wenn Dinge dir um die Ohren fliegen.
Und diese Handlungsoptionen,
die, um mal wieder irgendwie zum Pudels Kern zurückzukehren,
die muss ich mir auf der linken Seite in der DevOps 8 einfach schaffen.
Durch eine adäquate Qualitätssicherung,
durch Transparenz über die unterschiedlichen Entwicklungsstufen hinweg.
Was wird wo wann getestet?
Wie kann ich isoliert an meine Service, an meine Funktion rankommen?
Weil nur, dass ich am Ende weiß, okay, da ist jetzt was kaputt gegangen.
Wenn ich nicht weiß, wo was kaputt gegangen ist,
und wenn ich nicht weiß, wer, wann, wo was gedreht hat,
dann wird die Fehlerursachenanalyse irgendwelche Logs durchwälzen.
Das wird dich auffressen.
Dann bist du nicht handlungsfähig.
Und dann verschiebt sich alles Weitere auch.
Weil ich meine, du musst erst mal den Fehler beheben,
bevor du das nächste Feature hinterher schieben kannst.
Im Normalfall.
Und allein darum geht’s.
Insofern ist es ja eigentlich bezeichnend.
Falk und ich haben im Zusammenarbeit mit der DASA,
der DevOps Agile Skills Association,
ein Training verfasst,
das heißt DevOps Specify and Verify.
Und das heißt ja nicht zum Spaß so,
sondern das soll wirklich genau das auch ausdrücken,
was du gerade eben vorgetragen hast,
weil dass das zwei Seiten derselben Medaille sind,
dass ich, so wie du es vorher gesagt hast,
dass ich diese sogenannten Three Amigos da haben muss.
Wenn ich also ein neues Feature ausdenke und spezifiziere,
dann muss ich einen Spezifikatör da haben,
wie auch immer du ihn nennst, Product Owner oder sowas.
Ich muss den Entwickler haben,
der gleich mit mir da ist,
der gleich mitredet.
Ich muss einen Tester haben,
der gleich mitredet und jeder bringt seine eigene Perspektive ein,
die notwendig ist,
damit hinterher auch tatsächlich gute Qualität dabei rauskommt.
Und um das gleich vorweg zu sagen,
ich habe auch gar nichts dagegen,
wenn du fünf, drei Amigos einlädst,
wenn das notwendig ist, um da Klarheit zu erschaffen.
Genau, dann kommen wir ja letztendlich auch gleich zum Punkt Wert.
Wenn du Qualität hast und jemanden, der diese nutzt,
dann kannst du natürlich Wertschöpfung betreiben.
Und dann hast du den Kunden,
der auch wirklich zufrieden mit dem Produkt ist,
finde ich letztendlich mal eine ganz nette Folge im Gedanken.
Im Skript habt ihr sowas geschrieben wie die Testpyramide,
eine Geschichte von Bäumen und Eistüten.
Da kenne ich mich mit Testen nicht so sehr aus.
Ich bin ja nur so ein komischer Entwickler und so,
Architekt teilweise noch.
Aber was sind denn so Bäume und Eistüten?
Erzählt mal.
Ja, ich hatte ja eingangs erwähnt,
also man sieht viel in so einer zentralen Position.
Und man sieht vor allem,
und das hat auch,
äh,
erklärbare Hintergründe,
Stichwort On-Premise-Anwendungen,
dass die viel zitierte Testpyramide,
und jetzt bin ich vielleicht erst mal bei der von,
von Cone mit den drei Stufen,
dass die oftmals umgedreht ist und eine Eistüte ist.
Also sprich, ich habe doch viel mehr Aufwände
oder Ressourcen, die ich in die Stufen stecke,
bei denen ich eigentlich möglichst wenig investieren sollte,
weil sie teuer sind, sage ich mal.
Stichwort automatisiertes Testen über die Oberfläche
eines integrierten Systems.
Also mal kurz einen Schritt zurück machen und sagen,
wie schaut denn so eine Testpyramide aus
und wie schaut eine Testeistüte aus?
Möchtest du den Schritt machen oder soll ich den Schritt machen?
Wenn dir das lieber ist, dann mache ich den.
Also passt auf, liebe Hörerinnen und Hörer.
So eine Testpyramide nach Mike Cone,
die stellt da Tests auf verschiedenen Ebenen.
Ganz unten hat man Unit-Tests,
wir alle kennen die, das sind sehr, sehr kleinräumige Tests,
die häufig mit einem sehr hohen Detaillierungsgrad
ganz kleine Elemente eines Produkts abtesten.
Dazwischen habe ich dann Integrationstests,
Servicetests, nenn sie wie du möchtest,
die schon auf etwas größerer Ebene sind,
wo jeder einzelne Test größere Abschnitte des Produkts überstreicht,
bis hin zu Systemtests, Abnahmetests,
funktionellen Tests,
die dann wirklich an der Oberfläche sich befinden
und sehr, sehr große Abschnitte der ganzen Applikation
auf einmal durchtesten.
Und der Mike Cone sagt eben,
du sollst im Vergleich weitaus mehr Unit-Tests haben
als am anderen Ende der Welt.
Am Ende der Pyramide, da wo sie spitz zusammenläuft.
Systemtests, Abnahmetests, funktionale Tests,
einfach weil solche großräumigen Tests viel, viel kostspieliger sind,
tendenziell vielleicht auch ein bisschen instabiler sind.
Wenn irgendwo in dieser langen Funktionskette irgendwas verändert wird,
nicht mal unbedingt kaputt geht, sondern einfach nur anders ist,
dann fliegt dir vielleicht ein Test um die Ohren
und dann bist du eben die ganze Zeit am Hinterherlaufen.
So, das ist jetzt erstmal die Testpyramide.
Vielleicht, Veit, möchtest du weitermachen mit der Test-Eistüte?
Also kann ich gerne auf dem Modell,
was du uns und auch den Zuhörer in den Kopf gesetzt hast.
Wie du schon gesagt hast,
eine Pyramide ist unten am breitesten und oben spitz.
Und die Pyramide sagt nichts anderes als genau das Gegenteil.
Also ich habe wenig Unit-Tests.
Ich habe wenig Tests auf der integrierten Ebene
von zwischen vielleicht Services oder bei Schnittstellen oder Systemen,
sondern ich habe ganz viel meiner Aufwände.
Vor allem, wenn es darum geht, Funktionalität zu testen.
Auf der obersten Ebene, auf Akzeptanz-Test-Ebene,
auf System-Integrations-Test-Ebene und da dann,
und das ist ja immer so die Krux an der ganzen Geschichte,
über die Oberfläche.
Ich meine klar, es gibt Tools, Frameworks,
Oberflächentests auch zu automatisieren.
Aber du hast ja schon angesprochen,
dass es meistens relativ instabil,
weil Änderungen, die tief unten stattfinden,
große Auswirkungen oben zeigen.
Und schon bist du wieder in der Situation,
irgendwie deine Tests wieder neu aufzustellen
oder deine Automatisierung anzupassen.
Und, das ist ja genau das, was wir im Shift-Left propagieren,
wir wollen ja schnelles Feedback.
Wenn du immer erst im integrierten System deine Tests fährst,
dann bist du weit weg vom schnellen Feedback,
weil da bist du relativ nah an, eigentlich wollen wir releasen.
Das, was da jetzt rauskommt,
naja, lass das mal irgendwie ins Backlog packen.
Oder ist das jetzt wirklich so dringend, was da passiert?
Oder ja, ist es? Na gut, dann müssen wir noch mal
die ganze Kette zurückgehen.
Und das ist so was,
was wir uns ja mit der Eistüte vorstellen, sozusagen.
Was nicht gut ist.
Ja, vielleicht sollte man an der Stelle auch erwähnen,
dass zum Beispiel ein Freund von mir,
der sehr viel mit Serverless macht,
der sehr stark die Desintegration von Diensten vorantreibt,
noch weiter als Microservices,
bis hin zu eben wirklich Funktionen,
die einzeln ausgeführt werden.
Und der sagt, lustigerweise, er macht kaum Systemtests
und er macht aber auch kaum Unit-Tests,
sondern er hat einen Test, was denn, Rhombus?
Ich glaube, das ist dann ein Test Rhombus, oder?
Mit ganz, ganz vielen Integrationstests.
Ja, genau.
Also, das ist das, was er macht,
das ist das, was er macht in der Mitte.
Weil er sagt, das ist das,
wo es bei dieser Art von Systemen dann regelmäßig knallt.
Genau, das ist das, was ich dann immer,
was ich dann mir immer so als Baum,
immer so als Bild male.
Ganz unterschiedlich.
Da kann auch mal ein Baum sein,
der in der Mitte irgendwie dicke Äste hat
und oben eher weniger.
Oder er hat einen dicken Stamm und wird oben wieder spitzer,
hat aber in der Mitte, was du gesagt hast,
mit Integrationstests irgendwie eine große Ausprägung.
Genau.
Und so sieht das dann auch auf die Pyramiden, sag ich mal.
Sondern das sieht immer so ein bisschen anders aus.
Ja, kommt auch auf die Architekturen,
die Anforderungen des Produkts dann an.
Ich will noch eine Perspektive mehr dazugeben,
weil das ist bei uns immer ganz interessant.
Wenn wir nämlich Shift Left sagen,
meinen wir damit auch immer,
und das sagen wir dann manchmal auch explizit,
Shift Down.
Also nicht nur orientiere dich nach links,
entwicklungsbegleitend,
sondern schau noch mal auf die Pyramide
und bitte konzentriere dich auch nach unten,
damit das noch mal ein bisschen mehr propagiert wird.
Wir sind uns einig,
das ist das Ziel.
Ich habe hier irgendwie x-tausend Unit-Tests.
Muss nicht Perfektion sein,
sondern wahrscheinlich liegt die weit irgendwo mittendrin.
Aber es darf halt auch nicht sein,
dass ich meine ganzen Aktivitäten oben versammelt habe.
Haben wir ja schon ausführlich diskutiert, warum nicht.
Man kann das schon machen.
Hat halt Nachteile.
Genau.
Aber haben wir eigentlich schon hinreichend gut erklärt,
warum wir uns jetzt so auf diese Testpyramide versteifen
und dass sie eine Pyramidenform haben möge
und keine Eistütenform?
Ich meine, ist doch alles okay,
denn es ist halt eine Testeistüte.
Warum ist das denn jetzt wichtig,
dass das pyramidenförmig ist?
Also, ich glaube,
wir haben zumindest den ein oder anderen Aspekt schon angesprochen,
weil eben, wenn es eine Eistüte ist,
wenn wir Dinge auf oberen Ebenen, Integrationsstufen tun,
die uns teuer zu stehen kommen, länger laufen,
wir bestimmt kein Fast Feedback in jeglichem Sinne haben werden,
instabil sind.
Also, ich glaube, wir haben genügend Aspekte genannt,
warum ich das zumindest
in verteilten Architekturen für keine gute Idee halte.
Was ist dafür notwendig, um da hinzukommen?
Keine Eistüte zu haben, meinst du?
Ja, genau.
Also, wie kommt man quasi von wo auch immer man startet
zu einer guten Testpyramide?
Also, eine gute Basis,
um jetzt nicht unbedingt bei Adam und Eva anfangen zu wollen,
aber ist eine Teststrategie zu haben
und sich zu überlegen, wo machen meine Tests am meisten Sinn?
Und das muss nicht unbedingt heißen,
dass alle nach unten purzeln, die Pyramide entlang,
sondern sich tatsächlich zu überlegen,
was kann ich wo am besten testen?
Und da immer als oberste Prämisse sich vorzuführen ist,
wo kann ich mein Testobjekt am einfachsten, am besten isolieren?
Und wenn ich eine Schnittstelle habe,
und es gibt ja auch genügend Frameworks,
und ich benutze jetzt PACT,
um Consumer-Driven Contract Testing zu machen,
dann mache ich das halt da.
Wenn ich die Möglichkeit nicht habe,
dann schaue ich halt, ob ich meinen Service irgendwie
auf einer anderen Stufe isolieren kann gegen was anderes.
Also, sich zu überlegen, wo kann ich am besten isolieren?
Wo kann ich die Techniken, die es gibt, am besten anwenden?
Und da dann einfach den Test zu fahren
und das möglichst nach unten orientiert.
Aber Startpunkt, mach dir Gedanken über eine Teststrategie.
Schnapp dir deine Anwendungsarchitektur
und schneide klein von System über Produkt über Service
über Funktion über Klasse und schau, wo du das testen kannst.
Kleinschneiden ist, glaube ich, so ein Thema.
Architektur mit ins Boot holen gefällt mir.
Also, sowohl von der Dokumentation her,
als auch die Architekten gegebenenfalls
auch mal mit ins Team zu holen.
Und da dann in vier Augen, acht Augen, wie auch immer,
Gespräch ein Stück in die Tiefe zu gehen
und so isolierte Testobjekte zu bekommen.
Ist das Thema Microservices bei euch auch ein Thema?
Unbedingt. Also, Stichwort, wir wollen in die Cloud,
um das jetzt mal irgendwie so ganz profan zu nennen.
Wir haben eine sogenannte Technologieleitlinie
und die gibt mehr oder weniger
Microservice-Architektur vor.
Und deswegen ist auch unsere Pyramide
oder die Testpyramide entsprechend adaptiert worden.
Wir reden zum Beispiel von der Integrationsstufe,
die heißt Microservice.
Also, in der Anwendung zum Beispiel Frontend isoliert
von dem Backend testen zu können
oder Backend-Service 1 isoliert
von dem Backend-Service 2 testen zu können.
Also ja, ist bei uns ein Thema, ist mehr oder weniger
auch eine architekturelle zentrale Vorgabe so zu entwickeln.
Ja, dann hat man ja relativ schöne isolierte Objekte,
die man auch gut mit einfachen Schnittstellen ansprechen kann.
Wenn man die Arbeiten vorneweg,
Stichwort Domain Driven Design, die gut getan hat, ja.
Genau.
Und ich möchte noch mal kurz auf das zu sprechen kommen,
was wir vorhin gesagt haben über die Testpyramide.
Und weil nämlich schlussendlich,
um das noch mal auf den Punkt zu bringen,
wenn ich eine Test-Eistüte habe und viele großräumige Tests habe,
die, wie du sagtest, lang laufen,
die tendenziell bestimmt auch erst spät überhaupt lauffähig sind,
weil dafür einfach schon sehr, sehr viel da sein muss,
dann mache ich ja faktisch nichts anderes,
als Shift-Right.
Also genau das, was wir nicht wollen.
Ich verschiebe mein Feedback nach hinten,
sowohl wann ich das erste Mal so einen Test erfolgreich laufen lassen kann,
weil überhaupt genügend da ist, was getestet werden kann,
als auch die Dauer eines einzelnen Testlaufs,
die ja bei einem Systemtest, wenn es schlecht läuft,
auch mal ein paar Stunden betragen kann.
Das ist natürlich unglücklich.
Insofern, das ist mir ganz wichtig, da noch mal darauf rauszukommen,
warum reden wir über diese ganzen Sachen?
Warum machen wir dieses Shift-Down, wie du es nanntest?
Weil das eine Voraussetzung ist,
damit wir überhaupt ein erfolgreiches Shift-Left hinkriegen können,
dass wir also erfolgreich so früh wie möglich uns Feedback holen können
über das, was wir zu tun hier gerade im Begriff sind.
Und da sind wir jetzt auch wieder bei den Three Amigos.
Du holst dir Feedback vom Tester,
noch bevor die erste Codezeile geschrieben ist,
bevor überhaupt ein Test überhaupt Sinn machen würde,
sondern du lädst ihn direkt ein, wenn du spezifizierst.
Das ist doch die Idee dahinter.
Ja, und ein Zusatz noch, was völlig realitätsfremd wäre,
zu sagen, wir wollen überhaupt keine Tests auf oberen Stufen haben.
Ich brauche die natürlich nach wie vor.
Irgendwann will ich ja auch mal meine Anwendung in einem Geflecht,
in einem Prozess vielleicht auch testen können,
zusammen mit anderen Anwendungen,
und will sehen, wie die harmonieren, ob die konsistent sind,
ob die weichen Faktoren wie gefühlte Performance gegeben sind.
Aber das sind halt dann manuelle, explorative Tests vielleicht
und eher weniger automatisierte.
Eine Sache, die man bei der Gelegenheit vielleicht auch ansprechen muss,
ist, vergangenes Jahr war ich auf einem QS-Tag
und eine Frau hat dort einen sehr interessanten Vortrag gehalten,
in dem sie referiert hat über die Ergebnisse von einer Entwicklerumfrage.
Die war jetzt nicht besonders repräsentativ vielleicht.
Da gab es halt irgendwie Laufkundschaft.
Das wurde irgendwie, glaube ich, auch zusammen gemacht
mit High-Z-Developer und so.
Also es gab da bestimmt so eine gewisse Selbstauswahl.
Aber nichtsdestotrotz, was sie referiert hat, war unter anderem,
dass faktisch man momentan in der Industrie ein Shift-Right beobachtet.
Dass also Testen nach hinten geschoben wird.
Dass es weggeschoben wird.
Dass es irgendwie auf einmal vielleicht weniger das Problem von Entwicklern ist.
Also genau das Gegenteil dessen, worüber wir jetzt die ganze Zeit sprachen, Veit.
Wie stehst du dazu?
Hast du das auch vielleicht beobachtet in Diskussionen mit anderen?
Ist das eine Strömung, die du vielleicht wahrnimmst,
gerade wenn du jetzt neue Entwickler anheuerst?
Erzähl mal was dazu.
Also ich würde nicht so weit gehen, zu sagen,
dass das jetzt irgendwie eine Strömung ist.
Das würde ich ganz gern so Menschen wie der Kollegin überlassen,
die das da auch vorgetragen hat.
Aber ist natürlich schon zu beobachten.
Das ist das, was ich eingangs erwähnt hatte,
dass jetzt durch DevOps auch Impulse kommen,
die einen dazu verleiten, zu sagen,
na ja, gut, lass doch mal jetzt mal die schöne neue Welt rechts ausprobieren
und da vielleicht schauen, ob wir da nicht Dinge,
die wir eigentlich früher tun sollten,
in einer anderen Art und Weise einfangen, abfangen können.
Das ist halt leider ein Irrglaube.
Und von daher würde ich das so ein bisschen bestätigen wollen,
dass man das schon merken kann.
Also deswegen sagte ich ja auch,
für uns ist es Fluch und Segen zugleich,
jetzt über DevOps und dergleichen Dinge nachzudenken,
für uns jetzt in der zentralen Position, in der zentralen QM,
weil wir ja schon seit Jahr und Tag auf den Shift Left pochen.
Das ist ja jetzt nichts Neues.
Aber es wird halt noch mal ein bisschen erschwert,
wenn der Wind eher von der anderen Seite weht sozusagen,
von der rechten Seite.
Was fällt für euch alles unter Shift Right, rechte Seite rein?
Ist das nur betriebliche Themen?
Geht das auch in Richtung Security?
Geht das auch noch weiter, Governance generell?
Also ich habe da vor allem jetzt erstmal die ja schon Operations-Themen
oder auch die technologischen Themen auf dem Schirm
und auch die Monitoring-Themen oder so Sachen wie Feature-Toggling,
Can I Release, A-B-Testing.
Also die anderen Perspektiven, die du gerade noch reingebracht hast,
vor allem Governance ist natürlich auch spannend.
Da hätte ich jetzt aber gerade spontan gar keine Hinweise dazu.
Ja, aber DevSecOps ist ja ein Thema, was immer mal wieder diskutiert wird.
Wäre jetzt so ein Gedanke, wie kriegt man nicht nur funktionale
und vielleicht nicht funktionale Themen getestet,
so automatisiert, dass man sie halt recht früh auch im Prozess
regelmäßig nachtesten, Regression und Co. im Griff hat,
sondern dass man halt auch Security-Tests,
die vielleicht im Nachgang irgendwo Pentests,
vielleicht auch in Richtung statischer Analyse von Komponenten
und Vulnerability-Tests in die Continuous-Delivery-Pipelines mit reinzieht
und so halt auch in Richtung Links bewegen kann.
Es ist ganz interessant, dass du jetzt vor allem Stichwort
Vulnerabilities und statische Code-Analyse ansprichst,
weil deswegen bin ich gar nicht auf dich angesprungen,
weil wir das tatsächlich in der Dativ auch schon haben.
Also das ist ja auch ein Thema.
Also da laufen Dinge wie Widesource oder Fortify in,
jetzt bei uns der Jenkins-Pipeline, automatisiert mit.
Stichwort Penetrationstests, ja, das scheint mir immer,
da scheint noch irgendwie ein Stück weit Weg zu sein,
die zu automatisieren und das ist doch meistens immer noch
großer manueller Aufwand, soweit ich das beobachten kann.
Aber ja, macht das natürlich Sinn, das auch irgendwie links zu etablieren.
Das ist ja der Punkt, dass man sich mal so ein bisschen austauschen
und kennenlernt auch in so einer Folge
und die Gedanken mit Stichworten alleine vielleicht nicht reichen,
sondern Beispiele, die ganz hilfreich sind, finde ich auch so.
Wir hatten ja gerade auch so ein bisschen darüber philosophiert,
warum das irgendwie alles so in Richtung Tools zu gehen scheint
und in Richtung eben der rechten Seite dieser linken Acht.
Und meine persönliche Vermutung ist dann an dieser Stelle auch immer,
dass so Technologie halt irgendwie vergleichsweise harmlos ist.
Die tut ja keinem weh, so ein Jenkins, der ist gleich installiert,
da muss keiner an sich selbst zweifeln oder seine Herangehensweisen ändern
oder seine Verhaltensweisen ändern.
Sondern das kann man einfach mal machen.
Aber der wirkliche Wert, glaube ich, kommt eben genau aus den Dingen,
die viel weiter links passieren, nämlich da, wo Leute miteinander interagieren,
wo man gemeinsam versucht, überhaupt zu verstehen,
was das Produkt ist, das man da bauen sollte.
Und wenn man das gut macht, dann ist der aktive Schritt
des irgendwie geschweiften Klammern-Tippens und so,
meine Güte, das ist ja dann gemessen daran gar nicht mehr so wild.
Insofern gefiel mir das, was wir hier auch in unseren Notizen drinstehen haben,
einer Prozess-QS, dass man schauen soll, dass Qualität nicht nur daraus erwächst,
dass ich jetzt, keine Ahnung, halt eine Testsuite laufen lasse,
sondern dass da eine Vielzahl von ineinandergreifenden Aktivitäten stattfinden müssen,
als eine ganze Kette, als Resultat, der dann etwas hochqualitatives hinten rausfällt.
Und als ganz wichtiger Aspekt von dem, was du jetzt gerade gesagt hast,
um das noch zu ergänzen, bei uns gibt es immer das geflügelte Wort,
wir müssen mal zum Äußersten gehen und miteinander reden.
Am Ende ist es genau immer das, das kann dir kein Tool abnehmen,
das kann dir keine Vorgehensweise abnehmen.
Du kannst dir mit so Dingen wie einem 3-Amigo-Gespräch zumindest die Rahmenbedingungen schaffen,
dass man auch zusammenkommt, um miteinander reden zu können,
wenn man es anders nicht schafft. Aber darauf kommt es am Ende an.
Und darauf kommt es noch mehr an, wenn Dev und Ops,
wenn die unterschiedlichen Menschen, Prozesse, Kollegen zusammenwachsen sollen,
ja, Herrgott, dann müssen wir reden miteinander.
Und dann sollten wir es möglichst oft und viel tun.
Und ein Tool, ja, da bin ich bei dir, das ist dann am Ende auch schnell eingekauft,
wenn der Geldbeutel groß genug ist.
Ja, wie kriegt ihr dieses Reden hin zwischen Dev und Ops?
Werden da echt Teams zusammengewürfelt, die dann halt vorher einzelne Teams waren?
Werden die Teams dann nicht zu groß?
Oder wie geht ihr mit solchen Themen um wie Bereitschaft, Port und Co.?
Ja, das ist natürlich eine gute Frage, die ich so im Detail gar nicht wirklich beantworten kann,
weil ich da dann doch ein Stück weit zu weit weg bin.
Ich weiß, es ist noch nicht Teams oder die Anzahl der Produkte und die Anzahl der Teams, die wir haben,
da sind wahrscheinlich die wenigsten wirklich als DevOps-Team unterwegs.
Das sind jetzt Dinge, die erst erwachsen müssen, mit denen man sich genau,
das sind genau die Herausforderungen, die du beschreibst.
Kann man einfach die Leute zusammenwerfen und dann ist das plötzlich ein neues Team?
Was kauft man sich ein mit Operations? Stichwort Rufbereitschaft und solche Themen.
Das zieht ja noch viel weitere Kreise.
Stichwort irgendwie Betriebsrat und Arbeitszeitvereinbarung und Sonstiges.
Das sind alles Dinge, die besprochen, die diskutiert werden müssen, die jetzt gerade erst entstehen.
Also wird spannend sein, das zu verfolgen.
Am Ende, um es mir da auch ein bisschen leicht zu machen, schreibt man gerne überall drüber,
Whole Team Quality und die betrifft dann natürlich Menschen, die sich eher im Ops zurechtfinden,
genauso wie Menschen, die eher im Dev-Bereich sind.
Aber natürlich ist, das wissen wir ja auch, Größe von arbeitsfähigen Teams auch begrenzt.
Man muss schon schauen, wie man das gut hinbekommt.
Ich sehe das schon kommen, Veit.
Wir müssen dich noch mal zu einer Architektur-Folge einladen,
wo wir diese Themen dann en Detail diskutieren können.
Oh, ich will aber nicht in fremden Gewässern fischen.
Aber können wir uns gerne überlegen, ja.
Ja, oder bringst halt einen Architekten mit. Ist ja auch okay.
Oder das, genau.
Ja, noch einfacher.
Sehr schön.
Veit, was haben wir vergessen?
Was musst du ganz dringend den Hörerinnen und Hörern noch mitteilen?
Oh, das ist natürlich sehr überraschend.
Jetzt muss ich gerade mal rekapitulieren.
Eigentlich haben wir tatsächlich nichts vergessen.
Das kannst du ja alles dann schneiden.
Aber vielleicht kann man einfach …
Also, wenn du mich fragst, was wir vergessen haben.
Wir haben eigentlich nichts vergessen.
Wir können aber eine Aussage vielleicht noch mal ganz dick unterstreichen,
die wir auch schon am Anfang propagiert haben.
Nicht unbedingt, dass DevOps links beginnt.
Aber vielleicht, dass …
Und ich will auch nicht so weit …
Na gut, vielleicht streise ich das noch mal.
Weil ich weiß aus unserem Vorgespräch, dass du gesagt hast,
hier geht es nicht darum, das irgendwie in Balance zu halten,
sondern wir müssen links erst richtig machen, damit rechts auch funktioniert.
Ja, das habe ich gesagt.
Aber ich glaube, was du immer wieder mal propagiert hast,
da bin ich auch sehr mit dabei.
Nämlich, man muss es einfach überall machen.
Es gibt niemanden, der sich da zurücklehnen kann und sagen kann,
nicht mein Problem.
Ja, sonst funktioniert Whole-Team-Quality nicht.
Wenn sich ein Teil der Acht irgendwo rausnimmt,
ob das in der Anforderung, ob das in der Entwicklung,
ob das im Betrieb ist, ob das Support oder sonst wo steht,
jeder hat einen Beitrag dazu zu leisten,
damit Qualität wirklich Ende-zu-Ende funktioniert.
Und deswegen gibt es, glaube ich, auch in dem Training,
was du vorhin erwähnt hattest, so eine schöne Folie,
liegende Acht und dann Test hier, Test hier, Test hier.
Und zwar an allen Stellen von der Acht, ringsherum.
So ähnlich ist es halt, wenn Qualität funktionieren soll.
Das ist übrigens hochinteressant,
weil ich glaube, so ähnlich, so eine Folie,
die gibt es auch bei uns, ja.
Also von daher …
Ja.
Also von daher volle Zustimmung.
Ja, dann …
Sehr schön.
Haben wir es, glaube ich, oder?
Ich glaube auch.
Ich glaube, das wird eine ganz tolle Folge
oder ist eine ganz tolle Folge geworden.
Veit, vielen Dank, dass du da warst.
Danke, dass ich da sein durfte.

Folge 71: Isaac Perez on Infrastructure Strategy [EN]

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Luca and Falko are joined by Isaac Perez, Head of Infrastructure at Fresha.

They discuss how to put together a strategy for the ever expanding responsibilities of devops/platform/infrastructure and all the areas that can fall under.

Questions discussed include the following:

  • What does the evolution of a traditional Infra / DevOps team to a modern one look like?
  • How do you show business impact of invisible work?
  • How do you modernise your strategy with old people?
  • How do you actively plan for the future, instead of being ambushed by it?

In this episode, Isaac Perez, head of infrastructure at Fresha, delves into the intricacies of creating and implementing an infrastructure strategy within the DevOps framework. He highlights the evolution from traditional operations to an agile, user-centric approach that aligns with modern software development practices. Perez underscores the significance of considering both technology and business objectives, while also focusing on improving developer experiences and service stability. He shares insights on enabling teams, dealing with distractions, and optimizing infrastructure decisions to support business growth and efficiency.

Inhalt

  • Introduction of Isaac Perez and his role at Fresha
  • The evolving role of infrastructure in DevOps
  • The significance of infrastructure strategy
  • The shift from traditional operations to agile methodologies
  • Integrating developer experiences with operational efficiency
  • The impact of infrastructure decisions on business outcomes
  • Challenges in balancing technology advancements and business needs
  • Role of microservices and platform stability in business growth
  • The importance of enabling teams and handling distractions
  • Infrastructure strategy’s influence on organizational structure
  • Recommendations for creating an effective infrastructure strategy
  • The role of microfeedback loops and efficiency in DevOps

Shownotes

Isaac’s Medium posts
Isaac’s LinkedIn

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Welcome to a new episode of DevOps auf die Ohren und ins Hirn.
Or in English, DevOps from your ears straight to your brain.
Usually this is a German language podcast, but we sometimes make exceptions for international guests.
Today is one such exception.
My name is Luca Ingianni and I host this podcast together with my colleagues Dirk Sölner and Falco Werner.
We’re DevOps consultants, trainers and coaches trying to get teams to work together better and create better products for their customers.
And today we are joined by a very wonderful guest, Isaac Perez, the head of infrastructure at Fresha.
Isaac, very welcome to the show.
Thank you. Thank you for having me, Luca and Falco.
Tell us a little bit about yourself, Isaac. What do you do for a living?
I lead the infrastructure teams at Fresha, which is a beauty and wellness platform.
It’s actually two-sided. We have the marketplace where you can book your appointment in a hair salon or nails or a massage or spa.
And we have the business management platform that allow those businesses to do everything that they need to run their business,
manage the rotation of the staff, sell products, marketing campaigns, book appointments, take payments.
And anything that you need, really.
The main areas of the teams that I lead, which are part of the platform organization, are focused on cloud infrastructure.
So traditional, where you run your workloads for us, AWS and EKS mainly.
And the other parts are deployment pipelines and developer experience.
So how we can get that software development cycle shorter and have a better user experience.
My background is in systems administration, data center operations, then DevOps, then platforms.
So it’s kind of the evolution of the space as it went through the years.
Yes. And the topic that we have picked for today is infrastructure strategy, isn’t it?
Yes.
So this is something that I’m very curious about.
How to sort of deliberately create a strategy to evolve your infrastructure and the people operating it,
as opposed to being…
Stuck in a reactive mode and sort of trying to muddle through.
Okay. But before we dive into the topic, we have a tradition on this podcast for every guest to give us their definition of DevOps.
So, Isaac, what’s your definition?
That’s an interesting one, because it seems that everyone has a different definition and a different implementation.
To me, I started seeing it from one point, which was bringing…
Software development practices to operations teams.
Traditionally, operations teams were at most scripting and not necessarily like having a software lifecycle for their tooling,
like not treating their services, their outputs as a real service where you have to test it, deploy it.
So that was the initial part.
But then I realized that it has another component, which is before, like many years ago,
like development teams would throw things over the wall, as we say, and operations teams would have to run and deploy the changes or the new features that the software delivery teams did.
But that was the usual complaint.
But I also realized that operations teams used to do the same.
So we used to build a tool, whatever we wanted, and then tell all developers, now you use this.
Like, we don’t care what you think.
We don’t care about the user experience.
You’re just going to use it.
And that caused frictions.
Both ways.
So I think DevOps is bringing two walls closer together in the sense that operations do more software development, more agile and more user experience.
But at the same time, development teams also learn how to run their services.
They own them now.
In theory, they own them or they should own them.
They got better at productionizing those services and maintaining them and making them operationally excellent.
Which was not something that software product teams were good at or were not good.
Like, it was not one of the goals for them.
It was just ship features.
And now it seems that both walls got a bit of each other.
And to me, that’s a better outcome than the silos.
Okay.
And where is testing in this?
That’s a good question.
To me, testing, I see it as kind of a platform offering.
So the platform team.
The team should provide the tools to do testing, like tooling services, like build a framework and the software teams should do the testing because they know that their software better.
So I think they should be able to run, create better tests and it goes earlier in the in the cycle, but with that with some help because the testing mentality is a bit different from software mentality when they test a lot.
Think about edge cases and load.
And all that, but I still think it’s better if most of the testing happens early in the cycle like TDD and done by software engineers with the help of some either coaching and tooling and platform services provided by really real experts also doesn’t scale if it’s not distributed.
You cannot have like one tester or one QA or a team that ends being the bottleneck for everything that’s deployed that reduces.
You cannot have one tester or one QA or a team that ends being the bottleneck for everything that’s deployed that reduces.
Makes the deployment times or recycle time much, much longer.
After operations, is there something that you need to consider in the value stream that’s after the operations teams or the infrastructure?
That’s a good question.
I would say the product team, right?
After that, you need to ensure that the features that you deliver.
Well, there’s two dimensions.
One is that the features actually produced an outcome from the business that they’re not, I don’t know, we just shipped a feature, doesn’t provide anything.
And then that you can continuously maintain and evolve that feature.
So one would be more technical in the terms of like, can we maintain, can we evolve this feature?
Do we have the metrics to know from an operational point of view that’s working well?
But also do we have the metrics to know that from a business point of view, it’s working well, it’s worth it?
Is it worth the cost?
How’s your connection to the customer then?
My connection to the customer, it depends.
These are another interesting question because usually I have a very personal distinction between users and customers.
To me, in the platform world where I sit in infrastructure or DevOps or platform, users are usually software engineers.
Who use the tools that we build.
But they’re not our customers because they don’t pay our salaries.
Our customers are the end customers that buy the products that the company sell.
And at the end of the day, those are the important ones.
So our users or software engineers are just a proxy to reach the customers.
Sometimes, most times, they both align.
So we create better pipelines, better developer experience, so we can get more features out and more stable features out to the customers.
But sometimes we may do some security work that actually hinders a bit the developers, but it’s to protect the customers.
Maybe we do some high availability work that hinders the developers, but protects the customers.
So at the end of the day, the customers, the ones who pay, are the ones we serve.
And most of the time we do it through our users who are the software engineers.
All right.
So maybe now is a good time to switch gears.
And I’m going to ask you a question.
And take a step back and set the stage for what we want to talk about, which is infrastructure strategy, right?
Why do we need that?
And did we have that before?
And what does it look like?
What did it look like?
I mean, you spoke in the introduction a bit about this separation between dev and ops, you know, the famous wall of confusion.
Was that part of a strategy or was that just an accident?
That probably was a result of the environment.
I wouldn’t call it an environment.
I wouldn’t call it an accident or a strategy.
I’m pretty sure it was not part of a strategy, because when you think about it, it seems a pretty bad strategy to have.
It’s like, let’s get operations and developers not talking to each other so they cannot work together and we release worse features less often.
So that as a strategy seems something no one will come out with.
But that was the result.
So I think it was a product of the time where Agile was.
It was probably still coming.
Well, it didn’t even exist before.
It was very waterfall of planning and you had two different sections and they have their different waterfall processes and Agile started catching up, but operations was behind.
So I think that the strategy was always there.
It just didn’t caught up with the times or with the modern practices and people at the strategic level were not thinking, updating.
They were not thinking, updating.
They were not thinking, updating.
There’s a way of thinking about the strategy, a way of thinking about technology or engineering in a modern way.
They were just the old waterfall process.
This is my turf.
This is your turf.
Don’t touch it.
We’ll talk at the end kind of thing.
And I think it makes sense from the point of view that strategies are usually created by senior people who most of the time are older and they’re setting their ways.
Well, I’m saying that I’m not that young, but I think that because they were created by an older generation, it took some time until the new generation who were more in Agile and had a more open mind, at least to that point, started creating the strategies themselves and they realized, okay, this doesn’t make sense.
We’re going to get better outcomes if we work together and then started being part of the new class of strategies, if you want, of the new strategies that were being created.
Okay, so now we do need a strategy.
What is, what’s the point of this strategy?
What are the cornerstones of the strategy?
What does the strategy aim at versus what maybe does it explicitly say, this is out of scope for me?
Yeah, that’s the always problematic point when you start a strategy, like what do you want the strategy to do?
What is the strategy for?
And I think this is where…
Most, not most, but hard for business leaders or like engineering leaders, especially in infrastructure, you’re quite removed from the business and sometimes we forget about the business part and we’re just like, we need to use Kubernetes or we need to use like, and really no one cares if you use Kubernetes or not.
Like you think like they have salons care if we run in AWS and Kubernetes, no, they don’t.
They care about the reliability of the product, how fast the features are.
Arriving at their terminals, at their like fonts.
So the strategy should really understand what is the problem we’re going to solve for the business.
It can be a technological problem, but it has to help the business.
And where was the environment?
So I would not do, and I certainly did different strategy in smaller startups than a scale up like Fresha.
They’re different than bigger companies they work for like Thomson Reuters, we have like 5,000 people in the…
Business unit that I was working in.
And so the strategy not only has to take into account the problems that you want to solve for the business, not for technology itself, but also the environment where it works.
Not the same is a highly regulated industry.
It is not.
It’s like it doesn’t matter if you lose the data for like one hour.
It’s like those kind of things should guide the strategy too.
Okay.
So what is the point of the strategy?
What is the goal of such a strategy?
Or what happens if you don’t have such a strategy?
So, okay, those two different, let me see if I can split them.
The goal of the strategy, it has to be to help the business reach its goals.
So let’s say that you’re in growth mode, like hyper growth mode, and you need more users per month, more active users per month, which is usually like a common goal for growth companies.
Then how do you get those users?
And do…
How do you get and how do you lose these users?
Something I like from system thinking is when you have a stock, you can fill…
Let’s say you have a bathtub, you fill water and you have the drain.
So you can fill the bathtub, you can put more water faster than it drains or stop the drain.
So when you have more active users, I say you want more active users, you get new users, but users leave.
And more users, let’s say that you need more features.
And users leaving is because the platform is not stable.
So they get frustrated and they leave.
And simple examples.
And what we can do as a strategy from infrastructure in that sense will be less work on having deployments to production faster or short and feedback loops for developers.
Those two common things that are usually painful and people always want deployment from, you could make a change to it’s running in production faster.
So you could work on that or you could say, actually we’re losing lots of users because the platform is not stable.
Because the platform is not stable.
Die Plattform ist wirklich unstabil und wir müssen ein paar Arbeiten machen, um die Kette zu stabilisieren.
Und das ist wichtiger, als mehr Features zu haben.
Wir können sagen, eine kurze Strategie, um die Stabilität zu fixieren, damit wir die User nicht verlieren.
Und eine langfristige Strategie, wir wollen mehr Features erstellen.
Die Stabilität ist auf einem guten Niveau.
Okay, aber das klingt immer noch wie eine Produktstrategie, nicht so viel wie eine Infrastrukturstrategie, richtig?
Ja, aber die lustige Sache ist, dass wir die Infrastruktur als Produkt behandeln sollten.
Wir sollten es nicht selbst machen.
Zumindest glaube ich das.
Unsere Infrastrukturstrategie sollte nicht so anders sein wie die Produktstrategie.
Was sich ändert, ist, wie wir sie implementieren.
Zum Beispiel könnte eine Produktstrategie sein, dass wir diese neue Feature eröffnen,
die euch ermöglicht, Abonnenten zu buchen,
ich weiß nicht,
von eurem Handy.
Weil wir das vorher nicht gemacht haben, was auf der Website war.
Und von der Infrastrukturstrategie her könnten wir sagen,
wir müssen eine Deploying Pipeline für Mobiltelefone erstellen,
weil wir keine vorher hatten.
Und es hat drei Tage oder fünf Tage gedauert, um zu bauen, zu kompilen, zu publizieren und alles.
Also unsere Strategie für die Infrastruktur wird das Geschäftsziel in einer anderen Weise unterstützen.
Und vielleicht ist es, um euch ein Beispiel zu geben, ein bisschen mehr Infrastruktur.
Und ein Projekt, das wir momentan arbeiten, ist das Migration von Jenkins und anderen
Arbeitsplattformen zu Argo Workflows.
Warum denken wir, dass das wichtig ist?
Ich denke, weil sie diese zwei Bereiche entwickeln, mehr Dimensionen zu diesem.
Aber zwei wichtige sind die Entwicklungserfahrung und die Entwicklungserfahrung.
Also die Erfahrung, die die Entwickler haben,
und die Entwicklung der Deploying Pipelines,
mit denen wir denken, dass es in Argo Workflows viel besser werden wird.
Und unsere eigene Erfahrung in der Entwicklung der Pipelines,
die viel, viel schneller werden wird als in Jenkins,
weil es viel einfacher zu arbeiten ist, es ist einfacher zu testen und so weiter.
Also die Art und Weise, wie wir die Geschäftsstrategie halten,
wäre langfristig, wir migrieren zu einem Cloud Native Workflow Engine,
das kosteneffektiv sein wird,
viel schneller zu arbeiten,
und viel schneller zu entwickeln.
Aber das klingt immer noch reaktiv für mich, richtig?
Du hörst auf die Anmerkungen der Entwickler, was eine gute Sache ist,
nicht wahr?
Aber es ist nicht proaktiv, ist es nicht?
Du wirst nur warten, bis du die meisten Anmerkungen bekommst,
und dann gehst du und fixierst es.
Ja, ja und nein.
Wir, zum Beispiel, können,
wenn du nur die Anmerkungen hörst,
hast du Jenkins fixiert.
In diesem Fall zum Beispiel.
Aber ich denke, die Strategie kommt dazu,
das Problem zu sehen,
dass es bessere Deployment Pipelines gibt,
und dann zu denken, okay,
wir gehen zu Cloud Native Tooling,
oder wir gehen immer noch zu Cloud Native Tooling.
Jenkins, zum Beispiel, ist zwei Generationen alt,
wir wollen etwas, das Cloud Native ist,
für diese Gründe,
was kosteneffektiv ist,
einfach zu arbeiten,
einfach zu unterstützen,
weil wir bereits viel Erfahrung in Kubernetes haben,
und das funktioniert in Kubernetes,
also denke ich, es ist ein bisschen mehr,
es ist das Hören zu diesen Anmerkungen,
aber auch gleichzeitig,
du wirst deine Plattform weiterentwickeln,
in Richtung eines Zukunfts,
das sich mehr mit,
also du wirst die Plattform weiterentwickeln,
in Richtung einer flexibleren und nachhaltigeren Lösung,
die dir ermöglicht,
in der Zukunft schneller zu gehen.
Also vielleicht fragst du dich,
etwas, das wir gemacht haben,
ohne zu hören,
zu User Complaints zu Beginn.
Und das ist,
ich habe noch ein anderes Beispiel,
wir haben begonnen, Backstage zu nutzen.
Was ist Backstage?
Ich habe das noch nie gehört.
Okay, das ist eine interne Entwicklungsplattform.
Es wurde intern geschaffen,
Spotify hat es geschaffen,
sie haben es open source gemacht,
und es ist irgendwie das Standard,
open source,
eine interne Entwicklungsplattform.
Und wir haben mit Kit angefangen,
weil wir wussten,
wir haben einige Schmerzpunkte,
wie z.B.
finden Sie Ihre Services.
Wir haben begonnen,
mit Microservices zu migrieren,
und jetzt haben wir etwa 80
zwischen Monolith und Microservices.
Und es ist sehr schwierig,
eine neue zu erstellen.
Und es ist sehr schwierig,
die Services zu finden,
die sie besitzen.
Wir haben Splitsheets,
und du musst durch den Code gehen.
Also Backstage hat das Problem gelöst,
plus es ist ein weiteres Tool,
das, sobald wir einen Fuß in das Tool haben,
es wird uns ermöglichen,
viel mehr Sichtbarkeit und Fähigkeiten zu bieten.
Und das kam,
teilweise aus Schmerzen von Entwicklern,
aber es war okay,
wir sehen,
interne Entwicklungsplattformen
werden in der Zukunft wichtig sein,
also wollen wir in sie investieren.
Und wir haben mit Kit angefangen.
Und das ist eine Art Stepping Stone
zu einer Plattform-Team,
einer Plattform-Organisation,
anstatt der traditionellen Infrastruktur,
wo wir etwas bauen und es nutzen.
Interessant, ja, danke.
Das war ein sehr gutes Beispiel.
Aber es bringt mich zu etwas anderes,
was mich bedroht hat,
nämlich dass du selbst gesagt hast,
dass die Beauticianen
oder jeder, der deine Plattform nutzt,
nicht wirklich interessiert,
ob du Backstage oder Kubernetes
oder irgendwelche dieser lustigen Dinge nutztest.
Also, ich meine,
und ich stimme dazu,
dass dies wahrscheinlich wertvoll ist,
aber wie kannst du Business-Impact zeigen?
Wie kannst du Wert für solch unbeleuchtetes Werk zeigen?
Ja, das ist ein guter Punkt.
Und es kommt alles zu,
aus meiner Sicht,
Metriken,
über die das Unternehmen sich interessiert.
Also z.B. für Backstage
eine der Metriken,
die wir verbessern wollen,
ist Onboarding.
Also sagen wir,
dass du 50 Entwickler im Jahr hast
und anstatt Onboarding,
hast du für 4 Wochen
mehr als für 2 Wochen,
weil sie alle Dokumentationen finden.
Das sind 50 pro 2 Wochen,
du bekommst 100 Wochen Produktivität pro Jahr.
Also das ist sehr einfach
für das Unternehmen zu zeigen,
wie wir 100 Wochen Produktivität
zum Ingenieur-Team hinbekommen.
Und das Gleiche
mit täglichen Aufgaben.
Es ist nicht so einfach,
nicht so einfach zu sagen,
wir bekommen etwa 2 Tage mehr
oder so etwas wie das,
aber wir können Metriken haben,
z.B. wenn es User-Surveys sind.
Wie lange dauert es,
um einen Service zu finden,
mit dem du arbeiten musst?
Die Dokumentation,
die Anwohner.
Also vorher
dauerte es vielleicht ein paar Stunden,
bevor du an einem Ticket startest.
Jetzt dauert es 5 Minuten.
Also das sind die Metriken,
die du nutzen kannst,
um Impakt zu zeigen.
Und im Backstage
sind die meisten Metriken
zu dem,
wie lange es dauert,
um etwas für einen Entwickler zu machen,
als jetzt.
Ein weiteres gutes Beispiel ist,
dass wir uns in Richtung
der Migration
zu Microservices
und der Extraktion
des Monoliths
bewegen.
Das ist ein sehr neues Problem,
das noch niemand
vorher hatte.
Und das war eine Lüge.
Ich dachte,
ihr würdet…
Keine Ahnung.
Also,
es ist nicht einfach,
einen neuen Service zu erstellen,
ohne das Tool zu haben.
Aber das erste,
was wir mit Backstage gemacht haben,
war,
Service-Template zu nutzen,
also,
ihr klickt
und bevor es euch 2 Wochen dauerte,
um einen neuen Service zu erstellen,
im Allgemeinen.
Jetzt dauert es,
ich denke,
jetzt sind es ein paar Stunden.
Es ist nicht
Zero-Zeit,
aber
ihr ging von 2 Wochen,
also,
sagen wir,
ihr plant
diese neue Feature,
wir brauchen
einen neuen Service,
denn wir wollen
zu Microservices
migrieren
und das hat andere Vorteile.
Wir planen
4 Wochen
oder 6 Wochen,
weil die ersten 2
mussten wir
nicht haben,
den Service.
Und jetzt
sind diese 2 Wochen
weg.
Ja,
wir werden es machen.
Es sind nur 2 Stunden,
also müssen wir nicht
so viel für es zahlen.
Also,
ihr verringert
die Migration
aus
der Monolith,
was
alle
Kaskadeneffekte
oder
schnelleres Entwicklung
bringt.
Aber ihr entfernt
essentiell 2 Wochen Arbeit,
jedes Mal,
dass ihr das macht.
Und ich denke,
das sind die Metriken,
die das Unternehmen
interessiert.
Und
sie sind,
sie sind super cool.
Du musst ihnen sagen,
schau,
es hat 2 Wochen gedauert,
um ein Service zu schaffen,
jetzt dauert es 2 Stunden.
Und vielleicht in einem Monat,
wenn wir mehr investieren wollen,
dauert es 0.
Weil alles
automatisiert wird.
Nicht nur das,
der Service kommt
mit
90% Produktion,
was wir als
Produktion bereit
bezeichnen,
das ist
ein weiteres Monat Arbeit,
das die Entwickler
tun müssen.
Das bringt mich
zu einem interessanten
Frage,
das ich
während
deiner Rede
beantwortet habe,
dass es
so eine Strategie
Formulierung
gibt,
wie würde es Teil
deiner Strategie sein,
zu sagen,
wir werden
zurückgebracht
oder wird
die Strategie Formulation
auf einem hohen Niveau sein,
wo wir sagen,
oh,
wir müssen
Wege finden,
um den Zeitraum
für einen neuen Service
zu reduzieren,
oder so etwas.
Ja,
ich würde nicht
die Technologien
selbst in
der Strategie
inkludieren.
Und das ist etwas,
über das ich
auch darüber
nachgedacht habe,
dass es
eine Strategie
für dieses Jahr
gibt.
Und du sagst,
oh,
wir brauchen eine
internen
Entwicklungsplattform,
weil das
diese und diese
Probleme
lösen wird.
Und für
irgendeinen Grund
startest du
im Januar,
du startest
im Juni.
Ich würde nicht
meinen Namen
in einer Technologie
in diesem
Kutting Edge
im Januar
sein,
wie es
im Juni
sein wird.
Ich denke,
die Technologien
sollten da sein.
Du solltest entscheiden,
welcher Cloud Provider,
wie du sie benutzt
wirst.
Für diesen
muss die Technologie
da sein.
Für Strategien
von
wir werden
die Entwicklungserfahrung
verbessern
bis zum Ende
des Jahres,
was wir
tun wollen,
und Teil davon
ist,
dass wir
besser mit
den Ideen
integrieren wollen.
Ich würde nicht sagen,
dass wir
von Tag 0
mit Visual Studio
oder VS Code
integrieren wollen.
Ich würde sagen,
wir wollen besser
mit Ideen
integrieren.
Wir werden eine Phase
der Forschung
machen,
welche die
am meisten
genutzt
und gut
erhoben sind.
Und dann
entscheiden wir.
Das Wichtigste
für diese Strategie ist,
besser mit
der Idee
zu integrieren,
nicht mit welcher Idee.
Für große
Migrationen,
wenn du
von MySQL
nach Postgres
migrieren willst,
musst du
dich
in der
Art
der
Idee
konzentrieren.
Und dann
kannst du
die
Idee
mit
den
Ideen
integrieren.
Und wenn
du
die
Idee
mit
den
Ideen
integrieren,
dann
kannst
du
das
mit
den
Wettbewerben
machen.
Wenn du
eine
Entscheidung
hast, die
einen
Loch unter
der
Wetterlinie
machen wird,
brauchst du
eine gute
Entscheidung.
Wenn sie
über der
Wetterlinie
ist,
ist es
okay,
du
wachst.
Für
kleinere
Entscheidungen
weniger
Einwohnung
von
den
Wettbewerben.
Und
ich war
involviert
als Teil
von
der
Leadership
Level.
Ich habe nur
einige
Bedingungen
gesetzt.
Zum Beispiel
wollte ich
Cloud Native
sein,
damit wir
die Kosten
später
optimieren können.
Wir wollen
es in
Kubernetes
runten,
weil wir
die Kosten
optimieren.
Es ist
eine
gute
Entscheidung,
die
wir
haben.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die Kosten
und die
Kosten
en
nicht
übertragen
.
Das
sollte
bei
Kubernetes
auch
sehr
tätig
sein .
Aber
an
VP oder
CTO
Niveau,
es wird
constituiert, es wird
wie du in der Zukunft funktionierst, in einer großen Art und Weise.
Aber einige Tools, wie Backstage und all das,
aber das Problem ist, dass es nicht so viele Optionen gibt für Backstage,
das ist der einzige, der die Entscheidung für dich gemacht hat.
Aber wenn es zwei oder drei Contestants gäbe,
denke ich, dass das mehr eine Konversation sein könnte.
Okay, aber das bedeutet in der Regel,
dass auch wenn du nur Entscheidungen über die Wasserline delegierst,
das noch viel Verantwortung auf individuelle Teams aufbaut, nicht wahr?
Was geht es darum, Teams zu ermöglichen,
diese Verantwortung effektiv und sicher zu nehmen?
Es gibt zwei Wege, um über diese Liste zu denken.
Eine oder mehrere Dimensionen.
Eine ist, dass man sicherstellt, dass es ein sicheres Umfeld gibt,
wo Leute Fehler machen können und wir von ihnen lernen.
Also wirst du nicht öffentlich für Fehler verurteilt,
aber du arbeitest mit.
Du arbeitest mit ihnen, um sicherzustellen,
dass wir lernen, dass jeder von der Entscheidung lernt.
Und es hängt auch vom Niveau der Kompetenz ab.
Wenn du delegierst, delegierst du nicht das Gleiche für alle Individuen.
Einige Individuen haben viel bessere, andere Fähigkeiten als andere,
sodass du einige Taschen delegieren kannst.
Du musst also beachten, dass die Teams die Fähigkeiten,
die Wissen und die Erfahrung haben, um diese Entscheidungen zu machen.
Du kannst sie trainieren, hiren oder trainieren,
coachen sie, um auf dem Niveau zu kommen, um diese Entscheidung zu machen.
Dann geht es so, als wäre es auf der Wasserlinie.
Aber du musst auch sicher sein, dass es als eine Gelegenheit ist, zu lernen.
Nicht, wenn du das nicht richtig machst, dann werde ich dich verletzen.
Ja, niemand wird Entscheidungen machen oder endet alle mit Kaibm.
Das ist der alte, berühmte Quote.
Niemand wird verletzt, wenn man Kaibm wählt.
Also musst du ein bisschen experimentieren.
Und sicher sein, dass es okay ist, wir haben einen Fehler gemacht, wir lernen davon.
Also klingt es so, als ob das auch Teil deiner Strategie sein sollte,
diese Art von Kultur zu bauen, die Teams in Bezug auf, ich weiß nicht,
Fähigkeiten und Organisationen zu ermöglichen.
Würde das nicht richtig sein?
Ja, ich denke, das ist richtig.
Du planst die Strategie, du nimmst all diese Komponenten.
Und ich denke, dass, jetzt, dass du es erwähnt hast, es in den Umfeld kommt,
was du die Strategie für machst, denn wenn du die Strategie machst,
machst du es, um ein paar Probleme zu lösen, aber du hast die Grenzen des Umfeldes,
für das du eine Strategie bauen kannst.
Und diese Teil des Umfeldes ermöglicht Teams,
Entscheidungen zu machen, wenn das die Strategie ist, die sie folgen wollen.
Vielleicht willst du diese Strategie nicht folgen wollen.
Du bist wie ein Top-Down-Approach, der in einigen Umständen funktioniert,
oder unter einigen Umständen.
Aber ja, Teil der Strategie zu machen, ist wie, wir werden diese Entscheidung handhaben,
weil wir sie ermöglichen wollen, und sie werden mehr engagiert, wenn wir das machen.
Also ist es definitiv Teil der Strategie.
Gibt es gemeinsame beste Praktiken für Infrastrukturstrategien,
um sich davon zu erinnern, oder in irgendeiner Art und Weise
kann man einige Ideen verkaufen und nicht von Anfang an anfangen,
oder von einer Art und Weise auszutauschen, basierend auf dem, was funktioniert und was nicht funktioniert?
Denn Strategie ist meistens eine langfristige Sache, die man sich umsetzen kann.
Also ist es wahrscheinlich gut, einen Startpunkt zu haben.
Ja, ich denke, es gibt definitiv beste Praktiken,
wo es jetzt ein bisschen eine schlechte Reputation gibt,
für irgendeinen Grund, aber sie sind beste Praktiken, die ich denke,
du kannst anfangen, sie zu bekommen, du kannst dir helfen, deine Strategie zu orientieren.
Lass uns sagen,
ich bin nicht mehr mit AWS kennengelernt, das ist die einzige Cloud, die ich professionell benutze,
aber du hast AWS beste Praktiken und CIS, das Center for Internet Security Benchmarks.
Also du könntest sagen,
wir, ich meine, ich glaube nicht, dass jemand sagen würde,
wir wollen unsere Plattform weniger sicher machen.
Aber lass uns sagen, dass du sagst, okay, Teil der Strategie dieses Jahres ist,
dass wir versuchen müssen, dass die Plattform sicher ist.
Und das ist irgendwie
unheimlich.
Es ist nicht der Sinn, es zu sagen, aber was ist die Strategie?
Also du könntest sagen, wir werden CIS Benchmarks für AWS benutzen
und wir werden AWS beste Praktiken und die White Papers benutzen, die sie haben.
Und das wird dir die Strategie helfen.
Ich denke, das Problem ist, dass es keine beste Praxis gibt, um eine Strategie zu bauen.
Es gibt viel Lärm und es gibt einige gute Praktiken.
Du hast einige gute Bücher.
Aber es gibt keine Strategie,
zumindest die ich kenne, wie eine Template-Strategie für Infrastruktur.
Es gibt einige Dinge, die fast immer wahr sind.
Du willst eine bessere Entwicklungserfahrung.
Du willst schnellere Entwicklungszyklen.
Du willst mehr abhängige Software.
Aber es ist immer eine Balance.
Manchmal willst du viel mehr abhängige Software,
viel mehr Software als Entwicklungserfahrung oder viel mehr abhängige Software als Entwicklungserfahrung oder
die Geschwindigkeit der Feature-Belieferung.
Also ich denke, das ist business-spezifisch.
Und du kannst sehen, was andere Unternehmen
an einer ähnlichen Phase und einer ähnlichen Größe für die Beleuchtung gemacht haben.
Aber leider glaube ich nicht, dass es eine Template für Strategie gibt,
weil es so kontextabhängig ist und so businessabhängig ist,
dass es sehr schwer ist, über die Strategie zu denken.
Ich mag William Larsen, er hat einen guten Post,
den ich vielleicht teilen und in die Show Notes schicken kann.
Oh ja, wir legen das in die Show Notes.
Danke.
Und das Buch Good Strategy, Bad Strategy.
Das ist eine Art Bibel für Strategie von Richard Rummelth.
Das ist ein guter Leser, aber es wird dir zeigen, wie man eine Strategie bauen kann.
Nicht,
eine spezifische Strategie für Infrastruktur oder Technologie oder
was auch immer. Es geht darum, wie du weißt, ob das eine gute Strategie ist oder nicht.
Ja, ich wollte nur fragen, ob es einige gute Startpunkte gibt.
Danke, dass du diese beiden Ideen oder Ressourcen vorgibst.
Und natürlich musst du entscheiden,
basierend auf der Situation deiner Organisation,
ob du oder ob du wirklich neue Entwickler benötigst.
Dann ist es vielleicht wertvoll, um die Bedürfnisse der Entwickler zu priorisieren.
Vielleicht sogar vor dem Kunden.
Wenn die Kundenbasis breit und wach ist und das Wort von Maus zu Maus ausbreitet,
dann ist es wahrscheinlich nicht so wichtig, wenn du einen sehr guten Wert verwendest.
Es ist nicht so wichtig, um die Bedürfnisse des Kunden zu erhöhen oder sich auf die Bedürfnisse des Kunden zu konzentrieren.
Also aus diesem Grunde, ja, ich stimme dazu, was die Situation angeht.
Ja.
Aber seit wir über Menschen gesprochen haben,
würde eine solche Plattformstrategie auch in Bezug auf das Verorganisieren von Teilen oder sogar all deine Organisationen reichen?
Ja, absolut.
Ich denke, das muss sein.
Nun, total.
In meiner aktuellen Rolle, zum Beispiel,
würde es total Teil der Strategie sein und es ist Teil der Strategie.
Also wenn wir über die Strategie denken, zum Beispiel wollen wir uns viel darauf konzentrieren,
weil wir wissen, dass wir eine gute Erfahrung dieses Jahres haben.
Also eine der Dinge, die wir machen wollen, um diese gute Erfahrung zu erreichen,
ist es, eine Erfahrungsteilnehmer-Team zu erstellen und die zwei Teams, die ich leite, in drei Teams zu dividieren.
Eine wäre die Erfahrungsteilnehmer-Team, weil ich denke, es macht extrem klar,
was die Bedeutung dieses Teams ist, was die Ziele sind und was der Fokus ist.
Wenn du es in demselben Team hast, ist es wirklich einfach,
dich von allem zu zerstören und Prioritäten zu verändern.
Aber wenn du sagst, nein, Erfahrungsteilnehmer-Team,
dein einziges Ziel ist es, die Erfahrungsteilnehmer-Team besser zu machen,
dann ist die Frage, welche Erfahrungsteilnehmer-Team ich besser mache.
Nicht, ob ich EKS verbessern muss oder die Plattform stabilisieren muss.
Also ich denke, für größere Organisationen muss es am meisten Teil der Strategie sein.
Andererseits, weil ich viel Erfahrung in kleineren Organisationen habe,
macht es nicht so viel, weil du nicht so viel umzusetzen hast.
Also zum Beispiel die erste DevOps-Strategie, die ich gemacht habe,
war ich und jemand anderes.
Also, wie viel du mit zwei Leuten machen kannst.
Und ja, es ist wiederum kontextabhängig.
Aber in größeren Organisationen sollte es ein Teil sein, um sicherzustellen,
dass du die Ressourcen und die Kapazität, wo sie sein sollten, um deine Ziele zu erreichen.
In kleineren Organisationen, vielleicht kannst du ein bisschen damit spielen,
aber es wird sehr hart sein.
Ja, aber du sprichst immer noch über dieses Thema von Verletzungen.
Vielleicht kannst du ein bisschen mehr darüber sprechen.
Ja, ich denke, das ist eines der größten Probleme, die ich für die Erfüllung deiner Strategie sehe.
Das sind Verletzungen in zwei Gründen.
Und das ist etwas, worüber ich mich als Leiter sehr viel denke.
Und ich sage meinen Teams sogar, wenn ich dich verletze, sag mir, umdrehen zu lassen.
Und dann komme ich zurück, bis ich meine aktuellen Aufgaben beende.
Und ich denke, es gibt zwei Art von Verletzungen.
Die wichtigen, die du überlegen solltest.
Zum Beispiel, wir arbeiten auf dem langfristigen Projekt oder migrieren in Argo Workflows.
Aber die Stabilität der Deployment Pipelines,
und das ist einer der Gründe, weshalb wir aus Jenkins und dem aktuellen Setup migrieren wollen.
Es ist nicht großartig.
Also manchmal ist es so, dass es aufhört zu arbeiten und jeden Deployment Setup beeinflusst.
Und damit habe ich mit dem CTO gesagt, ich weiß, wir haben dieses langfristige Projekt.
Wir haben einen Meilenstein in einem Monat,
aber ich möchte zwei, drei Wochen in der Plattform stabilisieren, weil das jetzt sehr schmerzhaft ist.
Also lasst uns die Abläufe ein bisschen weiter entfernen, damit wir das lösen können.
Also ich denke, das müssen wir immer noch umsetzen.
Und wenn du die Strategie verändern musst, weil eine wirklich wichtige Sache kommt, musst du das machen.
Aber es gibt
die kleinen Dinge, die nicht wichtig sind, wie Mikrodistraktionen, die viel hinzufügen.
Zum Beispiel frage ich einen der Teamleute, hey, kannst du mir diesen Dashboard geben?
Kannst du mir diese Metrik geben?
Kannst du mir diese, ich möchte das von P99 zu P75 in diesem Dashboard ändern?
Also es gibt Dinge, die wir als Managern sehr schnell fragen,
zu unseren Vorschlägen oder den Leuten, mit denen wir leiten.
Und wir denken nicht, oh, morgen werde ich fragen,
warum hast du dieses Ticket nicht beendet?
Du hast gesagt, du wirst es morgen beendet.
Und dann habe ich die Hälfte des Tages von dieser Person verpasst,
um stupide Dinge zu fragen, die nicht wirklich für die Ziele zählen.
Also ich denke, es ist nicht einfach.
Ich mache es immer noch, und ich denke darüber immer mehr.
Also du musst dir als Leiter bewusst sein,
von all den Fragen, die du fragst und all die Interaktionen, die du hast mit den Leuten,
die zu dir antworten, entweder direkt oder indirekt.
Du musst die Sicherheit bieten und die Teams ermöglichen, zu sagen,
hey, kann ich das morgen machen, weil ich das beenden möchte?
Und es ist sehr hart.
Ich habe versucht, ich habe dem Team gesagt,
sag mir ernsthaft, lass dich alleine lassen.
Und sie tun es nicht so oft.
Also muss ich sie wieder erinnern, dass sie mir sagen können, das ist nicht wichtig.
Ich will diese andere Sache beenden.
Aber ja, es sind die Verletzungen.
Die Mikrodestruktionen sind ein
großes Problem, obwohl du denkst, es sind nur fünf Minuten,
aber es sind fünf Minuten, wie 20 Mal pro Woche.
Und die Mikrodestruktionen, die ich denke, du als Leiter musst wehren.
Ist es wichtig genug, uns von der Strategie zu bestrafen oder nicht?
Und manchmal wird die Antwort ja sein.
Ja, es ist interessant, dass wir immer wieder zurückkommen
auch zu diesem Thema von erhöhter Effizienz und darüber, wie wir etwas Zeit abschneiden können.
Und etwas, das ich ziemlich
bemerkenswert finde, ist dieses berühmte Webcomic XKCD.
Vielleicht hast du es gehört.
Der Kerl, der es schreibt, ist manchmal sehr interessant.
Nicht wirklich Comics.
Und eines der Dinge, das er macht, ist wie ein Tisch, in dem er sagt,
wie viel Zeit du investieren kannst für eine gewisse Zeitverschuldung,
abhängig davon, wie oft du eine Aktivität machst.
Und wenn, ich weiß nicht, wenn du fünf Sekunden 20 Mal am Tag sagen kannst, dann bedeutet das, dass du dir
ich kann es nicht erinnern, eine Woche von Optimierungseffort investieren
und du kommst voran in einem Jahr oder fünf Jahren Zeit.
Es ist ziemlich interessant.
Ja, das ist sehr interessant.
Ich war, ich war in den alten Händen für unsere Ingenieurarbeit.
Aber ich habe meine Seite in den alten Händen
für unsere gesamten Ingenieurorganisationen letzte Woche.
Und eine Sache, die ich in ein paar Artikel gelesen habe,
diese Mikrofeedback-Lupen und sie waren wie fünf, zehn Sekunden, 20 Sekunden.
Und
eine Teil meiner Präsentation war, eine war, dass wir diese Debex-Champions
in den Teams kreieren wollen und die andere war, dass ich den Ingenieuren sagte,
wenn du etwas hast, das zehn, 20 Sekunden, eine Minute dauert und du es oft machst,
lass uns wissen, weil wir dir helfen werden.
Ich möchte diese Feedback-Lupen abschneiden oder sie entfernen.
Und einer der Ingenieure kam zu mir und sagte, ich hätte das nie gedacht,
wenn du das nicht gesagt hättest. Ich denke, die Leute sind so verwendet.
Und ich sagte, ja, wenn du sieben, zehn Sekunden hast,
wenn du es genug Mal pro Tag machst, ist es wert.
Und es ist nicht nur einer, es sind 100 Ingenieure, 130, die wir haben.
Also stell dir vor, ob es wert ist oder nicht.
Ich denke, die Leute denken einfach nicht nur über diese kleinen Mikrofeedback-Lupen.
Und das ist etwas, das ich erwähnt habe.
Und die Leute waren überrascht und wir werden damit beginnen, daran zu arbeiten.
Ich denke, die Leute denken einfach nur über diese kleinen Mikrofeedback-Lupen.