skalierbar und performant in der Cloud funktionieren kann.

Ja, sehr cool. Das zeigt schon deine Expertise. Das heißt, nur theoretisches Wissen. Du bist auch noch tief drin, schreibst selbst Code, selbst wenn es nur Demo ist, aber du weißt, wie es Vielleicht holst uns noch mal ab, wie bist du zur Technologie gekommen, was waren so deine Stationen, bist du zur AWS gekommen bist und verrat uns den Geheimtrick, wie landet man bei AWS.

Den habe ich leider auch nicht. Und ich muss gestehen, meine Tech-Begeisterung kam erst relativ spät. Also in der Schule hättest du mich gefragt, das war völlig klar, wollte ich erst Lokführer werden. Und wenn das nichts wird, Astronaut, und wenn das auch nichts werden würde, und es ist leider auch nichts geworden, dann wollte ich Lego-Designer werden. Da ist aus allem nichts geworden, und das hat damit zu tun, dass ich irgendwann, als es so bisschen auch in Richtung Berufswahl ging, eine Dokumentation, Bericht,

über Roboterfußball gesehen habe. Und genau das will ich auch machen. Und habe dann eben gesucht, was muss ich dafür tun? Und da wurde relativ schnell oder wurde mir dann relativ schnell klar, es war schön und gut Roboter bauen, zu bauen, zu schweißen, zu löten. ist eh, handwerklich bin ich eh nicht so geschickt, sondern was für mich faszinierender war, die Intelligenz an der Stelle. Und das ist jetzt schon ein paar Jahre her. Das heißt, wir haben da große Fortschritte gemacht. Aber selbst damals schon fand ich super spannend zu sehen, wie eben verschiedene

Heute würde man sagen, Agenten, verschiedene Komponenten, verschiedene Teile des Systems versuchen, intelligent miteinander zu spielen und auch gleichzeitig eben gemeinsam Ziel zu erreichen und andere eben versuchen, das zu blockieren. Hab deswegen Informatik studiert, einfach weil ich eben wissen wollte, wie kann ich selbst so was umsetzen, selbst so was erreichen. Bin dann aber kein Roboter-Fußballer geworden, leider, sondern hab dann irgendwann für mich auch das Thema Machine Learning entdeckt und hab dann in der Richtung

mich bisschen weiter vertieft. Aber als es dann irgendwann an der Zeit war, so Uni ist fertig, man steht so vor dem großen Tor zur Welt, da war mir eigentlich noch gar nicht so klar, wie kommt man jetzt richtig, kommt man da richtig rein? Und habe deswegen hier in Frankfurt bei einem großen europäischen Konzern angefangen, einfach als Software-Entwickler. ich Möglichkeiten, da kann ich mich weiterentwickeln in die verschiedensten Bereiche.

Das Spannende war nur, dass das der totale Kulturschock war. Man kommt eben als frischer Uniabgänger, agile Softwareentwicklung, hat das Manifest quasi verinnerlicht. Und ich bin dann in einem Projekt gelandet für einen öffentlichen Sektor, für Bundesbehörden. Und es wurde nach Wasserfall entwickelt. Also sechs Monate vorher bespricht man sich mit dem Kunden und kehrt dann in seinen seinen Kämmerlein zurück, dann zu entwickeln. Totaler Kulturschock.

fand ich super schwierig und gerade auch eben mit der mangelnden Erfahrung, denkt man sich oder hab ich mir dann gedacht, ja gut, ich muss jetzt erstmal durch und irgendwie nach einer gewissen Zeit, so nach zwei Jahren, hab ich mich schon gefragt, richtig Spaß, mach das jetzt hier nicht, ist es eigentlich der richtige Job für mich? Und dann gab es zufälligerweise, glücklicher Zufall, eine E-Mail bekommen, eine Nachricht bekommen von einem Recruiter von Amazon, der sagte, hey, hast du nicht Bock bei uns zu interviewen? Wir suchen noch Softwareentwickler.

Und ich dachte mir, das Schlimmste, passieren kann, ist, dass ich einen bezahlten Trip nach Luxemburg bekomme. dachte, okay, sign me up. Da also hin und offensichtlich auch einen halbwegs akzeptablen Eindruck hinterlassen. Denn dann, ich glaube, es war 2015, sorry, eben als Softwareentwickler für Amazon in Luxemburg angefangen. Genau, das war auch so aus meiner Sicht eine prägende Zeit, total prägende Zeit. Das war auch genau die Phase,

in der auch aus meiner Sicht und auch hier bei uns so richtig die Entwicklung groß nochmal in Richtung Cloud gab, einen Riesenschub in Richtung Cloud, auch für mich, wirklich so Räume eröffnet hat. genau, wenn da dann so richtig gestartet, würde ich sagen.

Ja, sehr cool. Roboter waren keine zu sehen, aber du machst jetzt Cloud.

Genau, Roboter

gibt es bei uns in anderen Bereichen, aber mich hat dann doch die Cloud noch mehr fasziniert.

Okay.

Vielleicht schaffst du es ja irgendwann dann auch wieder zu den Robotern. Das Thema wird ja jetzt erst ganz interessant. Ja super, das heißt, über einen Recruiter bist du quasi angesprochen worden. Du eine der wenigen Stellen auch hier in Frankfurt dann, weil Amazon natürlich nicht sehr viele Stellen hat. Glückwunsch dafür. Du arbeitest als Senior Solution Architekt. Was macht ein Senior Solution Architekt und was fasziniert dich so?

der Reis. Genau.

an diesem Job.

Genau, ist eine super spannende Frage und vielleicht noch kurz als Ergänzung. Ich habe nämlich auch eine Besonderheit bei uns, dass ich Amazon irgendwann wieder verlassen habe, aus familiären Gründen und zwischendurch noch woanders gearbeitet habe und jetzt erst seit drei Jahren, seit 2021 wieder hier in den Frankfurtern auch tätig bin. Hättest du mich zu dem Zeitpunkt früher gefragt, Solution Architect, hätte ich auch nicht gewusst, was der da eigentlich tut, was man da eigentlich tut.

Und für mich, meine Erklärung ist quasi die Folgendrache, so wie ich es versuche zu erklären, ist, dass ich anfangs als Software-Entwickler, als Software-Architekt gearbeitet habe, war aber halt sehr nah an der Technik. Und was mich dann fasziniert hat, ist noch viel stärker zu verstehen, was denn eigentlich das Businessproblem desjenigen ist, der auf der anderen Seite sitzt. Also was versucht er denn zu erreichen? Weil dadurch der der Lösungsraum auch viel, viel größer wird, weil man eben nicht nur eine Anforderung bekommt, das muss innerhalb von

20 Millisekunden dies oder das tun und auch irgendwelche nicht-funktionale oder auch funktionale Anforderungen, sondern er eben viel tiefer versteht, was die Aufgabe ist und da auch viel mehr Einfluss, sagen wir mal, hat und auch noch beratend vielleicht tätig werden kann. Jetzt aber zurück, was mache ich als Solution Architect? Was ist denn eigentlich meine Aufgabe? Aus meiner Sicht ist das der beste Job, man haben kann. Warum? Warum? Ich sitze genau an der Schnittstelle zwischen der Technik. Ich habe also einen Hintergrund als Software-Entwickler, als Software-Architekt.

also da mitreden, aber auch auf der Businessseite. da sind eben, es sind Fachbereiche, sind Entscheider auf der Businessseite, die ich und zwischen denen übersetze ich. Ich muss also beide Seiten verstehen, kann die Sprache auch aus beiden Domänen verstehen und zwischendrin übersetzen. Und dann habe ich noch einen dritten Standbein oder einen dritten Aspekt, den hast du auch schon angesprochen, und das ist eben

Ich sage mal, Speaking, sind das Konferenzen, das White Paper, sind das Blog Posts. Also man kann auch in Richtung des Content Creations noch aktiv werden. Also man hat eben diese wunderbare Mischung aus Personen, aus Business, aus Prozessen, aus einer Organisation, aber auch noch natürlich, je nachdem wie man sich selber so sein seine Nische, sein Nest baut, auch viel Technik. Und das finde ich super faszinierend.

Ja, hört sich spannend an. unserem Vorgespräch hast du gesagt, du hast noch mal kurze Zeit in einem Start-up gearbeitet und warst wirklich, build it, you run it in der, ich sag mal, DevOps-Verantwortung. Wie viel nimmst du davon immer noch mit? Weil ich glaube, diese Praxis mal gespürt zu haben, wirklich liefern zu müssen und dort dann halt auch aktiv in der Verantwortung zu stehen. Hilft dir das heute noch in der Beratung mit den Teams?

Ja, absolut. Und auch wenn es nur der Aspekt ist, dass es quasi Glaubwürdigkeit vermittelt. Also ich erzähle nicht nur von irgendwelchen Konzepten und irgendwelchen Ideen, die ich in einem Buch gelesen habe, sondern ich kann da auf persönliche Erfahrungen zurückgreifen und erkenne auch genau den Schmerz und auch die Diskrepanz manchmal zwischen Wirklichkeit und dem Plan, den man formuliert, im Sinne von, wenn man selbst verantwortlich ist, dann hat man ja ein höheres Interesse.

sauberer, ordentliche Software zu schreiben oder irgendwie stabileres Software. unterstellt ja irgendwo, dass man es sonst nicht tun würde. Und ich gehe eigentlich davon aus, dass jeder versucht, seine bestmöglichste Arbeit irgendwie abzuliefern. Also das führt ja nicht automatisch dazu, dass man nachts drei rausgeklingelt wird, dass dadurch die Software automatisch besser wird. Dann hat manche auch den genau gegenteiligen Effekt. Das heißt also, das war einerseits bereichernd, ist natürlich aber auch, und müssen wir ganz ehrlich sein, das auch eine Belastung.

von der Einteilung her, von der Verantwortlichkeit her und auch wie das dann auch die Freizeitgestaltung natürlich bisschen mit beeinflusst. Von daher eine super Erfahrung habe ich in meiner aktuellen Rolle auch nicht mehr. Einer der weiteren Gründe, warum die Solution Actik so toll ist.

Ja.

Ja, sehr schön. Ich glaube, ist wirklich das. Man weiß dann, was die Teams, dann später deine Beratungen umsetzen sollen, wirklich auch in ihrem Backlog haben, was auch dazugehört, in Rufbereitschaft unterwegs zu sein, können das mitnehmen. Jetzt aber im Ernst, es gibt ja auch starke Charaktere dort. Irgendwelche Architektin, die wirklichen ...

gutes Wissen schon haben, die auch dafür bezahlt werden, nicht ihre Meinung dauernd zu ändern und jedem Hype hinterher zu laufen. Wie schaffst du es denn, die auf einer vielleicht auch nicht technischen Ebene abzuholen, dass es jetzt vielleicht mal gut wäre, noch mal den einen oder anderen Service mal ausprobieren oder den technischen Horizont zu erweitern? Kann ich mir vorstellen, dass es nicht immer einfach ist? Hast du da irgendein Geheimrezept für mich, wenn ich das nächste Mal mit Architekten spreche?

Ich wünschte, ich hätte eins, das Geheimrezept. Das würde ich jetzt eh nicht verraten. Spaß beiseite. Ich glaube, ist wichtig, auch immer, und das habe ich auch gerade eingangs gesagt, dieses Übersetzen. Wichtig ist, die Sprache zu sprechen. ich da auftauche und irgendwelche Buzzwords, irgendwelche Frameworks reinwerfe, ohne zu verstehen, was sie denn eigentlich tun, irgendwelche Technologien einfach nur erwähne, irgendwie die Namen erwähnen zu haben, wo dann relativ schnell klar wird.

Der hat eigentlich gar keine Ahnung von dem, was er erzählt hat, irgendwo gelesen. Das heißt, die eine Dimension ist wirklich diese technische Authentizität. Also die Glaubwürdigkeit, ich weiß, wovon ich rede, dass ich das ausprobiert, dass ich das selbst gemacht habe und nachvollziehen kann. Zu einem gewissen Maße natürlich, was gerade da vorgeht. Und der andere Aspekt, die Technik, sind eben die Personen. Also warum, zu verstehen, warum sind denn da so Widerstände? Und das können ja ganz, ganz...

essentielle Dinge sein, wie da Da herrscht Angst den Job beispielsweise, wo man sagt, wenn wir jetzt hier modernisieren, wenn wir jetzt irgendwie in die Cloud gehen oder wo auch immer hin, ist dann mein Job in Gefahr oder welche Rolle habe ich zukünftig? Und da spielt eben auch diese Aspekte eine ganz wichtige Rolle, das zu verstehen und da dann auch natürlich auch einzugehen. Und der andere Aspekt ist, auch als du gerade sagtest, wollt ihr den neuen Service ausprobieren?

Wir sind einfach sehr beschäftigt und einfach mal irgendwas ausprobieren. Ist eine super Idee, macht auch Spaß, aber bringt uns irgendwie im Sprint wahrscheinlich nicht so richtig weiter. Das heißt, wenn ich irgendwas vorschlage, dann dann versuche ich immer ganz klar aufzuzeigen, was ist denn der Mehrwert? Also was passiert denn? Was sind die Möglichkeiten in verschiedenen Dingen? Es können ja Kosten sein, es können irgendwie weniger operationelle Aufwand sein.

Und viele solche Aspekte. Und wenn ich das demonstrieren kann, ich aufzeigen kann, was habt ihr davon? Dann ist die Konversation plötzlich eine ganz andere. Dann ist es nicht mehr irgendwie mein Vorschlag gegen deinen Vorschlag, sondern, okay, wie können wir jetzt irgendwie dieses Ziel erreichen, von dem ihr auch profitiert?

Ja, sehr spannend. Also wie so oft ist Technik nicht immer die Lösung, sondern auch natürlich auf der menschlichen Ebene das Warum zu klären, also das große Why wahrscheinlich klar zu machen, ist wirklich spannend. Wenn wir jetzt so wieder in den Beratungsalltag reinschauen, ist jetzt ein neuer Change irgendwie am Kommen, also nicht nur irgendwie, sondern er ist wirklich da. Wir setzen AI in allen möglichen Ebenen ein und wir haben ja, also du sprichst mit Höchst-, also mit wirklichen Spezialisten.

Sie kennen ihr Cloud-Business und sind ihre Arbeitsabläufe gewohnt, haben vielleicht auch Methoden, die sie implementiert haben, wie CI-CD oder Cloud-Native-Entwicklung. Und jetzt wird plötzlich AI dort reingeworfen, was sie nicht nur entwickeln sollen, sondern das sie auch nutzen können. Wie merkst du da, was für ein Change siehst du dort? Wie wird das angenommen aus deiner Sicht?

Ich glaube, gerade bei uns in der Software oder in der IT ganz allgemein, die IT allgemein eine Branche, einfach Change grundsätzlich sehr häufig, sehr schnell passiert. Im Gegensatz zu vielen anderen Industrien, entwickeln sich auch weiter. Aber aus meiner Erfahrung ist es in der IT insbesondere schnell. Es gibt genug Memes, die alle sechs Wochen gibt es ein neues Frontend Framework, das wir jetzt alle wechseln müssen. Da ist ja irgendwo ein wahrer Kern dahinter.

Das heißt, wir leben eh in einer Industrie, wo Change sehr oft und sehr häufig passiert. Das ist aber meist in einzelnen Bereichen. Also wir sagen, wir wir migrieren jetzt von unserem liebgehegten und gepflegten Jenkins zu irgendwelchen managet CI/CD pipelines. Da war vorher jemand, der hat ihn gepflegt und gehegt und hat jetzt plötzlich ganz andere Aufgaben. Das ist auch eine Umgewöhnung. Oder eben auch die natürlich der Wechsel zur Cloud hin.

Also als wir sagten, müssen eben nicht mehr Infrastruktur provisionieren und irgendwie Hardware und Blech hin und her karren und reinschrauben etc. Da haben sich ja auch Berufsfelder oder Aufgaben geändert. Und ich glaube der Unterschied mit KI oder insbesondere generativer KI ist der, dass das einfach sehr sehr viele, wenn nicht alle Bereiche der Softwareentwicklung beeinflusst. Also wir sagen, wir haben natürlich

Coding Assistance hatten wir aber auch schon bevor es KI gab, in dem es Code-Generation in der IDE gab. Das ist ja auch der Teil, der vielleicht besser geworden ist, aber der nicht neu ist. Aber jetzt sprechen wir ja davon, dass komplette Features möglicherweise von der KI entwickelt werden oder eben auch Dokumentation, Tests, etc. Also es greift einfach in alle Bereiche des Software-Entwicklungs- und des Produktlebenszyklus auch ein. Und ich glaube, da ist natürlich jetzt die Reibung einfach eine höhere.

wo eben wieder diese Fragen aufkommen. werde ich hier möglicherweise abgehängt? Muss ich mich jetzt zum Prompt Engineer weiterbilden lassen? Und da entsprechend müssen jetzt alle KI-Experten werden? Schreibe ich überhaupt in der Zukunft noch Code? Ich glaube schon, übrigens, keine Sorge. Genau, und dem muss man einfach auch wieder realistisch begegnen. was treibt die Person da Und wie können wir das nutzen als Unterstützung? Ich glaube ...

Keiner von uns möchte der KI einfach blind vertrauen und sagen, das wird schon alles passen. Dazu haben wir, glaube ich, alle genug Erfahrungen mit Halluzinationen oder ähnlichen verrückten Outputs gemacht. Aber es ist halt in den Tool. Und wie bei jedem anderen Tool auch, ändert sich der Arbeitsablauf, ändern sich die Prozesse, an die man sich gewöhnt hat, die etabliert sind und in denen man auch produktiv ist. Wenn ich jetzt also neues Tool einführe und nehmen wir jetzt generative KI, da bin ich erst einmal aus meiner Sicht unproduktiver.

weil ich meinen Arbeitsablauf anpassen muss, weil ich mich daran gewöhnen muss, weil ich neue Dinge lernen muss. Natürlich ist die Hoffnung und auch was ich bei vielen Kunden auch sehe, das die Produktivität danach, wir können darüber streiten, was Produktivität genau meint, aber dass die Produktivität danach steigt. Aber da ist erstmal diese Hürde, diese Hemmschwelle, dieser Huckel, den man überwinden muss. Und ich glaube, da sind wir noch bei vielen in vielen Unternehmen.

sehr spannend. Also deckt sich so auch mit meiner Wahrnehmung. Ich glaube, ich kann das im Moment für mich so definieren, dass man Neugierde hat, dass man das ausprobieren möchte, dass man auch dort mit natürlich ein großer Hype-Trend auch hat und dass man natürlich da mit dabei sein möchte. Was ich aber auch glaube, ist, dass diese Effekte, die durch KI erzielt werden, nicht von 0 auf 100 in der ersten Sekunde da sind, sondern dass so einfach wie es aussieht, Prompten auch gelernt werden muss und dass man seine

damit machen muss, wie geht man damit ich sehe es auch so, die Neugier ist da, die Offenheit ist dort. Ein bisschen Skepsis ist auch noch dabei, aber wir sind ja auch erst am Anfang. Ja super.

Du hast natürlich ein Riesen-Portfolio sozusagen mit AWS, was bei deinen Kunden immer wieder aufschlägt. Und da ist die Frage, wie hältst du denn dein Wissen so auf dem neuesten Stand? Ich glaube, eure Services verändern sich sehr rasant. Es gibt immer wieder Updates, gibt neue Services, es gibt neue Themen, die spannend sind für die Teams. wenn man jetzt mit dir spricht, man kann dich ja zu allen Themen fragen sozusagen und...

Das ist natürlich ein Riesendruck auf der einen Seite, man das Gefühl hat, ich muss alles wissen. Wie managest du das? Wie hältst du deinen Wissen auf Stand? Wie gehst du mit diesem Druck das gesamte Portfolio oder die gesamte Palette von AWS beherrschen zu müssen?

Genau. Jetzt erzähle ich, ich, aus dem Nähkästchen, wenn ich dir verrate, ich weiß auch nicht alles. Nee, genau. Und das ist ein total wichtiger Punkt. Ganz ernsthaft. als ich in der Rolle angefangen habe, hatte ich auch genau dieses Gefühl, diesen Druck, alles wissen zu müssen. Weil ich habe ja das Label, ich komme von AWS, komme vom Hersteller so gesehen, und da sind Kunden, die erwarten von mir eine Antwort. Und das ist dann zum Teil auch Impostor-Syndrom, wo man ...

wo man denkt, alle anderen haben Ahnung, nur ich nicht. Es stimmt nicht ganz. Man ist eingestellt worden, kann auf eine langjährige Berufserfahrung zurückblicken. Man ist nicht völlig ohne Ahnung. Oder nicht ahnungslos. Trotzdem ist dieses Gefühl, dieser Druck da. Und ich glaube, es ist superwichtig zu verinnerlichen. Und egal, an welcher Stelle in der Berufslaufbahn oder im Leben man ist, dass es auch völlig in Ordnung ist, zu sagen, dass ich das nicht weiß.

Und das meiner Erfahrung schafft das oft mehr Vertrauen beim Kunden, als wenn ich entweder irgendwas so rumdruckse oder irgendwie so was Wages erzähle und das dann auch entweder nicht stimmt im schlimmsten Fall. Das wäre das absolute Katastrophe. Oder ich irgendwie dann nachträglich nochmal irgendwie was richtig stellen muss. meine Vorgehensweise ist, wenn ich wirklich was nicht weiß und natürlich versuche ich es so gut es geht zu beantworten. Da kommt auch schon mal vor, dass wenn man

im Homeoffice sitzt und der Kunde auch, also Virtuality, also man nebenbei mal googelt, das mache ich natürlich auch. Man muss einfach gut googeln können, das ist vielleicht das Geheimrezept.

Genau, jeder Entwickler kann gut stackoverflowen und googeln.

Ja, richtig. Das ist der Trick.

Die eigene Größe zu haben, das Bewusstsein und auch dann zu merken, dass das völlig okay ist, dass man nicht alles weiß, hilft erstmal ungemein, diesen Druck von einem zu nehmen. Natürlich ist es so, ich habe jetzt nicht nachgezählt, aber sicherlich über 200 Services. Davon sind aber ganz viele eben auch entsprechend für bestimmte Industrien oder für ganz bestimmte Anwendungszwecke vorgesehen.

Das heißt, wir haben entsprechend nur, nicht jeder Kunde interagiert wirklich mit 200 und mehr Services. Das heißt, es gibt so ein Set an Evergreen-Services oder einen sehr populären Services, die wahrscheinlich fast jeder Kunde nutzt. wir haben, jeder braucht eigentlich Compute, jeder braucht irgendwie eine Datenbank, jeder braucht irgendwie Storage, Networking und irgendwie noch so ein Security und Identity Management drum herum. Und da

ist natürlich so, dass man da schnell auch Expertise aufbaut und auch Expertise braucht, weil das erwartet wird. Und dann entwickelt man eben so bestimmte bestimmte Fokusbereiche. Wenn man sagt, weil jetzt in meinem, ich habe viel mit Großkunden, mit Enterprise Kunden zu tun. Die denken eben viel stärker zum Beispiel über Governance, über Managebarkeit drüber nach, als jetzt beispielsweise aus meiner Erfahrung zumindest kleine und mittelständische Unternehmen oder Startups.

die vielleicht eher erst mal an Wachstum interessiert sind und auch ganz andere Anforderungen haben, wie sie denn jetzt ihre Landschaft, ihr Portfolio managen und was die Entwickler dürfen und was nicht. Und dadurch, das ist so die eine Dimension, die ist dann von Reaktiv, wo ich sage, bringe mir, ich arbeite mit mehr Wissen, mehr Expertise bei dem, was meine Kunden von mir fordern.

Und der andere Teil ist natürlich, ich surf auch Reddit und Hacker News, zu gucken, was kommt denn da die Ecke, was ist denn da jetzt so das das Gespräch der Stunde. Und je nachdem, ob mich das dann aus professionellem Interesse oder aus privatem Interesse reizt, steige ich dann entsprechend tiefer ein. mein mentales Modell ist immer an der Stelle, was ich als Architekt oder Solution Architect mache, ist, und ich baue gerne auch Lego privat.

ist einfach Lego Steine. Ich habe einen Haufen Lego Steine und das sind irgendwie meine Services, meine Tools, Möglichkeiten, meine Produkte. Und ich kann die auf verschiedenste Art und Weise zusammenbauen. Ich kann die so zusammenbauen, dass das super stabil ist. Da brauche ich aber viele Steine, was aus meiner Sicht entweder Komplexität oder Kosten darstellt. Ich kann es vielleicht auch besonders schön und filigran bauen. Das fällt dann aber sobald man wirklich Last auf das System kommt. Und ich finde...

Die beste Art und Weise ist einfach ausprobieren, das wirklich mal einsetzen, den Service austesten, irgendwie mal selber einrichten, selber in einer Demo, in einem Proof of Concept ausprobieren. Weil dann merkt man auch wirklich, wie passt das so zusammen und hilft mir dann, und das ist eigentlich so mein Trick, oder nicht der Trick, aber mein mentales Modell ist, meinen Lösungsraum. Wenn du zu mir kommst und eine Frage hast, dann kann ich

oft viele Dinge schon ausschließen. Und ich muss jetzt beispielsweise nicht jedes Feature eines unserer Services kennen. Ich muss nur wissen, okay, der Service ist dafür geeignet. Nachrichtenbasierte Kommunikation. Der ist nicht für Stream-basierte Kommunikation. Das heißt, da kann ich schon ausschließen bzw. eingrenzen. Und wie groß jetzt oder wie detailliert jetzt ein Feature aussieht, das kann ich nur nachschauen oder später noch mal irgendwie rausfinden oder mit dir dann gemeinsam evaluieren als Kunde, was sind eigentlich deine Anforderungen?

Aber dieser Lösungsraum, und deswegen ist es auch so spannend aus meiner Sicht, wenn so manchmal gibt es eben neue Releases, neue Features, neue Services, die diesen Lösungsraum dann komplett umbauen, man sagt, die Architekturen dieser Art und Weise waren vorher gar nicht möglich. Mit den Features, mit dem Service ist es plötzlich möglich. Und das sind aus meiner Sicht Dinge, auf die man sich konzentrieren muss und verstehen muss, was das für Auswirkungen auf den Lösungsraum hat.

Ja, sehr spannend. Ich glaube, ist das, was du eingangs schon erzählt hast. So in die Fachlichkeit auch mit genau verstehen, was möchte ich hier umsetzen und deine Erfahrung auch mit reinbringen. Also du kennst mittlerweile auch deine Branche, deine Kunden und kannst bestimmte Sachen ausschließen. Das heißt, nicht alle 200 Services sind prinzipiell interessant und du scrollst nicht eure internen Systeme nach Roadmaps und Feature Updates. Ja, würde einen glaube ich auch wahnsinnig machen.

Zum Glück, genau.

Ja, aber das hat sich jetzt so einfach angehört, aber du hast natürlich auch ein wirklich tiefes Wissen. hab eingangs mal geschaut, hast du irgendwie fünf Zertifizierungen oder noch mehr? Und das heißt, du bist in verschiedenen Themen einfach auch richtig tief drin, wo du sagen kannst, da fühle ich mich zu Hause, da kann ich das anwenden und du musst jetzt nicht von Doku zu Doku hetzen. Wie ...

Schätzt du denn jetzt für uns, die Zuhörer, für mich das Thema Zertifizierung? Wann macht es den Sinn, eine Zertifizierung zu machen? Ist das jetzt nur, sage ich mal, Lippenstift auf dem CV? Bringt es mir wirklich was? Was wäre deine natürlich persönliche Empfehlung dort? Wie gehst du damit

Genau, ich glaube, ist super spannendes und auch kontroverses Thema. Aus meiner Erfahrung ist es so, dass die Zertifizierung, es gibt zwei Dimensionen davon. Was die Zertifizierung ja darstellen soll oder zeigen soll, ist, dass du eine gewisse Expertise in einem gewissen Feld aufgebaut hast. Und idealerweise ist es so, dass du diese Expertise

die erwerbst, weil du ein, zwei, drei Jahre mit den entsprechenden Technologien arbeitest, tagtäglich. Und dann das nachweist, indem du diese Zertifizierung machst und sagst, hier ist der Stempel, du hast diese Expertise. Da ist natürlich noch eine andere Dimension, wenn wir jetzt natürlich darüber nachdenken, auf dem Arbeitsmarkt. Wie kann ich meinen Wert steigern? Wie kann ich nachweisen, dass ich irgendwas habe? Und da sind natürlich

Wenn alle Dinge gleich sind, also ich habe zwei Kandidaten und ich schaue mir die Lebensläufe der Erfahrung quasi an und der eine hat vielleicht die Zertifizierung und der andere nicht, dann ist das sicherlich ein Kriterium, was da reinspielt. Aber man muss aus meiner Sicht ganz realistisch sein und sagen, für Zertifizierungen, da kann ich auch explizit für lernen. Ich kann mir das anschauen, mir das Wissen erwerben, dass ich für die Zertifizierung brauche.

und die dann auch erfolgreich abschließen. Kann ich das dann in tagtäglichem Doing umsetzen? Weiß ich nicht. Also ich glaube, man sollte Zertifizierungen nicht alleine betrachten, sondern den Kontext. Also wenn ich jetzt sage, ich sehe jetzt jemanden, der hat jetzt 10 Zertifizierungen, dann frage ich mich natürlich, wie hat er all dieses Wissen erworben und der

Hat er das dann auch noch? Wie kann er denn so viel Wissen in so vielen verschiedenen Spezialgebieten auch aktuell halten? passt das dann, wenn ich beispielsweise im Gespräch, kann ich das irgendwie raushören oder auch im Lebenslauf, bei LinkedIn, wo auch immer, passt das denn eigentlich mit der Erfahrung, mit der Expertise, mit dem Werdegang zusammen? Also kurz gesagt, ich glaube schon, dass das eine tolle Sache ist, zu zeigen, dass man diese Expertise im Laufe seiner, seines Berufserfahrung, seines Werdegangs erworben hat.

Aber in meiner Erfahrung kann man auch dafür lernen. Muss sich dann natürlich auch die Frage gefallen lassen, wenn jemand fragt, kannst du da ein echtes Beispiel geben, wofür du das, wann du denn dies und das eingesetzt hast. Also der Kontext ist hier entscheidend.

Sehr interessant, also nicht einfach Medaillen jagen für den CV und den Lippenschift sozusagen draufkleistern, sondern wirklich sich mit dem Thema beschäftigen und dann kommt das als Nebeneffekt einfach. Also wenn ich in der Materie drin bin, wenn ich verstehe, was ich tue, brauche ich auch nicht so viel zu lernen, habe ich dich Verstände, dann nehme ich mein Wissen, wende es an und kann das nachweisen mit der Zertifizierung und habe dadurch auch eine Möglichkeit

Ja, ne.

das sichtbar zu machen. Alternativ sage ich immer, im Open Source Bereich unterwegs, habt ein gutes GitHub-Repo, wo man sieht, wo euer Code ist. Aber natürlich auch die Zertifizierung bringt einiges.

Genau, aber das ist ein super Punkt, da nochmal zu ergänzen, ist mit GitHub. Also viele commits per GitHub an sich sind aus meiner Sicht nicht aussagekräftig. Also ich kann einfach natürlich meinen einen Change in 20 commits zerlegen und Gott weiß was da in die commit-Message reinpacken. Also einfach Aktivität an sich ist erstmal kein Zeichen von Qualität. Und da ist wieder der Kontext entscheidend. Also wo, wo kontribute ich denn? Was sind das für Dinge, die ich da tue?

Und das findest du halt im Gespräch raus. Und dann merkst du auch ganz schnell, wie du sagst, ist das jetzt auswendig gelernt, ist das schön Färberei oder steckt da wirklich was dahinter? Und darauf kommt es dann an.

Okay, du meinst meine Strategie, WIP, my change did not work, WIP, my change did not work, ist keine gute Commit-Strategie, werde ich überdenken, aber ich glaube, ich glaube, sehr schön. Nee, der Punkt ist klar, danke dir dafür. Also wirklich interessante Insights nochmal. Jetzt nochmal zum anderen Architektur-Thema, was viele in der Strategie beschäftigt. Also wir haben jetzt mal einen Experten wirklich von einem Cloud Provider hier, mit dem wir offen unter uns sprechen können, mit allen Zuhören.

Ich würde die Nachdrücklich

Thema Multicloud Diskussionen. Also wie viel Zeit und Geld soll ich in Multicloud investieren? Lohnt sich das? Ich möchte dich jetzt natürlich nicht auf die Zeit- Gelddiskussion hier bringen, sondern eher auf der technischen Ebene aus deiner persönlichen Einschätzung. Wie viel Abstraktion

Sollte ich zulassen oder sind sinnvoll? Was sind sinnvolle Abtraktionen? Und wann fange ich an, mir sozusagen die Power der Cloud ein bisschen zu verbauen, weil ich zu sehr abstariere? Und wirklich eine persönliche Meinung von dir. Was ist dann gutes Gleichgewicht oder wie würdest du da mit ins Rennen gehen?

Jetzt ziehe ich die klassische Solution-Architekt-Antwort. Ja, hängt davon ab. Genau, und es hängt auch wirklich davon ab, weil eine pauschale Aussage ist aus meiner Sicht Quatsch. Was gibt es für Dimensionen, die wir betrachten müssen? Zum einen ist natürlich klar, wenn ich mehr als einen Cloud-Anbieter, aber das ist bei allen anderen Dingen auch, mehr als einen Hersteller oder Zulieferer, erhöht das mal die Komplexität.

heißt, ich muss zwei verschiedene Systeme managen. muss irgendwie auch das Wissen entweder im Rahmen meiner Mitarbeiter oder persönlich, also auch irgendwie mir erwerben, damit irgendwie umgehen zu können. Also Komplexität und Kosten spielen natürlich auch eine Rolle. Dann ist es aber natürlich auch wieder so, das sehe ich auch bei meinen Kunden, mit denen ich interagiere. Das sind ja oft große Konzerne, große Unternehmen, die

wollen möglicherweise auch ein gewisses, wollen wir mal sagen, Abhängigkeitsverhältnis vielleicht vermeiden. Inwiefern das wirklich ein Abhängigkeitsverhältnis ist, ist ja eine große, auch wieder eine kontroverse, da kann man lange darüber diskutieren. Ich Gregor Hoppe hatte auch eine sehr explizite Meinung zu. Aber vereinfacht gesagt ist, das ist auch die Realität, die ich in meiner, in meinem Umfeld auch sehe. Dass halt viele Unternehmen auch einfach mehr als einen Cloud-Anbieter haben.

Und dann würde ich sagen, es hängt jetzt davon ab, was für eine Workload, was für eine Anwendung das ist. Es macht sicherlich nicht Sinn, jede Anwendung zweigleisig zu fahren. Warum? Weil das funktioniert ja nur, indem ich mich auf den kleinsten gemeinsamen Nenner einigen kann. Das heißt, ich kann nicht die herausragenden Features des einen Anbieters nutzen, weil der andere Anbieter den nicht hat. Da war der vielleicht wiederum Features, die super zur Architektur und zur Lösung passen würden, die der andere aber nicht hat.

Also ich muss mich künstlich auf das, auf den kleinsten gemeinsamen Nenner einigen, verliere also total viele Vorteile der Cloud an der Stelle. Dann ist aber auch wieder der Aspekt, okay, vielleicht habe ich aber auch Anwendungen, die in einem gewissen Risiko bestehen, wo ich garantieren muss, dass sie auch bei technischen, bei vielleicht auch politischen, aus einer Vielzahl von Gründen immer verfügbar sein müssen.

Also nicht nur verfügbar im Sinne von es läuft technisch, sondern auch einfach betreibbar sein müssen. Also wo man dann auch hingehen muss und sagen muss, okay, ich möchte mir diese Option offen halten. Wieder der Trade-off an der Stelle sind Kosten. Und dann wird es wie im Disaster Recovery Fall oder im Business Continuity Fall sollte es eine Business Entscheidung sein. Also wie viel Zeit und Geld bin ich jetzt bereit vorab zu investieren, eben einen Multi-Cloud Ansatz zu fahren?

im Vergleich zu, wenn denn jetzt der Fall eintreten würde, dass ich irgendwie wechseln müsste, migrieren müsste, warum auch immer, wie viel Zeit und Geld kostet mich das dann? Also was ist die Eintritts-Verscheinlichkeit und was sind die Kosten dafür? Ja, wir reden, die Realität ist manchmal anders, aber wir reden ja auch davon, Anwendung, die ich heute entwickle, die läuft ja keine 20 Jahre. In fünf Jahren wird die vielleicht abgeschaltet und modernisiert und dann könnte ich immer noch wechseln. Also die Zukunft vorherzusehen,

und zu sagen, ja, wir müssen uns diese Optionen offen halten und dann entsprechend viel Engineering-Aufwand, Zeit und Kosten vorab zu investieren, sehe ich selten als gerechtfertigt an. Es gibt immer Ausnahmen. Das hilft nichts keinen, aber es gibt halt immer Ausnahmen. Ich würde immer dafür zu plädieren, sagen, okay, man muss mit demjenigen reden, der die Businessentscheidung trifft, verstehen, was ist die Trade-offs in

im Rahmen von Zeit und Geld, also Engineering, Zeit und Geld und dann die Entscheidung da an der Stelle treffen.

Das heißt, ihr der Risikomanagement Ansatz an der Stelle und das die Technologie nachgelagert, was für mich natürlich immer so ein Punkt ist. Ich sehe ganz stark auch eine Möglichkeit im Software Entwicklungsbereich dort mit einzuwirken. Das heißt, wenn ich in den Teams so einen Mindset reinbekommen, dass Change normal ist, dass wir quasi immer wieder überdenken können, wie entwickeln wir und dann bin ich auch innerhalb einer Cloud in der Lage, Technologien auszu

tauschen und zu wechseln und das hilft mir natürlich dann auch in einem Fall der Fälle, falls ich wirklich mal den größeren Sprung machen muss, dass ich ein Team habe, was vom Tooling her so aufgestellt ist, dass es in der Lage ist auf Change wesentlich besser zu reagieren. Das sind die Sachen, die du eingangs angesprochen hast mit dem agilen Mindset, kleine Pakete schneiden, kein Wasserfall und so weiter. das ist...

genau

Mein Gedanke noch dazu, aber super spannend. Es ist wie gesagt eine kontroverse Diskussion. Ich glaube, es hängt auch von den Unternehmen an. Welche Strategie verfolgt das Unternehmen und wie abhängig sind sie davon, jetzt diesen Schritt machen zu müssen oder sich darauf vorbereiten zu müssen.

Hm.

Ich habe noch ein anderes Thema. Moment ist draußen so eine ökonomisch angespannte Situation, die man merkt. wie schafft das AWS dort oder wie hilfst du in deiner Rolle? Wie kannst du Unternehmen helfen, mit Cloud zu sparen oder die Cloud-Kosten zu optimieren? Es gab mal eine ReInvent, einen interessanten Vortrag von eurem CTO, der den Frugal-Architekt ausgerufen hat. Es gibt

Programmiersprachen, die besser geeignet sind, optimierter zu laufen. Was ist denn dein Ansatz, den wir uns jetzt alle mitnehmen können, wie wir, wenn wir Cloud einsetzen, sparen können?

Genau, das ist ein super spannendes Thema, weil wir haben ja wieder die Dimension, die Technik und wir haben quasi die Businessseite. Ich könnte ja hingehen und sagen, wir schalten das Ding einfach ab. Was auch immer diese Anwendung ist, wir schalten es ab und dann sparen wir richtig viel Geld. Das Ziel ist ja eigentlich, den nötigen Wert zu liefern, den Businesswert zu liefern, mit möglichst geringen Kosten. Und da müssen wir als nächstes darüber reden, was sind denn jetzt Kosten in dem Fall eigentlich? Und ganz oft sehe ich eben

dass jemand dann den Pricing Calculator aufmacht und sagt, für die Infrastruktur bezahle ich so und so und so viel. Und fertig. Und aus meiner Sicht ist es auch entscheidend, mitzuberücksichtigen, was habe ich denn noch für Kosten? Es geht so Richtung Total Cost of Ownership. Natürlich sind höherwertige Services, wo der Anbieter mehr Arbeit für dich übernimmt als du, also weniger Arbeit für dich, mehr Arbeit für den Anbieter.

sind natürlich höher, in den allermeisten Fällen höher, bepreist, weil entsprechend auch Arbeit verlagert wird. Dann kommen aber natürlich so Aspekte wie Economies of Scale, also Skaleneffekte treten dann ein, wo die höheren Kosten aber auf viele, viele, viele Kunden verteilt werden und für den einzelnen Kunden dann vielleicht doch geringer sind. Also, heißt also, wir dürfen uns, also meiner Sicht darf man sich dem Thema wieder nicht direkt von der Technik nähern, sondern als allererstes muss man hinterfragen, was macht denn diese Anwendung? Was macht denn dieser Workload überhaupt? Können wir den wirklich abschalten?

sind es vielleicht drei Nutzer, den aus, weil es den immer schon gab, benutzen und die hätten den gerne, dass das weiter betrieben wird. Ist in den allermeisten Fällen natürlich nicht so. Die allermeisten Einwanderungen generieren wirklich einen Wert und sind auch nötig und kritisch für den Geschäftsprozess. Dann ist es oft so, dass ich verstehen muss, wodurch entstehen die Kosten? Wird da wirklich Infrastruktur provisioniert, die den ganzen Tag lang läuft?

unabhängig davon, wie viel Last eigentlich erzeugt Im Idealfall will ich es schaffen, dass ich Kosten pro Transaktion, dass ich das fix halten kann. Also wenn ich sagen kann, hier ist ein Geschäftsprozess, muss jetzt irgendwas durchgeführt werden und ich kann dafür sorgen, dass die Kosten für diese Transaktion einen gewissen Wert haben. Dann kann ich entsprechend mit der Last, mit dem Bedarf skalieren. Das funktioniert aber natürlich nicht, oder deutlich schlechter.

wenn ich wirklich Infrastruktur provisioniere, bereitstelle, die einfach 24 Stunden läuft. Weil, wenn wir uns das anschauen, die Welt funktioniert nun mal so, dass wir Wochenenden haben, dass wir Tag und Nacht haben und dass einfach viele, viele Anwendungen auch tagsüber oder zu gewissen Zeiten mehr Last generieren als an anderen Zeiten. es zwischen Tag und Nacht, mag es zwischen Wochenende und Wochen, Wochen-Tags sein. Oder es sind irgendwelche Batch-Jobs, die zeitgesteuert ablaufen.

oder sogar irgendwie Monatsabschlüsse etc. Das heißt also aus der Sicht muss ich verstehen, wieder Business Sicht, was tut die Anwendung eigentlich, was versucht sie zu erreichen und dann kann ich überlegen, wie könnte jetzt die entsprechende Architektur aussehen, die genau das noch erreicht, aber eben die Kosten minimiert und eben zu sagen, okay wir wechseln, wir wechseln eben von der Infrastruktur, die über virtuelle Maschinen redet, zu hin einer, die wo ich das Lastverhalten

schneller anpassen kann und im Idealfall sogar noch einen Schritt weiter denken, wo ich eine quasi ereignisbezogene Abrechnung habe. Also wo würde ich nur dann auch Kosten entstehen, wenn ein Mehrwert entsteht? ein Geschäftsprozess wird ausgeführt, der generiert hoffentlich Mehrwert, sonst wüsste die ganze Anwendung hinterfragt werden. Also der Geschäftsprozess wird ausgelöst und nur dann entstehen mir Kosten. Und dann kann ich wunderbar in Korrelation setzen und auch quantifizieren.

Ja.

in welchem Verhältnis das steht und auch welche Einsparungen ich erzielen kann.

sehr cool.

Also ich höre auf jeden Fall raus, eine datengetriebene Entscheidung hilft, das heißt eine Transparenz oder ein gutes Verständnis über deine Applikation auch zu bekommen, also nicht nur den Businessprozess, sondern auch zu verstehen, wie sind meine Kunden der Applikation unterwegs, wann habe ich eine große Last, wann habe ich Möglichkeiten die Ressourcen runterzufahren und was ich auch so raushöre ist dieses klassische Make versus Buy, also dass ich mir genau überlegen sollte,

Muss ich das jetzt selbst entwickeln oder gibt es dort einen Service, ich einfach einkaufen kann, der jetzt vermeintlich erstmal ein bisschen mehr kostet, aber wenn ich die Total Cost of Ownership sehe, inklusive dem, was bei mir auf der Seite hinten dranhängt, kann es sich doch rentieren, dort umzuswitchen auf einem Service. Also ich glaube, sehr wertvolle Tipps. Vielen Dank dafür.

Ich möchte jetzt nochmal switchen zu deinem Lieblingsthema, oder hast du zumindest im Eingangsgespräch gesagt, dass du dich sehr für Serverless interessierst? Dass Serverless so ein Herzensthema von dir ist. Ja, für wen ist denn Serverless überhaupt was? Wer sollte Serverless einsetzen und wer sollte es nicht einsetzen? Oder heißt es jetzt Serverless all the things?

Haha.

Ja, ich würde es mir ja wünschen, aber genau. Serverless ist im Endeffekt, das habe ich ja auch schon gesagt, wir wollen eigentlich, dass ich als Entwickler will so wenig wie möglich mit Dingen zu tun haben, die eigentlich nicht die Geschäftslogik sind. Also das ist ja das, aus der Unternehmenssicht ist das, wo Wert generiert wird. Und aus meiner Sicht als Entwickler ist es eigentlich das, wo die spannenden Dinge passieren. Ja, also irgendwie.

Fehlerbehandlung zu Fehlerbehandlungscode zu schreiben ist nicht spannend oder irgendwie einfach nur Integrationscode zwischen zwei verschiedenen Systemen ist aus meiner Sicht nicht spannend. Die wirklich spannende Herausforderung und das ist ja eigentlich das aus meiner Sicht, wonach der Job auch so viel Spaß macht, ja, man kriegt ein schwieriges Problem, was man irgendwie lösen will und darauf will ich mich konzentrieren. Mit all dem Drumherum will ich nichts zu tun haben.

Es gibt sicherlich Leute, haben Spaß daran, Beziehungssysteme zu patchen. Ich nicht. Und gerade at scale nicht. Das heißt also Serverless ist für mich diese Rückbesinnung oder diese Besinnung auf eigentlich die Developer Experience, wo ich sage, ich konzentriere mich auf meine Aufgaben und alles drumherum, kann ich ausklammern. Auch im Betrieb. Wo ich sagen muss, Kapazitätsmanagement ist mir egal, weil das eben der Anbieter für mich macht. Sicherheitsupdates etc. etc.

Das heißt, für wen ist das was? Erstmal pauschal für alle. Sternchen, it depends. Weil einfach natürlich, wie in allen anderen Dingen, gibt es auch Workloads, die sich einfach nicht dafür eignen. Und ich glaube, die richtige Herangehensweise ist zu sagen, und das macht aus meiner Sicht auch unabhängig vom Label, ob wir serverless oder was dran schreiben, serverless first. Ich versuche, mit einem möglichst hohen Abstraktionsgrad

Mein Problem zu lösen. Und wenn ich das schaffe, habe ich viel gewonnen, weil ich mich über viele Aufgaben nicht kümmern muss. Und nur wenn ich Anforderungen habe, die mich zwingen, in den Abstraktionsgrad tiefer zu gehen, also mir entsprechend mehr Arbeit aufzuhalten, dann mache ich das und entsprechend immer weiter runter die Kette, bis wir dann irgendwann wieder auf einem Server betreiben mit all den Dingen, die das beinhaltet. Also prinzipiell für jeden.

Aber es hängt eben davon ab, ob denn der Workload dafür geeinigt ist. Der große Vorteil ist eben, was ich auch gerade schon sagte, aus meiner Sicht erlaubt es auch ein wunderschönes Modell, das Verständnis der eigenen Architektur. Weil ganz oft habe ich es bei Serverless Services so, dass sie verbrauchsabhängig abgerechnet werden.

Das heißt, ich habe dieses Modell, ich sage, hier kommt ein Ereignis, kommt eine Nachricht, kommt eine Datei, wird hier angeliefert, was auch immer. Und jetzt habe ich so eine Kette an Ereignissen, passieren. daran kann ich mich wunderbar entlanghangeln und auch mein Verständnis meiner Architektur, meiner Services aufbauen und verstehen, was da passiert.

Ja, super spannend. Was ich echt interessant finde, ist auch den Einsatz, den du eben geschildert hast, dass du damit Geschwindigkeit bekommst. dass du gerade, wenn du Sachen jetzt mal ausprobieren möchtest oder deine Geschäftsidee austesten möchtest, hast du eine Möglichkeit kleinteilig auch Businessprozesse vielleicht umzusetzen mit der Hilfe von Step Functions oder anderen Möglichkeiten, die es jetzt gibt. wo du dann später diese Entscheidung, also die Entscheidung auf später verlagern kannst, wie

ich jetzt wirklich einen Server, welche Datenbank nehme ich und dass du auf jeden Fall Geschwindigkeit bekommst damit. Lambda ist jetzt glaube ich zehn Jahre irgendwie wurde ernaunt, wenn ich das richtig verfolgt habe.

Das Tooling hat sich verbessert. habe auch ganz am Anfang mal irgendwie was mit Serverless gemacht. Da gab es noch wenig Tooling außenrum, sodass du wirklich diese Praktiken der Softwareentwicklung auch ausnutzen konntest. Da war dann mehr noch Copy-Paste in der Konsole und Ausführen. Die Zeiten sind zum Glück vorbei. Ich glaube, deiner Erfahrung hast du auch einiges gesehen, was vielleicht schief läuft im Serverless-Bereich. Also was sind denn so die typischen Anti-Pattern, die man nicht machen sollte?

Haha.

Und was siehst du dort, was empfiehlst du den Zuhörern, was man nicht mit Lambda oder Serverless machen soll, diese Anti-Pattern zu vermeiden.

Genau, ich glaube, das ist wieder so ein allgemeingültiger Teil. Die Technik ist nicht die Lösung für jedes Problem. Also ich kann nicht erwarten, wenn ich jetzt eine monolithische Mainframe-Anwendung habe, dem mal das absolute Horror Beispiel zu nehmen. Aber wenn ich sage, ich implementiere, ich migriere die jetzt nach Serverless, dann habe ich all meine Probleme gelöst. Dann wird es automatisch, werde ich automatisch schneller, ich automatisch irgendwie vielleicht günstiger und habe irgendwie weniger Probleme im Betrieb. Das heißt also,

Ich muss mir quasi bewusst sein, dass mit dem Wechsel auf den Abstraktionsgrad auch eine gewisse Veränderung einhergeht. Und da helfen wieder gute Software-Entwicklungsabstraktionen. Also wie kapsel ich meinen Code? Wie unabhängig kann ich die Infrastrukturlogik von der Geschäftslogik trennen? Oder herrscht da irgendwie eine starke Koppelung? Also muss mein Code wissen, wo er gerade läuft? Und wohin?

oder woher er Nachrichten bekommt. Und wenn ich das schon in der Softwareentwicklung stark und gut voneinander trennen kann über verschiedenste Methoden, dann hilft mir das natürlich auch beim Einsatz von Technologien wie Serverless. Das heißt also, aus meiner Sicht ist, und wenn das nicht der Fall ist, dann muss ich da eben auch Arbeit reinstecken. Das heißt, eine blinde Migration führt meistens nicht zum Erfolg. Und der andere Aspekt, den du auch schon hervorragend angesprochen hast, ich brauche ein gewisses Verständnis dafür,

Mmh.

was meine Anwendung tut und wieso das Lastverhalten ist. Weil Kosten ist natürlich ein Thema. Und wenn ich überhaupt nicht weiß, was da eigentlich passiert, dann kann ich auch nicht abschätzen, was dann dafür Kosten auf mich zukommen. Das geht halt unter, wenn ich einfach einen Server habe, der steht da und der läuft halt 24 Stunden, der geht auf irgendeine andere Kostenstelle wahrscheinlich noch, weil der schon immer da war. Dann ist das jetzt plötzlich anders. Das heißt also, aus meiner Sicht

braucht es gute Software oder eine gute Abstraktion in der Software, mir diese Migration möglichst leicht zu machen. Und es braucht eben dieses Verständnis davon, was die Anwendung tut, was die Nutzer tun, das einschätzen zu ob das das Richtige ist.

Sehr spannend. Also wieder kein Pauschalrezept, wir bekommen. Klassische Berater Antwort it Depends. Macht natürlich auch Sinn. Ich glaube, man ist wesentlich kleinteiliger unterwegs im Serverless-Bereich. Das heißt, das, man im Großen hat, je besser ich das kleiner schneiden kann, umso besser kann ich die kleinen Teile dann auch in einzelne Funktionen auslagern. Das hört sich natürlich jetzt spannend an. Du hast es schon mir fast verkauft hier, auch in das Serverless-Business einzuschicken. Ich habe allerdings vor so 2023

Haha.

sich rum gab es so ein Artikel, irgendwie vom Amazon Prime Team viral gegangen ist, auch auf Hacker News und überall war. Sie haben annoucet, sie gehen weg von Serverless, 90 Prozent ihrer Kosten zu sparen. Was ist da los? Ich denke, Serverless wird alles gut, ich kann Geld sparen. Vielleicht kannst uns noch ein bisschen einen Hintergrund zu dem Artikel geben und deinen Blick darauf, warum die Entscheidung vielleicht die richtige war oder was du davon hältst.

Haha. Ja.

Genau, ich glaube, der Blogpost, ich erzähle dir auch gleich sofort, worum es da konkret vom Workload her ging, das ist eigentlich das perfekte Beispiel für diese Serverless-first-Ansatz. Also zu sagen, ich muss nicht jedes Problem mit Serverless lösen können, das geht auch gar nicht, aber das ist der erste Ansatz. Und wenn die Anforderungen kommen, dann wechsle ich auch die Architektur, wenn es nötig wird. Und genauso ist das Team aus meiner Sicht auch vorgegangen. Also worum ging es? Es ging darum,

eine große anzahl oder erstmal eine gewisse video streams zu analysieren und es basierte eben auf und disclaimer ich war nicht in dem team also ich kenne auch ich kenne ein mehr hintergründe aber don't quote me on it - also es ging darum in video streams zu analysieren mit einer verteilten Architektur viele verschiedene mehrere verschiedene Komponenten das ganze wurde orchestriert

von Step Functions, das ist serverless workflow orchestrator, der die verschiedenen Komponenten miteinander vernetzte. Die Zwischenergebnisse wurden in einem S3 Bucket in Object Storage gespeichert. Jetzt ist es allerdings so gewesen, dass

Prime Video, das muss man auch sagen, Prime Video hat eine gewisse Größe. Das ist jetzt nicht einfach mal irgendeine Anwendung, die da irgendwo in einem Enterprise-Kontext irgendwo läuft, sondern ist ja ein global verfügbarer, weltweiter Service mit entsprechender Größe. Das heißt also, die haben eben gemerkt, dass die Logik, die sie sehr kleinteilig aufgedröselt hat in viele verschiedene Services, dass sie eigentlich aus logischer Sicht zusammengehörte.

Natürlich mit jeder und das ist der Trade-off. Ich habe zwar viele kleine Teile, aber ich habe jedes Mal Latency Trade-offs, weil natürlich irgendwelche Calls gemacht werden müssen. Ich habe dadurch Verzögerungen, habe dadurch natürlich auch verschiedene Komponenten, die alle miteinander interagieren müssen. Und eigentlich ist das Code gewesen, der logisch gesehen zusammengehört, weil es keine An- Notwendigkeit das als verteiltes System zu betrachten.

sondern dann sollte eben mit hohem Durchsatz, mit hoher Geschwindigkeit viele Daten schnell miteinander verarbeitet werden. Was da passierte, waren es wurden einzelne Frames aus den Videos genommen und die wurden verarbeitet. Und es machte einfach Sinn, diesen Code. Und in der Blogpost redet natürlich von dem monolithischen System. Aber es ist kein klassischer Monolith. Es läuft immer noch auf ECS, also eben einem Container Orchestrator und S3 SNS, also auch Services, die ich voll und ganz als Serverless das bezeichnen würde.

weil das ist jetzt wieder welches Label packen wir dran. Also die Anforderungen waren einfach klar durch die Größe, durch die Skalierung und durch die Anforderungen an die Latenz war einfach klar, man musste, es macht einfach Sinn, die Logik, die sehr verteilt war, die sehr kleinteilig war, wieder zusammenführen, in einen Container packen und hat damit eben die Vorteile dieser, ich habe Interprozesskommunikation, das ist einfach viel, viel schneller als in einem verteilten System. Der Trade-off, und das darf man auch nicht vergessen, ist natürlich, ich habe

Was die Observability angeht, wird natürlich schwierig zu sehen, was genau der Prozess denn da tut. Wenn ich einzelne Services habe, die ich auch unterschiedlich skalieren kann und Einblicke habe, ist das nochmal eine andere Herausforderung. Und dann natürlich auch die Auslastung. Also es ist ein Workload, der und jetzt sind wir wieder bei Skalierung und Lastverhalten. Ich musste meine Anwendung kennen, der eine sehr, hohe Grundlast hatte, wo wenig Fluktuation war, weil es eben ein Prozess war, der

nicht von Menschen oder von Tag- und Nachtrhythmus beispielsweise gesteuert war, sondern es mussten einfach Videos verarbeitet werden, die eingehen. Und da macht es aus meiner Sicht total Sinn, dass das Team dann auch die Architektur gewechselt hat. Und das ist eher ein Argument für diesen Server-as-first Ansatz und aus meiner Sicht steht keineswegs im Widerspruch.

Die Stories waren wirklich wild. Also tot den Microservices, es Leben, die Moduliten und alles, dazukam. Aber auch da, das Team war in der Lage, sich zu verändern. Das System war nicht so verprogrammiert sozusagen, dass man sich nicht ändern konnte. Die Architekturentscheidung wurde natürlich auf Verständnis der Applikationen dann angepasst. Echt super spannend. Danke auch für deine Insights. Ich würde jetzt gerne noch mal einen Switch machen in eine andere Richtung. Man hört viel von der Kultur.

Ja.

von AWS. es gibt ja, ihr sprecht über spannende Sachen. Also die Two-Pizza-Teams sind ja bekannt geworden. Auch die E-Mail von Jeff Bezos. Jeder muss eine API veröffentlichen, sonst wird er gefeuert. Ihr habt so ein bisschen was über Leadership schon veröffentlicht. Das Working Backwards ist ein Thema, wo ihr einfach über eure Kultur sprecht, wie ihr arbeitet und das auch teilt. Und einen Prozess finde ich super spannend und zwar ist das ein Innovationsprozess und

der nennt sich PR FAQ. Das heißt, für jede Innovation, du kannst mich gleich korrigieren, aber mein Verständnis ist, für jede Innovation, die ihr vorantreiben wollt im Unternehmen, schreibt ihr aus Kundensicht erst mal so eine Press Release. Das Produkt ist jetzt fertig, ich schreibe jetzt eine Press Release und finde dann gleichzeitig auch noch Frequently Asked Questions dazu. Also, Fragen würden mir gestellt werden und welche Antworten habe ich drauf, die Idee zu untermauern?

Warst du bei so einem Prozess schon beteiligt? du da mal was mitgekriegt? Habe ich das richtig interpretiert?

Genau, auf jeden Fall im Groben und Ganzen sicherlich schon. Genau der Prozess existiert auch so. Und ich glaube, die Idee ist und eine unserer Leadership Principles, also Unternehmensleitlinien, Unternehmensrichtlinien oder nicht Richtlinien, aber Unternehmenswerte ist Custom Obsession. Also wir wollen uns immer versuchen, auch in den Kunden hinein zu versetzen. Und das auch mein, das versuche ich auch. Ich versuche nicht, Serverless zu verkaufen, sondern ich versuche zu verstehen, was das Problem des Kunden ist.

und dann eine Lösung dafür zu finden. das ist auch noch ganz kurz exkurs, das ist so bisschen manchmal die Sorge, die ich dann sehe, dass wir die Technik das Technikwillens machen. Also weil diese Service, dieses Feature, diese Framework so richtig neu und sexy ist, will ich das jetzt in meinem neuen Einwenderungen unbedingt ausprobieren. Kann ich verstehen, ist aber glaube ich nicht die richtige Herangehensweise. Genau, da habe ich schon, da geht genau die Richtung.

Hype-Triphen-Development, oder?

Und ich glaube, das ist einfach ein Mechanismus, sicherzustellen oder zu validieren, dass das, was wir tun wollen, wirklich einen Mehrwert für den Kunden bringt. wo man eben, das ist einfach so eine Übung, ich nicht sagen aus der Psychologie, wo man sagt, man setzt jetzt die andere Brille auf, man setzt jetzt die Kundenbrille auf, liest sich das dann durch und hört sich das eigentlich gut an. Trifft das denn den Kern, den man sich da vorstellt? Das hilft natürlich auch, dass dann andere Personen nochmal draufschauen können.

und entsprechend dann auch verstehen, worum es geht. Weil wenn sie dann das schon nicht verstehen, dann helfen auch keine FAQs mehr und keine anderen Erklärungen mehr. Es muss ja so verständlich sein, dass der Mehrwert begreiflich wird. Aus meiner Erfahrung machen wir das gar nicht, habe ich es jetzt gar nicht so oft erlebt. Also ich war schon wenige Male mit dabei, weil es natürlich auch ein gewisser Aufwand natürlich darstellt. Es sind viele Iterationen. Es ist nicht so, als würden wir das, als würde das beim ersten Mal perfekt rauskommen.

sondern dem gehen noch viele weitere Schritte voraus, bis es dann soweit ist. Da wird viel iterriert wird viel Feedback eingeholt von verschiedenen beteiligten Parteien. Aber das Endergebnis ist dann schon ganz cool, weil man eben wirklich diese Perspektive einnimmt und gleichzeitig aber auch selbstkritisch bleibt. Also man schreibt ja nicht nur ein Pressrelease und sagt, das ist das allerbeste, die eierlegende Wollmichsau, sondern auch eben die FAQs, die dann auch kritisch...

Was heißt kritisch? Oder die dann eben die Fragen angehen, die man sich dann auch sofort stellen würde. Okay, wo ist der Haken so ungefähr?

Ja, sehr spannend. Was ich natürlich wissen muss, ist, ich hab gehört, euch gibt's in dem Prozess keine Powerpoints. Das heißt, so Meeting läuft ab, dass die Leute sich hinsetzen, jeder erst mal zehn Minuten Zeit bekommt, das durchzulesen. Es wird dann irgendwie nicht präsentiert, sondern man arbeitet mit dem geschriebenen Dokument, was vorher in mehreren Interaktionen entstanden ist. Also keine Powerpoints bei AWS.

Da muss man natürlich direkt dazu sagen, ja und nein. Also wenn ich jetzt einem Kunden was vorstelle, dann habe ich auch eine PowerPoint-Präsentation manchmal dabei, weil es einfach ein etabliertes Vehikel ist, Dinge einfach vorzustellen. Wenn wir auf Konferenzen sind, habe ich auch eine PowerPoint-Präsentation dabei. Wenn es jetzt aber andere Dinge geht, andere Prozesse, dann ist das richtig und es macht auch meiner Meinung nach total Sinn. Warum? Weil ich mich auf den Inhalt und nicht auf die Präsentation konzentriere.

Und ich glaube, jeder weiß, wie leicht es sein kann, so paar Bullet Points auf eine Powerpoint oder ein paar Bullet Points aufzuschreiben. Aber vollständige Sätze, die einen konkreten Gesprächsfluss oder einen roten Faden haben, der sich durchzieht, sind unglaublich viel schwieriger darzustellen. Also wo ich mich nicht hinter Animationen und irgendwelchen Farbverläufen verstecken kann, sondern wirklich den reinen Inhalt mit dem reinen Inhalt überzeugen muss.

Und das erlaubt es einfach jedem auch, alle Informationen zu haben. Natürlich wollen wir, wenn wir auf Konferenzen sind, dass man wirklich mir das zuhört und nicht nur die Slides liest. Das ist eine andere Intention, deswegen packe ich wenig auf die Slides. Hier soll es darum gehen, dass das Dokument für sich selbst stehen kann und es erreicht sich durch einen geschriebenen Text, einen vollständig ausgeschriebenen Text, natürlich viel besser aus meiner Sicht. Das ist auch meine Erfahrung. Dass das zum Entscheidungsfindung und zum Diskurs über Vorschläge,

oft zum besseren Ergebnis wird.

Also die Powerpoints sind nur für uns quasi, damit ihr uns das Wissen vermittelt. Ja, echt interessant. Jetzt kommt natürlich KI ins Spiel mit den LLMs. Du hast gesagt, es sehr wichtig, dass man da auf sich auf die Fakten konzentriert, dass man drüber iteriert, dass man auch diesen Gedankenprozess dort hat.

wird AI dort verwendet mit Sicherheit? Wie stellt ihr sicher, dass die Gedanken wirklich so ausgefeilt sind oder bist du da einfach nicht tief genug drin in dem Thema?

Ich kann aus meiner persönlichen Erfahrung

sprechen. Das schlägt den Bogen zum Prompt Engineering. Wenn ich wenig Ideen, wenig konkreten Inhalt mitbringe, dann meiner Erfahrung die LLMs oder die Foundation Models an, viel Fluff drum herum zu generieren. Sehr blumige Textbeschreibungen, sehr lange Textbeschreibungen, wo eigentlich wenig drin steht. Wenn jemand das kritisch liest, dann sieht er das auch.

Wobei es hilft, so bisschen diese Demokratisierung. Nehmen wir mal an, ich bin jetzt nicht Native Speaker und ich habe vielleicht eben, ich kann nicht so gut meinen Gedankengang zu Papier bringen. Nicht jeder von uns ist der geborene Schriftsteller. Da helfen solche Tools natürlich schon. Den Gedanken, ich oder mein Argument, was ich vielleicht in meiner Sprache oder in einfachen Worten runterschreiben kann, dann doch nochmal

Ich will nicht sagen aufzuhübschen, aber etwas etwas flüssiger zu gestalten. Aber trotzdem bleibt es bei Shit in, Shit out. Wenn ich keinen vernünftigen Gedanken, wie in allen anderen Dingen auch, wenn ich kein ordentliches Argument, wenn ich keine Fakten mitbringen kann, dann wird auch der Output entsprechend wischiwaschi sein. Das heißt, es ist ein Tool, aber es ersetzt das aus meiner Erfahrung auf keinesfalls.

Okay, auf jeden Fall. Was ich noch oft sehe, ist, dass man vielleicht KI als Sparrings-Partner für die Idee nehmen kann, ein paar Mal hin und her iterieren und dort drüber gehen kann. Du siehst es also jetzt nicht tot für das gut geschriebene Wort, sondern eher als Hilfsmittel, dort dann noch eine bessere Qualität oder vielleicht, wenn man Sprachbarrieren hat, dass man die quasi überbrücken kann und seine Gedanken sortieren kann.

Mein Halbwissen von draußen hatte irgendwie so in Erinnerung, dass ich gehört habe, dass Alexa auch in diesem Prozess irgendwann mal erstanden ist durch die ganze Organisation und dann durch diesen PR FAQ dann im Produkt gelandet ist. wäre eine super Übergang zu deinem weiteren Hobby. Es gibt eine Webseite, die heißt voicegames.de. Was sind Voice Games und was hat das mit Alexa Skills zu tun?

Genau, das hatte was mit vielen Dingen zu tun, auch mit Serverless. Und es fing damit an, dass ich Gelegenheit hatte, Alexa in Deutschland oder die Echo-Geräte in Deutschland erschienen sind, mit Alexa, dem Sprachassistenten, das schon vorab auszuprobieren. Und dann auch in dem Zuge auch dazu gekommen bin, oder, und das ist wieder so ein Moment, das muss ich einfach mal ausprobieren.

So ein eigenes Skill. Skill sind im Endeffekt Apps für Alexa, die entsprechende Dinge tun können. Zu schreiben. da war die Idee, zu dem Zeitpunkt, ist so, dass der Klassiker was besonders Spaß macht, was engaging ist, ist erst mal ein Spiel. Das heißt also, das war so die logische Konsequenz, was macht mir Spaß, das macht hoffentlich auch anderen Spaß, also entwickeln wir irgendwie ein Spiel. Und das fing irgendwie mit ganz stumpfen Dingen einfach mal an.

wo ich sage, das war irgendwie, weil ich auch die Methoden ausprobieren wollte, so was wie Tierkette. Ich sage jetzt irgendein Tier und der Endbuchstabe, mit dem muss dann der Spielpartner, also dem Fall die Alexa, ein neues Tier. Und dann ging es immer so hin und her, bis einer kein Tier mehr wusste. Einfach mal so das auszuprobieren. Und es hat mir super viel Spaß gemacht, weil es auch einfach eine neue Form der Interaktion war und mich da so bisschen weiter als Hobby eben weiterentwickelt.

Daraus sind viele lustige Dinge entstanden. Also einer der Skills, die ich heute noch so lustig finde, ist, das war schon ein paar Jahre her, immer wieder relevant, ist Bundestagsbingo. Warum geht's da? Ich habe dann damals diese Slogans von den Werbeplakaten genommen und dann den Spieler raten lassen, welche Partei er das denn gesagt haben könnte. Und so ein bisschen auch aufzuzeigen, wie ...

ist da eigentlich überhaupt eine Zuordnung möglich. Also kann man aushand dieser Sprüche eigentlich ableiten, wer das denn gesagt haben könnte. da sind eben noch viele weitere. Das Spannende ist, dass das einem auch zwingt, unglaublich über die Nutzererfahrung nachzudenken oder diese künstliche Restriktion, kein Bild zu haben und auch extrem wenig

Interaktionsbügegigkeit. Man kann dem Nutzer nicht 50 Dinge präsentieren oder in nötigen 20 Dinge im Kopf zu behalten. Ein klassisches Rollenspiel, wo du 20 Gegenstände im Inventar, 15 Skills hast. Das fokussiert einen aus meiner Sicht darauf, einen minimal viable product, ein minimal lovable product zu erzeugen. Was ist die Kerninteraktion? Und die muss noch Spaß machen. Man kann es nicht mit Präsentationen aufhübschen. Und ganz ehrlich unter uns ...

Ich bin auch überhaupt kein Frontend-Typ, also Grafik und Grafikdesign. Deswegen kann mir Sprachinteraktion auch extrem entgegen.

Ja, sehr gut. Also nur das Backend, die Logik. Also ich kann mir das auch sehr spannend vorstellen, überhaupt Ideen zu generieren. Also das Spiel mit den Tieren, das habe ich natürlich mit meiner Tochter auch schon gespielt, echt wirklich gut. Machst du das noch aktiv oder ist das jetzt, also nochmal, wir werden deine Seite natürlich in den Show Notes verlinken, ist das mal so eine Phase gewesen, weil ich sehe jetzt zum Beispiel dieses Voice-Thema, gerade wenn es Prompen geht, immer...

Genau!

relevanter. wir müssen ja ganz viel da rein tippen und die meisten sind vielleicht mit tippen langsamer als mit der Sprache. Ich habe auch schon die eine oder andere Demo gesehen, wo sie dann auf den kleinen Knopf drücken und dann einfach jetzt per Voice dann quasi den Prompt rein geben. Also ich glaube, Voice hat noch einen Platz, den diese irgendwie jetzt erkunden muss und ein ganz viel Potenzial dahinter. Wie verändert sich Alexa diesbezüglich?

Ich glaube, ich bin total beide. Das geht in Richtung multimodal. Wir haben einfach eine Vielzahl an Interaktions, an Modi, mit denen wir interagieren können, per geschriebener Sprache, per gesprochener Sprache, visuell, ob es Bilder oder Videos sind. Die Interfaces, mit denen wir bisher interagiert haben, waren auf das, was für Maschinen zu verstehen ist. Das ist, wenn ich was runterschreibe.

Und wir merken jetzt so langsam, dass das sich wandelt. Also wo ich auch, wenn ich jetzt eben namhafte LLMs ausprobiere, die beides verstehen können. Ich mache ein Foto oder ich zeige nun ein Bild und kann dann damit interagieren. Und es wird weitergehen, nämlich sage ich kann auch sprechen und ein Bild zeigen. das wird also aus meiner Sicht die Richtung, diese Verschmelzung, diese Interaktion, so dass sich das auch so natürlich wie möglich anfühlt. Natürlich wird es weiterhin so bleiben, dass manche Dinge einfach auch geschrieben viel leichter sind.

als eben gesprochen, weil es eben Unschärfe in dem einen oder anderen Medien gibt. Also Dinge, die sich gleich aussprechen lassen, komplizierte Wörter, Zahlen, Buchstaben, Kombinationen, was auch immer. Ich möchte mein Passwort jetzt ungern laut vorlesen. Also das heißt also, ich glaube, dass das auch noch wieder einen Aufschwung erleben wird, was Alexa angeht. Gab es, glaube ich, jetzt erst kürzlich eine Ankündigung dazu, wie das Produkt sich auch weiterentwickelt, auch eben natürlich mit generativer KI.

Da ist Amazon allerdings so groß, dass ich da auch einfach nur Kunde bin und auch einfach gespannt bin, was da auf uns zukommt.

Ja, also definitiv werde ich die Website bookmarken und mal schauen, was da für Voice Games jetzt noch entstehen. Ja, gerne.

Vielleicht noch ein kurzer Hinweis, wenn ich das einstimmen

darf. Es gab auch mal eine lustige Interaktion. Ich hab dann auch irgendwann mich mal in die Richtung Produktivitätsskills da mal gewagt. das Ding hieß Lagerfuchs. Weil ich mir nie merken kann, kommen jetzt die Tomaten in den Kühlschrank, kommt jetzt die Avocado, wo kommt die jetzt hin? Also wo ich einfach sagen kann, wie lagere ich das entsprechende Obst, Gemüse oder was auch immer korrekt. War eben von bescheidenem Erfolg geprägt.

Aber es gab irgendwann mal den Kontakt von einem namhaften Hausgerätehersteller, der das dann in seinen Kühlschrank integrieren wollte, wo man quasi dann sagen konnte, man könnte den Kühlschrank dann fragen, ich habe hier so ein Ding, heute würde das wahrscheinlich per Kamerarekennung machen, das schon ein paar Jahre her, und dann entsprechend das integrieren wollte. Und dann ist im Endeffekt nichts draus geworden, leider, weil dann entsprechend vertragliche und eben nicht technische Gründe im Weg standen, aber eigentlich eine ganz lustige Anekdote.

Du hättest uns alle retten können, dass ich jetzt endlich weiß, wo der Salat hinkommt und wo der Aufschnitt landet im Kühlschrank. Ja, spannend. Also da merkt man auch, dass das eine gewisse Strahlweite hat, wenn man mit den neuen Technologien unterwegs ist und dass der Markt beobachtet wird. Sehr schön. Wir sind schon ein bisschen jetzt in der Zeit fortgeschritten zum letzten Thema.

Haha.

Du bist natürlich am Pol der Zeit auch. Was sind denn deine Themen aktuell, die du am Markt beobachtest? Was siehst du denn so für die Zukunft? Was interessiert dich? Was sind so Themen, wo du gerade Richtung Zukunft drauf schielst, die vielleicht noch nicht ganz da sind, aber wo du sagst, hey, das ist spannend. Das steht hier bei mir auf der Liste ganz oben.

Ja, klar, ganz präsent ist natürlich das Thema KI und generative KI immer noch. Und das deckt sich mit dem anderen Thema, was ich sehe, oder das hat eine starke Überschneidung, ist Developer Experience. Weil ich habe eingangs erwähnt, wir sind in so einer Phase, wo sich Prozesse ändern, wo sich Arbeitsweisen ändern, wo einfach viel Umbruch herrscht. Und aus meiner Sicht ist es so, dass im Laufe der Zeit immer mehr Tools, immer mehr Governance, immer mehr

es immer mehr Dinge gibt, die ich als Entwickler zu berücksichtigen habe. Dann gibt es wieder Phasen, Schweinezyklus, wo wir versuchen, das wegzuobstrahieren, das Leben leichter zu machen, dann kommt noch mal mehr dazu. Und so im Laufe meiner Erfahrung wird es eher mehr als weniger. Das heißt also, ich glaube, in die Zukunft blickend wird weiterhin ein ganz großes Thema sein, wie können wir als Entwickler uns auf das konzentrieren, was wir eigentlich tun wollen. wir können andere Entwickler dafür sorgen, dass wir das erreichen können.

Und es geht Hand in Hand mit dem Thema KI, wo ich sage, ist aus meiner persönlichen Erfahrung oder meiner beschränkten persönlichen Erfahrung, alt ist das Thema ja noch nicht. Aber das, ich auch sehe und selber merke beim Nutz, bei der Nutzung ist, das hat einen unfassbaren Einfluss. Erstens, wenn ich es richtig nutze, wenn ich auch Zeit ein bisschen reinstecke. Und es wird ja nur besser. Das heißt also, das, wir jetzt haben, sind ja die Anfangsschritte der Technologie.

Wenn wir jetzt hingehen, wir haben bisher ganz oft den Use Case gesehen, Text rein, Text raus. Wir sind jetzt an dem Umbruch, das sehe ich bei Kunden, das sehe ich bei uns, dass wir zu so einer sogenannten Agenten-A.I., also agentenbasierten, wo ich nicht mehr nur noch über Wissen rede, sondern auch über Aktionen, wo dann die Tools für mich auch, weiß ich nicht, meiner Infrastruktur interagieren können, wo die für mich jetzt im ...

andere Beispiel, Meetings organisieren können, im Internet irgendwelche Dinge tun können. Also wo wir jetzt über höherwertige Aufgaben sprechen, das erfordert natürlich wieder Vertrauen, das erfordert auch natürlich irgendwo Responsible AI, also es sind noch viele ungeklärte Themen drum herum. Die Entwicklung lässt sich, glaube ich, nicht aufhalten und es wird einfach super spannend zu sein, in welche Richtung sich das entwickelt und wie viel Mehrwert das noch für uns generieren kann.

Ja, sehr spannend. Ich hatte letztens auch zu dem Thema ein Gespräch, was ich oft sehe, wir haben ja ganz viele Systeme, die einfach nur dafür da sind, gewissen Zustand zu dokumentieren. Und das sind oft, ich sag dann manchmal Schreibmaschinen, also Systeme, die nachgelagert quasi diese Informationen notieren, aufschreiben, also man kann es automatisieren. Aber der Fakt ist sozusagen, dass wir versuchen Transparenz zu schaffen über einen bestimmten Zustand, über bestimmte Sachen, die wir erfüllen müssen. Und die werden einfach in den Systemen

notiert. wenn man jetzt einen Schritt weiter denkt und sagt, wir machen die Systeme so intelligent, dass ich diese Systeme selbst fragen kann über ihren Zustand oder die Historie, woher sie kommen, fallen natürlich eventuell auch das ein oder andere System weg, was ich einfach nur aus der Tradition gebraucht habe, gewisse Schritte zu dokumentieren.

mehr. Ja bedeutet aber auch, dass du wieder den Prozess verstehen musst. Was machen die Entwickler? Wie arbeiten die Entwickler? Und das Gute, was ich in deiner Stimme höre, ist, dass wir Menschen noch gebraucht werden. Die KI macht nicht alles selbst.

bin mal gespannt, wie gut der Spruch altert, aber ist zumindest meine Einschätzung im Moment. Ich glaube, wir kennen alle die Sprüche, wir müssen demnächst nicht mehr programmieren. Hat sich bisher nicht als wahr herausgestellt. Schauen wir mal, wie es diesmal aussieht.

Das

Okay, wir sind auch am Anfang. Es bleibt spannend. Ben, vielen Dank, dass du da warst. Hat mir sehr viel Spaß gemacht, dir zu sprechen. Wenn Leute mit dir in Kontakt treten möchten, auf welchen Social-Medias bist du aktiv? Wie können die Leute dich erreichen? Wo finden sie was über dich im Internet?

Genau, ich im Sinne der Priorisierung und Fokussierung, ich hab viel zu tun, bin ich eigentlich nur auf LinkedIn unterwegs. Wenn ihr mit meinem Namen bei LinkedIn sucht und AWS, da der Nachname ist zum Glück eindeutig, findet ihr mich dann da. Du hast ja mal die Webseite schon angesprochen über Voice Games. Das ist natürlich auch eine Möglichkeit. Genau, ich glaube, das ist die beste Variante.

Alles klar, werden die Daten natürlich alle in den Show Notes notieren. Nochmals vielen Dank, dass du da warst. Für alle anderen, danke, dass ihr zugehört habt. Die zweite Episode war sehr spannend. Bitte subscribt und liked die Videos oder Audio auf eurer beliebigen Plattform, da wo ihr den Podcast hört, das HIPs, die Beyond-Code-Community wachsen zu lassen. Vielen Dank und bis zum nächsten Mal. Ciao.