Den Softwareentwicklungs-Prozess beschleunigen, indem mehr Arbeit auf die Entwickler abgewälzt wird?
2024 ist das Jahr der Effizienz. Überall wird nachgesehen, was noch schneller und besser laufen kann. So auch bei der Softwareentwicklung. Denn dort ist allzeit bekannt: Umso später ein Fehler aufgedeckt wird, desto teurer ist seine Behebung. Deswegen wurde früh damit angefangen, nicht nach der Softwareentwicklung das Programm zu testen, sondern schon während der Entwicklung die Tests zu schreiben. Der Test-Prozess wurde in der Zeitleiste nach Links geschoben. In der Industrie nennt man diesen Vorgang “Shift Left”.
Doch bei Tests ist es nicht geblieben. DevOps verlagert die Operations nach Links. Cloud die Definition von Infrastruktur als Code (und somit in die Softwareentwicklung). Security nimmt ebenfalls einen wichtigen Standpunkt in der modernen Welt ein. Metriken, strukturierte Logs und weitere Signale für Observability sind ein fester Bestandteil der Softwareentwicklung. Doch wie viel Prozesse sollen (und können) dennoch nach Links verschoben werden? Wie viele Aufgaben soll eine einzige Entwicklerin erledigen? Ist nicht einfach mal gut?
Bonus: Alles mit Ops - DevOps / MLOps / CloudOps / AIOps / DataOps / SecOps / DevSecOps / HROps LegalOps BizOps LLMOps ChatOps NoOps
**** Diese Episode wird gesponsert vom Open-Source Förderprogramm Media Tech Lab
Bewirb dich jetzt und erhalte bis zu 50.000€ Fördersumme für dein Open-Source Projekt https://engineeringkiosk.dev/medialab
****
Das schnelle Feedback zur Episode:
Links
- Shift Left: https://de.wikipedia.org/wiki/Shift-Left-Ansatz
- Engineering Kiosk Episode #106 CI - Continuous Integration in der Praxis mit Michael Lihs von Thoughtworks: https://engineeringkiosk.dev/podcast/episode/106-ci-continuous-integration-in-der-praxis-mit-michael-lihs-von-thoughtworks/
- Engineering Kiosk Episode #101 Observability und OpenTelemetry mit Severin Neumann: https://engineeringkiosk.dev/podcast/episode/101-observability-und-opentelemetry-mit-severin-neumann/
- Engineering Kiosk Episode #60 On-Call: Warum auch Software-Engineers auf Rufbereitschaft sein sollten: https://engineeringkiosk.dev/podcast/episode/60-on-call-warum-auch-software-engineers-auf-rufbereitschaft-sein-sollten/
- Engineering Kiosk Episode #103 Plattform Engineering und Interne Developer Plattformen mit Puja Abbassi: https://engineeringkiosk.dev/podcast/episode/103-plattform-engineering-und-interne-developer-plattformen-mit-puja-abbassi/
Sprungmarken
Hosts
- Wolfgang Gassler (https://mastodon.social/@woolf)
- Andy Grunwald (https://twitter.com/andygrunwald)
Feedback (gerne auch als Voice Message)
- EngKiosk Community: https://engineeringkiosk.dev/join-discord
- Email: stehtisch@engineeringkiosk.dev
- Mastodon: https://podcasts.social/@engkiosk
- Twitter: https://twitter.com/EngKiosk
- WhatsApp +49 15678 136776
Transkript
Wolfi Gassler (00:00:00 - 00:00:36) 
Untertitel im Auftrag des ZDF, 2021 DevOps, MLOps, CloudOps, AIOps, DataOps, SecOps, DevSecOps, HROps, LegalOps, BitsOps, LLMOps, ChatOps, NoOps oder einfach nur ShiftLeft. Aber was bedeutet dieser Trend vom ShiftLeft? Müssen wir jetzt als EntwicklerInnen alles lernen? Sind wir für alles verantwortlich? Und was ist an der Theorie dran, dass unsere gut bezahlten Jobs nicht der KI, sondern ShiftLeft zum Opfer fallen könnten? Wir nehmen uns diesem Hype-Thema einmal an und besprechen die ganzen Implikationen.
Andy Grunwald (00:00:36 - 00:00:36)
Und los geht's!
Wolfi Gassler (00:00:42 - 00:01:24)
Hanni, du weißt ja, dass wir eigentlich fast ein Hype-Driven-Podcast sind. Wir sprechen ja ständig über AI und ob AI unseren Arbeitsplatz ablösen wird, zum Beispiel. Also nicht nur wir, irgendwie die ganze Welt spricht darüber. Und dabei hat die ganze Welt irgendwie einen anderen Hype, der sich so eigentlich in den letzten Jahrzehnten eingeschlichen hat. Übersehen, würde ich fast sagen. Und der eigentlich noch viel gefährlicher ist wie das ganze AI-Zeug. Und zufälligerweise haben wir ja in diesem Podcast einen absoluten Spezialisten, wenn es darum geht. Also darf ich Andi Dich heute mal herzlich willkommen heißen, weil es geht in dem Fall über ein Thema, das dich ja den ganzen Tag beschäftigt.
Andy Grunwald (00:01:24 - 00:01:28)
Ich bin mir nicht ganz sicher, ob du jetzt den Klimawandel meinst, Ja, der.
Wolfi Gassler (00:01:28 - 00:01:29)
Beschäftigt dich doch nie.
Andy Grunwald (00:01:29 - 00:01:53)
Naja, also all das, was du gerade gesagt hast, könnte man auch auf den Klimawandel setzen. Er, der Klimawandel, bedroht unsere Jobs, denke ich schon. Ich bin aber kein Experte für den Klimawandel, aber da wir im Internet sind, hat jeder eine Meinung und somit kann ich auch Experte sein. Wusstest du eigentlich mal, dass ich den jeglichen Respekt vor dem Wort Experte verloren habe, als ich mal eine Episode von Galileo auf ProSieben gesehen habe?
Wolfi Gassler (00:01:53 - 00:01:54)
Jetzt bin ich gespannt.
Andy Grunwald (00:01:55 - 00:02:20)
Und zwar haben die getestet, was man irgendwie aus 20 Metern fallen lassen kann. Dann sind die mit so einem Kran hoch und haben sich auf irgendeinem Hof getroffen, wo da eine Betonfläche war, und haben Sachen fallen lassen. Und auf einmal wurde eine Person interviewt, weil die hatten Konservendosen dann irgendwie in der Hand und wollten Konservendosen fallen lassen. Und dann stand da der Name, und darunter steht ja immer der Titel. Und dann stand da, weiß ich nicht, Max Mustermann, Dosenexperte.
Wolfi Gassler (00:02:20 - 00:02:21)
Experte für Dosen.
Andy Grunwald (00:02:21 - 00:02:36)
Dosenexperte. Und ich weiß jetzt, die haben jetzt nicht erwähnt, dass der irgendwie in einer Konservenfabrik gearbeitet hat oder sowas. Ich weiß nicht, wie man Dosenexperte wird. Deswegen hab ich ein bisschen den Respekt vor Experten verloren oder halt von der Definition von ProSieben, von dem Wort Experte.
Wolfi Gassler (00:02:36 - 00:03:02)
Eine Freundin von mir hat mal, ich glaube, es war nicht für Galileo, sonst bekommen wir dann noch Klagen, aber für so eine ähnliche Show gearbeitet. Die hat mir da auch Horrorgeschichten erzählt, wie da recherchiert wird. Da wird sich irgendwas ausgedacht und dann wird noch schnell eine Webseite gesucht, wo das irgendwie erwähnt ist und damit ist das schon genug Recherche und man macht da schon eine ganze Fernsehsendung draus. Also es ist erschreckend, schlimm diese Research wahrgenommen wird in solchen Sendungen.
Andy Grunwald (00:03:02 - 00:03:09)
Dann bin ich ja froh, dass ich GEZ zahle und hoffentlich sowas bei ARD, ZDF, Dreisat und Co. nicht habe.
Wolfi Gassler (00:03:09 - 00:03:10)
Das hoffe ich doch mal.
Andy Grunwald (00:03:11 - 00:05:32)
Alle von uns benutzen Open Source. Viele haben den Drang mal bei Open Source mitzuwirken. Einige tun dies in ihrer Freizeit und ganz ganz wenige Leute haben den Luxus dafür auch bezahlt zu werden. Wenn du doch mal den Drang hast zur letzten Kategorie zu gehören, dann hör mir mal zu. Das Media Lab Bayern hat mit dem Media Tech Lab eine 50.000 Euro Open Source Förderung auf die Beine gestellt. Was ist das? Wie funktioniert das? Du bekommst 50.000 Euro um sechs Monate alleine oder in einem Team zu zweit an einer Open Source Lösung für die Medienbranche zu arbeiten. Das kann wirklich alles sein. Im Bereich künstliche Intelligenz, Infrastruktur und Webtechnologie, User Experience und User Interfaces. Seid einfach kreativ. Schaut euch YouTube, Twitch und Co. an. Was könnte die Medienbranche nach vorne bringen, beziehungsweise was wollt ihr auch als Konsumenten von der Medienbranche? Ihr habt Zeit, das zu entwickeln. Eure Idee pitcht ihr in einem kleinen Dokument, jetzt nicht acht Seiten oder so, also wirklich ganz klein und reicht diese ein. Wenn das ganze recht interessant für dich klingt, du aber sagst, hey, aufgrund meines Angestelltenverhältnisses habe ich dafür eigentlich gar keine Zeit, dann kommt hier mal meine Idee. Sprech doch mal mit deiner Vorgesetzten über dieses Förderprogramm. Viele Firmen erlauben einem ein sechsmonatiges Sabbatical einzulegen oder gegebenenfalls unbezahlten Urlaub für diesen Zeitraum zu nehmen. Finanziell seid ihr durch die Fördersumme gut abgesichert. Ich denke, dass das eine gute Möglichkeit ist, um etwas anderes zu sehen, mal was Neues zu lernen, neue Inspirationen zu bekommen und sich selbst so ein bisschen aus der eigenen Komfortzone rauszubewegen. Im Endeffekt profitiert davon auch euer Arbeitgeber. Und wer weiß, vielleicht wird nach den sechs Monaten sogar mehr aus dem Open Source Projekt. Wolfgang selbst hat mal daran teilgenommen und arbeitet heute immer noch an seiner Podcast Analytics Plattform. Also schaut mal unter engineeringkios.dev slash medialab vorbei. Den Link findest du natürlich auch in den Show Notes. Und falls du noch ein bisschen Inspiration brauchst, komm doch einfach in unsere Discord-Community. Wolfgang steht dir da, Rede und Antwort. Und jetzt geht's weiter mit dem Podcast. Jetzt löse ich das ganze Rätsel mal auf. Es geht nicht um den Klimawandel. Und zwar spricht der Wolfgang über den Hype, wenn wir alle hier nicht aufpassen oder uns nicht weiterentwickeln, der uns dann trotzdem den Job wegnimmt oder beziehungsweise nicht wegnimmt, sondern eher abhängt. Und zwar sprechen wir heute über Shift Left. Und Shift Left, davon rede ich jetzt nicht von der Politik mit der AfD und den Linken.
Wolfi Gassler (00:05:32 - 00:05:34)
Das wäre ja Shift Right aktuell.
Andy Grunwald (00:05:35 - 00:05:40)
Leider in europa aktuell shift right das ist richtig hoffe da kriegen wir nochmal die kurve aber wir sprechen über shift.
Wolfi Gassler (00:05:40 - 00:05:45)
Left und also die taste auf dem keyboard links von mir.
Andy Grunwald (00:05:45 - 00:05:48)
Es regnet dauerhaft ne ist shift konstant oder shift dauerhaft naja.
Wolfi Gassler (00:05:48 - 00:05:50)
Das ist shift lock.
Andy Grunwald (00:05:50 - 00:05:51)
Das war ein flacher witz.
Wolfi Gassler (00:05:52 - 00:05:56)
Caps lock so heißt es. Ich hab sogar den flachwitz versaut.
Andy Grunwald (00:05:57 - 00:06:33)
Aber es geht um den Begriff, die Methode, das Konzept von ShiftLeft. Und ich weiß nicht, ob es euch auch so geht, aber zumindestens in unserem Management, also in der Firma bei meinem Arbeitgeber, höre ich das seit zwei Jahren runter und rauf, das Wort. Also dieses Wort ShiftLeft oder diese zwei Wörter ShiftLeft habe ich so oft in letzter Zeit gehört. Und jetzt in den letzten Monaten ist es vermehrt in dem einen oder anderen Software Engineering Newsletter auch nochmal aufgepoppt. In meiner Bubble ist es auf jeden Fall allgegenwärtig. Und deswegen wollen wir fragen, wo hast du den Term Shift Left das erste Mal gehört?
Wolfi Gassler (00:06:33 - 00:06:45)
Wir springen schon auf jeden Hype-Train auf so langsam. Ist ja unglaublich. Also das erste Mal, puh, keine Ahnung, was mir so einfällt als letztes Mal, wo ich es gehört habe, ist in einer Episode von uns.
Andy Grunwald (00:06:45 - 00:06:57)
Lustigerweise habe ich mich natürlich auch auf diese Episode vorbereitet und es war in der Continuous Integration Episode mit dem Michael. Deswegen überlasse ich dir gerne mal ganz kurz die Definition, was ist denn Shift-Lift.
Wolfi Gassler (00:06:58 - 00:08:01)
Ich habe gedacht, du bist der Experte für ShiftLeft. Aber dankenswerterweise bin ich natürlich einigermaßen vorbereitet. Und man kann sich vielleicht schon das Ganze ein bisschen vorstellen, was ShiftLeft bedeutet, wenn man sich das grafisch vorstellt. Wenn man sich so einen Prozess ansieht von der Softwareentwicklung von links vom Start von so einem Softwareprozess, wo man die Software erfindet, bis ganz nach rechts, wo die Software dann irgendwo läuft, deployed ist. Und shift left bedeutet jetzt eigentlich, dass man das Ganze nach links drückt. Also vom Deployment wandern gewisse Dinge nach links. Und was sind jetzt die gewissen Dinge? Dass man eben Aktivitäten oder Teile von diesem Prozess, die früher irgendwelche Leute da eher auf der rechten Seite gemacht haben, dass man die weiter nach links drückt, eher in Richtung EntwicklerInnen. Und dass die auf der Seite mehr übernehmen, was früher eher auf der rechten Seite war. Also, wenn man das rein grafisch sieht, einfach alles von rechts, oder nicht alles, aber ganz viel von rechts, wandert mehr nach links.
Andy Grunwald (00:08:02 - 00:08:07)
So, das war jetzt der erste Paragraf von Wikipedia und im zweiten Paragraf werden oft Beispiele genannt.
Wolfi Gassler (00:08:07 - 00:08:08)
Darum bist du Experte.
Andy Grunwald (00:08:08 - 00:08:10)
Bitte fahren Sie fort, Wikipedia-Gassler.
Wolfi Gassler (00:08:10 - 00:08:48)
Ich hab gedacht, du bringst jetzt die Beispiele. Also ganz klassisch, was wir ja aus der Vergangenheit schon kennen, ist das leidige Testen zum Beispiel. dass Entwickler mittlerweile testen müssen und Tests schreiben müssen. Früher hat es ja irgendwer ganz auf der rechten Seite gemacht, QAs, die haben dann manuell da sich durch die Oberfläche geklickt und gecheckt, ob da alles noch so ist wie früher. Und mittlerweile übernehmen EntwicklerInnen auch mehr von der Aufgabe, Tests zu schreiben, Tests zu erstellen. Das wäre ein Beispiel. Darum habe ich am Anfang eben auch gesagt, etwas, was sich über die letzten Jahrzehnte schon eingeschlichen hat, weil das ist ja eigentlich ein Beispiel, was wir alle kennen müssen und hoffentlich auch machen.
Andy Grunwald (00:08:49 - 00:10:37)
Natürlich, wir machen alle Test-Driven-Development dauerhaft. Zum Glück sieht keiner das Video gerade. Nun gut, ja, das Ganze ist eigentlich nix Neues. Also zumindest nicht im Kompletten etwas Neues. Denn dieses Shift-Left ist eigentlich nur ein neuer Begriff für, ich sag mal, Best Practice. Er kommt wirklich aus der Software-Testing-Welt, wo wir früher manuelle QA hatten. Dann ist es mehr zu automatisierten Tests gegangen. dahin gegangen, dass wir alle Tests geschrieben haben oder Test Driven Development gemacht haben und dann ist es soweit gekommen, dass wir Continuous Testing in unserer Continuous Integration Testing Umgebung gemacht haben und somit kontinuierlich bei jedem Build die Tests ausführen. Ja, das hat man dann alles Ich sag mal, das, was früher Menschen gemacht haben, wurde durch Tools früher in den Entwicklungszyklus geschoben. Alles gut. Und in letzter Zeit kommt der Begriff aber immer wieder hoch, beziehungsweise der ganzen Thematik wurde einem Begriff gegeben, Schiffklefft. Denn Testing ist ein alter Hut. Fair enough. Aber da irgendwie alles heutzutage eine App ist und eine Web App und immer mehr digitalisiert wird und immer mehr kritische und wichtige Prozesse über das Internet laufen, hat das Security Team in jeder Firma auch ein ganz schönes großes Wort mitzureden inzwischen bei der Applikation und das in diesem ganzen Shift Left Konzept jetzt auch Security mit reinkommt. Das ist ein relativ neues Gebiet, zumindestens für europäische Firmen in Amerika. Aka dem Silicon Valley ist das eigentlich auch schon fast schon ein alter Hut, aber deswegen haben wir mal gedacht, nehmen wir mal das ganze Thema als Podcast Episode, denn nur bei Testing und nur bei Security Da ist es heutzutage leider auch nicht geblieben, weil ihr kennt das, wenn ein Thema angefasst wird, dann wird heutzutage in 2024 ordentlich aufs Gaspedal getreten und mit Security und Testing ist es leider noch nicht getan.
Wolfi Gassler (00:10:37 - 00:10:49)
Okay, wir haben jetzt Security dabei, wir kennen das auch aus DevOps, da hat man auch gewisse Sachen nach links gedrückt, aber warum drückt man denn überhaupt Sachen nach links? Also was hat das für einen Zweck? Was will ich damit überhaupt erreichen?
Andy Grunwald (00:10:49 - 00:10:55)
Naja, im Allgemeinen geht es um die Buzzwords, Qualität verbessern, Risiken reduzieren, Effizienz steigern, bla bla bla.
Wolfi Gassler (00:10:55 - 00:11:00)
Ja, klassisches Management. Wenn du mit Buzzwords anfängst, das klingt schon, das ist alles nur irgendwas vom Management und bringt überhaupt nichts.
Andy Grunwald (00:11:01 - 00:12:05)
Nee, also im Endeffekt heißt das natürlich, dass du wichtige Prozesse früher in den Entwicklungsprozess ziehst und damit natürlich potenzielle Probleme früher erkennst und die Fehler auch frühzeitig beheben kannst. Jetzt stell dir mal vor, wir beide würden ein Auto bauen. Du willst die Karosserie designen, ich die Türen, du den Motor und ich die Reifen. Wir würden aber nicht miteinander sprechen. Ich würde sagen, wenn wir alles hergestellt haben und versuchen, die Teile zueinander zu bauen, ohne dass wir miteinander gesprochen haben, ich schwöre dir, entweder ist mein Motor zu schwer, Oder die Türen passen nicht in die Karosserie und so weiter. Und besonders solche konzeptionellen Fehler, weil wenn die Tür nicht auf die Karosserie passt, würde ich mal als konzeptionellen Fehler beschreiben, die sind natürlich später enorm teuer zu beheben. Wenn wir uns aber, ich sag mal, vorher zusammensetzen und eine Designphase machen und vielleicht mal mit einem Zollstock aka Gliedermaßstab irgendwie uns mal auseinandersetzen, wie breit soll die Tür sein und so weiter, dann sind diese Fehler relativ gut vermeidbar und natürlich sehr günstig im Endeffekt. Frühere Überhebung der Fehler, günstiger, schnellere Time-to-Market, weil wir nicht alles korrigieren müssen.
Wolfi Gassler (00:12:05 - 00:12:14)
Aber das würde jetzt hier nur heißen, dass du mehr kommunizieren musst. Das heißt ja noch lange nicht, dass ich als Entwickler jetzt plötzlich Tests schreiben muss. Könnt ihr auch nur mit den QA-Leuten kommunizieren?
Andy Grunwald (00:12:14 - 00:12:39)
Schon, aber wenn wir miteinander kommunizieren, wie steigern wir dann die Effizienz? Die Effizienz steigern wir hier in diesem Fall durch Automatisierung, dass wir Software schreiben, nämlich Software-Tests, die wir in Millisekunden ausführen können, anstatt dass das manuelle QA-Team 35 Mal pro Tag durch die Applikation klickt. Natürlich können wir sagen, klickt schneller, aber das ist dann auch mehr Effizienz, aber die hat ja einen Cap oben drauf.
Wolfi Gassler (00:12:40 - 00:12:43)
Ja, aber das QA-Team könnte ja auch die automatischen Tests schreiben.
Andy Grunwald (00:12:43 - 00:12:43)
Klar!
Wolfi Gassler (00:12:43 - 00:12:44)
Könnte nicht ich als Entwickler schreiben.
Andy Grunwald (00:12:45 - 00:12:46)
Hat auch niemals gesagt.
Wolfi Gassler (00:12:46 - 00:12:53)
Dann wäre es ja kein Shift-Left, dann bleibt es ja alles, wo es ist, nur dass es automatisiert wird. Dann ist es ja kein Shift-Left, sondern nur eine Automatisierung.
Andy Grunwald (00:12:53 - 00:13:42)
Der Unterschied ist aber hier, dass du in der Regel Programmierer hast, also im früheren Wasserfallmodell, du hast Programmierer, die machen die Software, geben dann das fertige Paket ab, eine Abteilung weiter und dann bekommst du drei Wochen später ein PDF-Report, was alles nicht funktioniert, und dann sitzen die Programmierer wieder dran. Bei Shift-Left hast du vielleicht sogar ein oder zwei Leute aus dem QA-Team in deinem Team mit drin sitzen. Beispiel. In diversen Firmen ist das so, ich glaub sogar bei Google oder Uber, dass auf zwei Software-Engineers ein Software-Engineer in Test sitzt. Und Software-Engineer in Test heißt im Silicon Valley eigentlich QA-Engineer, der Software schreiben kann. Und somit automatisierte Tests. Da merkst du schon, da gibt es diese richtige Relation. Zwei Softwareentwickler, ein Softwareentwickler nur für Tests. Und das ist shift left. Die arbeiten konstant zusammen.
Wolfi Gassler (00:13:42 - 00:13:50)
Das heißt, es geht auch gar nicht so sehr darum, wer das macht, sondern eher darum, wann es gemacht wird. Und in dem Fall eben früher. Mehr links.
Andy Grunwald (00:13:50 - 00:14:20)
Genau, also ich meine, die ganze Sache hat natürlich, wenn wir jetzt sagen, alles, was wir nach links verfrachten wollen in den Prozess, in ein Team stopfen, dann sind wir halt auch irgendwann ein 20-Mann-Team und dann ist es halt auch nix mehr mit der Effizienz. Also da muss man natürlich schon ein bisschen abwägen, aber wenn du natürlich jetzt von manuellem QA wirklich klicken zu einer QA-Person gehst, die mit im Softwareentwicklungsteam sitzt, die dann auch reproduzierbare Tests schreibt, dann ist das natürlich eine deutliche Effizienzsteigerung.
Wolfi Gassler (00:14:21 - 00:14:48)
Jetzt liest man das aktuell überall, wie du gesagt hast, in Newslettern und irgendwie ist es jetzt in aller Munde und es wird rauf und runter geradelt, das Shift-Left, aber irgendwie hat es ja doch auch einiges früher schon gegeben, wenn wir bei Cross-Functional-Teams anfangen, DevOps, automatisierte Tests. Also warum wird es jetzt plötzlich so intensiv kommuniziert überall, obwohl die Idee und auch das Thema ja durchaus ein altes ist?
Andy Grunwald (00:14:49 - 00:14:54)
Ich freue mich gerade richtig, endlich kommt mein Wirtschaftsinformatikstudium so ein bisschen zur Geltung.
Wolfi Gassler (00:14:54 - 00:14:56)
Dr. Dr. Grunwald bitte.
Andy Grunwald (00:14:57 - 00:15:02)
Also, da muss man jetzt mal so ein bisschen die makroökonomischen Effekte kennen.
Wolfi Gassler (00:15:03 - 00:15:06)
Moment, das hast du dir jetzt rausgeschrieben, das Wort vorab, oder?
Andy Grunwald (00:15:06 - 00:16:54)
Nee, hatte ich wirklich im Studium und ich grins auch mal so ein bisschen. Ich bin gerade so ein bisschen aufgeregt. Ich glaube, wir alle wissen, dass wir die letzten, weiß ich nicht, zehn Jahre eine sehr gute Zinspolitik für uns hatten. Geld war sehr günstig, eine sogenannte Nullzinspolitik. Oder im Englischen eine Zero Interest Rate Policy. Und wenn man mal nach SIRP, Z-I-R-P, googelt, dann findet man dazu ganz viel. Naja, auf jeden Fall, die letzten 10 Jahre oder die letzten 8 Jahre war Geld sehr, sehr günstig. Also fast umsonst gefühlt. Und deswegen haben sehr viele Softwareunternehmen natürlich Leute angestellt, Leute angestellt und die haben auch sogar zu viele Leute angestellt. Sogenanntes Overhiring. Es gab sogar Gerüchte, dass die großen Big-Tech-Unternehmen einfach Leute eingestellt haben, damit die Konkurrenz die Leute nicht einstellen kann. Also Google hat einfach Overhired, damit Netflix die Leute nicht kriegt. Unabhängig davon, ob die eine Aufgabe hatten oder nicht. Weil die hatten Venture Capital, Geld war günstig und so weiter. Und inzwischen hat sich das Bild so ein bisschen gedreht. Es wird ja nicht umsonst gesagt, es ist das Jahr der Effizienz. Und es waren auch nicht umsonst so viele Layoffs in den letzten fast zwei Jahren, würde ich fast sagen. Weil inzwischen finden wieder Layoffs statt. Geht einfach mal auf layoffs.fyi. Die Kurve geht wieder nach oben. Und man hat also sehr viele teure Softwareentwickler und Entwicklerinnen entlassen. Dennoch muss der Softwareentwicklungsprozess aber schneller werden. Und wie machst du das? Die Leute haben sich wieder den neuen Begriff Chef Lab ausgedacht. Okay, wir verlagern ziemlich viele Elemente früher in den Entwicklungsprozess und dadurch erkennen wir Fehler früher und dadurch geht das hoffentlich schneller. Ja, so im Management-Sprech. Kurzum, Geld ist gerade wieder teuer, wir müssen alle schneller werden, wir müssen schneller, inkrementeller shippen, am besten ohne Fehler, bug-free. Das ist so der ganz simplifizierte Grund dafür.
Wolfi Gassler (00:16:56 - 00:17:05)
Okay, dann gehen wir jetzt mal wirklich in die Praxis. Wenn ich jetzt ein kleines Startup habe, wie kann ich das dann denn alles optimieren, damit ich effizienter bin?
Andy Grunwald (00:17:05 - 00:17:37)
Ha, mega. Brauchst du gar nicht. Das Tolle am Startup ist ja, in der Regel sind da ein, zwei, drei Leute, die dann irgendwie alles machen. Du hast eine Softwareentwicklerin, die ist die Security-Expertin und die macht noch den Server auf AWS oder Serverless und schreibt noch die Software und so weiter. Verstehst du? Die eine Softwarefrau, die ist da alles. Die die die die ist schon shift left in person und das ist so ungefähr der vorteil von kleinen firmen da bleibt der firma nichts anderes übrig als shift left von haus aus zu machen.
Wolfi Gassler (00:17:37 - 00:17:57)
Und was mache ich jetzt wenn ich wachse als als firma als kleines startup und jetzt kommt da, Böser Rechtsruck, weil ich mache jetzt plötzlich rechts irgendwelche Funktionen auf und da gibt es jetzt mein Deployment Team. Brauche ich das zuerst mal, um dann wieder ein Shift-Left-Move zu machen oder wie gehe ich dann an die ganze Sache dran im Wachstum?
Andy Grunwald (00:17:57 - 00:18:40)
Ich hoffe, dass bei einem Rechtsruck die neuen Teams, die da aufgemacht werden, nicht ihre Logofarbe braun haben. Aber nun gut. Ja, du hast schon gesagt, natürlich, wenn die Firma wächst, kommst du natürlich auf die Wachstumsgeschwindigkeit an, und das sind dann auch die Wachstumsschmerzen, wenn ziemlich viele Leute in sehr kurzer Zeit ... der Firma beitreten. Und immer wenn eine Funktion, wenn dafür ein Team gegründet wird, jetzt ein Operations-Team, ein Cloud-Team, ein Security-Team, dann ist es natürlich so ein gewisser Knackpunkt im Bereich Schiffleft. Weil du willst ja mehr nach links und auf die, ich sag mal, Development-Arbeit oder während des Development-Prozesses irgendwie einführen. Und du willst ja nicht ein eigenes Team mit eigener Strategie und so weiter einführen.
Wolfi Gassler (00:18:40 - 00:19:05)
Aber wie skaliere ich denn dann? Weil irgendwie, es bläst sich ja dann mein Team auf der linken Seite immer weiter auf, wie du auch gesagt hast. Irgendwann sind wir dann 20 Leute, weil du brauchst einen Security-Spezialisten, einen Test-Spezialisten, ein paar Entwickler, ein paar UI, UX-Designer, ein paar normale Designer und am Ende hast du irgendwie alles nur mehr in einem Team, was an sich schon nicht mehr kommunizieren kann. Also irgendwie muss ich ja meine Teams aufteilen und irgendwie muss ich ja dann skalieren.
Andy Grunwald (00:19:05 - 00:20:53)
Am Anfang willst du natürlich einen gewissen Halt haben. Du bist einfach nicht so effizient, wie wenn ein oder zwei Personen alles machen und dann machen 20 Personen dasselbe. Das funktioniert halt einfach nicht, weil Kommunikation muss da sein und so fort. In der Aufbaufase bei sowas geht es natürlich eigentlich darum, dass du vom Security-Experten dir die Meinung einholst, okay, welche Tools können wir denn einsetzen, um dir als Security-Experte die Arbeit zu erleichtern? Oder welche Tools können wir denn schreiben? Der Security-Experte schaut die Applikation an, die Domäne, was ist denn hier eigentlich wichtig, was ich hier überprüfe? Nehmen wir uns nochmal die Definition von Shift-Left zur Hand. In der Praxis bedeutet dies, dass Softwareentwickler dedizierte Werkzeuge verwenden, um das zu tun, was früher dedizierte Rollen taten, aber später. Das bedeutet, du holst dir ein Security-Team und die schauen sich eure App an und schauen sich an, okay, was können wir hier während des Softwareentwicklungsprozesses denn bereits automatisieren. Nehmen wir mal zum Beispiel Static Analyzer. Static Analyzer sind ein perfektes Beispiel dafür. Die gibt es inzwischen nicht nur für Software-Sprachen, also wirklich so für Java und Co. oder für Go, die dann auch Race Conditions rausholen und so weiter. Die gibt es aber inzwischen auch für Dockerfiles. HadoLint ist zum Beispiel so ein Static Analyzer. HadoLint schaut sich nicht nur an, ah, der macht da einen Upget-Befehl, sondern sagt auch in deinem Upget-Befehl, in deinem Dockerfile, fehlt das Version-Pinning. Und da fehlt das Don't-Install-Recommended-Software-Flex. Oh, und in deinem Dockerfile hast du auch Inline-Shell, dann führt der Shell-Check aus. Also der hat auch Security-Best-Practices drin und Operations-Best-Practices. Das schützt sich natürlich nicht vor jedem Security-Einfallstor, ganz klar. Es entlastet aber den Security-Spezialisten, vor der manuellen Arbeit dauerhaft die Dockerfile zu checken.
Wolfi Gassler (00:20:53 - 00:21:30)
Also wenn ich früher da rechts ein Team rausgezogen habe, das sich nur um Sicherheit zum Beispiel kümmert und dann das Dockerfile analysiert hat, dann ziehe ich jetzt das Team nicht wieder nach links rein, sondern dieses Team kümmert sich um die Automatisierung, bleibt also draußen außerhalb von dem eigentlichen Team, aber stellt dann denen das Tool zur Verfügung, das automatisch die Dockerfiles checkt und sagt, hey, du hast da irgendein CVE, was grad irgendwie ein Loch ist bei irgendeiner Dependency, und mach was dagegen. Und dann denen quasi atomisiert mitteilt, ihr müsst da was machen. Also so erreiche ich dann die Skalierung, indem ich mehr Leute auf ein Problem setzen kann, aber außerhalb.
Andy Grunwald (00:21:30 - 00:22:03)
Ja, das ist zum Beispiel ein Weg. Die Leute werden dann nicht gefeuert, weil du ersetzt ja wirklich spezialisierte Jobs nicht durch, ich sag mal, Quote-unquote, einfache Tools, obwohl HadoLint jetzt kein einfaches Tool ist. Aber die Leute können sich dann aufs Wesentliche fokussieren, beziehungsweise auf den nächsten Schritt fokussieren. Nehmen wir mal an, du hast überall Version-Pinning und du weißt ganz genau, welche Software da installiert wird. Und Achtung, Security-Spezialisten, haut mich jetzt bitte nicht, denn ich weiß, das ist ein bisschen falsch gesagt, aber nur um das Beispiel zu bringen. Theoretisch könntest du dann einen S-Bomb erstellen, ohne das Docker-Image zu bauen, weil du weißt ja, welche Images du erstellst.
Wolfi Gassler (00:22:03 - 00:22:05)
Kannst du kurz S-Bomb erklären?
Andy Grunwald (00:22:05 - 00:22:09)
Ja, ein S-Bomb ist ein Software Bill of Materials. Kommt eigentlich so, ich sag mal, aus dem Hardware-Bereich.
Wolfi Gassler (00:22:09 - 00:22:18)
Immer wenn du... Schon wieder so ein neuer heißer Scheiß am Hype-Train. Also heute ist ja in einer Tour. Bullshit-Bingo-Karte ist eigentlich jetzt schon voll bei mir.
Andy Grunwald (00:22:19 - 00:23:01)
Kommt eigentlich aus der Platinenerstellung. Immer wenn du nämlich mal eine Platine im Hardwarebereich löten möchtest und Anleitungen suchst, dann ist da immer ein sogenanntes Bill of Materials dabei, was eigentlich eine Einkaufsliste an Materialien sind. Du baust diesen Transistor und so weiter. Und ein Software Bill of Materials ist eigentlich eine komplette Auflistung von aller Software inklusive Versionen, die du in deinem Stack hast. Und mit dieser Liste kannst du natürlich dann zu Security-Datenbanken gehen und sagen, hey, hat irgendeine Softwareversion hier ein Sicherheitsleck und muss ich die patchen und all so was. Besonders im Compliance-Bereich und im Security-Bereich und im Infrastrukturbereich ist das eigentlich, ich würd mal fast sagen, Standard heutzutage. Sag mal.
Wolfi Gassler (00:23:01 - 00:23:20)
Da kann ich wieder mal sagen, du in deiner heilen Welt ... Das könnten wir auch langsam auf dem T-Shirt drucken. Aber mittlerweile ist es ja auch Pflicht, oder bald Pflicht, mit dem European Cyber Resilience Act musst du das ja sogar nachweisen und dementsprechend immer überprüfen, auf welchen Abhängigkeiten du da drauf bist und was es da für Probleme gibt.
Andy Grunwald (00:23:20 - 00:23:50)
Also ich kann euch sagen, wenn ihr einen GitHub Enterprise Vertrag habt, dann könnt ihr GitHub fragen, gebt mir euer S-Bomb. weil ich brauche das für meine Compliance. Du kannst das eigentlich fast bei jedem Datenbank-SS-Service-Provider nachfragen, die auf jeden Fall eine PCI-DSS SOC2-Compliance, also die eigentlich so die üblichen Datenschutz-Compliance-Zertifikate haben. Kannst du bei jeder größeren Firma, kannst du das SBOM anfragen und dann kriegst du einfach mal eine komplette Liste aller Software, bis auf die Proprietäre natürlich von denen.
Wolfi Gassler (00:23:51 - 00:24:02)
Wenn ihr da so in einer Ecke diese Maschine stehen habt, diese Blackbox, die das ganze Geld macht mit dem Legacy Code, die hat auch so eine API, wo ihr da schnell anfragen kann, oder? Gib mir den S-Bomb und alle Abhängigkeiten, seht ihr das richtig?
Andy Grunwald (00:24:02 - 00:24:12)
Also ich würde mich jetzt mal aus dem Fenster lehnen und sagen, nicht jedes S-Bomb ist auf via eine API abfragbar, ab und zu ist es einfach nur ein Textteil, was einmal pro Tag erstellt wird oder ähnliches.
Wolfi Gassler (00:24:14 - 00:24:15)
Sehr diplomatische Antwort.
Andy Grunwald (00:24:15 - 00:24:37)
Ein guter Hack ist sehr persistent, würde ich mal sagen. Nein, wir reden jetzt aber natürlich die ganze Zeit von Tools. Wir haben Leute und die kommen dann rein und die sagen dann, nutzt Tool A. Ja, aber so einfach ist es halt auch nicht immer. Shift-Left kann auch bedeuten, macht einfach mal Pair-Programming, weil Pair-Programming ist ein Shift-Left vom Pull-Request-Code-Review.
Wolfi Gassler (00:24:37 - 00:24:44)
Jetzt haben wir endlich uns langsam an die Pull-Requests gewöhnt. Jetzt wirst du die Pull-Requests auch noch nach links schieben und wegrationalisieren.
Andy Grunwald (00:24:44 - 00:25:17)
Das nicht, aber ich würd fast sagen, hast du ein Feature im Paar programmiert, könnte man überlegen, ob man den Pull-Request-Step, also für den Code-Review, nicht für die automatischen CI-Checks, dafür nicht, aber für den Code-Review und dieses Ping-Pong und dieses Nitpicking, ob man den Teil skippt und dann sagt, wir beide, erstellen jetzt kurz ein PA, lassen die automatischen Checks laufen, wie zum Beispiel Hardulint und Shellcheck und mein Static Analyzer, haben wir ja gerade gelernt, und dann merken wir den einfach durch, weil wir haben den ja zu zweit bereits schon reviewed und programmiert.
Wolfi Gassler (00:25:18 - 00:25:52)
Also du hast mich gerade mit einem Wort überzeugt, das Nitpicking. Und nachdem dir so viele Leute hassen, dieses Nitpicking, also dass man irgendwelche Kleinigkeiten im Nachhinein anmerkt und dann ändert man die und dann werden wieder Kleinigkeiten angemerkt, die nicht so wichtig sind. Also das macht teilweise wirklich eine schlechte Stimmung im Team. Alleine wenn du das nach vorne ziehst und wenn du Peer Programming machst, dann redest du einfach darüber, kannst sofort irgendwie Gegenkontakt geben und Argumente bringen. Also alleine deswegen finde ich das schon eine geniale Idee eigentlich und darum liebe ich Pair-Programming auch so. Hast du mich schon überzeugt ausnahmsweise?
Andy Grunwald (00:25:52 - 00:26:40)
Du kannst auch Mob-Programming machen, wie du möchtest. Aber wir hatten schon die ganze Zeit darüber gesprochen, es kommt auch zum Testing. Ja klar, automatisierte Builds, automatisierte Unit-Tests, Akzeptanz-Tests, neuer heißer Scheiß, Performance-Tests. Ziemlich viele Sprachen machen auch Benchmark-Tests. Wir zum Beispiel als Datenbank-as-a-Service-Provider, immer wenn wir unser Betriebssystem updaten, also wir nutzen Fedora als Serversystem, dann machen wir auch weitläufige Performance-Tests. Wie verhält sich eine Postgreed-Datenbank auf Fedora 38 und auf 39? Haben wir da eine Regression drin und so weiter? Steigt die CPU an? Ja, so was muss auch gemacht werden. Ja, shift left, bevor wir das in Produktion deployen und dann der Kunde ein Support-Ticket aufmacht zum Beispiel. Sowas gehört dann auch dazu.
Wolfi Gassler (00:26:40 - 00:27:38)
Ich glaube, dass da auch einfach in der Vergangenheit viel mehr dazugekommen ist, weil früher hat man das vielleicht in der Datenbank-Welt gemacht. Das ist ein alter Hut. Vor 20 Jahren hat die DB2 und Oracle genauso tagelang irgendwelche Tests durchlaufen lassen, automatisierte Tests. Aber das war halt absolut speziell für Datenbank und für die Datenbank-Welt. Und jetzt ist es halt fast Standard, wenn du irgendwie eine Software hast, die einigermaßen kritisch ist, dass du halt auch Performance-Tests durchlaufen lässt, weil es halt einfach wichtiger geworden ist vielleicht und auch einfacher, muss man auch dazu sagen. Und darum ist es halt jetzt wieder einfach Stand der Technik, würde ich sagen. Aber es ist natürlich jetzt viel dazugekommen zu der ganzen normalen Unit-Test-Schreiberei und vielleicht mal ein Acceptance-Test, jetzt kommt halt schon wieder ein Performance-Test dazu und so wird halt eigentlich das Ganze immer aufwendiger und man muss immer dazu lernen und früher hat man das halt abgeschoben und jetzt muss man den Teil halt auch nochmal mitmachen und auch verstehen.
Andy Grunwald (00:27:38 - 00:28:21)
Viele Firmen machen das vielleicht nicht automatisiert während eines Code-Builds, aber dann vielleicht ein paar Wochen vor ihrem saisonalen Hoch wie zum Beispiel Black Friday. Also ich weiß zum Beispiel, dass Trivago auch saisonales Geschäft hat und die Leute aus dem Site Reliability Engineering Team haben da auch ihre Load Tests inzwischen automatisiert. Bevor die Hochsaison beginnt, stoßen die einmal an, oft fliegt dann da auch was um die Ohren und dann haben sie noch ein paar Wochen das zu fixen. Also das ist ja auch schon Shift Left. anstatt einfach den, weiß ich nicht, Black Friday kommen zu lassen, Leute auf On-Call zu haben und dann den Inzident während der Hochverkaufssaison zu haben. Also das ist ja auch eine Art von Shift Left.
Wolfi Gassler (00:28:21 - 00:28:59)
Aber jetzt musst du mir mal was erklären, weil wir haben ja in Episode 101, was war das für eine Episode? Andi, du kannst alle Episoden auswendig. Da muss ich dir wieder antworten. Observability und Open Telemetry mit Severin. Da haben wir ja eigentlich besprochen, dass man mit Telemetriedaten die Applikationen überwachen kann. Wäre das jetzt eigentlich nicht wieder ein Shift-Right, weil ich ja dann meine ganzen Performance-Tests eigentlich im Produktivsystem mache und dort die ganzen Daten und Telemetriedaten sammle, um dann Rückmeldungen zu kriegen, also möglichst schnell zu shippen, um dann wieder die Informationen zu bekommen. Das wäre ja eigentlich fast ein Shift-Right.
Andy Grunwald (00:28:59 - 00:30:08)
Teilweise ja, aber eher nein, weil folgendermaßen. Ich meine, mit Open Telemetry und auch mit den Metriken und den Logs und dem Tracing, dass so was Standard in deiner Applikation ist, ist ja jetzt auch noch nicht so alt. Applikationen von vor acht Jahren wurden eigentlich so geschippt, die haben in der Regel keine Metriken nach außen gegeben. Das waren Blackbox-Systeme für den Betrieb, für das Operations. Und die haben dann per Nagios einfach geguckt, aha, rennt da der Prozess, verbraucht der Prozess gerade noch so und so viel RAM, Aber inzwischen machst du mit OpenTelemetry, gibst du ja die Innerdaten deiner Applikation raus. Wie viele Bestellungen wurden in der letzten Minute gemacht und so weiter und so fort. Das bedeutet, das ist für mich eigentlich ein Shift Left, weil jetzt auch Metriken für den operationellen Betrieb während der Entwicklungsphase bereits in die Software eingefügt werden und nicht erst wir shippen das und dann fragt Ops nach, Ja aber Moment mal, der gibt ja einen falschen Exitcode raus, aber ich brauche den Exitcode 0 und dann geht das wieder in die Dev-Abteilung und so weiter. Die Devs kümmern sich gerade jetzt schon, welche Metriken wollen wir eigentlich.
Wolfi Gassler (00:30:09 - 00:30:32)
Okay, also die Metriken werden zwar generiert oder aufgenommen auf der rechten Seite, aber sie fließen eigentlich wieder zurück auf die linke Seite ins Dev-Team, die ja die beauftragt haben sozusagen auch durchs Coding und die fließen auch wieder zurück und gehen nicht durch ein Ops-Team, das dann die Auswartung macht und dann erst wieder die Developer informiert. Also es hängt viel enger zusammen, wenn ich dich richtig verstehe.
Andy Grunwald (00:30:32 - 00:31:49)
Ja, also ich meine, wir hatten in der Optelemetrie gesagt, okay, es gibt drei Signale. Die Metriken, okay, das ist für den operationellen Betrieb eigentlich sehr gut. Tracing, und da kommt es jetzt wieder ans Performance-Testing, welcher Function Call verbraucht wie viele Millisekunden, würde ich fast sagen, ist eher eine entwicklerspezifische Metrik oder ein entwicklerspezifisches Signal. Und jetzt nehmen wir mal Logs und jetzt Besonders in Bezug auf Datenbanksysteme, die Logs prozessen, in OpenSearch, in Clickhouse und so weiter, da machen ja Structured Logs ja noch mehr Sinn. Und ich würde schon fast sagen, Structured Logs sind ebenfalls eher aus der Entwicklungssparte anzusiedeln, anstatt aus der Opsparte. deswegen die ganze sache hat schon ordentlichen shift left und jetzt lehne ich mich mal aus dem fenster ich denke umso mehr leute open telemetrie beziehungsweise diese metriken einbauen desto eher geht es dahin dass bald die entwicklerinnen und entwickler auch die alerts zum beispiel in der sprache wie prom ql oder ähnliches schreiben dass sie dann den Ops Leuten auch wirklich sagen, hey, ich würde da drauf checken, weil ich bin der Domänenexperte und ich weiß, wie diese Metrik sich verhält. Hier, ich habe dir schon mal den PromQL Alert geschrieben.
Wolfi Gassler (00:31:49 - 00:32:23)
Und wenn wir schon bei Alert sind, ein super Übergang. Heute können wir wirklich viele Episoden erwähnen, nämlich in Episode 60, haben wir über On-Call gesprochen. Und das ist natürlich auch eine Entwicklung, dass Entwickler an sich in dem Team viel mehr in On-Call-Rotationen auch mit dabei sind und auch die Metriken auswerten und die ganzen Informationen bekommen und dann halt auch wirklich sofort reagieren, auch wenn es in der Nacht ist. Also auch da gibt es eigentlich einen Shift-Left-Move im On-Call, weil früher hat es halt nur der Admin gemacht, der da rausgeleitet wurde in der Nacht.
Andy Grunwald (00:32:23 - 00:32:43)
Ich kann dir jetzt auch noch sagen, die Gegenwehr von Softwareentwicklerinnen und Softwareentwickler ist immer noch sehr hoch auf Wurfbereitschaft zu sein. Keiner macht's gerne. Aber ich sage es jedem Gegner, der jetzt am Kopfhörer sitzt oder im Auto oder wo auch immer und das hört und sagt, nein, ich werde nicht on call sein, versucht es mal.
Wolfi Gassler (00:32:43 - 00:32:48)
Und hört euch die Episode 60 an, weil da kommen noch mindestens 20 weitere Argumente von Andi.
Andy Grunwald (00:32:48 - 00:33:05)
Ihr werdet bessere Devs, wenn ihr das Zeug betreibt und dafür auch gerade steht. Ihr macht denselben Fehler nicht zweimal. Ihr werdet bessere Devs. Ich sag's euch, probiert mal. Ihr könnt ja auch auf Second-Level-On-Call sein, aber quatscht mal mit eurem Ops-Team.
Wolfi Gassler (00:33:05 - 00:33:12)
Aber wenn jetzt das ganze Team, also auf der linken Seite, Shift-Left, mehr Responsibilities, mehr ... Wie nennt sich das auf Deutsch?
Andy Grunwald (00:33:12 - 00:33:13)
Verantwortungen.
Wolfi Gassler (00:33:13 - 00:33:26)
Danke. Verantwortungen hat. Darf das Team dann auch mehr mitbestimmen auf der rechten Seite, also auf der Plattform-Seite, auf der Admin-Seite? Also gibt es einen Kanal zurück auch auf die rechte Seite?
Andy Grunwald (00:33:26 - 00:35:10)
Ja, Plattform und Infrastruktur ist natürlich ein tolles Thema, weil besonders in dem ganzen Cloud-Movement geht es ja immer noch mehr an Infrastruktur als Code. Und umso spezialisierter es wird, ich gehe jetzt mal in die Bereiche ML Ops, AI Ops, wie betreibt man Modelle auf Infrastruktur und Co. Ich würde fast sagen, da ist die Mitbestimmung bzw. der direkte Austausch unausweichlich. Denn die Software muss ja auch an die Infrastruktur angepasst werden. Nehmen wir mal AWS Lambda Funktionen. Du musst ja mit der AWS Lambda API und mit dem SDK sprechen, damit das alles ordentlich stattfindet. Oder nehmen wir mal Amazon EC2 Instanzen und dann bist du kostengünstig auf Spotinstanzen unterwegs. Und Spotinstanzen senden dir zum Beispiel, ich glaube, 60 oder 40 Sekunden, bevor die runterfahren, ein Signal. Diese Signale musst du ja catchen. Also, in irgendeiner Art und Weise muss eine Kommunikation da sein. Und desto spezifischer die Anforderungen werden, auch in Bezug auf proprietäre Nutzungen oder proprietäre Service bei Cloud, denn Achtung, du nutzt einen Cloud-Provider nur effizient, Wenn du dich dann auch auf die proprietären Systeme von diesem einlässt, damit du auch die volle Power nutzen kannst, da muss natürlich in irgendeiner Art und Weise eine Mitbestimmung oder ein Kommunikationskanal da sein. Wo es natürlich anders ist, wenn du ein Plattformteam hast, was dir natürlich alles sehr eng stirnig zusammenstellt. Aber auch da muss das Plattformteam dann auch, ich sag mal, Umfragen machen, um die Developer-Experience hochzuhalten. Es gibt ja auch schon, ich sag mal, Serverless-Functions, die du auf deinem eigenen Cloud-Provider laufen lassen kannst und so weiter. Also ein offenes Ohr muss da auf jeden Fall sein, damit die Entwickler-Experience und die Developer-Experience halt hochgehalten werden kann.
Wolfi Gassler (00:35:10 - 00:35:45)
Also ich filme gerade, wie so eine Meta-Episode, wo wir alle anderen Episoden irgendwie zusammenfassen. Aber ich habe schon wieder eine Referenz auf Episode 103, wo wir über Plattform-Engineering gesprochen haben. Und genau darin, haben wir auch gesprochen über dieses Business-Mindset, dass die Plattform-Engineers eigentlich ja ein Produkt anbieten und ihre Kunden verstehen müssen und die Kunden sind jetzt die Developer auf der linken Seite. Das heißt, hoffentlich fragen die auch die Developer, was braucht ihr, was wollt ihr eigentlich erreichen, was können wir euch anbieten, dass da wirklich eine bidirektionale Kommunikation stattfindet und die die Kunden halt auch dementsprechend bedienen.
Andy Grunwald (00:35:45 - 00:35:49)
Es ist ja keine Werbeveranstaltung für vorherige Engineering-Kiosk-Episoden.
Wolfi Gassler (00:35:49 - 00:35:50)
Klingt nur so.
Andy Grunwald (00:35:50 - 00:37:26)
Aber es ist halt wirklich so eine Art ... Wie soll ich das sagen? Ja, alter Wein in neuen Schläuchen, nur ein bisschen weiter gedacht. Weil wenn wir jetzt mal an weiter gedacht denken, was jetzt gerade der neueste heiße Scheiß ist, ist FinOps, Financial Operations. Da geht's eigentlich darum, wir hatten grad das Jahr der Effizienten, ihr erinnert euch an meinen kleinen Wirtschaftsinformatikexkurs mit der makroökonomischen Lage. Die Cloud ist leider auch nicht gratis. Und viele Firmen versuchen gerade, ihre Cloud-Kosten zu reduzieren. Da sind wir natürlich im Shift-Left-Bereich super aufgehoben. Weil was wäre denn, wenn deine Software-Entwickler sich während des Entwicklungsprozesses oder auch die Operations-Leute oder die DevOps-Leute während dem Schreiben von Infrastructure as Code bereits Gedanken machen über ihre Cloud-Kosten. Wenn ich jetzt in Teraform drei neue Nodes hochstarte, wie teuer sind die? Und was ist, wenn man im Continuous-Integration-System oder im Pull-Request schon einen Report kriegen würde, wie teuer wird es, diesen Terraform-State oder Ansible-State oder was auch immer auszuführen? Dazu gibt's natürlich jetzt auch schon Tools. Ein Tool nennt sich InfraCost, ist so eine Cloud-Cost-Estimation-Geschichte für Terraform. Im Endeffekt geht's eigentlich um Automatisierung von Kostenanalysen und dass frühzeitig ein Bewusstsein für die Kostenentwicklung von Cloud-Ressourcen geschaffen wird. Und wenn man das einfach mal kontinuierlich weiterdenkt, klar, jetzt haben wir gerade gesagt, kommt Security mit in den Mix, aber jetzt bald kommt auch das Finanzdepartment in den Mix, um die Cloud-Kosten weiter runterzutreiben.
Wolfi Gassler (00:37:27 - 00:37:42)
Jetzt hatten wir am Anfang DevOps oder am Anfang hatten wir eigentlich Ops, dann hatten wir DevOps, jetzt ist die Security Sache dazu gekommen, jetzt haben wir DevSecOps. Wenn du jetzt die Finanzwelt noch dazu bringst, haben wir dann DevSecFinOps. Gibt es diesen Begriff?
Andy Grunwald (00:37:42 - 00:38:00)
Den Begriff in einem habe ich noch nicht gehört, aber FinOps ist jetzt der neue heißer Scheiß, der gerade rüberkommt. Aber wir können auch weitersprechen. Es gibt ja auch HR Ops, Legal Ops, BIS Ops, LLM Ops, Cloud Ops, Data Ops. Also es gibt... Nimm einfach irgendwas, mach eine Abkürzung drauf und pack da Ops dran.
Wolfi Gassler (00:38:00 - 00:38:20)
Operation ist wichtig. Ich sehe es schon. Aber so, jetzt habe ich heute schon mal die ganze Fragerolle da gebachtet. Jetzt kann ich auch mit deinen Klassikern kommen. Jetzt komm mal runter da von deiner grünen Wiese und von deiner Marketingveranstaltung, von unseren anderen Episoden und wie toll das nicht alles ist, da nach links zu rücken. Gibt's denn keine Nachteile auf der linken Seite?
Andy Grunwald (00:38:20 - 00:38:25)
Naja, die erste Frage ist, die, ich sag mal, vor dir am Tisch liegt.
Wolfi Gassler (00:38:25 - 00:38:30)
Nein, es ist nicht politisch gemeint, wenn du das jetzt fragen willst. Ich rede schon von der Shift-Left-Ecke.
Andy Grunwald (00:38:30 - 00:38:53)
Schon klar. Nur, wie viel soll Entwickler denn noch tun? Also, wie viel Verantwortung kann denn ein einzelner Job haben? Ja, ich wiederhole mich noch mal. DevOps ist keine Person, das ist ein Konzept. Weil es ist ja nicht so, als können ... Kann eine Softwareentwicklerin 100 Prozent Entwicklerin sein und 100 Prozent Operationsperson. Und Achtung, DevSecOps ist nicht eine Person, die drei Jobs macht.
Wolfi Gassler (00:38:53 - 00:39:27)
Wir haben auch gerade in unserer Discord-Community eine Diskussion am Laufen. Und da hat auch ein Mitglied aus einem DevSecOps-Team geschrieben, entwickelt hauptsächlich, und er will sich eigentlich nicht mal mit der Datenbank auseinandersetzen, weil er da eigentlich ein OMR dazwischen hat. ORM, nicht OMR. Habe ich jetzt OMR gesagt? Klassischer Fehler, ORM. Und dass das schon eine Zusatzbelastung ist und die in seinem Fall einfach nicht so wichtig ist, die Datenbank jetzt intus zu kennen, Verstehe ich auch, aber da sprechen wir jetzt gar nicht noch von den ganzen anderen Bereichen, die man abdecken soll.
Andy Grunwald (00:39:28 - 00:40:11)
Ja, das ist halt wirklich die Frage, die auf dem Tisch liegt, weil Entwicklerinnen sind dann eigentlich für Qualitätssicherung, Sicherheit, Effizienz, Monitoring, Finanzen der Software zuständig. Und dann fragt man sich, okay, die Komplexität deines Jobs wird halt echt hart steigen und auch das Wissen über die Best Practices, weil im Endeffekt musst du ja verstehen, wenn du einen Prozess, einen menschlichen Job, einen menschlichen Prozess versuchst, in ein automatisiertes Tool zu überführen und somit das Left zu shiften, dann musst du ja schon wissen, wie es richtig funktioniert. Du wandelst also ein Best Practice um oder du wendest den Best Practice an. Und wie viel Best Practices aus anderen Disziplinen musst du denn drauf haben? Also das ist ja schon eine harte Sache.
Wolfi Gassler (00:40:12 - 00:40:39)
Aber heißt das eigentlich, dass man immer mehr in Richtung, so wie ein Startup funktioniert eigentlich geht, aber auf Team-Ebene, dass man sagt, okay, man braucht eigentlich alle Spezialfunktionen irgendwie im eigenen Team und dann kauft man sich natürlich gewisse Sachen durch die Automation, von einem Cloud-Ambiter oder von einem internen Plattform-Team quasi dazu, aber man braucht das gesamte Knowledge im Team, entweder in einem Kopf oder in ein paar Köpfen, aber zumindestens alles lokal im Team.
Andy Grunwald (00:40:39 - 00:41:11)
Ja, auf jeden Fall bist du einem gewissen Grad, denn im Endeffekt hast du dann ein Teil implementiert, weiß ich jetzt, sagen wir mal Security oder Monitoring oder ähnliches oder Observability, Dann können die Leute, die müssen ja jetzt da nicht neben dem CI-System sitzen und dann immer aufs CI-System schauen, die können sich dann um weitere Dinge kümmern, was euer Security-Bereich dann aufs nächste Level hebt, um ein neues Tool zu schreiben oder oder oder, was dann halt auch immer notwendig ist. Und dann kann man sich die, dann braucht man die Leute halt nicht mehr im Team, sondern eigentlich in der Firma und dann können die halt, ich sag mal, zentralisiert arbeiten in einem Plattform-Team oder eben.
Wolfi Gassler (00:41:12 - 00:41:56)
Ja, aber das sind die Spezialisten, klar, die nochmal tiefer gehen. Aber ein Grundverständnis brauche ich schon in meinem Team. Es gibt zwar einen Spezialisten, der vielleicht dieses Tool schreibt, das mir die Dockerlöcher aufspürt, aber dass ich dieses Tool überhaupt brauche und was eigentlich für Probleme mit Docker kommen oder mit meinem klassischen Linux-System ist ja ganz egal oder mit meiner Software und Libraries, mit meinen Abhängigkeiten, dieses Wissen, brauche ich natürlich schon im Team, um mal überhaupt zu wissen, welche Tools soll ich verwenden, auf was muss ich Acht geben, was gibt es vielleicht auch für Einfallstore, gerade wenn es um Security geht, in meiner Software. Also diese Dinge braucht man natürlich schon, weil die kann man schwer automatisieren. Man kann natürlich schon gewisse Tools zur Verfügung stellen, aber ein Grundwissen brauche ich trotzdem, ein Verständnis von dem Ganzen.
Andy Grunwald (00:41:57 - 00:42:21)
Also in der Zukunft werden sich die Erwartungen an dich als Softwareentwickler deutlichst erhöhen. Und das ist ja genau unser Intro gewesen. AI ist meines Erachtens nach vielleicht ein Risiko für deinen Job. Aber ich finde dieser Shift-Left-Ansatz, wenn du da stehen bleibst, ich denke das ist ein größeres Risiko, ich sag mal, abgehängt zu werden.
Wolfi Gassler (00:42:22 - 00:42:53)
Aber das heißt auch, dass man die klassischen T-Shaped, also diese Formen wie ein T, dass man so ein Grundwissen oben hat und dann irgendwo in die Tiefe geht, dass diese eher aussterben, weil man irgendwie diesen Strich vom T eher nach oben schiebt und eigentlich in mehr Bereichen grundlegende Informationen oder auch vielleicht so halb tiefgehende Informationen oder Wissen benötigt, um überhaupt den Job zu erfüllen und es immer weniger Spezialisten gibt oder die Spezialisten dann halt in diesen externen Teams draußen arbeiten.
Andy Grunwald (00:42:53 - 00:43:00)
Ich denke einfach, dass der horizontale T-Strich einfach länger wird. Die Spezialisierung musst du weiter aber haben, um Wert im Team zu leisten. Aber der horizontale T-Strich wird einfach nur länger.
Wolfi Gassler (00:43:01 - 00:43:10)
Du bist gut, du machst da einfach irgendwelche Striche länger. Da hängen ja viele Weiterbildungen und Kurse und Informationen dran zu dem Strich.
Andy Grunwald (00:43:10 - 00:43:33)
Das weiß ich und ich habe auch größten Respekt davor. Und auch ich frage mich, wie kriegt man das alles in meinen Kopf? Denn Achtung, ich werde leider nicht jünger und man merkt ja jetzt schon, ich bin auch keine 20 mehr. Aber Leute nach dem Studium, sage ich dir ganz ehrlich, die hängen mich jetzt schon ab in der Geschwindigkeit, wie junge Leute neue Frameworks und neue Techniken lernen können. Also da sag ich auch nur Respekt.
Wolfi Gassler (00:43:33 - 00:43:40)
Jetzt kommt schon der alte Mann, der jammert, diese Jugend, die versteht ja nichts, die wendet nur alles an und kann ja gar nichts mehr in der Tiefe verstehen.
Andy Grunwald (00:43:40 - 00:43:41)
Das hab ich nicht gesagt.
Wolfi Gassler (00:43:41 - 00:43:46)
Und früher Assembler, wir haben alle noch Assembler kurz nach dem Krieg programmiert.
Andy Grunwald (00:43:46 - 00:44:09)
Nee, da möchte ich auch nicht zurück, aber nee, es wird eine Herausforderung. Und die Firmen werden mehr und mehr drauf schauen auf Automatisierung in allen Bereichen. Und SoftwareentwicklerInnen von heutzutage, die müssen sich mehr und mehr und mehr mit all diesen Bereichen, zumindest auf einem High Level, auf jeden Fall auseinandersetzen.
Wolfi Gassler (00:44:09 - 00:44:55)
Jetzt klingt das ja alles ganz nett, okay, man bildet sich da weiter und braucht halt mehr Wissen, dass man das Ganze bedienen kann, würde ich mal sagen. Aber wenn ich mich da so zurückerinnere an die ganze DevOps-Bewegung, ist ja kein Job, sondern ein Mindset, wie du mir immer beibringst. Da hat es ja schon sehr viel Konfliktpotenzial gegeben oder gibt es immer noch zwischen den Ops-Leuten und denen, die vielleicht dieses DevOps-Mindset voranbringen wollen, die Ops die irgendwas abgeben müssen auf die Developer-Seite, Kompetenzen abgeben müssen, vielleicht auch Kontrolle abgeben müssen oder dürfen, wie man sieht. Aber es hat auf jeden Fall ein hohes Konfliktpotenzial. Jetzt erweitern wir aber die Dimensionen da auf noch viel, viel mehr Dimensionen. Ist es nicht extremes Konfliktpotenzial, vor allem bei der Umstellung?
Andy Grunwald (00:44:56 - 00:46:25)
Sehr gute Frage und ich weiß nicht, ob meine Antwort richtig ist, aber ich präsentiere dir mal meine These. Das Konfliktpotenzial bei DevOps liegt in der Natur der Sache. Du hast Dev, die werden dafür bezahlt, Sachen zu ändern, Bugs zu fixen, Features zu entwickeln. Du hast Ops, die werden dafür bezahlt, Systeme stabil zu halten. Und du hältst Systeme stabil, indem du einfach nichts änderst. Und da hast du natürlich zwei entgegengesetzte Motivationen, die aufeinander clashen. Nehmen wir mal den Security-Bereich. Es kommen jeden Tag neue Exploits und neue Wege, wie du in ein System eindringen kannst und neue Informationen erhaschen kannst. Nehmen wir mal Heartbleed und Co. Das bedeutet, Security Folks sind von Haus aus, ich sag mal, dynamischer unterwegs. Die müssen sich jeden Tag mit neuen Sachen auseinandersetzen. Wenn die jetzt mit Entwicklerinnen zusammenarbeiten, dann ist das ein und dieselbe Motivation. Die sind beide auf derselben Dynamik unterwegs. FinOps, genau dasselbe. Du hast ein Finanzdepartment, deren Ziel ist es, zuzusehen, dass die Firma nicht zu viel Geld verbrennt. Und wenn sie ein Optimierungspotenzial finden, dann lass uns doch an dieser Schraube drehen. Klar, jetzt kann man sagen, okay, Entwicklerinnen sind jetzt nicht die Leute, die gerne Cloud-Kosten ausrechnen und diese optimieren. Ja, das stimmt schon. Aber da ist nicht so ein Konfliktpotenzial, so ein gegenläufiges Konfliktpotenzial wie bei Operations und Dev. Und deswegen denke ich, ist das nicht vergleichbar. Macht das Sinn? Würdest du da mitgehen?
Wolfi Gassler (00:46:26 - 00:46:59)
Ja, ich kann es irgendwo nachvollziehen, aber natürlich klassisch war ja Security immer in Ops angesiedelt und jetzt ziehst du Security in irgendeiner Form raus, also könnte da natürlich schon auch wieder Konfliktpotenzial drin sein. Aber ich verstehe natürlich, was du meinst, ja, weil gewisse Bereiche wie Testing, hat wahrscheinlich weniger Konfliktpotenzial. Das stimmt. Das hat eher vielleicht das Konfliktpotenzial, dass die Devs sagen, warum soll ich die testen? Ich will eigentlich nicht testen. Das ist so eine nervige Arbeit und eigentlich will ich keine Tests schreiben. Aber darüber sind wir, glaube ich, schon drüber. Das war ja die Diskussion vor zehn Jahren.
Andy Grunwald (00:46:59 - 00:47:27)
Für mich ist das so ein bisschen, Entwickler, die keine Tests schreiben wollen, sind für mich irgendwie Handwerker, die eine Duschtasse einbauen und nicht unter der Duschtasse abdichten wollen. Also ist für mich irgendwie das gleiche, du machst deinen Job, Alter, bin ich ordentlich. Und ja, natürlich schreibe ich nicht gerne Tests. Ich verstehe das, ich schreibe aber auch nicht gerne Dokumentation, aber der Zukunfts-Andi, der in einem Monat wieder auf die Software guckt, ist immer wieder glücklich, dass da Dokumentation ist. Also gehört halt einfach zur Profession dazu.
Wolfi Gassler (00:47:27 - 00:47:49)
Und man kann glaube ich einfach viel mit Automatisierung heutzutage abfangen. Also sei es jetzt von einem internen Plattform-Team, Security-Team, die da Tools zur Verfügung stellen, aber es gibt ja auch tausende Tools da draußen und das ist natürlich teilweise teuer und irgendwelche SaaS-Tools, die Security-Lags auch spüren, aber sie machen natürlich auch schon Sinn. Und so kann man sich natürlich auch wieder helfen.
Andy Grunwald (00:47:49 - 00:48:40)
Im Endeffekt muss ich jetzt auch mal die Arbeit und die Überwindung von Widerständen und Kollaborationsbarrieren und so weiter Ich finde das immer schwierig, wenn Leute sagen, das will ich jetzt aber nicht, weil im Endeffekt alle Leute, die für eine Firma arbeiten, wurden eingestellt, um den Traum von jemandem zu entwickeln, und zwar in der Regel von der Chefetage. Das bedeutet, alle sollten das Incentive haben, am selben Strang zu ziehen und das Ziel umzusetzen. Deswegen ist es natürlich fraglich, warum es Kollaborationsbarriere gibt und warum, ah, das möchte ich jetzt nicht und ah, nee, das macht ja alles instabil. Also immer, wenn man halt sagt, ah, das macht das alles immer instabil, dann frage ich mich, okay, dann switch doch mal in den Lösungsmodus. weil wir haben jetzt beide dieses problem auf dem tisch und das muss jetzt irgendwie von unserem tisch und deswegen verstehe ich es halt nicht und die ja das ist dann politik und allem drum und dran und kriege man kriegt man heils bei ja aber.
Wolfi Gassler (00:48:40 - 00:49:40)
Man muss natürlich schon, Sagen, das was du auch am Anfang erwähnt hast, es geht ja eigentlich um die Kommunikation und wie wir nicht müde werden zu wiederholen, Kommunikation ist nicht so leicht. Das heißt man muss wahrscheinlich schon auch in dem Bereich einfach investieren und darf die Kommunikationsseite nicht vergessen, weil die ganzen Teams in irgendeiner Form miteinander kommunizieren müssen. Und es ist keine reine technische Lösung. Und auch wenn man sagt, okay, Business-Mindset wäre besser, aber eigentlich geht es ja da auch ganz viel um Kommunikation, dass die Plattform-Teams ein Business-Mindset haben mit den Kunden, mit den Entwicklern, demnach sprechen. Also da findet überall Kommunikation statt. Und es kann ja durchaus sein, dass die Techies nicht immer die kommunikationsstärksten Leute sind. Ausnahmen bestätigen die Regeln natürlich. Aber da muss man, glaube ich, investieren und das darf man bei so Shift-Left-Änderungen, Prozessänderungen nicht vergessen, weil es ist halt doch immer noch eine große Prozessänderung und jede Prozessänderung hat Gegner und Gegnerinnen und dem muss man sich halt auch annehmen.
Andy Grunwald (00:49:41 - 00:50:21)
Eine Idee, die mir dazu seit ein paar Wochen im Kopf rumschwirrt, ist, du bekommst eigentlich immer nur das, was du inzentivierst. Was meine ich damit? Das Operations Team wird anhand von Sachen gemessen, wie stabil die Plattform ist. Das Entwicklerteam wird daran gemessen, wie viele Features die pro Monat oder in einem Cycle rausgehauen haben. Aber warum inzentivierst du denn beide Gruppen nicht gegeneinander? Warum sagst du nicht, das Operations-Team kriegt eine KPI vom Entwicklerteam und das Entwicklerteam kriegt auch eine KPI zur Performance-Messung vom Operations-Team? Dann haben beide automatischen Incentive, sich gegenseitig zu helfen.
Wolfi Gassler (00:50:21 - 00:50:49)
Aber ich glaube, das ist ein guter Punkt und wichtiger Punkt, dass du eben deine alten Prozesse nicht mehr gleich anwenden kannst, weil die KPIs, die du früher verwendet hast, funktionieren in so einem Modell vielleicht nicht mehr. Gleich wie die Kommunikation ein Problem ist, hast du gewisse alte Mechanismen, die du halt auch mit ändern musst im Leadership zum Beispiel oder eben wie machst du deine Zielsetzungen und solche Dinge. Es ist kein reines technisches Problem und das ist ein guter Punkt, da die ganze Leadership-Ecke natürlich auch nochmal mitzunehmen.
Andy Grunwald (00:50:50 - 00:51:21)
Gut jetzt umso umso höher das im leadership geht ja die werden shift left auf irgendeinem c level cto meeting mal gesehen haben oder gehört haben und dann werden das mit kosteneinsparung in verbindung gebracht werden und das haben die vom cfo der cfo liegt dir nämlich schon seit monaten im ohr dass du mal deine cloud kosten runterdrücken sollst. Dann lass doch einfach mal finden, ob es noch mal was shift left. So, buff. Für ein CTO ist das jetzt geregelt und dann kann sich das Mittelmanagement und die Engineeringmanagement-Riege nämlich damit rumschlagen und dann geht es natürlich an den Zielsetzer.
Wolfi Gassler (00:51:21 - 00:52:04)
Aber das war ja auch genau bei DevOps das Problem, dass die Ops-Leute ja verantwortlich sind, dass alles läuft und für die ist es eben schlecht, wenn es Ausfälle gibt. Jetzt haben sie das aber nicht mehr in der Hand, sondern müssen das aus der Hand geben oder auch Security, dass auf der Entwicklerseite das mehr gemacht wird. Das heißt, das hat natürlich dann sofort Konfliktpotenzial, wenn du die Rahmenbedingungen nicht änderst und dementsprechend musst du die Rahmenbedingungen halt auch immer mit ändern und ich glaube, da ist dann halt auch viel Kommunikation im Spiel und da sind dann irgendwelche Agile Coaches oder sonstige Leute, die halt mehr mit Kommunikation machen, Engineering Manager, dem ganzen Leadership Team auf allen Ebenen, die sind dann natürlich auch gefordert, das dementsprechend umzuändern und nicht nur irgendeine Technologieänderung zu machen oder, weil es halt gerade so cool ist, Shift-Left zu schreien.
Andy Grunwald (00:52:05 - 00:53:22)
Ja, wie du auch beschreibst. Also ich meine, Shift Left ist nichts Neues. Man könnte sagen, alter Wein in neuen Schläuchen. Hat angefangen damals mit Testing, was heutzutage, glaube ich, hoffentlich Standard in vielen Firmen ist. Zumindest ein bisschen Unit Testing, Akzeptanz Testing, Integration Testing oder ähnliches, was automatisch im CI-System läuft. Aber im Endeffekt geht es halt jetzt weiter. Da kommt Security mit in den Mix, da kommt Monitoring Observability mit in den Mix, da kommt Finance mit in den Mix, mit einer Infrastruktur. Und ich gehe stark davon aus, in den nächsten Jahren werden wir noch mehr Themen im Bereich Shift-Left auf uns zukommen sehen. Denn wie ich schon gesagt habe, in der Zukunft werden sich die Erwartungen an Softwareentwicklerinnen deutlich erhöhen. Und wie im Intro gesagt, Ich denke, umso mehr Shift Left es geben wird, desto höher ist gegebenenfalls auch das Risiko für unseren Beruf. Nicht, dass wir nicht mehr benötigt werden, aber dass wir gegebenenfalls abgehangen werden, weil wir kein Basiswissen in Security haben, weil wir kein Basiswissen in Operations haben, weil wir kein Basis in dem Wissen der Cloud-Kostenoptimierung und, und, und haben. Denn ein gewisses High-Level-Verständnis von der ganzen Sache musst du schon haben, sonst ist das vielleicht das nächste Jobrisiko. Und ja, sieh mal zu, dass dein T-Strich von deinem T-Shape-Developer, dein horizontaler T-Strich, mal ordentlich breiter wird, würde ich sagen.
Wolfi Gassler (00:53:22 - 00:53:34)
Oder wie es Björn aus unserer Community sagt, der Cum-Shape, er driftet schon immer weiter ab zu einem Cum-Shape, wie einem Cum mit ganz vielen Spitzen nach unten. Vielleicht ist das die Zukunft.
Andy Grunwald (00:53:35 - 00:53:53)
Das ist schön, das ist schön. Aber mein kleiner Win in dieser Podcast-Episode, Wolfgang zum Shift-Left-Fan gemacht zu haben, um endlich mal einen validen Use-Case für Pair-Programming gefunden zu haben. Oder eine gute Management-Argumentation. Kann der gute Consultant jetzt wieder verkaufen.
Wolfi Gassler (00:53:53 - 00:54:41)
Ich würde sagen Personal Pain, den ich immer bei Leuten spüre, die da kämpfen. Aber ich bin ja ein alter Shift-Left-Fan, also hab da ja auch viel schon mitgemacht im negativen und positiven, bin aber immer noch voll überzeugt. Uns würde aber natürlich auch eure Meinung dazu interessieren, also kommt vorbei in unsere Discord-Community, erklärt uns, ob ihr T-Shape, Cum-Shape, keine Ahnung was für ein Shape bevorzugt und Warum? Hoffe, spannende Diskussionen. Auch vor allem, wenn ihr anderer Meinung als der Andi seid. Das freut mich immer am meisten. Kommt gerne vorbei. Und alle Episoden, die wir erwähnt haben, sind natürlich auch in den Shownotes. Könnt ihr direkt draufspringen, um jeweils in die Tiefe zu tauchen. Und sonst freuen wir uns natürlich auch, wenn ihr uns weiterleitet, empfehlt, irgendeinen Stern vergebt oder irgendeinen Daumen nach oben. Was es auch immer ist. Egal auf welcher Plattform.
Andy Grunwald (00:54:41 - 00:54:48)
Das war der Werbespot von Dr. Wolfgang Gassler. Und jetzt zurück. Nehmt ernst. Hat Spaß gemacht. Tschüss, bis zum nächsten Mal. Bye bye.
Wolfi Gassler (00:54:49 - 00:54:59)
Ciao. Und nicht vergessen, 50.000 Euro für dein Open Source Projekt für sechs Monate einzureichen bis Ende März. Also gib Gas. Link findest du in den Show Notes.