All posts tagged: technologie

Skillbyte Podcast #40: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 2)

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt (Teil 2)

// Inhalt //
01:27 – Masiar’s IT Katastrophengeschichte
02:29 – 6. Lektion: Verstehe zuerst das Problem, schreibe dann erst Code für die Lösung
08:18 – 7. Lektion: Frage um Hilfe wenn du nicht weiter kommst (ultimative Superkraft)
11:20 – 8. Lektion: Du wirst immer weiter lernen (müssen)
21:22 – 9. Lektion: Test driven development (TDD) ist ein Mythos
26:34 – 10. Lektion: Alles dauert länger als geplant. Lass dich nicht von willkürlichen Deadlines verrückt machen.

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Nein. Prozess. Prozess beim ersten Mal o. citta bibber und um Gottes Willen und die Welt geht unter. So, und dann machst du und tust du. Und dann bist am Wochenende da und nachts bis drei. Und hin und her. So wird es aber trotzdem später, weil irgendetwas passiert ist, wo du keinen Einfluss drauf hast oder merkst. So schlimm war das jetzt doch nicht, weil der der Druck gemacht hat. Der war dann auch entspannt. So, und wenn das ein paarmal passiert, dann zuck sogar wenn Merkel.

Herzlich Willkommen zu unserem Skill bald Podcast Episode Nr. 40 10 Lektionen, die wir in über vierzig Jahren Softwareentwicklung gelernt haben. Teil 2 Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld, wenn ihr die Entscheider oder die Fachkraft seid. Wenn ihr Hörer Fragen habt, sendet uns gerne eine E-Mail an Podcast als Skill bei D. Wir freuen uns immer über eine positive Bewertung und wenn ihr den Podcast an Freunde und Kollegen aus dem ähnlichen Arbeitsbereich weiter empfehlt ich bin heute hier wieder mit Mazur zum zweiten Teil.

Hallo Masiar, Hallo Maurice, du bist heute sehr Energized.

Ich bin heute total Energieriese. Ich hatte eine gute Woche und freue mich jetzt mit dir. Wirklich, wirklich. Weil die ersten 5 Lektionen sind schon super angekommen. Da hab ich viele Zuschriften bekommen per WhatsApp und freue mich jetzt mit dir. Lektion 6 bis 10 durchzusprechen voller Energie. Vorher allerdings möchte ich dich fragen Sind dir noch Katastrophen aus deinem Leben eingefallen?

Ganz im Ernst. Ich habe überlegt und überlegt, wie es wirklich nichts eingefallen. Allerdings muss ich sagen, jetzt letztens kam eine GERB für Gravity Kiwi so toll eingerichtet. Was dir berichtet, ob alles in Ordnung ist. Und da kam eine Falschmeldung und damit hat sich das Herz in die Hose gerutscht. Da hatte ich seit langem mal wieder Angst, weil ich unterwegs war und nix machen konnte. Aber es war eine Falschmeldung. Insofern war es wieder gut. Was stand in der Meldung, dass Gravity nicht verfügbar ist?

Also komplett offline? Ja, genau. Ah, okay. Ich dachte jetzt Datenbank kaputt. Hacker haben die Daten geklaut oder so irgendwas Relevantes.

Mir ist nichts passiert in der Richtung nichts passiert. Okay. Erst bauen und Fehlalarm.

Das ist bestimmt meine Aura, die sowieso alles abhält. Deine Aura möchte ich auch haben. Na gut, springen wir zur sechsten Lektion. Vielleicht fällt dir unterwegs noch eine Katastrophe auf, wenn wir durch die Lektionen gehen. Die sechste Lektion ist eine ganz wichtige. Und zwar verstehe zuerst das Problem und schreibe erst dann den Code für die Lösung. Das Problem hierbei ist es oft. Ich bin sicher, das hast du auch gesehen, dass wenn es um Softwareentwicklung geht, springen viele Leute sofort ins Coding.

Die haben die Anforderung gehört. Ach ja, ich weiß schon, was ich machen muss. Achja, da mache ich das so. Da braucht man hier in Cash und das und das und setzen sich sofort an die Tastatur und legen los. Neue Funktionen wenn, dann so iterativ, ganz schnell implementiert und laufend angepasst. Und man merkt erst nach einiger Zeit, dass man das Problem gar nicht korrekt verstanden oder vollumfänglich verstanden hat. Und dann fängt man nochmal von vorne an oder es kommt auf jeden Fall zu einem erheblichen Zeitverlust.

Ich bin sicher, das hast du auch schon gesehen.

Ja, absolut. Ich meine, ich hab mich selber schon mal dabei ertappt. Ich hab mir seit dem das war so in den Anfängen hab ich das so gemacht. Tatsächlich. Aber irgendwann hab ich mir angewöhnt, keine Sequenzer, Diagramme, Urmel, Diagramme und so weiter groß gemacht, sondern einfach auf ein Blatt Papier, so die Komponenten aufgemalt, die Beziehungen aufgemalt. Kann echt auf einem Blatt Papier sein, um einfach mein Kopf zu sortieren und dann steige ich habe auch schon gerne ein.

Mir liegt die Klassennamen auf oberster Ebene, verknüpfe sie, schreibe die ersten Tests Duala Test Driven und das funktioniert ganz gut.

Das ist so, bis ihn der Flow, denn ich habe genau das ist für mich ein ganz klarer Indikator, ob man es mit einem Junior Entwickler oder Senior Entwickler zu tun hat. Ein Senior Entwickler stellt erst einmal sehr viele Fragen und versucht das Problem genau zu verstehen oder die Anforderungen genau zu verstehen und ist halt erst Input fokussiert. Wie geht man das jetzt an? Also du hast es eben schon gesagt. In jungen Jahren geht der Tüftler mit einem durch und man möchte sofort einsteigen und loslegen.

Ich habe so zwei unterschiedliche Pattern, je nachdem ob es um Feature Entwicklung geht oder um Bugfix sing.. Fangen wir mal mit dem Einfacheren an. Das wäre das Bugfix sing.. Das Allerwichtigste beim Bugfix sing. ist, dass man erst einmal den Bug zuverlässig reproduzieren kann, weil erst dann sinnvolle Entwicklung eines Fixes möglich. Meiner Ansicht nach erst, wenn ich weiß, wenn ich hier klicke und da klicke und dann tritt der Fehler auf und das immer wieder machen kann. Erst dann kann ich ja quasi prüfen, ob meine Lösung das Problem wirklich löst.

Ein weiterer Hinweis und ich bin verblüfft, wie viele Leute das nicht machen ist, den Debugger zu verwenden, also wirklich Schritt für Schritt durch das Programm durch zu steppen und sich die Variablen anzugucken. Was passiert hier? Was passiert da gerade, wenn man das Programm selber nicht kennt oder es nicht selber entwickelt hat, dann wird es oft sehr einfach, da einen Fix zu entwickeln, weil man einfach genau sieht Ah, ok, an dieser Stelle muss etwas anderes passieren oder muss etwas weiteres passieren und das könnte man dann implementieren.

Einfach den die Bagger abklemmen und idealerweise wenn man den Bug dann gefixt hat, dann hinterher war man jetzt schon im Thema drin. Noch einen Testa zu schreiben, der prüft, dass der fix funktioniert und dass das Problem eben nicht nochmal auftritt. Das ist meiner Ansicht nach eine professionelle Möglichkeit ans Bugfix hing ranzugehen, um nicht direkt in den Code zu springen. Bei der Feature Entwicklung und da bist du wahrscheinlich bei mir ist es oft so, dass die Anforderungen gar nicht so klar sind.

Also das ist wirklich ganz ganz selten, dass der Projektleiter. Jeder auf einen zukommt und glasklar schon sagt Das soll so sein. Das soll so sein. Das soll so sein. Das soll so sein, sondern ja, wie hat man altes System? Und da lief das so und so und ich möchte das jetzt genau so haben. Nur hier und da, da muss etwas geändert werden. Also das tritt sehr häufig auf. Auch hier das Problem erst einmal voll umfassend verstehen.

Wenn schon Quote da ist. Also wenn z.B. das Feature eine Erweiterung darstellt, erst einmal diesen verstehen, dann ne Lösung Skizze erstellen, genau wie du sagst. Ich versuche mir immer die Eingabe und Ausgabe Daten erst einmal aufzuschreiben. Was geht rein, was soll rauskommen und dann eine Technologie Skizze zu machen. Und im Grunde ist für mich ein Computersystem in Daten Topf mit Code drumherum, also eine Daten Haltung die Transformationen auf diesen Daten durchführt. Und ich glaube, wenn man die Daten und die Transformations Schritte hinreichend genau beschrieben hat, dann wird das Problem mehr oder weniger klar und der Rest folgt fast automatisch.

Oder die Problemlösung folgt fast automatisch. Und bis man soweit ist, hat man sehr viel gelesen, aber noch keinen Code geschrieben oder sehr wenig Code geschrieben. Warum passiert das? Warum springt man sofort in den Code? All das einfacher ist, als sich Gedanken über das Problem zu machen. Das ist oft sehr schwierig. Man muss nachfragen, man hat es nicht genau verstanden. Man muss diese Zeichnung erstellen und direkt zu coden. Das möchte im Grunde jeder. Aber mit zunehmender Reife weiß man, dass das nicht unbedingt das zielführende Vorhaben ist.

Du bist auch motiviert, hast eine Idee im Kopf und setzt sich hin und willst das sofort machen. Also ich muss sagen, wenn ich tatsächlich eine Idee fest im Kopf habe, dann mach ich das auch schon mal hier und da setze ich mich hin und knallt die Klassen einfach rein. Das funktioniert auch ganz gut, aber ich glaube, das kannst du nur machen, wenn du gewissen Erfahrungsschatz mitbringst.

Erstens das und wenn das Problem hinreichend klein ist. Ja, definitiv. Also nicht bei super komplexen Funktionen oder wo sehr viele Transformationen gemacht werden müssen. Genau. Und dann ist es oft auch wichtig, das Problem korrekt zu erfassen oder das ist eigentlich das Wichtigste und dann das Problem zu lösen, anstatt irgendwie fancy mit Architektur Patterns technische Exzellenz zu zeigen. Das sehe ich auch relativ häufig. Dann werden dann einfache Sachen technisch exzellent gelöst, aber das Problem ist gar nicht so richtig verstanden worden.

Da gibt’s ein schönes Zitat und damit möchte ich die sechste Lektion abschließend von Abraham Lincoln Gib mir sechs Stunden einen Baum zu fällen und ich werde die ersten vier Stunden mit dem Schärfen der Axt verbringen.

Als Kind ist es echt schön. Ja, genau.

Ich kenne sogar so eine extreme Version. Da heißt es Gib mir fünf Stunden und 50 Minuten zum Schärfen der Axt, sodass man mit einem Hieb im Prinzip den Baum durchbekommt. Aber was heißt das hier? Ganz klar Desto genauer du das Problem verstehst, desto einfacher wird die Lösung hinterher. Nur man muss halt mehr Zeit mit der gedanklichen Beschäftigung mit dem Problem verbringen statt mit dem eigentlichen Coding. Deshalb ist das so schwierig zu befolgen. Die siebte Lektion ist für mich eine ultimative Superkraft.

Und zwar Frage um Hilfe. Wenn du nicht weiterkommst, wie machst du das?

Wenn ich nicht weiterkomme, muss ich sagen such ich tatsächlich im Internet. Stack Overflow ist definitiv eine Quelle, die mir sehr viel Tipps und Inspiration gibt, aber auch alle Menschen toll sehr Ego im Netz sind. Da werde ich für den speziellen Fall, wo ich nix finde, frage ich ja tatsächlich natürlich auch Kollegen.

Man verbeißt sich oft in Problem oder so geht’s mir manchmal. Du fängst an, alles ist ganz einfach. Dann kommen irgendwie Hindernisse, auf den gelangst du immer tiefer in diesen Kaninchenbau rein. Man probiert unterschiedliche Ansätze und wendet sehr viel Zeit auf. Also dann ist man richtig frustriert und fragt nach zwei Stunden vielleicht einen Kollegen. Und er sagt Ach ja, kenne ich schon. Du musst hier das und das machen. Boah, das hat mich damals drei Tage gekostet, das herauszufinden oder so, wo man so richtig schön per Facepalm dann denkt Oh Mann, da hätte ich mal vorher gefragt.

Das ist aber auch so eine Gratwanderung. Du kannst ja nicht wegen jeder Kleinigkeit den Kollegen fragen. Na weil, dann ist er auch irgendwann genervt. Manchmal, wenn du der Mensch bist, der sich am längsten mit einem Problem beschäftigt hat oder am längsten ein Projekt ist. Es ist einfach unwahrscheinlich, dass die andere weiterhelfen können. Natürlich Google Stack Overflow und alle Quellen benutzen, die man im Internet findet. Das ist das Naheliegendste. Aber hier soll es wirklich darum gehen, den Kollegen zu fragen oder die Kollegen Kolleginnen zu fragen, ob man weiterkommt.

Also ich mache das so, ich probier das erstmal eine halbe Stunde, sag ich mal. Wenn ich an ein Problem komme und wenn ich dann nicht weiterkomme, zwinge ich mich, aufzustehen und jemanden zu fragen oder eben patschert jemanden zu fragen. So um dann einerseits respektvoll mit der Zeit der Kollegen umzugehen, auf der anderen Seite aber auch nicht zu viel Zeit zu verständigen. Und das hat sich bei mir eigentlich als gutes Vorgehen herausgestellt. Aber du fragst nicht so viel, oder?

Nee, hat vielleicht auch ein bisschen mit Persönlichkeit zu tun. Ich versuche lieber selber zu lösen. Keine Ahnung, ist einfach so. Ich kann nicht sagen, warum. Aber ich will den Knoten selber irgendwie aufmachen.

Das hab ich auch, dieses Gefühl. Man hat schon so ein bisschen das Gefühl Ah, wenn ich frage.

Und das ist jetzt vielleicht eine einfache Sache, das geht so ein bisschen in die Berufsehre. Sitzt noch nicht mal irgendwie, aber so ich mache auch nicht gerne welche Superpower Grabbing oder sowas würde ich programmiere, möchte ich irgendwie allein sein. Ich hoffe, das versteht Cat irgendwie, oder ob das jemand nachvollziehen kann.

Ich glaube, das können sehr viele nachvollziehen. Bei mir ist das tendenziell auch so, aber ich hab ne Frustrationstoleranz, die sehr niedrig ist, wenn ich nicht in kurzer Zeit ausreichende Fortschritte mache. Also wenn ich das Gefühl habe, oh, mit jemandem zusammen komme ich schneller voran. Der Zweck heiligt die Mittel sozusagen. Dann setze ich mich auch zu zweit hin. Wenn ich das Gefühl hab, ich komme ja alleine weiter, dann hab ich auch kein Problem, das zu machen.

Aber ich glaube dennoch ab und an um Hilfe zu fragen. Kann einem sehr schnell sehr viel weiterbringen. Zumindest für das Team. Insgesamt ist es besser, als wenn jeder verbissen an seiner eigenen Lösung arbeitet. Die 8 Lektion. Hier geht es um Weiterbildung. Da haben wir ja auch schon in diversesten Episoden drüber gesprochen. Im IT-Sektor wirst du immer weiter lernen müssen. Das Technologie Umfeld ändert sich so schnell. Bestehende Technologien verlieren an Relevanz, neue kommen hinzu, die es noch gar nicht gab, die sehr schnell sehr prominent werden.

Und es wird gefordert, weil man ist ja Technologie Experte, dass man sehr schnell eine Einschätzung liefern kann. Was sind kurzlebige Trends und was sind wirklich längerfristige Entwicklung und was bedeuten diese für das eigene Umfeld? Im Grunde Welche Technologien muss ich lernen und welche kann ich einfach vorbeiziehen lassen? Wie machst du das? Hast du da bestimmte Kanäle, über die du dich informierst, abseits der üblichen wie Heise, Golem usw.?

So um Trends und so weiter mitzubekommen. Tatsächlich einfach im Internet. Heise Golem. Ich habe aber auch diese ich habe mal Subscription eins zu Cloud, Gusi und viele Yumi Kurse. Da schaue ich regelmäßig mal vorbei und gucke, was neue Kurse sind. Speziell ist es aber für die Bereiche Java oder DevOps. Wo ich unterwegs bin, suche ich gezielt danach. Und wenn mir irgendwas interessant erscheint oder mir ein Wort begegnet Technologie, von dem ich noch nicht gehört habe, dann gucke ich mal rein.

Dann suche ich danach explizit. Ich versuche halt immer so ein Level zu erreichen, wo ich verstehe, was das Tool macht. Will mir eins besonders interessant erscheinen, oder? Ich meine, das passt mir sehr gut den Kram. Dann mach ich auch schon mal so ein Tutorial mit, um einfach mitreden zu können, einfach zu wissen, was es ist, was man damit machen kann und so erweitere so nach und nach mein Tool. Schade. Oh dann, je nachdem ich das nächste Mal auf so ein Problem stoße, weiß ich Aha, da gab’s doch mal so ein Tool.

Okay, toss im Grunde diese Sternenkarte schon im Kopf. Und wenn ein neuer Stern auf ploppt, dann guckst du dir den kurz an und kannst ihn dann einordnen.

Ja, das halte ich auch für sehr wichtig. Ich finde, diese längerfristigen Entwicklungen oder diese großen Trends, die erkennt man relativ gut, weil sie auch mehrere Jahre bestehen. Also Cloud wäre z.B. ein Trend, Datenauswertung wäre ein großer Trend. Generell Megatrend ist natürlich Digitalisierung. Wobei tue ich mich schwer, das als Trend zu beschreiben, sondern das ist einfach eine weitere Entwicklungsstufe der Menschheit. Das möchte ich jetzt nicht als Trend verstanden sehen, sondern man kann technologisch einfach Prozesse effizienter abbilden, als man das manuell könnte.

Gerade jetzt mit Heimarbeit wird das offenbar an vielen Stellen, sodass das auf eine weitere Entwicklungsstufe ist. Aber es gibt auch Micro Trends, das sind z.B. Tools im Kobanê, das Umfeld oder im Container Umfeld, die man so ein bisschen im Auge behalten muss. Vielleicht hier als Tipp. Ich weiß nicht. Kennst du jeden Freitag auf dem Heise Newsticker diese Developer News in ein, zwei Sätzen? Du kannst mal auf Heise Slash Developer gehen, da kriegst du nur die für Developer relevanten Artikel angezeigt.

Ist für mich ein Super Life Hack und die ganzen Clickbait Artikel sind dann weg und da gibts es jeden Freitag so ein Digest, wo dann in zwei Sätzen immer dran steht. Das Tool ist und der und der Version entschieden. Das kann jetzt so und so.. Die Software hatte Sicherheitslücken, die wird nicht mehr gepflegt, die ist neu hinzugekommen. So und das sind immer 35 40 Einträge, wo man einfach weiß, was so abgeht. Dieses Symbolbild von dem Artikel ist immer das gleiche.

Daran erkennt man es dann sofort und man hat einfach einen schnellen Überblick. Viele Tools sagen einem auch nichts. Also wenn das sieht so aus dem Automotive Bereich kommt oder irgendein Spezialwerkzeug ist okay, dann hat einem das noch nicht berührt. Aber so hat man so einen Überblick. Und da guck ich dann rein. Wenn jetzt ein Tool schon zum dritten, vierten Mal Erwähnung findet, dann kann ich mir vorstellen Ah, okay, das scheint auf jeden Fall wichtig zu sein, oder?

Da wird häufiger drüber gesprochen, weil die Entwicklung da so rasant ist. Jede Woche eine neue Version ist ja dann schon eindeutig ein guter Tipp. Auf der anderen Seite, also wenn es schon gesagt. Im IT-Bereich wird man immer lernen müssen. Auf der anderen Seite finde ich auch desto mehr Erfahrung man hat, desto weniger Schrecken ein. Diese neuen Technologien, weil man immer wieder feststellt So wirklich, wirklich Neues. Das kommt vor. Aber es ist nicht so häufig, sondern oft erscheinen neue Frameworks oder Libraries.

Und die sind nur ein Aufguss einer bekannten Technologie aus einem anderen Kontext. Und alles war irgendwie schon mal da. Deshalb bin ich dazu übergegangen, mir eher die Konzepte anzuschauen Welches Konzept steckt denn hinter der Blockchain oder einem Paket Manager oder Haskell? Wenn du SQL kannst, da kannst du alle Datenbanken und nicht nur eine bestimmte. Wenn du weißt, wie ein Paket Manager funktioniert, dann kannst mit N.P. Umgehen, mit Maven, mit Neef, geht mit APC, mit Pacman Kapern und wie sie alle heißen.

Und wenn dann jetzt der nächste dazukommt, dann weiß man AOC, dass im Paket Manager DeWitt irgendwie so funktionieren. Ich weiß, was im Paket Manager macht und das ist dann der Achte im Bunde. So ungefähr auch Protokolle. Also ganz früher gab’s den Remote Procedure Call, der ist sogar noch vor meiner Zeit, den kennst du wahrscheinlich noch. Dann kam die Scope Schnittstelle. Heute sind wir bei Rest APIs angekommen. Wer weiß was danach kommt. Hier Proto Buffer oder so.

Bei Frameworks genauso Tools kommen auch andauernd neue hinzu. Na da gibt’s natürlich so mega Tools wie Git. Also Code Warning ist glaube ich schon in den letzten 15 Jahren extrem gepusht worden, wo früher die Leute ihre Dateien irgendwo gesichert haben. Es war ganz grausam und zwischen den einzelnen Ökosystemen, also dort net Java node Python you name it. Wenn irgendwo ein cooles Feature auf ploppt ist meiner Erfahrung wird das sehr oft geklaut.

Sehr gut. Ist ja normal. Ja, ich finde das auch gut. Das ist ja die Schönheit. Ein Open Source. Wenn einer was rausgefunden hat, können alle profitieren. Also wie schließen wir mit dieser Lektion ab oder was ist unser Empfehlung? Ich würde sagen, man muss nicht alles im Detail verstehen, aber man sollte halt die Konzepte verstehen und diese Themen einordnen können. So wie du das eingangs im Prinzip gesagt hast. Du hast diese Sternenkarte und kannst neue Sterne schnell platzieren.

Du versuchst halt zu abstrahieren, soweit wie möglich.

Was ist für dich eine Technologie der letzten Jahre, wo du gedacht hast Okay, das ist ein Megatrend? Mein Gott, da muss ich wirklich viel lernen.

Das ist das Thema Cluster Orchestrierung. Docker Dieses ganze Gebilde. Das war für mich völlig klar, dass ich meine, damals waren mehrere so am Start da visus Marathon, kybernetisch, die waren alle gleich auf. Und interessanterweise, das hab ich auch schon bei einem anderen Podcast erwähnt. Ich hab mich am Anfang komplett gegen diese Docker Technologie gewehrt, als die Kollegen das angesprochen haben. So ein bisschen erklärt hab. Ich fand das halt mega abstrakt. Ich hab das alles gar nicht verstanden wie Leya und wie.

Ich kann da nicht reinschreiben was soll der Scheiß. Nach und nach je mehr die das gemacht und eingeführt haben, umso mehr hab ich verstanden. Mein Gott und dann hat es irgendwann Klick gemacht. Hat euch boah wie geil darunter. War mir klar, das willst du lernen. Ja, da hab ich mich rein gekniet. Das war vor fünf Jahren. Und dieses Universum expandiert wie das richtige Universum, wie es permanent neue Tools erfindet sich neu. Da kommt K3 is leichtgewichtige Scobel net das, was du quasi auf dem Raspberry laufen lassen kannst.

Das explodiert quasi diese Technologie. Und ich liebe es aber auch so dran zu bleiben. Kugel und auch Madhya. Das ist super und find ich klasse. Also diese Technologie war für mich so zu all dem was die letzten Jahre passiert ist mit ein Gamechanger der Wahnsinn.

Nachdem du dich zuerst gewährt hast, wusste ich gar nicht. Hast du gedacht, das ist so kleinteilig?

Und was braucht man mehr als VMS oder genau was bringt da auch so außer jetzt eine riesen Lernkurve? Muss das jetzt sein? Sah ich so halt als Spielerei der Admins an und eigentlich war diese Erfahrung ganz gut, weil wir ich jetzt quasi bei einem Kunden bin. Und du hast meinetwegen so einen alteingesessenen Unix Systemadministrator, der diesem Konzept entsprechend auch nicht aufgeschlossen gegenüber ist. Dann kann ich das super nachvollziehen und weiß dann, wie ich den anderen führen kann. Was so?

Weil du diese Entwicklung selber mitgemacht hast, kannst du sozusagen auf der empathischen Schiene sagen. Ich weiß, die Bedenken hatte ich auch. Aber sieh mal folgendes Ja, da kommen mehrere Sachen zusammen. Mit Docker hattest du so eine erste Abstraktionsebene und Docker alleine bringt ja nicht so viel. Aber in dieser Kombination mit dieser Cluster Technologie und diesem Paradigmenwechsel dieser da wir eine Episode gemacht dieser 12 Faktoren für Cloud Native Apps kannst du ja Anwendungen komplett anders bauen, die dann eben wirklich weltweit skalieren.

Also du kannst mit den großen Gagfah Unternehmen mithalten, vom technischen Standpunkt aus, wenn du diese Software nach diesen Paradigmen entwickelst und diese Gaffer unternehmen haben die sie ja entwickelt. Das ist nicht nur Technologie, sondern auch so ein Mindset plus auch diese Cloud. Denke da kommt alles zusammen. Und das ist eine größere Blase oder ein eigenes Universum, was man nicht so isoliert betrachten kann. Und für dich? Du hast ja mal gesagt, dass du auch früher viel IT Administration gemacht hast.

Also Netzwerk Administration, Linux Administration nehme ich mal an..

Die SEMA Administration oder so Backoffice wirklich, oder?

Ich war Third Level Support einmal und zum zweiten haben wir mit einem anderen Kollegen via Mail und Unix Systeme. Administriert mit send Mail. Ja, das waren noch Zeiten. Okay, da war noch nichts Container visiert. Äh, nicht so wirklich.

Ich kann mich genau erinnern, wo der Kollege ankam mit 20 Disketten und Material. Guck mal, Linux hier, Ledoux da. Das war also damals das Linux System. Putzer und Linux kam gerade erst auf und VM, wer will ich nie faxen? Wir sagte hier Guck mal die Virtualisierung von VM. Wer und wie ich da Disketten reingeschoben hab und damit rumgespielt hab. Und da waren wir auch. Glaube, da könnte was draus werden und diese war so Vollbild geworden ist.

Das stimmt. Also dieses Feld wandelt sich weiter und wie im Universum. Es gibt schnelle Sterne, es gibt langsame Sterne, große Sonnen, die nicht mehr weggehen. Und das kommt in der IT auf jeden Fall mit. Man muss sich weiterbilden in allen 40 Jahren oder in all der Zeit. Dann die neunte Lektion. Ich weiß nicht, ob es schmerzhaft ist oder lustig. Test Griffen Die Welt abmahnt ist ein Mythos, heißt die Lektion. Und was ich damit meine ist Testserver Development, dass man zuerst die Tests schreibt und dann anhand der bestehenden Test da rein die Funktion implementiert.

Das hab ich schon so oft gehört. Bei Kunden und in der Theorie macht das auch Sinn, dass man sich zunächst über alle Grenzfälle einer Anwendung Gedanken macht und das Verhalten genau bestimmt. Und wie soll es denn sein? Wie soll sie sich verhalten, dass man anschließend alle diese Annahmen in Unit oder Integrations Test niederschreibt und dann im Prinzip die Komponente selbst entwickelt und nur noch die Komponente so minimal entwickeln muss, dass alle Tests grün sind, also alle Tests erfolgreich durchlaufen werden.

Und dann hat man sozusagen die minimale Lösung, die alle Tests erfüllt. Das habe ich in der Praxis noch bei keinem Projekt gesehen, wo das wirklich funktioniert hat. Ich freue mich schon über die Zuschriften.

Gerne melden, wenn es bei euch in der Firma funktioniert oder wenn ihr ein Projekt kennt, wo es funktioniert hat. Aber ich habe es einfach noch nicht erlebt. Und ich glaube, das Problem besteht darin, dass die Anforderungen für ein neues Feature oder für eine neue Anwendung oft nicht so messerscharf spezifiziert werden können, dass sich daraus Tests direkt ableiten können. Ist da deine Erfahrung?

Ja, Test am Anfang hat man immer gemeint. Also ganz ehrlich, ich gehörte auch dazu. Tests machen die Sache nur teurer, weil du ungefähr ein Drittel deiner Zeit damit verbringen musst. Wenn du Test Rival entwickelst. Aber je mehr ich in komplexeren Projekten eingestiegen bin, um so mehr ist mir bewusst geworden, wie wichtig doch Tests sind. Und inzwischen gibt’s ja Tests irgendwie. White Box Testing, Blackbox Testing, Tschiche Test Varianten und jedes für sich macht Sinn.

Ja, je mehr, desto besser. Weil so hältst du deine Software wandelbaren, gewitzte, gewisse Sicherheit da auch Änderungen zu machen. Und du hast einfach keine Chance, manuell irgendetwas zu testen, wenn du in irgendeiner Ecke rumschrauben.

Ich glaube, da spielen mehrere Faktoren eine Rolle. Und zum einen verändert sich Software heute schneller als früher, weil sich die Geschäfts Anforderungen schneller ändern. Man ist gewöhnt. Ah, ich muss die Software nur ändern und dann ist die neue Funktion da drin und das funktioniert sofort. So, das ist bis in die Vorstandsetage hoch Geblubber. Und deshalb ist die Erwartung. Ich kann die Software schnell ändern, dann können wir das abfangen gestiegen. Also die Zeiträume bis hin zur Implementierung sind halt kürzer.

Wenn die Zeiträume kürzer sind, heißt das aber auch Development to Market ist kürzer. Und wenn du jetzt keine Tests hast, dann ist das so, als wenn du in schneller Folge beim Domino Day die Dominosteine aufstellen willst und umgeben bist von anderen Dominostein. Die Gefahr, dass du da irgendetwas anderes um stößt, ist gerade in komplexen Systemen riesig. Das heißt, die meisten Projekte, so kenne ich das, verwenden schon automatisierte Tests, meistens Unit Tests für einzelne Funktions Komponenten, die dann von der CCD Pipeline, also Git Lab, Bruna, Maven Tests usw.

angestoßen werden und Schlüssel Komponenten testen. Die IBAN sieht die richtig aus? Stimmen, die Datums Konvertierungen usw. und sofort. Aber eben nicht alles abdecken. Auch RPI Tests gibt es mehr und mehr, die einfach die Funktionsweise von Schnittstellen testen. Aber niemand hat 100 prozent und im Falle des Falles unter Zeitdruck fallen die Tests halt einfach runter. So, das ist meine Erfahrung und definitiv. Das sieht ja auch erstmal niemand.

Also du hast 100 Funktionen, 99 davon sind getestet, eines ungetestet. Jetzt machst du noch 10 Funktionen, noch 10 Funktionen ohne Tests, sodass nur so graduell wird das immer schlimmer. Aber das ist wie Carius. Erst einmal sieht man es nicht. Und irgendwann wird es dann offenbar. Und ich will nicht sagen, dann ist es zu spät. Aber dann muss man es dann doch behandeln. Ich glaube, ein guter Kompromiss ist hier die Kernfunktion, also kritische Sachen, wenn es um Transaktionen geht von Benutzerdaten, also datenschutzrechtlich relevanten Inhalten oder Zahlungsarten.

Das ist super wichtig, dass man das alles ab testet.

Es gibt dabei in jeder Anwendung auch unkritische Bereiche, da muss man sich ganz so genau nehmen. Unit Tests zumindest Völklein Komponenten halte ich für wichtig. Ja, und auf Front in Tests gibt es mehr und mehr und auch desto länger die Software besteht, desto mehr lohnen sich Tests. Gerade wenn viel verändert werden soll, hast du noch einen Tipp, wie man vielleicht dieses Tests Problem besser lösen kann? Also wie machst du das? Wie teilst du dir die Zeit ein für Tests?

Machst du Tests oder nur wenn es gefordert ist? Oder bestehst du darauf?

Nee, also so rigoros oder stringent bin ich nicht. Wenn ich meine, dass eine Interaktion zwischen Komponenten oder einer Komponente selber für mich in gewissem Komplexitätsgrad übersteigt, wo ich meine Oh, wenn es hier eine Änderung gebe, dann könnte es zu Problemen führen. Oder wäre das schön, wenn die anderen Komponenten das das bastel ich mir so im Kopf zusammen. Und wenn das einen gewissen Sprechrolle übersteigt, dann mach ich die Tests auch nicht für jede Klasse und jede Methode, sondern wirklich da, wo ich der Meinung bin, das könnte schwierig werden.

Später für die Worker oder Helper oder Converter oder sowas. Eben genau die sehr oft aufgerufen werden und die so eine Kernfunktion dann bewerkstelligen. Ja, sehe ich auch so. Haben wir schon einen gleitenden Übergang zur zehnten und letzten Lektion. Und davon können alle die Mitarbeiter und IT-Fachkräfte und Projektleiter ein Liedchen singen. Die zehnte Lektion heißt Alles dauert länger als geplant. Lass dich nicht von willkürlichen Deadlines verrückt machen. Das geht eher in Richtung Entwickler. Alles dauert länger als geplant. Wäre vielleicht die richtige Überschrift hier.

Was ist das Problem? Das Problem ist bei Kreativ Arbeit und nichts anderes ist ja die Erstellung von Programmcode. Im Grunde genommen ist ja nicht so, dass man da Mathematik rechnet, sondern eher kreativ sich eine Lösung überlegt und die dann runter codiert oder eine Formsprache bringt. Bei kreativer Arbeit ist es schwierig eine realistische Zeit Abschätzung abzugeben, gerade wenn die Anforderungen nicht klar sind. Zudem gibt es eine Vielzahl von Zeitfresser. Das erlebe ich immer wieder, die niemand auf dem Schirm hat.

Neue Bugs kündigen sich nicht an. Man kriegt einen problematischen Mertz Request von jemand anderem zugewiesen und brauch dafür 2 3 Stunden länger als gedacht. Mitten im Projekt gibt es Bibliothek, Updates oder Sicherheitslücken, die nicht warten können. Diese Bibliothek Updates ziehen Schnittstellen Änderungen nach, die man sofort machen muss. Was sonst funktioniert es nicht mehr? Irgendetwas funktioniert nicht wie beschrieben, kommt auch relativ häufig vor. Ein Kollege muss eingearbeitet werden, ein Kollege fällt aus. Es gibt viele Meetings.

Die Firma hat eine Restrukturierungen. Es wird kommuniziert, was jetzt alles restrukturiert wird und so weiter und so fort.

Und das taucht in keiner Zeit Abschätzung auf. Also ich habe noch bei keiner Sheets Runde gehört. Ja, also eigentlich würde ich sagen, ich brauch Tag, aber wenn wir restrukturiert werden unterwegs sollte ich vielleicht mal 2 Tage einplanen, weil beweiß. Dann bin ich ein Tag mit Meetings zugeschüttet oder so. Ich hatte jetzt letztens eine das hat mich nicht selber betroffen, aber eine Mitarbeiterin, die für ein Promo Video der Firma einen Tag quasi zur Verfügung stehen sollte. So was wird natürlich auch vorher nicht abgeschätzt.

Also was bedeutet das? Es dauert immer länger als du denkst. Sogar wenn du weißt, dass es länger dauert als du denkst. Wie gehst du damit um? Weil da wird ja manchmal schon relativ starker Druck gemacht. Extrem entspannt.

Also da drüber bin ich echt hinaus, um mir Druck machen zu lassen von Projektmanagerin oder Product Owner. Bei den Schätzungen gehe ich so vor, dass ich so eine Excel Liste mache und wir die jeweiligen Features Zeile für Zeile aufschreibe. Und dann mach ich eine Abschätzung für den Best Case, eine Abschätzung für den Worst Case dmit dort den Schnitt und addiere darauf nochmal 30 prozent für Unvorhergesehenes. So und so eine Schätzung gebe ich dann ab. Und wenn es dann länger dauert?

Ich versuche dann halt immer so ein bisschen zu dokumentieren, wenn was dazwischen kommt, was nicht auf dem Schirm war. Einfach um nachher, wenn einer fragt bis eine Liste raus und kann sagen Ja, das und jenes, welches ich habe keine Information bekommen nicht gebraucht habe oder der Kollege Z. Als Ansprechpartner war drei Wochen krank, ohne Vertreter, Regelung und und und, um einfach so ein bisschen sicher zu sein. Ansonsten kann ich es sagen. Wenn es dann noch länger dauert, dann ist es halt so.

Also du hast dieses Lass dich nicht von willkürlichen Deadlines verrückt machen völlig verinnerlicht.

War das bei dir immer so oder ist das ein Prozess?

Nein. Prozess. Prozess beim ersten Mal oh citta bibber und um Gottes Willen. Und die Welt geht unter. So und dann machst du und tust du. Dann bist am Wochenende da und nachts bis drei. Und hin und her wird’s aber trotzdem später, weil irgendwas passiert ist, wo du keinen Einfluss drauf hast oder Bergsee. So schlimm war das jetzt doch nicht, weil der der Druck gemacht hat. Der war dann auch entspannt. So wird das ein paarmal passiert da ja auch.

Was will man machen? Also zuckte du noch mit den ATL dieses Druck machen?

Ich sag mal ein bisschen Druck machen, okay. Aber dieses starke Druck machen? Es ist ja nicht so, dass du am Fließband stehst und jeden Tag in acht Stunden acht Autos Ponti hast. Und wenn du da zehn Stunden stehst, montiert du zehn Autos. Du denkst ja nicht schneller, weil du unter Druck geraten bist. Also. Ich weiß nicht. Bei mir funktioniert das nicht. Ich werde dann eher geblockt oder so. Wenn ich weiß Oh du Dexia, die schneller.

Ja, das ist ja sozusagen die Denke, da trödelt jemand, die mach ich jetzt.

Beine Nee, das kommt so aus der Industrialisierung und den setze ich unter Druck.

Und dann konzentriert er sich besser oder bleibt eher an der Sache dran. Das funktioniert bei Creativ Arbeit ja nicht. Also wenn ich einem Künstler sage mach schneller! Dann wirft er den Farbeimer gegen die Staffelei und dann kann er auch nicht sagen Ich bin fertig. Also vielleicht kann er das sagen, aber dann ist das Kunstwerk nicht gut. Und das sieht man leider auch mancher Software an, dass sie unter großem Zeitdruck entstanden ist.

Ich habe aber auch das Gefühl, Entwickler schätzen tendenziell zu positiv. Ich weiß nicht wieder.

Deine Erfahrung ist das kann ich so nicht sagen. Weiß ich das? Ich würde weder sagen positiv noch mal ist es klar mehr positiv, mal negativ heckt und ein bisschen damit zusammen, wie viel erfahrener oder unerfahrener Kollegen du im Team hast. Also eine generelle Tendenz kann ich glaube ich nicht sehen.

Ich hatte schon mal den Fall, dass Projektmanager bei Schätzungen gedrängt haben und sagen Nee, das ist zuviel, das muss schneller gehen und selber dann die Schätzung visieren oder beeinflussen.

Das auf jeden Fall halte ich für sehr gefährlich, es sei denn, der Projektmanager sagt vorher ganz offen Du, wir müssen unter diesem und jenem Level bleiben, um das Projekt genehmigt zu bekommen. Wenn das dann einmal läuft, dann wird es keiner mehr stoppen, wenn es länger dauert. Das hatte ich auch schon. Dass das so offen kommuniziert wurde, ist natürlich auch grenzwertig, aber das passiert manchmal. Aber klar, wenn das Projekt einmal läuft und man hat es schon 60 Prozent geschafft, dann wird es vielleicht der oberen Etage schwerer fallen zu sagen Na, wir stoppen das jetzt, weil das Budgets aufgebraucht, lass die letzten 20 Prozent weg.

Macht jetzt nochmal 20 Prozent und dann ist out.

Ich habe einmal erlebt, wo ein Produkt oder ein Kollegen so gedrängt hat, wird er das jetzt so so schätzt oder nicht fertig wird, dann gibt’s als mit dem Bonus nix.

Also wenn er es schätzt oder wenn es nicht fertig bekommt in der Zeit nicht oder so grob geschätzt.

Und dann sagte er Ja, es dauert halt so lange oder sagt sie Nee, auf keinen Fall. Dann gibt es wieder Modus. Nix gibt’s alles.

Ich hoffe, sie meint es nicht ernst. Doch ich war dabei.

Wenn’s nur auf die Schätzung ankommt, dann wird immer alles ganz schnell geschätzt.

Echt so, die Softwareentwicklung? Ja, manchmal ist es schon verrückt, meiner Erfahrung nach. Man kann sehr zuverlässige Schätzungen abgeben. Allerdings nur für sehr kleine Projekte oder sehr kleine abgegrenzte Probleme. Wenn die eingesetzten Werkzeuge und der Anwendungsfall sehr genau bekannt ist und man sicher gehen kann, dass man nicht von extern gestört wird. Das sind dann aber kleine Projekte und da weiß ich nicht. Die finden in den Firmen nicht so häufig statt. Meiner Erfahrung nach Bara sind dann nicht so wichtige Themen.

Ist denn in deiner Erfahrung mal ein Projekt vor der veranschlagten Zeit fertig geworden?

Ja doch, auf jeden Fall auch schon erlebt.

Ist zwar extrem selten gewesen, aber da gibt’s definitiv bei SKL bei Tamir einfallende, wo wir supergut im Zeitplan lagen. Oh, das war mega. Aber ansonsten. Ich muss mal überlegen. Na gut, auf der anderen Seite wir sind eine Consulting Firma und wir werden meistens angerufen, wenn in Excel schon eine rote Zelle erscheint.

Ja also diese Feuerwehr Geschichten gibt’s natürlich auch der Druck entsprechend groß ist.

Ja, das waren die 10 Lektionen. Unglaublich. Ich bin auf die nächsten 40 Jahre gespannt oder?

Ich hoffe nicht. Da mache ich so eine Abschluss Folge zur Verrenkung. Dann was ich gelernt habe, wenn unsere Zuhörer Fragen haben zu der aktuellen Episode oder auch so können Sie uns eine E-Mail an Podcasts Gilbert D.

Senden. Wir freuen uns immer über Bewertungen oder wenn ihr den Podcast abonniert. Empfehlt den Podcast auch an eure Freunde und Kollegen weiter und schaut auf der Skill bei D. Slash Jobs Seite vorbei. Weitere spannende Technologie Artikel findet ihr Weißgerber D im Blog Masa Es war wie immer ein pures Vergnügen mit ihr zu sprechen. Danke Rorys, dann wünsche dir noch einen schönen Abend.

Maurice KnoppSkillbyte Podcast #40: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 2)
Mehr

Skillbyte Podcast #39: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 1)

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt

// Inhalt //
01:20 – 1. Lektion: Halte die Komplexität in IT-Projekten so niedrig wie möglich
08:24 – 2. Lektion: Der beste Code ist einfacher Code.
14:44 – 3. Lektion: Gutes Projektmanagement ist wichtiger als das Vorgehensmodell
22:36 – 4. Lektion: Es ist sehr wichtig eine verantwortliche Person zu bennen
25:07 – 5. Lektion: Katastrophen werden passieren – stelle dich darauf ein!

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Also das Gefühl, wenn du so ein Ding gelöst hast. Das ist. Ich weiß es nicht. Ich kann nicht sagen, es ist besser als beim Sex. Aber es ist halt klar, den noch viele ein bisschen Aufregung und Spannung. Endorphine werden ausgeschüttet und wenn es dann gelöst, dass man das Adrenalin weg ist, dann fühlt sich einfach nur so hey, quasi.

Herzlich Willkommen zum Skill bald Podcast Nr. 39 10 Lektionen, die wir in mehr als 40 Jahren Softwareentwicklung gelernt haben. Teil 1 Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld er Entscheider oder die Fachkraft seid. Wenn ihr Hörer Fragen auf der Prisoner habt, sendet uns gerne eine E-Mail an Podcasts. Geh weiter. Bewertet diese Episode gerne mit 5 Sternen und wir uns immer bei Weiterempfehlung an Freunde und Kollegen und schaut auch bei der Skill BYD Jopp Seite vorbei. Ich bin hier heute wieder mit Malaysia.

Hallo Malaysia. Hallo Boris, grüß dich.

Freut mich, dass du da bist und dass wir heute aus deinem ganzen Erfahrungsschatz schöpfen können. Ich hoffe, da bin ich ganz sicher. Ich springe einfach mal mit der ersten Lektion rein und illustrer kurz das Problem und dann können wir gemeinsam darüber sprechen. Die erste Lektion ist Halte die Komplexität in Projekten so niedrig wie möglich. Was bedeutet das genau? Das Problem besteht darin, dass häufig in Projekten alle möglichen Werkzeuge verwendet werden Libraries, alte wie neue. Daraus entsteht eine sehr, sehr hohe Komplexität und ein Wartungsaufwand.

Weil natürlich jede Library dies irgendwann mal ins Projekt geschafft hat, muss mitgeschleppt, gewartet werden, weiterentwickelt werden. Gegebenenfalls. Wenn Sicherheitslücken auftreten, müssen die gefixt werden, was zu einem sehr großen Aufwand bei Versions Upgrades führt. Denn all diese Inhalte, die einmal ins Projekt gekommen sind, die laboris, müssen mitgezogen werden.

Das wird insbesondere dann kritisch, wenn man Komponenten verwendet hat, die aus dem Support raus sind, also die einfach nicht mehr gepflegt werden, weil es sich beispielsweise um eine veraltete Technologie handelt. Ich bin sicher, da kannst du auch eine ganze Menge zu sagen. Leider ja. wÃchentlich wir aber bei dem Lieblingsthema Scrum, wo die Verantwortung ja quasi dem Team obliegt und das Management diesen Prozess komplett vertraut. Nämlich, dass das Team sich selber organisiert. Dass das Team, bevor sie neue Tools und Technologien einführt, sich einig ist.

Ich muss jedem Mensch mit tatsächlichen Augen öffnen sein. Dem ist nicht so. In jedem Projekt, wo ich war, wo das so mal rigoros gelebt worden ist, haben Entwickler Tools Frameworks eingeführt, wie sie wollten. Natürlich, der Entwickler will dazulernen. Das ist auch völlig legitim. Er will mit neuen Technologien spielen. Aber leider hat halt der Entwickler, gerade jüngere Entwickler, nicht dieses Bewusstsein, dass das ja auch später jemand betreiben muss. Jemand muss das verstehen, der, der nach ihm kommt oder wie auch immer.

Das heißt, diese Betriebs Komponente, diese Langfristigkeit hat er leider nicht im Auge, sondern in dem Moment hatte erst mal nur seinen eigenen Vorteil oder seinen eigenen Spieltrieb nachgegeben und das fällt dem Projekt hinterher auf die Füße. Das sind nicht nur Tools. Also es gibt Projekte, wo ich erlebt habe, dass auf ihr für verschiedene Test Frameworks eingeführt worden sind. Im schlimmsten Fall hätte einer nicht mehr erkannt was das sollte und baute sein eigenes Ding. Machen hat seins drüber gestülpt.

Schwuppdiwupp hast du diese 400 Frameworks drin und es ist einfach nur noch Kraut und Rüben. Und das mal der ganzen Komplexität, die jedes Buch für sich mitbringt. Security Patches, Versions Upgrade, was du erwähnt hast und so weiter und so fort. Oder es wurde entschieden. Okay, Kafka ist es cool in aller Munde. Lass uns Kafka, nutze dem Projekt. Dann wurde das einfach eingeführt, dass das jemand betreiben muss, dass da zu einem Kafka viel mehr gehört als in Docker Run.

Das wird halt ausgeblendet. Aber nachher muss die Software drauf laufen. Und wenn dann tatsächlich Probleme auftauchen, blickt keiner durch. Eine schlimmsten Fall ist der, der das einführt. Hat 3, 4, 5, 6 Monate später weg und dann läuft das Ding halt irgendwo.

Ich bin auch auf jeden Fall dafür, dass man so eine Art Architektur Verantwortlichen hat im Team, der die Langfristigkeit der Anwendung im Blick hat, der den Application Lifecycle kennt, also dem bewusst ist Wenn das hier ein Erfolg ist, dann muss das noch 5 Jahre erstens weiterentwickelt werden und dann gepflegt werden und irgendwann ist die heiße Entwicklungsphase vorbei. Dann geht es in den Betrieb und der ist eben nicht mehr so von neuen Werkzeugen geprägt, sondern da kommt es darauf an, dass die Werkzeuge, die man hat, möglichst lange eben supported werden.

Und oftmals kristallisiert sich in einem Team ja schon so jemand raus. Das Problem ist, wenn der formal nicht die Macht bekommen hat. Da kann man gleich noch zu Neiman Lektion zu sagen Okay, so machen wir das. Oder auch die Frage zu stellen Wenn da eine neue Technologie eingeführt wird, was bringt uns das, was kostet uns das? Also ich sehe auch die Lösung dieses Problems darin, dass man als guter Entwickler tendenziell mit möglichst wenig Abhängigkeiten auskommen sollte ein Testing Framework und dann ein möglichst branchenübliche, was halt wahrscheinlich noch lange Unterstützung findet.

Bewährte Tool Scheines einsetzen. Nicht unbedingt das neueste und heißeste, sondern etwas, was es. Einige Jahre gibt und was eine gewisse Verbreitung erfahren hat, dass man halt auch Infos zum Internet findet. Aber dennoch, ich meine, das muss uns ja auch klar sein. Einen gewissen Prozentsatz an neuen Technologien muss man in jedem Projekt einsetzen, sonst würde man ja stehenbleiben. Absolut.

Mir geht es auch weniger so, dass man sie hinterher betreiben kann. Es ist ein Punkt für sich. Ja, aber das größere Problem sich in der Komplexität. Ja, du hast ein System und dieses System hat ne gewisse Entropie. Und jedes Tool, jedes Framework, jedes Stück, was du dazu nimmst, erhöht die Entropie. Das heißt, das System wird komplexer und ihr komplexes wird es. Mehr Manpower Bausumme um das am Laufen zu halten.

Da kann ich wirklich auch aus meiner Historie sprechen in einem Projekt, das es noch gar nicht so lange her. Dann werden auch ich glaube zwei oder drei verschiedene Test Frameworks benutzt, das einem brauch Not und p.m. Als Abhängigkeit, damit es funktioniert. Das andere ist von Java STANDARD Framework und da sieht man richtig die verschiedenen Altersstufen des Projektes, wann mal was Neues probiert wurde. Und das führt dazu, dass irgendwann einer sagt Boah, wir müssen das alles neu machen, weil keiner mehr durchsteigen.

Also halte die Komplexität niedrig. Weniger Komplexität ist meiner Ansicht nach ein Genie Streich. Also jemand, der darauf achtet, da hat man schon so viel gewonnen. Weniger Komplexität heißt weniger Bugs, weniger Probleme, weniger Sicherheitslücken und generell ein besseres Software Verständnis von dem entwickelten Artefakt. Ein Aufschwung aus dieser Lektion hört man z.B. in der Skill BYD Podcast Episode Nr. 18, warum IT-Projekte so teuer sind. Die Komplexität führt nämlich dazu, dass die Preise irgendwann explodieren oder der Aufwand explodiert.

Also für mich bedeutet professionelle Softwareentwicklung auch nicht, jedem Trend ungefragt hinterherzulaufen, sondern primär eine konsistente Architektur anzustreben und Neuerungen gezielt einzubauen. Ich hab mal gelesen, dass man pro Projekt 15 bis 25 prozent an neuen Komponenten einsetzen kann, wo man hofft, dass die möglichst lange gewartet werden. Das wäre dann so ein guter Wert.

Es ist schwierig, das so in Prozenten auszudrücken. Ich glaube, jedes Projekt ist sehr spezifisch. Bei dem einen bedarf es mehr an neuer Technologie. Keine Ahnung. Wenn du sagst, ich möchte jetzt auf Echtzeit Streaming gehen, dann kommt halt nur ein oder zwei Tunes in Frage. Will sagen, es ist finde ich schwer nachzuvollziehen, so Prozentzahlen zu sagen. Drittel der Komponenten sollten neu sein. Also jetzt rein subjektiv. Aus meiner Erfahrung kann ich jetzt nicht an irgendwelche Zahlen festmachen.

Es ist immer individuell.

Das stimmt. Und wichtig wäre noch darauf zu achten, dass wenn man so eine Komponente einsetzt, sondern eine neue Technologie einsetzt, dass es eine saubere Schnittstelle gibt. Wenn du jetzt sagst Echtzeit Streaming, dann gibt’s ja irgendwie ein Interface, um diese Streaming Komponente anzusprechen, dass das halt sauber ist, dass man das nötigenfalls mal wechseln kann. Das sehe ich genauso. Also neue Tools können ausprobiert werden und jeder von uns hat natürlich den Drang, das zu tun und möglichst viele Sachen neu auszuprobieren.

Aber in einem professionellen Projekt muss man das abwägen, ob das wirklich immer sinnvoll ist. Die zweite Lektion stößt ja ein bisschen ins gleiche Horn. Der beste Code ist einfacher Code. Das ist meiner Ansicht nach auch ein Problem, wenn man die Entwickler sich selber überlässt. Also dieses Prinzip do not repeat yourself.

Die R ui, das kennt sie ja bestimmt auch. Das wird ins Extreme verkehrt. Also da werden Konfigurationen über Bilder Patterns gebaut und verschiedene Dinge, wo ein einfaches Textteil gereicht hätte. Ja, weil man diese Konfiguration nur einmal sozusagen einliest und dann nicht mehr braucht. Da werden Konstrukte aufgesetzt, die wahnsinnig komplex sind für eine einfache Sache. Und man guckt mehr darauf, ne Funktion nur wirklich einmal zu implementieren, statt dass man sagt Okay, is of reading ist hier wichtig.

So eine flache Konfigurationsdatei, auch wenn sich da irgendwie einen Wert doppelt. Ja, also Server für Datenbank und Server für sagen wir mal E-Mail ist jetzt vielleicht der gleiche, dann steht zweimal der gleiche Wert da drin, dass man trotzdem die beiden Werte einfach reinschreibt, anstelle dass man die Konfiguration dann wiederverwendet.

Also ich würde tatsächlich auch Einfachheit über Dry favorisieren, wenn es hart auf hart kommt. Sich entscheiden müsse ich mich persönlich immer wiederholen, als das Ganze kompliziert zu machen.

Würde ich auch so sehen. Also es gibt natürlich für jedes Pattern die Entwicklungspfad, dann haben natürlich ein Sinn. Ich möchte hier überhaupt nicht gegen Patterns wettern, aber ich habe es schon gesehen. Statt einer einfachen for-Schleife wurde ein komplexes Producer Consumer Pattern implementiert. Wurde dann irgendwie zehn Werte von irgendeinem Dienst consumers wurden, wo man denkt ja okay, die zehn Werte jetzt auch einfach als Liste übergeben können, da hätte jeder verstanden, was du willst. Und so muss man das erst ausgraben.

Man muss ja sagen, die Idee Unterstüzung ist ja auch tatsächlich so weit, dass sie auch q blöcke wär, wenn du sie wiederholst erkennt das sei es. Sowas lässt sich schneller auffinden, weil Dojo BDO Set kommt er dann zum Tragen, wenn du Code verändern willst? Und muss irgendeine Änderung reinnehmen, dass du seine Stelle machst und an der anderen Stelle vergisst. Hast du ein Bad drin? Sowas lässt die Idee dann schon erkennen, dass das die Unterstützungs entsprechend da.

Das spricht dann für mich auch eher dafür, dass sich das System mir einfacher halte oder mein Boot, als es zwingend unter allen Umständen auf Teufel komm raus diesem Prinzip gerecht werden muss. Genau.

Also ich glaube ein gutes Beispiel für Dohna Creepy yourself wird z.B. die Berechnung der Mehrwertsteuer, die aktuell bei 16 prozent statt bei 19 prozent liegt. Wenn das natürlich komplett durchs Programm verstreut ist, wird es sehr aufwendig, alle Stellen zu erwischen. Da will man natürlich eine Methode haben, die dann überall aufgerufen wird.

Aber gerade bei Configuration Klassen oder Klassen, die so Rest Calls aufrufen oder so. Da kann man sich dann doch sehr Fahrkünste an Was mir zu diesem Thema sofort einfällt ist eher so diese wie sich verschachteln Stream Map Filter Konstrukte über mehrere Zeilen gehen. Das ist für mich ja. Man mag sich dann hip vorkommen, weil man tolle neue Features benutzt hat, die in anderen Programmiersprachen schon länger da sind. Und es mag shiny sein, aber kann man argumentieren wie man will?

Es macht den Code schwer lesbar und das ist es mir definitiv nicht wert. Dann hab ich lieber drei Bout Blöcke, was man einfach lesen kann wie ein Buch statt sich da so einzudecken. Weil es ist ja so, du hast ja eine anonyme Funktion hinter der anderen. Diese Ketten, die aus dieser JavaScript Server Seuche herkommt. Und du musst ja wenn du das bitte folgen willst mit dem Kopf, dann musst du ja quasi ins Deck bilden. Der Rekursive ist und das strengt mich so an und Leute, das hat nix mit meinem Alter zu tun, sondern das ist einfach Mist.

Das fällt jedem schwer, als wenn ich das quasi in einfachen Zeilen hab.

Ja dieser Landa Notation, die verführt halt dazu, dass man immer ach und man filtert das. Achja und dann sortiert man es noch. Achja und dann macht man noch das Ding und dann dies und dann jenes und dann entsteht so eine Kaskade. Und in der Sekunde wo man da drinne ist ist das toll, weil man einfach da so runter schreiben kann. Aber ich hab auch schon mal eine lange Landa Funktion in zwei oder drei Blöcke aufgeteilt, weil ich einfach dann so ein Zwischenergebnis haben wollte und sage Okay, das ist die gefilterte Liste beim nächsten Mal.

Okay, das ist jetzt das tilgte Liste. Okay, das nächste Mal, da sind die gefundenen Treffer drin oder so. Sodass man dir dann eben folgen kann, wenn das irgendeiner mal anfassen muss.

Das ist also sehr richtig gesagt. In dem Moment, wo du selber dich quasi diesem Kontext aufgebaut hast und drin bist, dann lässt sich das relativ einfach runterschreiben. Aber der nächste muss ja auch da rein und der übernächste.

Also meine Regel ist, wenn der Quellcode nicht direkt auch von den Junior Entwicklungs Kollegen verstanden werden kann, was da passiert ist, dann ist er zu kompliziert. Punkt. Also klar, dass man mal ein Pattern erklären muss oder dass man sagen muss Oh, hier hab ich eine neue Funktion benutzt, dies in der neuen Version gibt. Das verstehe ich aber da Verschachtelung Stephen und irgendwelche wilden typisierten.

Ja genau das ist das nächste Ding.

Funktionen, die sich dann selber aufrufen. Ja, dann wird’s ein bisschen zu wild und man muss sagen hör mal, was machen wir eigentlich? Weil meistens mag man ja nur Daten irgendwie aufeinander, wenn man programmiert und arbeitet. Nicht immer Spaceshuttle, Steuerung und auch die Map letztlich nur Daten, auch sehr beliebt.

So typisierte Methoden Rückgabewert mit Wildcards und auch sehr Nies nicht.

Also nochmal Patterns haben natürlich ihren Sinn, aber man muss immer gucken ist das hier die richtige Hammerl Größe für das richtige Problem? Ich glaube das ist ganz wichtig.

Man muss einfach auch an andere denken, die dann kommen, vielleicht nicht nur den Skill Level haben.

Ich habe auch festgestellt, die besten Entwickler wenn eine Lösung entwickelt haben, dann hören die nicht auf und committen das einfach, sondern die lesen das dann nochmal von oben nach unten durch und vereinfachen auch komplizierte Funktionen. Also es gibt diesen Spruch Jeder Schwachkopf kann Dinge kompliziert machen, aber es braucht ein Genie um Dinge einfach zu machen. Und die gehen wirklich nochmal diese extra Runde, dass sie sagen Okay, jetzt hab ich zwar eine Lösung, die funktioniert. Aber was mache ich hier eigentlich nochmal?

Okay, das ist ein Zwischenschritt, der logisch. Das ist ein Zwischenschritt des logisch und zergliedern. Das entweder in einzelne Methoden oder einfach in logische Blöcke. Manchmal recha das Einführen von Leerzeile schon, weil du kennst ja bestimmt zu klickst in einer Datei auf nach so ne Wall of Text 300 Zeilen ohne eine Leerzeile dazwischen. Da denkt man schon Boah, was ist hier passiert? Da ist es wichtig, dass man auch diese logischen gedanklichen Schritte dann eben voneinander absetzt und dann möglichst ein einfachen Fluss hinbekommt.

Da kommen wir zur dritten Lektion und da bin ich ganz sicher, wirst du ganz viel zu sagen können. Die dritte Lektion Gutes Projektmanagement ist wichtiger als das Vorgehens Modell.

Was meinst du damit mit Vorgehens Modell? Das Vorgehens Modell könnte das agile Vorgehens Modell sein. V Modell x t Wasserfall Modell ganz klassisch oder irgendeinen meißtens wenn die Vorgehens Modelle ja nicht in Reinform ausgeführt, sondern es entsteht so eine mehr köpfige Hydra, die sich an allen Vorgehens Modellen irgendwie bedient und dann ein neues Monster erschafft. Nachdem das Team dann arbeitet nein, es soll gar nicht so negativ sein. Also natürlich gibt’s kein Vorgehens Modell in Reihenfolge. Es muss auch immer zur Firma und zum Projekt passen.

Aber ich glaube, nach den Jahren kann man schon sagen, dass man gutes Projektmanagement von schlechtem Projektmanagement unterscheiden kann.

Aber Moriz Projektmanagement gibt’s doch gar nicht mehr. Ist doch alles agil.

Ja, auch ein Kilis Projektmanagement ist ja Projektmanagement. Was ich festgestellt habe ist Es gibt so Projektmanagement, das sich so im Unternehmen entwickelt hat und was dann so implizit durchgeführt wird oder was du von oben aufgestört wird. Agil wäre z.B. ein Beispiel für Da kommt eine Entscheidung und das wird häufig von oben aufge stülpt. Ja, wir haben das jetzt gehört. Wir machen es jetzt alle. Aber diese von oben aufgestellten Modelle scheitern oft an der Realität. Also das agile Paradigma wird ausgerufen, es wird ein Sprint geplant, die Leute fangen an zu arbeiten und nach zwei Tagen kommt jemand rein und sagt Nee, das ist aber jetzt ganz wichtig.

Dann sagt man Ja, schreibs ins Backlog. Gucken wir uns zwei Wochen an So, und jetzt hasst der Lackmustest. Gelingt das jetzt? Oder sagt jemand Ja, Moment. Ich bin aber der Geschäftsführer. Ich will das jetzt sofort. Und so sterben dann die guten agilen Ansätze dann auch ein. Also die verwässern so nach und nach. Ich will das gar nicht so negativ klingen lassen, aber dann landet man meistens bei irgend so einer Zwischenform. Also um Priorisierung von oben.

Notfälle passieren. Naja, Hacker-Angriff, Sicherheitsprobleme. Das Leben bewegt sich ja auch. Es ist ja auch nicht so stark, dass es sich in ein Modell quetschen lässt. Schlüsselpersonen geht. Neue Mitarbeiter kommen, die noch keine Vorkenntnisse haben. Jemand wird krank. All das kann während der Projekte geschehen und es gibt keinen Plan, der alle Eventualitäten abdecken kann. Das ist die Realität. Wie löst man das gut?

Grundsätzlich ist es ja bei dem agilen Vorgehen. Es ist eigentlich eine Wohltat für die bisherige Softwareentwicklung gewesen. Gar keine Frage. Wir alle oder nicht alle? Vielleicht die? Die jüngeren Zuhörer nicht. Dieses Modell, das man sich vorher im Prinzip schon qualmende Ingenieuren, die Anforderungen genau holen musste, niederschreiben musste und abschätzen musste oder Modell Werkvertrag gemacht. Das hat alles nicht funktioniert. Insofern ist agil schon super. Aber ich glaube, dieses so völlig rigorose Agilität, wie das Agile Manifest sagt oder was daraus geworden ist, sag ich mal, das ist totaler Humbug.

Du kannst keinem Management erklären. Pass mal auf. Wir können dir nicht sagen, was es kostet. Wir können dir nicht sagen, wann es fertig wird. Wo hast du sowieso nichts zu melden, außer die Kohle da hinzulegen? Das funktioniert einfach nicht. Selbst wenn das Management von großen Firmen sagt Ja, wir führen das jetzt ein und egal was wir machen, ist agil, agil, agil. Trotzdem fragen sie immer nach Wann ist es fertig? Was kostet das?

Trotzdem wird Projektmanagement nicht mehr gemacht. Man merkt, dass Sie nicht loslassen können. Klar. Ich meine das selbst ich als Softwareentwickler dieses Modell ja mitgemacht hat und sehr froh ist, dass es das auch gibt, sagt. Das ist totaler Quatsch. Entwickler können machen was sie wollen. Hin und her. Das funktioniert einfach nicht. Deswegen vermischt sich das im Moment. Klar, wenn du nur diese Menschen sind, Firmen und Coaches und so weiter. Die verdienen ihr Geld damit, dieses Modell einzuführen.

Aber aus der Praxis, so wie ich es erlebe, entsteht irgendwie eine Mischform. Dadurch aber, dass diese Mischformen links beschrieben ist, vermisse ich das Alte mit dem Neuen. Und da kommen ganz komische Konstrukte raus. Mein Punkt ist jetzt gar nicht mal so finanziell und Management und Zeit, Berechnungen usw. Also auch das werden mit Sicherheit 99 prozent der Zuhörer zustimmen. Irgendwie schleicht es sich ein, dass die Komplexität Punkte plötzlich in Tagen weiter kommuniziert werden. Aber mein Punkt ist rein technisch im Moment.

Und dass sich diese Architektur Thema, dieses Setzen eines Rahmens, in dem man sich frei bewegen kann und nicht einfach blind vertrauen und sagen, dass die Macht es schon. Ah, braucht das Team einen Rahmen. Es fühlt sich wohler. Der Entwickler fühlt sich wohler, wenn ein Rahmen, in dem er sich bewegen kann, im Grunde wie ein Bauplan auf der Baustelle.

Na, da baut ja auch nicht einfach jeder drauflos, wie er lustig ist, sondern es gibt einen großen Plan und das so muss das am Ende zusammenpassen.

Genau, du gehst ja auch nicht, wenn du ein Haus bauen willst und schmeiß irgendwie schon haben wir kein Geld ins Gesicht und sagt so guck mal wir das OP’s aufbaut. Nee, du gehst mal schon denken als erstes. Genauso ist das mit der Softwareentwicklung. Es ist auch sehr schwer, wenn du als Dienstleister, was wir hier sind Verträge machen wollen. Weil wenn ich dem Kunden komme, sagt Ja. Wir arbeiten zwar als verlängerte Werkbank, das ist unser Modell, das nach timen Material.

Aber wenn wir Projekte machen und ich sage agil, dann kommen genau diese Fragen. Und wenn ich dem sage, jetzt mal nichts zu sagen, wir machen das und du kannst nur sagen Stopp nach allen 14 Fahnenmeer und Sprint Review hast. Mit dieser Zeit kannst du das Projekt stoppen. Toll. Deswegen entstehen diese Mischformen und auch Verträge. Was wir machen ist dann kein Dienstleistungs Vertrag, kein Werkvertrag, sondern agiler Vertrag. Also dieses Konstrukt gibt’s tatsächlich, wo man gewisse Rahmen festsetzt.

Ich hoffe, das wird noch ein bisschen dauern, bis das, was ich jetzt gerade sage, den Unternehmen auch tatsächlich bewusst wird und man erkennt. Rein so agil, wie es Groom oder diese Coaches einem propagieren, so geht’s einfach nicht. Das wird früher oder später kommen, spätestens wenn dann Projekte zeitlich und finanziell aus dem Ruder laufen. Wenn man sich wieder fragen warum, wieso, weshalb? Und dann, wenn das Argument auf den Tisch kommt, dann überlegt man sich etwas Neues.

Also das beste Projektmanagement, was ich erlebt habe. Es hat total problemorientiert. Das guckt wo sind die Stolpersteine oder was steht uns im Weg, was steht unserem Erfolg in weg und kümmert sich darum? Also es räumt im Grunde einfach nur Hürden aus dem Weg und lässt dem Team schon viel Autonomie. Aber kommuniziert die Ziele immer sehr klar. Also da wollen wir hin, da wollen wir hin. Da wollen wir hin und alles, was da im Weg steht. Probleme müssen gelöst werden.

Leute müssen überzeugt werden und darum kümmert sich das Projektmanagement. Und auf der anderen Seite schützt ist das Team, das das Team in Ruhe arbeiten kann und nicht in endlosen Meetings Runden verhaftet wird, um alle Stakeholder, die es irgendwie geben könnte, abzuholen. Das sind die effektivsten Projekte, in denen ich bisher gearbeitet habe, wo man einfach gesagt hat Okay, wir räumen alle Probleme aus dem Weg. Ihr könnt in Ruhe arbeiten, natürlich alle zwei Wochen oder je nach Sprint Ende wird gezeigt, woran ihr gearbeitet habt.

Und dann sagt der Kunde, wohin es als nächstes geht. Natürlich gibt’s so einen groben großen Plan, was man erreichen möchte. Mit den Schlüssel Features. Aber das war sehr zielorientiert und die Projekte, die ich so gemacht habe, waren sehr erfolgreich. Vielleicht können wir hier auch festhalten. Also das ist so mein Fazit aus dem Punkt gutes Projektmanagement. Wenn Projekte scheitern. Ich hab das noch nie erlebt, dass ein Projekt, eine Technologie scheitert, weil irgendwas nicht gegangen wäre oder so vielleicht.

Bei Raumfahrtunternehmen ist das so. Aber ganz oft sind es menschliche Faktoren, Firmenpolitik oder einfach nicht gut durchgeführtes Projektmanagement, wo dann hinterher das ganze Team demotiviert war. Das sind so die Gründe, warum Projekte scheitern.

Meiner Ansicht nach ja, ist schon so. Aber ich hatte auch. Also muss ich wirklich hervorheben einige Projekte, die wirklich super erfolgreich waren, wo gutes Projektmanagement stattgefunden hat, wo dem Team der Rücken gestärkt wurde und alle Probleme organisatorischer Art eben aus dem Weg geräumt wurden. Also super klasse gelaufen, muss ich wirklich sagen. So ein bisschen in die dritte Lektion Gutes Projektmanagement spielt die vierte Lektion hinein, würde ich sagen. Die ist nämlich Es ist sehr wichtig, eine verantwortliche Person zu benennen.

Was ist das Problem? Also das kennst du bestimmt auch bei Retro oder auch so werden Missstände benannt, was vielleicht nicht so toll ist, was man besser machen kann. Dann gibt’s eine Diskussion im Plenum, da spricht man darüber und dann wird darum gebeten, meistens von höherer Stelle, dass sich darum gekümmert wird, ohne explizit eine Person zu benennen. Vielleicht wird sogar noch ein Ticket erstellt im Backlog. So, und das wars. Und bitte kümmert euch darum.

Heißt für mich Keiner kümmert sich darum. Gerade wenn das ein heißes Thema ist. In erfolgreichen Projekten, so ist es meine Erfahrung, wird eine verantwortliche Person benannt, wenn das Thema wichtig ist. Wenn ein Thema nicht wichtig ist, dann wird keine Person benannt, aber dann braucht man es auch nicht aufschreiben. Und diese Person ist dann dafür verantwortlich, dass dieses Thema weiterverfolgt ist und hat dann die Themenführerschaft da drüber und kümmert sich auch. Und das ist gar kein Fingerprint Ding, das man sagt Okay, du kümmerst dich jetzt darum.

Sondern jeder hat ein paar Themen, für die er verantwortlich ist. Dadurch entfällt diese ganze Fragerei, wenn irgendwie Probleme in einen gewissen Themenkomplex fallen. Man weiß sofort Aha, Person X oder Epsilon ist dafür verantwortlich. Brauch halt nicht weiter zu fragen, hat sofort einen Ansprechpartner. Auf der anderen Seite hab ich ja selber drei Themen, für die ich verantwortlich bin, sodass da auch kein Ungleichgewicht entsteht. Ich weiß nicht, wie hast du das erlebt? Also auch da ist ja das Team kümmert sich.

Also wenn wir es beim Business-Modell Scrum bleiben, heißt es ja, das Team ist eigenverantwortlich und wenn ich eine gute Durchmischung hab von jüngeren und erfahrenen Entwicklern, dann erfolgt quasi alles im Team. Und die sollen sich selber organisieren. Faktisch aber auch jetzt organisatorisch, innerhalb. Selbst wenn man das Modell macht und man im Team Dinge bespricht, ist es ganz wichtig für jedes Thema Verantwortliche zu benennen. Das ist ja dieses Prinzip. Ja, das hat eine andere schon mal vielleicht gehört.

Ja, wenn du in einer Menschengruppe unterwegs bist und irgendeiner hat einen Herzinfarkt, wenn du sagst Kann jemand mal einen Arzt rufen, macht es am Ende keiner, weil sich jeder von anderen verlässt. Aber wenn du dann jemanden anguckst und sagst, kannst du einen Arzt rufen, dann ist die Wahrscheinlichkeit viel größer, dass derjenige oder vielleicht wenn du dir selber bis überlebt.

Genauso ist es in IT-Projekte vielleicht nicht weniger dramatisch. Man braucht vielleicht nicht so oft ein Arzt, wobei das auch vorkommen kann. Je nach Katastrophen Lage. Ja. Oh mein Gott, ich seh gerade das war ja ein wundervoller Übergang. Die fünfte Lektion Katastrophen werd passieren, stell dich drauf ein. Da können wir jetzt ja mal wirklich von ein paar Katastrophen erzählen, die wir bisher erlebt haben. Ich fange mal von meiner allerersten Katastrophe an, da war ich noch Student und hab.

Eine Webseite betreut und hub zu einem gewissen Zeitpunkt des Vormittags Club zehn oder elf Uhr morgens ein Update gemacht. Dieser Webseite und die Webseite gehört einen riesigen Dax-Konzern habe das Update eingespielt. Okay, und auf die Webseite und drücke 5 aus passiert gar nichts. Und das Rad dreht sich und das Rad dreht sich und das Rad dreht sich. Ich drück nochmal 5! Das Rad dreht sich, das Rad dreht sich. Man geht auf Google um zu gucken. Hat der Rechner kein Internet oder sowas.

Alles funktioniert. ernÃhren, Webseiten funktionieren. Nochmal zurück auf die eine Webseite Rad dreht sich das Rad dreht sich, kommt keine Webseite. Da wurde mir heiß, kalt, heiß, kalt in schneller Folge mich aufgestanden und zu meinem Manager gegangen und hab gesagt Hammerl, ich habe gerade in D dein Schild an die Webseite lädt nicht mehr und er macht seinen Browser auf, geht auf die Webseite und das Rad dreht sich. Das Rad dreht sich und das Rad dreht sich.

Das war so wie im Trance, muss ich wirklich sagen. Ich war total. Oh mein Gott, was soll ich machen? Und dann griff er zum Telefon, auch relativ hektisch dann und hat wild rum telefoniert. Wahrscheinlich hat es nur 10 Minuten gedauert, aber für mich gefühlt ne Ewigkeit. Und dann hat der Kunde angerufen und gesagt, dass er gerade eine Wartung von diesem Server macht, wo ich gerade drauf wie Pleul hatte. Ich war also gar nicht schuld.

Es lag gar nicht an meinem Release, sondern der Kunde selber hatte den Server neu gestartet und dann auch noch in andere Firmen auf diesem Server drauf. Also es war quasi eine kurze Downtime von paar Minuten, wo ich nichts konnte, weil ich einfach nicht wusste, dass da jetzt durchgestartet wird oder so. Das heißt, am Ende war ich nicht schuld, aber das will ich nie vergessen. Das war für mich eine Katastrophe und das wäre auch für die kleine Firma, für die ich damals gearbeitet habe, eine Katastrophe gewesen.

Am Ende des Tages ist alles gut ausgegangen, aber das weiß ich noch ganz genau. Das war so die erste Feuerprobe. Und ich bin sicher, jeder Entwickler kennt diesen Moment und kann von anderen Situationen erzählen, wo dieses Heiß kalt Gefühl aufgekommen ist. Also was ist die Lektion hier? Trotz aller Vorbereitung wird es irgendwann zur Katastrophe kommen. Downtime ganzer Produktionssystem durch Softwarefehler oder Datenbank Updates schlecht reproduzierbare Bugs. Ich weiß, wir haben mal in einem Projekt zusammen gearbeitet, da es alle sechs Wochen ein komplettes Rack ausgefallen.

Das inklusive braucht ein BIOS Update oder so. Aber wahnsinnig aufwendig zu reproduzieren. Und jedes Mal wenn der Fehler aufgetreten ist, ist das ganze System abgestürzt, sodass ein riesen Impact hatte. Datenverlust, Hardware, Defekte alles schon dagewesen. Betrug, Hacking, Diebstahl, DDoS also das wird passieren, da muss man darauf vorbereitet sein. Was war deine Katastrophe in jüngster Vergangenheit oder die größte, die du je erlebt hast?

Also ganz ehrlich, ich kann nicht sagen, es war jetzt eine große Katastrophe hier oder da. Der ganz normale Wahnsinn. Solche Ausfälle hier, da. Oh Gott, unser Gitt baut nicht und oh Gott, unsere Produktion Server ist down. Das ist eigentlich Normalität, dass das kommt. Ich muss ganz ehrlich sagen, es ist nichts dabei, was mich geschockt hätte. Ja so! Gerade wo ich angefangen hatte. Und so dachte ich Jo, hier in IT-Systemen.

Alles Ingenieure und komplexe Systeme. Wenn das läuft, dann läuft und da passiert nix. Wurde erst in ein, zwei Mal Sucks, du bist hier abwanderten. Also das ist wie Hartmut weißt. Klar werde ich nie vergessen. Irgendwie bei der großen Systemhaus am Anfang, wo wir Mailserver betreut haben für Kanal so 20000 Leute und die konnten keine Mails verschicken. Da ist gezittert und bibbert. Aber es kam danach noch schlimmere Dinge hinterher.

Wenn das Problem gelöst ist, kann man darüber lachen. Aber in dem Moment, wenn man nicht weiß, woran es liegt.

Es ist schon also das Gefühl, wenn du sunde gelöst, dass das ist. Ich weiß es nicht. Ich kann nicht sagen, es ist besser als beim Sex.

Aber okay, ja, ich weiß, was es so weit kommt sich vor wie Superman.

Ja, auf jeden Fall. Es ist halt klar die Endorphine, ein bisschen Aufregung und Spannung, Endorphine werden ausgeschüttet und wenn es dann gelöst und das andere Adrenalin weg ist, da fühlt sich einfach nur so Hey Vasile, das Widersprüchliche hier an der Lektion ist ja, dass die Unternehmen oder gerade auch Großunternehmen einen unglaublichen Aufwand betreiben, dass es eben nicht dazu kommt.

Also viele Back ups, redundante Systeme, 24/7 Support. Und trotzdem Irgendwann bist du fällig. Irgendwann passiert die Katastrophe. Ich weiß nicht. Gerade wenn man ein System schnell weiterentwickelt. Irgendwo ist ein Fehler drin, den keiner bedacht hat. Ob es ein Schaltjahr ist, das hatte ich auch mal bei einem System. Da fehlte der letzte Tag, weil das Jahr 366 Tage hatte statt 365. Das war nicht bedacht worden. So konnte am letzten Tag keine Buchung erfolgen.

Das sind alles so Dinge, die können passieren und das Wichtige ist, damit zu rechnen. Ich finde, daran erkennt man immer so supergut den Unterschied zwischen Junior Developer und Senior Development, weil da passiert das, was du beschrieben hast. Die einen haben die Hornhaut, die anderen haben die noch nicht. Pferde Junior Developer ist so wie ich damals schweißnass gebadet. Völlig paralysiert und weiß nicht, was er machen soll, und der Senior Developer zieht die Handschuhe an und greift ins Feuer.

So ungefähr. Bleibt ruhig. Okay, das Kind ist jetzt im Brunnen gefallen. Welche Optionen haben wir? Was können wir machen? Was man die letzten Schritte, die du getan hast? Welchen Impact hat das im Grunde? Wie gehen wir jetzt vor? Natürlich zügig, aber diszipliniert wird an einer Lösung gearbeitet.

Und das ist auch sozusagen die Lösung dieser Katastrophe. Das ist auch ganz wichtig, dass das Management mitspielt. Task Force zusammenstellen, alles stehen und liegen lassen und sich um das Problem kümmern. Den Rücken dieser Task Force freihalten. Ja, vielleicht alle paar Stunden mal den Status abfragen, damit man das entsprechend kommunizieren kann. Richtung Vorstand oder Kunden, den Fortschritt und das aktuellen Problem Status Monitoren. Was kann man machen? Wo befinden wir uns und wirklich sehen, dass das Team die volle Konzentration auf das Problem werfen kann und nicht gestört wird?

Kein Telefon und so weiter. Also außer zur Problemlösung dann erlaubt und auch dem Team dann die nötigen Ressourcen, also Experten z.B., die sich mit einer Technologie ganz besonders gut auskennen, die dann eben Hilfestellung geben können, in kritischen Situationen zur Verfügung stellen. Und Annas Team muss man einfach sagen Bleib dran, ihr müsst durchhalten. Es gibt ein tolles Zitat von Winston Churchill. Das fällt mir in diesem Zusammenhang immer wieder ein If you going to hell, keep going.

Also nicht stehenbleiben, weitermachen, dranbleiben, das Terrier gehen, auspacken und einfach weiter daran arbeiten, bis das Problem gelöst ist. Und unterwegs Schadens Minimierung betreiben. Natürlich.

Aber ich kann es immer noch nicht glauben. Du hast keine Katastrophe erlebt.

Nee, ich überlege echt die ganze Zeit. Aber wie gesagt, es ist halt relativ Katastrofe.

Also ich weiß, dass wir schon in Projekten gearbeitet haben, wo Leute panisch über den Flur gelaufen sind, weil die Webseite offline war. Wenn das dich nicht aus der Reserve gelockt hat, dann hast du auf jeden Fall mehr Hornhaut als ich.

Die Sache ist eine Sache der Perspektive. Willst du brauchst einen kühlen Kopf bewahrt.

Ich weiß, einmal ist ein Manager aus dem Urlaub zurückgekommen, hat sein Notebook eingesteckt, dann auf dem Notebook lief noch irgendwas Server Komponente vom Produktiv System, die in der Entwicklung dann noch gestartet war und dann klappt das Notebook auf. Und dadurch, dass er eine Zeitlang im Urlaub war, zieht das Notebook alle Events von Zeitpunkt. Ich gehe jetzt in Urlaub bis Zeitpunkt. Ich bin wieder da. Nach dem Produktionssystem und blockiert das ganze Produktionssystem stundenlang und keiner wusste, woran es liegt, weil keine Änderung erfolgt ist, außer dass dieser Mensch aus dem Urlaub zurückgekommen ist, was man ja auch erst nicht weiß.

Das war auch eine heiße Phase, diesen verkehrssicher auf Rädern, weil sie rausgefunden haben, da haben nicht wir geschwitzt, da hat er dann geschwitzt, aber das weiß man dann erst nicht.

Es sind einfach so Sachen. Technologie ist manchmal wunderbar wie Magie und manchmal auch sehr einfach. Und sehr dumme Fehler passieren. Das muss man auch sagen. Na ja, ich freue mich, mit dir im zweiten Teil über die Lektionen 6 bis 10 zu sprechen, nachdem wir jetzt die Lektionen 1 bis 5 durchgegangen sind.

Ja, sehr gerne freue ich mich auch. Bis dahin ganz schön nochmal überlegen, ob wir noch ähnliche Katastrophen erleiden wollen.

Genau da greifen wir den Faden wieder auf und machen noch so einen Marsyas Katastrophen Blog am Anfang. Sehr schön bin ich gespannt, wo die die meiste Hornhaut gewachsen ist. Wenn unsere Zuschauer Fragen haben oder Feedback zur aktuellen Podcast Episode, können Sie uns eine E-Mail schreiben an Podcasts. Geh weiter. Wir freuen uns immer über Bewertung oder Weiterempfehlung des Podcasts an eure Freunde und Kollegen. Schaut darauf, dass Gilbert Jopp Seite vorbei. Wenn ihr mehr spannende Technologie Themen lesen möchtet, schaut auch auf der Skjelbred Website Slash Blog vorbei und abonniert natürlich unseren Podcast.

Ja, es war wie immer eine Freude. Ich wünsche noch einen schönen Abend.

Bis dahin.

Maurice KnoppSkillbyte Podcast #39: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 1)
Mehr

Skillbyte Podcast #38: Darum müssen IT-Manager programmieren können!

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Darum müssen IT-Manager programmieren können!

// Inhalt //
01:20 – Was ist das Problem?
03:35 – Nur general Management Skills reichen nicht für IT-Projekte
06:29 – IT-Management braucht zwigend technischen Sachverstand
07:40 – Kardinalfehler: Aufgrund mangelnden IT-Verständnisses werden fachliche Anfoderungen sehr ungenau spezifiziert
09:14 – Technischer Sachverstand und Coding Skills helfen extrem bei der Anforderungermittlung mit der Fachseite
12:02 – Technischer Sachverstand ist nötig um vom Team respektiert zu werden
13:05 – So schaffen IT-Manager den Programmier-Einstieg (Bugfix, Unittest, Hello-world, neue Technologien sichten)
17:07 – IT-Zeitabschätzungen validieren
21:36 – Technologiekenntnisse boosten die Anforderungsanalyse und die Ergebnisspräsentation
27:42 – Wo können IT-Manager coden im Projekt lernen?
31:02 – Workaround wenn keine Technikskills vorhanden sind
31:44 – Gegenfrage: Darum sollten Entwickler auch Management-Aufgaben übernehmen!

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #38: Darum müssen IT-Manager programmieren können!
Mehr

Skillbyte Podcast #35: Moderne Microservice Architekturen – Die Zukunft der Softwareentwicklung als Servicenetz

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Moderne Microservice Architekturen – Die Zukunft der Softwareentwicklung als Servicenetz

// Inhalt //
01:30 – Definition: Microservice Architekturen (Masiar)
04:07 – Exkurs: Enterprise Service Bus
05:03 – Definition: Microservice Architekturen (Maurice)
10:39 – Die Historie hinter dem Microservice Trend
13:29 – Flexibilität vs Komplexität
16:57 – Betrachtungen der Paradigmen Monolith vs Microservice
20:47 – Vorteile von Microservices
20:51 – Modularität
21:33 – flexible Integration
23:33 – Skalierbarkeit (Cloud native Paradigma)
25:30 – Verteilte Entwicklung / Best of Breed Ansatz
25:49 – mehr (API Schnittstellen-) Dokumentation
26:46 – Robustere Systeme
29:55 – Nachteile von Microservices
29:57 – Netzwerkkommunikationsoverhead entfällt beim Monolithen
31:15 – Höhere Komplexität
32:25 – HTTP-Protokoll (overhead, stateless)
33:43 – Microservice Beispiele aus der skillbyte Praxis

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #35: Moderne Microservice Architekturen – Die Zukunft der Softwareentwicklung als Servicenetz
Mehr

Skillbyte Podcast #34: Serverless Computing – Hype oder Chance? AWS Lambda, Azure Functions, Google Cloud Functions richtig verwenden

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Serverless Computing – Hype oder Chance? AWS Lambda, Azure Functions,
Google Cloud Functions richtig verwenden

// Inhalt //
01:04 – Was ist Serverless Computing?
03:15 – FaaS – Functions as a Service
06:43 – Cloud Anbieter für Serverless Computing
07:52 – Abrechnung von Serverless Computing Ressourcen
09:25 – AWS Lambda am Beispiel von Amazon Alexa
11:56 – Vorteil: Zeiteinsparung bei der Administration ist signifikant
14:25 – Vorteil: Abrechnung nur verbrauchter Ressourcen
15:16 – Vorteil: Kosten werden Transparent
17:09 – Vorteil: Kleine Teams können Anwendungen Millionen von Menschen zur Verfügung stellen
18:10 – Nachteil: Vendor Lock-in
20:04 – Nachteil: Keine Performance-Garantie
23:43 – Nachteil: Ressourcenbeschränkungen (CPU Zeit, RAM, Laufzeit, etc.)
25:34 – Nachteil: unflexible Laufzeitumgebungen mit fixen Softwareversionen
28:35 – Debugging bei der Entiwcklung von Functions
30:30 – In diese Szenarien ist Serverless Computing besonders sinnvoll…
35:34 – …und in diesen sind sie nicht besonders sinnvoll

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Herzlich Willkommen zum Skill bald Podcast Episode Nr. 34 Servile Computing Hype oder Chance Apps, Landa, Escher Functions, Google Cloud Functions und so weiter richtig verwenden abonniert unseren Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn die Entscheider oder IT Fachkraft seid, lasse auch gerne eine 5-Sterne Bewertung da oder sendet uns eine E-Mail mit euren Fragen an Podcast Skill bei. Wir freuen uns auch immer, wenn ihr den Podcast an eure Freunde und Kollegen weiter empfehlt.

Ich bin heute hier mit Max von Skill bald Hallo Max, Hallo Moritz, es freut mich ganz besonders, da wir ja schon wirklich über ein Jahr zusammen arbeiten, dass wir heute diese Episode zusammen machen können.

Freue mich auch dabei sein zu können. Es hat mich immer gereizt, jetzt immer auch mein Thema gefunden und einen Zeitpunkt wo verpasst.

Ja und was für ein Themas ist auf der einen Seite ein hoch spannendes Thema Server es Computing. Auf der anderen Seite hab ich den Eindruck, dass es aktuell auch etwas gehypt wird. Wir können ja mal darauf eingehen, was servile Computing eigentlich ist. Was verstehst du denn darunter?

Ich verstehe zwei Sachen Wissen. Lattmann da sei einmal Server, alles im reinen Sinne oder so wie es jetzt im Moment und den Cloud Providern beworben wird. Bedeutet zwar aber, dass er erstmal, dass man sich selber nicht um die Hardware kümmern muss. Das heißt, dass man im Endeffekt den Cloud, wobei der dafür bezahlt, dass sie die Infrastruktur bereitstellen, wo man dann nur noch seine Anwendungen drauf ausrollen muss. Und das ist eben für mich erst mal der grundlegende Server des Computing an der Stelle.

Aber natürlich gibt es auch die engere Definition, die dann vor allen Dingen auch heute im Podcast eher die größere Rolle spielt. Bowls dann eher in Richtung Funktion Access Service geht, wo dann eben auch der ausführende Layer sozusagen nochmal abstrahiert ist, sodass man wirklich nur sehr wenig Aufwand selber hat, was man sozusagen bereitstellen muss. Genau, also die Wartung der Plattform.

Du hast eben gesagt Server lässt, man muss sich nicht mehr um die Hardware kümmern. Genau genommen muss man sich ja auch um einige Ebenen der Software nicht mehr kümmern. Also kümmern im Sinne von installieren, warten, Updates einspielen, den Server tauschen, wenn er mal alt ist. All diese Dinge also ganz klar sollten wir vielleicht sagen Server List Code läuft natürlich nach wie vor auf Servern, nur man hat keinen direkten Kontakt mehr dazu, weil eben diese Schicht weg abstrahiert ist.

Ich denke, das spannendste Thema für unsere Zuhörer ist die Abstraktionsebene Functions, also Service oder App. Faas.

Das ist auch die geschichtlich neueste Stufe der Server alles Ebene. Da geht es darum der Anbieter stellt eine Laufzeit Umgebung zur Verfügung. Also das kann eine Python Runtime sein. Das kann eine Java Run Time sein, eine dort net run time. Alle möglichen Plattformen sind hier denkbar. Und auf dieser Plattform werden dann eben einzelne Funktionen oder Programmteile ausgeführt und diese werden dynamisch gestartet anhand von bestimmten Triggern und auch skaliert. Also ob ich ein Bild konvertiere beispielsweise oder tausend Bilder konvertiere parallel.

Das ist damit dann möglich. Rampen für Cloud Provider eben dafür zuständig €000 Laufzeit Umgebung bereitzustellen, die dann parallel den Job abarbeiten können. Hast du in letzter Zeit selber schon Functions, also Service Funktionen entwickelt?

Hab ich in der Tat. Das war bei zwei verschiedenen Projekten jeweils verschiedene Anwendungsfälle. Einmal haben wir das genutzt, um Web Application also an der Stelle einer Westlake JAL bereitzustellen, die eben von außen aufgehoben wird. Dann Processing mach. Und je nach bestimmte Antwort zurückgibt. Der andere ist mehr asynchronen Fal, wo sozusagen durch Daten Anlieferung Funktion getriggert wird, die dann eben Daten einliest, transformiert und dann wieder raus schreibt. Und dann kann auch in einer Kaskade dahinter eben neue Fangzähne getriggert werden, sodass dann sozusagen dieser übliche Ettl Job durch mehrere verschiedene Functions abgebildet wird, wobei jede Funktion immer nur eine Transformation ausführt und dann Pappi Events wie Datei wurde geschrieben oder neue Datei existiert.

Angetriggert werden und dann entsprechend ihre eigene Verarbeitung an der Stelle fortsetzen. Das heißt, die Verkettung der Trigger ist quasi ein Stück weit der neue Programmcode. Wieso?

Bei einer Dominostein Reihe genommen würde ich sogar vielleicht noch einen Schritt weiter gehen und sagen, dass wenn man mit Pantheons arbeitet und da komplexere Logik umsetzen will, ist man eigentlich gezwungen Microservices mehr oder weniger in Reinform zu denken und umzusetzen, weil dazu, wenn er später noch kommen Franzens bestimmte Limitationen haben, was vor allen Dingen Performance angeht, also CPU Rechenzeit. Und dann ist so eine Funktion tatsächlich auch nur gedacht als einen logischen Schritt, sodass man, wenn man verschiedene Schritte in seiner Ausführung hat, hat man sozusagen immer wieder einen neuen Micros Service, der gekrault wird oder durch ein Event ausgeführt wird, einfach um ein plastisches Beispiel zu.

Geben Wir sind ja noch bei der Definition, was Server des Computing ist. Früher hätte man so eine klassische Webanwendung oder ein Webshop hätte eine Anwendung beinhaltet, wo dann die Bestellung ausgelöst wird, das Etikett ausgedruckt wird für den Karton, der später versendet wird. Plus die Zahlung von der Kreditkarte, mit der der Kunde bezahlt hat. Eingezogen wird und im letzten Schritt wird der Warenbestand um 1 Dex demontiert, um eben diese Bestellung dann darzustellen. Und im Server ist reich, während das einzelne Funktionen, die sich nacheinander aufrufen oder das kann er teilweise sogar auch parallel geschehen.

Aber Microservices in Reinform. Diese kleinen Funktions Blöcke, die sich dann eben nacheinander aufrufen, was man vielleicht noch sagen sollte, weil das Wort oder der Begriff Server des Computing oft marketingtechnisch ausgeschlachtet wird meinen kann, sind auch so Docker Container Round Times also die bezeichnen sich auch als Server. Alles das ist hier im Kontext dieser Podcast Episode nicht gemeint. Mir meinen wirklich nur einzelne Funktionen, die miteinander verzahnt werden können und nicht ganze Programme, Bausteine oder ganze Programm Plattformen die eben hochgefahren werden, wo man dann auf einer niedrigeren Abstraktionsebene einsteigen würde.

Im Grunde, wenn man die Geschichte der Applications Entwicklung sieht, sind Server lässt die neueste Stufe, denn es wird auch. Ich habe in einem Artikel gelesen DevOps als DevOps auf Steroiden bezeichnet. Man kümmert sich im Grunde nur noch um die Programm Logik, also die einzelnen Funktionen und die Verschaltung dieser Funktion von Deist als das Beispiel, was du gegeben hast. Max, dass die Funktion über eine API aufgerufen werden und dann eben weitere Schritte wieder über Abis anstoßen. Schon wahrscheinlich das Paradebeispiel im Server des Computing Bereich.

Mit welchen Anbietern hast du denn? Und Laufzeit Umgebung? Hast du denn jetzt schon Erfahrung gesammelt?

Persönlich hab ich schon so gut wie in den drei größten Cloud Anbietern gearbeitet. Also Amazon habe erst an der Stelle Track Software an Google Cloud Computing allerdings lediglich in Apps und den Ärger mit den befangene Pandoras gearbeitet. Das wäre an der Stelle daneben Landa Funktionen bei Apps und einmal ja Funkens, dann bei Microsoft.

Ich glaube bei Google heißt es Cloud Functions und bei IBM heißt es auch Cloud Functions. Aber das unter dem Begriff Lambada und dem jeweiligen Provider wird man ganz sicher den Produktnamen ausgraben können. Okay, ich glaube, da haben wir schon mal ein gutes Grundverständnis gegeben, was Server Computing ist. Also vielleicht noch ganz kurz Welche Laufzeit Umgebung hast du eingesetzt? Ich nehme an Python, oder?

Genau. Bei mir war es jedesmal Theißen. Allerdings wenn die relativ die Wert mittlerweile aufgestellt. JavaScript funktioniert und auch jede andere große Programmiersprache wird mittlerweile auch an der Stelle unterstützt. Vielleicht noch ein Wort zur Abrechnung.

Also klassische Server bezahlt man ja, indem man einfach die Server mietet oder? Beim Cloud Server wird ja auch pro Minute abgerechnet. Beim Server Computing ist das so ein Mix aus verbrauchten CPU Ressourcen. Remme Ressourcen und Durchsatz. Das unterscheidet sich glaube ich auch bei jedem Anbietern. Bisschen gab es unterscheidet sich auch dann nochmal zusätzlich, in welchem Kontext du sie verwendet. Also ich weiß, dass man bei Apps verschiedene Modi haben kann. Man kann die typische Lambda Funktion haben.

Man kann auch Lambda haben. Man kann die Landa Funktionen mehr oder weniger direkt dem Internet preisgeben oder ein API Gateway benutzen und je nachdem welches Modul man dann je nach Funktionsweise benutzt. Damit wird es auch nochmal ein bisschen anders abgerechnet. Beim Großen und ganzen kann man eben sagen, man bezahlt für die Ressourcen, die man auch tatsächlich einsetzt. Lambada bedeutet, dass die Funktions Ausführung möglichst nahe an den Endkunden herangeführt wird, oder?

Genau das hat. Ich glaube in dem Kontext zwei Bedeutungen. Einmal wird eben z.B. das API Gateway nicht benutzt, was dann eben auch nochmal zusätzlich ein Netzwerk Delay verursachen würde. Und wie du richtig gesagt hast, werden dafür auch Server benutzt, die eben sehr nahe beim Kunden stehen. Das wirkt dann, wenn man das so möchte und bucht quasi und auch bezahlt weltweit auf die verschiedenen Server verteilt, sodass dann je nachdem von wo der Kunde das aufruft, das dann an den nächst gelegenen Server geht.

An der Stelle noch ein Beispiel Bevor wir zu den Vor und Nachteilen von Server des Computing kommen, ist Amazon Alexa also der Sprachassistenten von Amazon selber. Jedesmal wenn man mit Alexa spricht, ruft man im Hintergrund quasi eine Lambda Funktion auf, die dann antwortet. Das fand ich ganz interessant, dass Amazon die eigene Technologie für ja doch dieses Blockbuster Produkt verwendet, was natürlich dann auch Signalwirkung haben soll. Seht her, das ist stabil genug, darauf kann man sich verlassen.

Okay, jetzt haben wir schon einige Vorteile. Implizit angesprochen. Lass uns doch nochmal durchgehen, ob wir nicht was vergessen haben. Skalierbarkeit hatten wir eben schon angesprochen. Amazon Alexa kann man sich z.B. vorstellen, dass am Anfang gab es vielleicht einige tausend Nutzer, die regelmäßig mit ihrer Alexa gesprochen haben. Mittlerweile dürfen das einige Millionen sein. Und diese ganzen Anfragen können eben parallel durchgeführt werden, ohne dass man sich darum kümmern müsste, die Infrastruktur entsprechend zu skalieren.

Das macht der Cloud Provider und auch das Konzept für die Fans sind, denen ausgelegt sind, wo man quasi nur eine Funktion vom Code her bereitstellt, mit vordefinierten Inputs und definierten Outputs. Diese Art der Programmierung dadurch ist trivial möglich, dass auch tatsächlich die Anwendung eben skaliert. Weil n klassischen Anwendungen muss man potentiell eben auch nochmal Gedancken reinstecken, ob die Anwendung überhaupt staatlich ist, ob sie skalieren kann und so weiter. Und diese Sachen sind implizit automatisch gegeben, wenn man entsprechend diese Umgebung nutzen will, weil dann muss man sich diese Gedanken alle vorher machen.

Angekommen vom Cloud Provider sozusagen ein vordefinierte Event eingereicht, mit dem man arbeiten kann. Mehr hat man nicht. Man kann natürlich auch externe Systeme noch anfragen, aber erstmal hat man nur dieses Event und tut dann eben mit diesem Event was. Und dass es in sich allein von den logischen Gedanken beliebig skalierbar, sodass allein die Herangehensweise an die Programmierung so einer Funktion eben an der Stelle das Skalieren quasi gratis mitliefern.

Ich hab bei der Recherche so einen schönen Satz gefunden. Ich glaube es von Google. Das heißt from prototype to production to planet scale, also dass im Prinzip der parallelisiert Kargheit dieser Service Funktion keine Grenzen gesetzt sind. Physikalische Grenzen sind natürlich schon durch den Cloud Provider gesetzt, aber die liegen so hoch, dass man dort erst einmal keine Probleme haben sollte.

Okay, dass man sich nicht mehr um die Beschaffung von Hardware, die Installation des Betriebssystems, die Wartung und das Update des Betriebssystems und etwaiger anderer Software Komponenten kümmern muss. Das hatten wir eingangs schon erwähnt. Ist aber ein wichtiger Punkt, denn ich wette in vielen vielen Admin Teams wird signifikant viel Zeit für diese Tätigkeiten aufgewendet. Soviel zu meiner Erfahrung. Ich weiß nicht, welche du da gesammelt hast, doch das ist ja identisch.

Muss man sich ja nur einmal in der Fachliteratur ein bisschen umschauen. Es tauchen gefühlt jede Woche mindestens eine Sicherheitslücke auf, wo man dann das Team eigentlich überprüfen muss. Okay, der Server, auf denen unsere Anwendung läuft, ist da die Open Access Bibliothek jetzt drauf, die betroffen ist oder nicht? Wenn ja, wie? Installieren wir das? Können wir das im laufenden Betrieb machen und so weiter. Und all das entfällt eben, wenn man in diesem Server lebt, Kontext unterwegs ist.

Dafür bezahlt man am Ende dann den Cloud Provider, dass die sich dann eben um Wartung, Update und so weiter kümmern. Und man selber bekommt von der Situation überhaupt nichts mehr mit. Und dann muss sich auch keine Gedanken machen, was an der Stelle eben irgendein Produktionsausfall oder sowas ist. Oder dass die Funktion erstmal nicht mehr erreichbar. 2 Grad der Hauptsatz aber ja, updatet oder sonst was.

Das hat man eben an der Stelle überhaupt nicht, da auch das Thema, was oft unter den Tisch fällt Hardware Ausfall. Vielleicht erinnerst du dich an ein Projekt, wo wir beide waren, was noch nicht so lange her ist, dass eine fehlerhafte Netzwerkkarte also wirklich wochenlang Haare raufen gesorgt hat, bis sie im gefunden und deaktiviert wurde und ab dann konnte normal weitergearbeitet werden. Das sind auch Sachen. Also nicht, dass es die defekte Netzwerkkarte in einer Cloud Umgebung nicht geben kann.

Aber ich denke die STANDARD Hardware dort ist so gut Monitor, dass das relativ schnell auffällt. Genau. Und soweit ich das weiß, haben sie ja auch nochmal spezielle Software laufen, die Unstimmigkeiten im Netzwerk aufspürt oder insgesamt Unstimmigkeiten in der Hardware. Und dann wird mal einfach ein kompletter Server Schrank aus der aktiven Hardware rausgenommen, falls nur die Ahnung ist, dass da mit dem Server schon was nicht in Ordnung ist, weil Cloud Provider haben natürlich so viel Ressourcen oder so viele Backups auch, dass das einfach mal möglich ist.

Was natürlich für ein normales durchschnittlichen Unternehmen nicht einfach mal möglich ist. So viel über pro. resümierte Hardware dazu haben, dass man meinen gesamten Server Schank aus dem Rechner Cluster rausnehmen kann.

Und wer eine Woche mit Debugging von Hardware Problemen verbracht hat, der wünscht sich, dass er damit nichts zu tun haben möge.

Preis ist auch ein Vorteil. Wir haben es unter Vorteil gelistet, aber ich würde sagen, da muss man etwas aufpassen, denn es gibt durchaus auch Szenarien, wo es günstiger ist, wenn man einen eigenen Server mietet, der z.B. kontinuierlich unter Hoch Last steht oder der sehr spezielle Anforderungen erfüllen muss, also sei es Spezial Hardware oder sehr viel Arbeitsspeicher aufweisen muss, dann sind Server alles Funktionen leider keine Option.

Genau, also das muss man je nach Anwendungsfall immer evaluieren. Es gibt eben meistens bei der Cloud nicht die STANDARD Aussage. Ja, das ist günstiger als alles andere, weil dann gäbe es das andere auch nicht. Mehr dementsprechend. Wie du richtig gesagt hast, mein Server ständig ausgelastet wäre, dann ist der häufig günstiger, als wenn man die gleichen Neuyork laut über Funktionen an der Stelle Fahndungen.

Ein weiterer positiver Punkt, der in vielerlei Hinsicht positiv ist, ist die Abrechnung für verbrauchte Ressourcen, also CPU Zeit, RAM Io. Und nicht nur, weil man tendenziell, wenn man ein System, das man nur für die Last starken Zeiten im Prinzip bezahlt, sondern es wird auch sehr deutlich im Projekt oder bei mehreren Projekten, welche Projekte wie viele Kosten verursachen und wo genau bei welchem Arbeitsschritt und welchem CPU Dienst oder bei welchem Programmteil die höchsten Kosten anfallen und die meiste Berechnung anfällt und man kann dort gezielt optimieren.

Das finde ich auch sehr schön eigentlich. Früher hat man gesagt, die Datenbank läuft 24 Stunden am Tag. Dann können wir auch hier alles rein und rausrechnen und Backup machen. Jeden Abend 100 Gigabyte übers Netzwerk schieben, das ist ja eh da und jetzt muss man sich das schon genauer überlegen. Also kann natürlich auch negativer Punkt sein, weil man sich jetzt damit beschäftigen muss. Aber generell halte ich das für eine gute Sache, dass man weiß, wo welche Aufwände erzeugt werden und man einfach so nochmal einen Überblick bekommt.

Genau.

Also vielleicht auch das Beispiel, das sein Wickler ein bisschen anders entwickelt kann. Ich habe selber gemerkt, dass wenn man sich jetzt eben genau an diese neue Serviceleistung Banken mit arbeitet, dann denkt man auch mal zwei oder drei mal mehr nach, um zu überlegen Okay, brauche ich jetzt diese Datenbank Anfrage oder nicht? Wie du eben so schön gesagt hast wenns im normalen System läuft und die Datenbank Ishtar, dann macht man im Saft. Hab eine Anfrage Mehrheit dahin, obwohl es natürlich auch Bermann Snack optimieren würde.

An der Stelle bringt das natürlich auch Vorteile in jeder anderen Umgebung. Aber gerade in diesem Klout Umgebung hat man sowieso nochmal einen monetären Vorteil dadurch, sodass man dann auch als Entwickler gleich Kaymer überlegt, ob man das nicht wieder schöner oder performant an der Stelle schreiben kann.

Also es wird einfach transparent und man kann sich gezielt darum kümmern oder sich gezielt dafür entscheiden, sich nicht darum zu kümmern. Was ich noch als gigantischen Vorteil seh ist, dass dieses Wissen für die Administration, was ja in jedem Unternehmen aktuell vorhanden ist und auch früher für die Produktentwicklung unabdingbar war, nicht mehr unbedingt notwendig ist. Und auch kleine Entwicklerteams, die vielleicht nur aus Entwicklern und einem 2 DevOps Menschen bestehen, dass sie Anwendungen entwickeln und betreiben können, die von Millionen von Nutzern genutzt werden können da draußen und das ohne eigenes Infrastruktur Team.

Wenn man sich auf Zerfalle Computing konzentriert, also das entbindet einen nicht von allen administrativen Aufgaben. Man muss sich natürlich auskennen und dieses DevOps wissen sich auf schlauen was ist eine IP Adresse? Wie funktionieren Netze, wie sicher ich das ab und so weiter. Und wie Provision niedrig die Infrastruktur auf meinem gewählten Cloud Provider. Also diese klassische Rolle zwischen Entwickler und Betrieb dann aufnehmen. Aber ist es wirklich kein Admin im engeren Sinne mehr notwendig für eine Anwendung, die Millionen von Leute nutzen?

Das ist ja auch schon mal was. Also Apps zum Beispiel. Aber wie das so ist, auch wenn es wunderbar klingt und wer jetzt die Vorteile aufgezählt haben, da gibt es natürlich auch ein paar Nachteile, die wir schon gestrichen haben.

Ich glaube, der größte Nachteil, wo man sich immer bewusst sein muss, sobald man in der Cloud unterwegs ist und vor allen Dingen bei den sogenannten Managed Service. Was Fangnetze Service an der Stelle ist, ist, dass wir ein Vendor Login haben. Das heißt, wenn wir uns jetzt entscheiden, bei Apps in der Landa Funktion was zu tun, dann können wir das nicht eins zu eins so auch danach bei Google z.B. laufen lassen, falls das wichtig ist. Allerdings, das muss man natürlich auch zugeben ist, dass dadurch das Konzept hinter den Fangzähne bei den meisten festgeschrieben ist, muss man natürlich nicht die komplette Funktion neu schreiben, sondern an der Stelle eher den Input und Output so neu formatieren, dass er auch die neue Cloud passt.

Allerdings kannst du dann auch nochmal sein, dass er nach anderen Cloud ein bestimmtes Paket nicht verfügbar als Voda. Man kann es nicht nach installieren oder lohnt was. Also man legt sich erst mal auf eine Cloud fest, wenn man eben eine bestimmte Funktion Umgebung auswählt. Am Ende dessen muss man sich bewusst sein, was natürlich auch am Ende der Tweet of ist. Zwischen dem Komfort, den wir eben erwähnt haben, bezahlt man einer gewissen Stelle dann natürlich damit, dass man den Cloud-Anbieter treu sein muss.

Es hat sich noch keine Open Source Server alles Computing Platform herauskristallisiert, so z.B. kybernetisch. Es ist ja das DevOps Rechenzentrum oder der STANDARD für Container Computing kann man sagen, der von allen Cloud Anbietern angeboten werden muss, weil er einfach so omnipräsent ist. Und für Server des Computing gibt es so einen verbreiteten offenen STANDARD eben noch nicht, der ja vielleicht noch kommen kann. Es wäre zu wünschen, dass man dann zwischen den Anbietern eben auch wechseln kann.

Ich glaube, da besteht ein hohes Bedürfnis, gerade von großen Unternehmen. Aber wer weiß, was die Zukunft bringt. Einen weiteren Nachteil sehe ich im ansprecht Verhalten einer Sour, weil es Funktion. Es gibt keine Garantie, dass diese sofort eine Antwort liefert. Manchmal ist so eine gewisse Ramp up Periode notwendig von wenigen Sekunden, bis dann die Funktion eben ausgeführt werden kann. Das ist insbesondere dann kritisch, wenn ich eine interaktive Anwendung habe, also wo der Nutzer Eingaben tätigt und er dann auf die Rückantwort wartet.

Muss aber gestehen, ich habe hier noch keine Hands on Erfahrung. Ob das wirklich so ein großes Problem ist? Wir haben tatsächlich an der Stelle einmal die Erfahrung gemacht also diese Vampir Periode ist tatsächlich nur am Anfang oder wenn die Funktion eben noch länger nicht ausgeführt wurde oder immer nur sehr sporadisch ausgeübt. Dann hat man eben dieses von dir erwähnte Problem und wir hatten tatsächlich den Fall, als wir eben die erwähnte Vest API bloed haben bzw. Konsequenz von unseren Websiten aus gekrault haben.

Da ist der Traffic schlagartig angestiegen und an der Stelle das Skalieren fand nicht schnell genug statt. Auch wegen dieser WMP Zeit. Und da hat es dann eben die ersten 5 bis 10 Minuten sehr viele Bettwil Requests Server, Time Outs und so weiter gegeben. Was an der Stelle jetzt nicht so kritisch war, weil das keine Daten waren, die das Nutzerverhalten zu sehr beeinflusst hätten. Aber je nachdem in welcher Situation man ist, kann man sich das eben nicht erlauben an der Stelle.

Wir sind danach auch etwas schlauer geworden, dass wir dann eben entsprechend, bevor wir ein anderes neues Deployment oder ein neue Landa Funktion woanders eingebaut haben. Kann man das eben auch einmal händisch selber vorheizen in Anführungsstrichen, wo man dann eben entsprechenden Traffic simuliert, dass eben vorhanden ist. Und ich glaube, mittlerweile gibt es auch seit längerem eine Checkbox, die man in den entsprechenden Oberfläche setzen kann, wo dann eben die Funktionen auf Standby gehalten wird, sodass dann eben diese Scale out oder das Skalieren sehr viel schneller geht.

Allerdings muss man den eben einmal setzen und ich glaube, es kostet auch was eine gewisse Betrag, sodass man da nämlich ständig setzen sollte. Aber es ist gut zu wissen, wenn der Cloud Provider das nicht hat, dann sollte man eben einmal quasi händisch vorheizen, sodass dann bei dem produktiv ausrollen. Wenn man nicht die Möglichkeit hat, prozentual über mehr Traffic abzugeben, dann muss man eben einmal händisch das sicherstellen, dass der Traffic erarbeitet werden kann. Händisch vorheizen.

Das hört sich ja an wie bei einer alten Dampflokomotive her.

Ich war auch amüsiert, als ich das erste Mal den Vorhalt Begriff in diesem Kontext gehört habe. Aber am Ende ist es genau das.

Das ist einfach eine technische Notwendigkeit. Die Cloud Provider haben natürlich tausende oder Millionen Funktionen registriert von all ihren Kunden auf diesen Laufzeit Umgebungen und da wird wahrscheinlich nur ein Bruchteil konstant genutzt und alle anderen werden schlafen gelegt, damit es bei diesen geringen Kosten bleiben kann. Und wenn eine Funktion angefordert wird, dann muss erst einmal eine Laufzeit Umgebung Provision tiert werden oder diese Funktion dort zur Ausführung gebracht werden. Und das kann dann eben diese berühmt berüchtigten ein, zwei, drei, vier Sekunden dauern.

In der Zeit hat man keine Antwort oder die Anwendung kann ich weitermachen? Ja genau.

Und nach dieser Vampir Periode ist das eigentlich kein Problem mehr, weil die meisten glaubt wieder an der Stelle im hingehen und diese entweihen, wo die Funktion ausgeführt wird eben sozusagen Kelchen. Das erst mal nachdem die hochgefahren wurde. Diesen sauberen State sozusagen wird dann mehr oder weniger als Abbild für alle anderen Funktionen der Nacht genommen, sodass dann eben nicht mehr die gesamte Umgebung hochgefahren werden muss, sondern nur noch dupliziert werden muss, was an der Stelle sehr viel schneller geht.

Ein weiterer Nachteil und da sind wir selber, das weiß ich aus erster Hand schon häufiger dran gestoßen und haben da Lösungen für entwickelt. Ist die Ressourcen Beschränkung innerhalb einer Server Ulis Funktion? Das ist wahrscheinlich auch oder es macht einen Unterschied. Je nach Anbieter gibt es da unterschiedliche Ressourcen Beschränkungen. Aber generell kann man glaube ich festhalten, dass man in einem sehr, sehr engen Korsett steht, also beispielsweise, dass eine Funktion maximal 40 Sekunden Laufzeit aufweisen darf. Danach wird sie zwangs beendet oder dass sie nur ein Speicherbedarf von ein Gigabyte RAM konsumieren darf und kann dann nicht weiter wachsen.

Und diese Beschränkungen sorgen zum einen dafür, dass man sich natürlich sehr kurz fasst und die Funktion wirklich nur einen sehr kleinen Teil des Programms dann eben übernimmt. Auf der anderen Seite kann es ja vielleicht doch nötig sein, eine große Anzahl an Bildern zu konvertieren und dann müsste man das irgendwie anders lösen. Genau.

Also das ist so ein bisschen dem Anwendungsfall geschuldet. Ich glaube, das liegt in der Konzeption begründet, dass eben Bankwesens kleine logische Einheiten sind, die häufig wenig Ressourcen Anspruch haben und schnell antworten. Aber das dann in millionenfach sozusagen. Wie du richtig erwähnt, das haben wir auch schon häufiger Probleme gehabt mit diesem Kontext, einfach weil sich dann am Ende das Anwendung. Szenario doch anders entpuppt hat, als es ursprünglich erdacht war, sodass man dann am Ende dann doch auf eine andere Technologie ausweichen musste.

Und man muss sich wirklich vor Augen halten. Also nach diesen 40 Sekunden als Beispiel Wert wird die Funktion Ehard beendet, also mit einem Kill abgeschossen. Wenn man da noch offene Datenbank Transaktionen hat, werden die nicht abgeschlossen oder verbleiben dann in diesem Schwebezustand. Also das muss man wirklich bedenken, wenn man da eine Anwendung, die Zeit, einen weiteren Nachteil.

Wobei ich sagen muss, ich seh das gar nicht als so großen Nachteil, weil die Cloud Provider sich ja doch sehr viel Mühe geben, sind die unflexible Provisionszahlungen der Laufzeit Umgebung. Also ja, wir haben eben schon gesagt Java wird angeboten, Pfeifen wird angeboten, sie Charb wird angeboten. Alles was Rang und Namen hat, JavaScript wird angeboten, aber dennoch muss man sich Vereine dieser FOR konfektioniert Laufzeit Umgebungen entscheiden und kann nicht frei seinen eigenen Sophistik dort aufbauen.

Genau das ist auch je nach Cloud Provider ein bisschen anders gelöst und das von dir angesprochene Korsett einmal enger geschnürt als bei anderen, sodass man da eben Dependency es zum Teil können eben relativ leicht nache installiert werden. Gemeint sind Pulsen Umfeld ist ein Python Paket kann man eigentlich in allen Umgebungen nochmal nach installieren, weil das eben einfach der normale Weg ist. An der Stelle aber zum Beispiel System Bibliotheken, auf die zum Teil bestimmte Pakete angewiesen sind, weil das eben nicht nochmal neu implementiert wird in der entsprechenden Programmiersprache, sondern eben auf normalerweise vorhandenen System Bibliotheken zurückgegriffen wird.

Die können zum Teil Probleme bereiten, wenn eben entsprechend in der Laufzeit Umgebung das einfach nicht vorinstalliert ist.

Hast du da ein Beispiel? Also Verschlüsselung oder Open CSL? Würde mir direkt einfallen, dass man vielleicht nicht jedes Cypher Sued hat.

Genau an der Stelle ist es ein relativ spezielles Beispiel, also das Knuff PGP quasi. Die asymmetrische Verschlüsselung ist an der Stelle nicht installiert in den Äther Pantheons. Zumindestens hab ich das an der Stelle nicht rausgefunden, wie ich es laden könnte. Und so gut wie alle landesüblichen heißen Pakete, die eine einfache Interaktion mit nur P&G verschlüsselten Dateien ermöglichen, setzen eben darauf, dass entsprechend die Bibliothek dafür vorinstalliert ist, was an der Stelle daneben dann nicht der Fall war und was daneben zu sehr viel Rechercheaufwand geführt hat.

Am Ende mussten wir uns auch an der Stelle aus anderen Gründen auch für eine andere Umgebung entscheiden, einfach weil sich herausgestellt hat, dass die Daten am Ende zu groß waren für die Funktion.

Da kann man mehrere beschränkende Faktoren zusammen, also Software Estag und diese Ressourcen Beschränkungen, sodass man sich dann dort von der andere nicht zur weiles Computing Lösung entscheiden musste.

Ein anderes Beispiel, was ich auch noch nennen kann es QT benutzt, was Leuten, die mit einer Maschine noch nicht vertraut sind, wahrscheinlich was sagen wird. Es ist nicht mit dem STANDARD C Compiler kompiliert, zumindest standardmäßig nicht meine ich, dass das zumindest das zugrundeliegende Problem war. Auf jeden Fall ist es nur sehr schwierig möglich, das in z.B. PKW’s zum Laufen zu bekommen. Es funktioniert, aber man muss dann doch wieder mehr Aufwand da reinstecken, dass man das eben selber kompiliert, weil die Laufzeit Umgebung sich eben leicht unterscheidet zu dem, was man normalerweise vorfindet, wo das Paket normalerweise ausgeführt wird.

Naja, und das sind dann genau diese Details Probleme, die dann doch wieder Zeit kosten. Was ich noch als Nachteil sehe.

Wobei da muss ich auch sagen, dass es bei manchen Cloud Providern doch relativ gut gelöst ist, das Debugging, während man diese Funktion entwickelt als man brauche so eine Art Remote Debugger, der dann in diese Server alles Computing Environment den dieBürger dort andockt und dass man die Funktion dann eben Schritt für Schritt durchlaufen kann. Da gibt es auch ganz gute Lösung, aber man hat halt all die Probleme, die man mit Remote Backing hat. Die Ports müssen offen sein, man muss die Funktion registrieren, es klappt nicht immer und man sieht nur die Funktion oder kann halt dadurch steppen.

Dadurch, dass man den Ausführung Stack nicht kennt, weiß man nicht. Okay, hab ich vielleicht einen Speicher Problem oder man sieht einfach nicht so viel wie wenn man das auf einer nativen Maschine macht. Genau.

Es gibt an der Schalotten unseren Ansatz. Zumindestens kenne ich den bei Apps so, dass sie tatsächlich einen lokalen Emulator für die Landa Funktionen bereitstellen. Der läuft dann meistens in Docker. Ich glaube es gibt auch alternative Installations Möglichkeiten, aber da hab ich mich dann für Docker entschieden. Und da wird dann quasi ein Docker Image Gisborne, wo dann deine Funktion Godwein kopiert wird und darum herum wird eben dann diese Funktion Logic simuliert. Funktioniert auch ganz gut, wenn man eben sozusagen die Events gucken will, ob die übereinstimmen, ob der Programmcode überhaupt ausführbar ist.

Was allerdings nicht ein Porst wird, zumindest zu dem Zeitpunkt wo ich es genutzt sind genau die angesprochenen CPU Limits MMW Limit. Execute belämmert in der Größe und so weiter, das wird an der Stelle dann eben nicht geprüft, sodass selbst wenn es dann eben lokal ausgeführt werden kann, man trotzdem in der Cloud noch auf Probleme stoßen.

In der Podcast Episode mit Olli haben wir ja über diese zwei Faktoren gesprochen, dass die Ausführung Umgebung möglichst der Entwicklungsumgebung entsprechen sollte. Und durch diesen Bruch hier kann man sich dann eben neue Probleme einfangen. Hier ist das dann nicht gegeben. Jetzt haben wir die Vor und Nachteile besprochen und ich glaube, jetzt kann man ganz gut ein Bild zeichnen, in welchen Szenarien servil es Computing denn besonders sinnvoll oder eben nicht sinnvoll eingesetzt werden kann. Alexas Gilt’s hatten wir schon als Beispiel.

Du hast gesagt, Dienste, die Überrest APIs miteinander sprechen, eignen sich auch sehr gut, weil das einfach die natürliche Sprache der servile Funktionen ist. Wir haben gesagt, es gibt verschiedene Trigger, mit denen die Funktion gestartet werden kann. Also neue Datei in einem Cloud Folder hochgeladen. In einer Message Cue steht ein neues Objekt an. Ein Rest API Call ist auch ein Trigger Import. Daten sind vorhanden, klopfen irgendwo an, in einer Datenbank entsteht ein Eintrag. Wenn die Anwendung sich darauf stützt, kann man das auch sehr einfach abbilden und bei hoch parallelisiert Baan Anwendungen also zum Beispiel könnte man sich vorstellen einen Web Dienst wo Leute ihre Audiodateien hochladen können im Wave Format und bekommen einen komprimiertes MP3 zurück.

Das wäre ja perfekt. Parallelisiert war eben pro User oder sogar pro User Datei. Das wäre so ein Anwendungsfall wo man sehr gut dann eben sovieles Computing Funktionen einsetzen könnte.

Genau. Wobei man natürlich auch an der Stelle nochmal anmerken muss, dass man sich im Vorhinein überlegen muss, ob man entsprechend Größen Beschränkungen z.B. im Mäzenen, den Kommentierungen Beispiel zu bleiben größten Beschränkungen für die Josa auferlegt, damit das eben garantiert ist, dass in der benötigten Zeit abgearbeitet werden kann. Apropos benötigte Zeit ich bin auch über einen Artikel gestolpert, wo eine Architektur vorgeschlagen wurde, dass eben die sovieles Funktionen möglichst über Message KÜS miteinander verbunden werden sollen. Das Problem liegt darin, wenn man die Server Funktionen miteinander verknüpft und eine Funktion auf die Antwort einer zweiten Funktion wartet, dann wird das berechnet, weil die erste Funktion aktiv auf den Rückgabewert der zweiten Funktion wartet.

Und der Vorteil bei Message Cues ist, dass die erste Funktion ihren Job abschließt, in die Message Kyu ein Objekt anhängt. Die zweite Funktion läuft los, führt ihren Arbeitsschritt durch. Das Ergebnis wird wieder in die Message Kyu eingehängt und jetzt startet die erste Funktion wieder mit dem Ergebnis der zweiten Funktion und kann damit weiterarbeiten. Und das das kann man sich leicht vorstellen. Bei vielen, vielen 000. Funktionen, die vielleicht parallel ablaufen, doch sehr viel Zeit sparen kann und unterm Strich natürlich auch Kostenvorteile bringt.

Wobei an der Stelle würde sehr wahrscheinlich eher so laufen, dass du insgesamt drei Funktionen und zwei Medikus hast. Hast du sozusagen die erste Funktion in die erste mildtätigen schreibt, dann die zweite Funktion aus der ersten liest und in die zweite mit Süd-Korea einschreibt und dann die dritte Funktion darauf wieder reagiert. Dann hast du eben die Trennung der Microservices noch klarer, weil sonst hast du in der ersten Funktion zwei Logiken drin einmal den externen Trigger sozusagen und dann nochmal Handfeger.

Wenn, wie deine Antwort in die Meterdicken geschrieben wird an der Stelle genau serverseitig macht es natürlich Sinn, das auch noch aufzuteilen. Mir war jetzt eigentlich nur wichtig zu zeigen, dieses aktive Warten einer sovieles Funktion. Das sollte man vermeiden, eben aus Kosten, Gesichtspunkten.

Und ein anderer Vorteil natürlich bei diesem asynchronen ist, dass dann, wenn eine davon Ressourcen intensiver als einfach durch die Hörer Verarbeitungs Zeit, dann ist das eben auch an der Stelle abstrahiert. Ich glaube es ist insgesamt ein guter esein Hinweis für die Microservices Architektur, dass du die Kommunikation möglichst asynchron machst an der Stelle, wo du es kannst, dass man die Message Cues das machen lässt, wofür sie gedacht sind, eben per Sistieren von Objekten und die Koppelung der Funktionen.

Dann eben im Grunde wie bei einer Fabrik mit ganz vielen Fließbändern. An die Fließbänder sind da die Message QoS, dass man das dann so aufbaut. Mach doch das Recovery einfacher. Wenn einzelne Dienste streiken oder es zu Problemen kommt, dann sind die Nutzdaten weiterhin in den Message cuius vorhanden, in der Mehrzahl der Fälle aber sinnig verloren. Die Prozessors führen kann ein resoniert werden. Ich denke generell, dass sovieles Computing bei der Neukonzeption von Anwendungen, insbesondere Webanwendungen die Stärken ausspielen kann, wenn klar ist, dass die Anwendung in der Cloud betrieben werden soll, wenn klar ist, welche Funktionen dort umgesetzt werden können, auch mit Nutzer Interaction oder Import-Export Jobs.

Im Grunde so eine klassische Webanwendung kann schon oder weitestgehend Services umgebaut werden. Glaube ich schon. Im Grunde hat man mit der Services Computing Technologie oder Funktion, also Service. Ziel wie mit den Container Technologien nur auf der Abstraktionsebene höher. Man möchte Ressourcen schonen, wenn eine Funktion nicht laufen muss. Möchte man sich nicht darum kümmern und keine Hardware vorhalten oder die Hardware, kann man für andere Funktionen benutzt werden. Und nur die Funktionen, die jetzt gerade laufen müssen, sollen dann eben auch Hardware in Beschlag nehmen.

Genau wie bei Container Technologien auch plus Skalierung plus Ausfallsicherheit. Diese ganzen Benefiz, die man dazu bekommt bei der Container isierung, bekommt man natürlich auch beim Server des Computing dazu. Dennoch gibt es auch einige Szenarien, wo Functions A Service nicht sinnvoll sind.

Genau, also zwei prominente Beispiele. An der Stelle einmal das von uns bereits angesprochene Sache, dass wenn ein Server zum Beispiel 24 Stunden am Tag sieben Tage die Woche komplett ausgelastet ist, dann kann das potenziell günstiger sein, sich tatsächlich dann den virtuellen Server dahin zu stellen oder auch zwei oder drei je nach Last Verteilung an der Stelle. Was aber für mich der wichtigere Punkt ist, ist, dass man eben auch Limitationen hat. Man hat Lais Herz die Ressourcen, die man benutzen darf CPU, RAM und vor allen Dingen Dauer der Funktion, aber auch die Limitationen im deiner Umgebung.

Das heißt, wenn du Ebene Software Komponente hast, die bestimmte Bibliotheken benötigt, die man nicht ohne weiteres nach installieren kann, dann ist das eben definitiv ein Fall, den man nicht in den Fanzines umsetzen kann. Zumindestens aktuell nicht. Es kann natürlich sein, dass sich das in Zukunft ändert, aber nackte entstand hat man da einfach zu wenig Freiheiten, als dass man jede Anwendungs Situation da komplett abbilden kann?

Ich denke auch, es gibt ja durchaus Szenarien, wo man die volle Kontrolle über die Software Komponenten die man einsetzt haben möchte. Einfach weil man eine Anwendung betreibt, die zertifiziert ist mit einer bestimmten Version einer Datenbank. Und dann ist zwar weiles Computing auch nicht geeignet, einfach weil man alle Variablen kontrollieren muss, um die Anwendung konform zu betreiben, eben mit diesen zertifizierten Komponenten und der Cloud Provider, sogar wenn er die Anwendung anbietet. Es kann immer sein, dass es nächste Woche ein Update gibt und dann die nächste Version benutzt wird ungefragt und man dann quasi nicht mehr zertifizierte Software einsetzt.

Genau. Und noch ein anderer Punkt, der je nach Unternehmen weniger wichtig oder wichtiger ist, ist die Portabilität. Weil wir haben an der Stelle ja schon hervorgehoben, dass je nach Cloud Anbieter sich eben die Pantheons leicht unterscheiden und man dann eben die Anforderungen hat, das sehr leicht sehr schnell zwischen verschiedenen Clouds hin und her gewechselt werden kann. Dann empfangt uns an der Stelle nicht das Richtige, sondern dann muss man sich zum Beispiel mit Containern und der Cuba net selbst Bentheim angucken, die so standardisiert eigentlich in jeder Cloud auch als Managed Service angeboten werden.

Die Limits einer Server Umgebung als Nachteil. Also wenn man die nicht halten kann. Das haben wir schon angesprochen, dass das problematisch ist. Also wenn man sehr viel Memory braucht oder kontinuierlich CPU braucht einen Punkt, den man noch gar nicht angesprochen haben und der auf jeden Fall ein Nachteil ist. Denn der Server des Computing Welt ist das Thema Security, denn man muss sich eben vor Augen führen. Der eigene Code wird parallel mit Code von ganz vielen anderen Unternehmen ausgeführt.

Generell ist das schon gegeneinander abgeschirmt, aber wenn man jetzt an die Prozessor Fehler der großen 86 Hersteller denkt, ist das natürlich ein Thema. Also man läuft mit Code von anderen Unternehmen, mit Daten von anderen Unternehmen Memory parallel und es gibt einfach Anwendungsfälle, wo man das rechtlich nicht darf oder wo man das einfach nicht möchte. Und in diesen Fällen ist Server des Computing oder generell Cloud Computing ist auch schon schwierig. Dann vielleicht nichts für ein naja. Also in den Fällen muss man wie du schon sagst, generell bieten Cloud Provider Möglichkeiten, dass man eben exklusiv auf Service läuft, also auf tatsächlich Hardware Maschinen.

Ich bin mir nicht sicher, ob das in den Pantheons vorgesehen ist. Wenn ja, bezahlt man da deutlich mehr, weil dann natürlich die gesamte Hardware bezahlt werden muss, auch wenn man sie nicht nutzt. Das heißt, da sind dann potenziell andere Services durchaus besser geeignet, wenn man eben diese Bedenken berechtigterweise dann hat.

Das muss man dann abwägen, je nach Anwendung, die da ausgeführt wird und natürlich auch, welche Arten man am Ende verarbeitet.

Herr Server, weil Computing eignet sich insbesondere dann, wenn man dieses Microservices Service Masch eben hochfahren kann oder die Anwendung sich darauf abbilden lässt. Und man kann glaub ich sagen in anderen Szenarien opfert man den einen oder anderen Vorteil. Dieser SVR Wallis Umgebung dann schon eben zugunsten von mehr Kontrolle. Kann auch Szenarien geben, wo man z.B. Abhängigkeiten zu externen Diensten hat. Also bei meinem aktuellen Projekt gibt es z.B. viele Stammdaten liegen einem SAP System, was mehrere Sekunden benötigt, um komplexe Anfragen zu beantworten und hier Ergebnisse zu liefern.

Und da würde ich mich auch schwertun direkt Server Funktionen anzudocken, ohne. Ein Caching ler dazwischen. Weil ich sonst nicht sicherstellen kann, dass ich diese 40 Sekunden Marke oder diese Zeit SchrÃnke der Server alles Funktionen nicht irgendwann mal reiße und dann abgebrochen wird und in undefinierten Zustand habe. Genau. Häufig ist es eben, solange man sich in der Cloud selber bewegt. Vor allen Dingen beim gleichen Anbieter ist man relativ sicher, was diese Timelords angeht. Hat natürlich niemals davor gewappnet.

Es gibt auch da Systeme, die einfach nicht auf zeitige Antworten ausgelegt sind. Aber wie du richtig sagst, sobald man externe Systeme noch dazukommen, hast du einfach da nicht zwangsweise die Kontrolle drüber. Zumal man, wenn man jetzt nochmal sagt externe Systeme, die man selber gar nicht kontrolliert, weil es nochmal von einem anderen Anbieter kommt, dann muss man eben schon auch gucken, ob da die Anforderungen eingehalten werden können.

Ja, wenn das GAP zwischen alter Technologie und servile Computing oder funktionelles as a Service, die ja wirklich ganz neu und an vorderster Front der Entwicklung stehen, wenn Scepter dazwischen zu groß ist, dann muss man schauen, wie man das minimiert, damit man nicht zu viele Abstriche machen muss in beiden Welten. Ja, vielen, vielen Dank, Max, dass du heute da warst. Wenn unsere Zuhörer Fragen haben oder Feedback senden möchten, können sie das gerne tun unter der E-Mail-Adresse, Podcast etc.

. Gilbert E. Lasst uns gerne eine Bewertung dar und abonniert unseren Podcast. Und wir freuen uns immer, wenn ihr diesen auch an Freunde und Kollegen weiterleitet. Für mehr spannende Technologie. Tim schaut auch gerne auf Skill bei TE Slash Blog vorbei. Max, ich bedanke mich ganz herzlich bei dir für dieses wahnsinnig interessante Gespräche rund um Server des Computing und das Thema Functions Service. Es hat einen Riesenspaß gemacht. Danke Meads, auch Spaß gemacht, dabei zu sein.

Wunderbar! Ich wünsche dir noch einen schönen Abend.

Danke. Gleichfalls.

Maurice KnoppSkillbyte Podcast #34: Serverless Computing – Hype oder Chance? AWS Lambda, Azure Functions, Google Cloud Functions richtig verwenden
Mehr

Skillbyte Podcast #32: Women in Tech / Frauen in der IT!

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Women in Tech / Frauen in der IT!

// Inhalt //
01:15 – Wann hast du dich für Technologie interessiert?
03:04 – Ausbildung und Studium
04:09 – Welche Technologie Themen begeistern dich?
05:51 – Erste Hands-on Praxiserfahrungen im Talent Program
09:16 – Hohe Komplexität und Abwechslungsreichtum im Job
10:42 – Permanente Weiterbildung ist notwendig
11:30 – Frauen in der IT – Wie ist das für dich?
15:09 – Empfehlungen für Frauen die in die IT oder die einen technischen Beruf ergreifen möchten
19:37 – Digitale Bildung früh ermöglichen
20:31 – Mentoren
21:23 – Spielerisches Lernen für Kinder z. B. mit dem Calliope
23:16 – codiviti.de – Kreatives coding für Kinder
28:52 – Franziskas Fazit

Kreatives coding für Kinder: https://www.codiviti.de

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

 

TRANSKRIPT der Folge Skillbyte Podcast #32: Women in Tech / Frauen in der IT!

[00:00:01.050] – Franziska
Man muss sich als Frau tendenziell öfter beweisen, zumindest am Anfang. Also, es kann eine ganz klassische Situation sein, dass man irgendwie in einem Workshop sitzt und man ist eigentlich vielleicht die Expertin für das Thema. Aber das wird den anderen im Raum erst durch viele, viele Wortbeiträge bewusst.

[00:00:23.090] – Maurice
Herzlich Willkommen zur Skillbyte Podcast Episode Nr. 32: Women in Tech / Frauen in der IT! Abonniert unseren Podcast, wenn ihr mehr spannende Themen aus dem Technologie-Umfeld hören möchtet, wenn ihr IT-Entscheider oder -Fachkraft seid, ist das besonders interessant für euch. Wenn im Verlauf des Podcast Fragen aufkommen, sendet uns gerne eine Hörerfrage an podcast@skillbyte.de und lasst uns eine Bewertung da, da freuen wir uns immer sehr. Ebenso über die Weiterempfehlung an Freunde und Kollegen. Und heute zu diesem ganz besonderen Podcast habe ich einen ganz besonderen Gast. Hallo Franziska, ich freue mich super, dass du heute hier bist.

[00:00:58.580] – Franziska
Hallo Maurice, vielen Dank für die Einladung. Ich freue mich auch.

[00:01:01.970] – Maurice
Gerne. Ja, wir können ja keine Folge Women in Tech machen, ohne eine Frau dabei zu haben. Ganz klar.

[00:01:08.990] – Franziska
Da stimme ich dir zu.

[00:01:10.130] – Maurice
Ich bin wirklich gespannt, was wir in der nächsten halben-, Dreiviertelstunde, was du erzählen wirst. Vielleicht möchtest du uns ganz kurz erzählen, seit wann du dich für Technologie interessierst.

[00:01:21.860] – Franziska
Ja, also bei mir war das tatsächlich, muss ich sagen, ein ziemlicher Entwicklungsprozeß. Also ich bezeichne mich da selber eigentlich auch eher so als Spätzünderin. Ich glaube, ganz offiziell bin ich ein Digital Native mit meinen 27 Jahren. Aber meine Eltern haben zum Beispiel auch erst recht spät ihren ersten PC angeschafft und dementsprechend ist man dann auch erst über Social-Media, die Chat-Funktionen wie ICQ und Co., so richtig darauf aufmerksam geworden. Und ja, ich glaube, ein großer Punkt war da auch, dass in der Schule leider super wenig Fokus darauf gelegt wurde, uns an die IT auch heranzuführen. Ich weiß nicht, ob sich das wirklich stark bis heute verändert hat, aber ich hatte noch keinen Informatik- oder Digitalkurs in der Schule und bin dann erst im Studium ganz klassisch durch „Grundlagen des Programmierens in Java“ so in die Technologie-Schiene geraten.

[00:02:11.490] – Maurice
Und das hat dich dann so fasziniert, dass du gedacht hast, da würdest du gerne mehr drüber erfahren?

[00:02:15.810] – Franziska
Definitiv. Also ich hab da direkt gemerkt Programmieren macht mir einfach wahnsinnig Spaß. Also für mich ist das ein bisschen wie eine Fremdsprache, mit der du aber so viel ganz logisch irgendwie darstellen kannst, was dann ja irgendwie zu einem ganz konkreten Output auch führt. Also irgendwie, nichts ist unmöglich und das ist echt super spannend, finde ich.

[00:02:36.110] – Maurice
Also du meinst so ein bisschen die Mächtigkeit. Wenn du diese Sprache beherrschst, beherrscht du die Maschine.

[00:02:41.930] – Franziska
Genau das bringt das eigentlich ziemlich genau auf den Punkt.

[00:02:45.160] – Maurice
Ja, also das fasziniert mich immer wieder, wenn du Code schreibst, an dem du tagelang, wochenlang gearbeitet hast, dass das in dem Moment, wo du das Problem geknackt hast, ist es gelöst. Also wirklich wie so ein Zaubermoment.

[00:02:56.450] – Franziska
Genau. Und das sind eben auch so kleine Erfolgserlebnisse, die einen dann immer wieder pushen, noch etwas Neues zu lernen und auszuprobieren.

[00:03:03.980] – Maurice
Aber auch bei dir war es also so, dass du sagst, okay, die Schule hast du relativ untechnologisch überstanden und hast erst im Studium dazu gefunden. Weil du einfach gemerkt hast, weil du zufällig Algorithmen und Programmieren hattest und dann gemerkt hast, dass dir Programmieren Spaß macht.

[00:03:19.700] – Franziska
Genau. Also ich würde sagen, so eine naturwissenschaftliche Prägung hatte ich schon immer. Also auch so klassisch den Mathe Leistungskurs gewählt. Aber ja, die Informatik war mir ganz fremd. Also man hat da wahrscheinlich auch gewisse Stereotypen natürlich mit verbunden. Ne, der Nerd, der da die Nacht irgendwie in seinem Keller am Computer verbringen. Ja, dass das ein ganz falsches Bild ist, das wurde mir eigentlich erst im Nachhinein klar, ne.

[00:03:42.620] – Maurice
Ja, also das ist immer. Es tut mir wirklich weh, so etwas zu hören, dass sich da so wenig getan hat. Ich hatte zwar Informatik in der Schule, aber auch auf einem ganz seichten Niveau, möchte ich mal sagen. Und dann so als AG noch angeflantscht, auf gar keinen Fall Plicht Kurs und ja, kann das gut nachvollziehen. Aber jetzt sind wir ja bei dir. Das heißt, du hast auf einmal, der Funke ist übergesprungen und du hast festgestellt, okay, das macht mir richtig viel Spaß. Gibt es was, was dich ganz besonders bei Technologie-Themen reizt, außer dieser Sprache?

[00:04:14.210] – Franziska
Also ich glaube natürlich ist für mich auch das bigger picture immer wieder faszinierend. Ne, also, wenn ich mir allein meine kurze Lebensspanne bisher anschaue und überlege, was sich da weiterentwickelt hat. Also wir sprechen irgendwie mit Unternehmen wie Volocopter nun über die Option eines Flugtaxis. Wir haben Apps, die uns eigentlich in jeglichem Lebensbereich, sei das jetzt bei so etwas Simplen wie Splitwise, wo du deine Ausgaben mit dem Partner teilst, ne, bis hin zu irgendwie Google Maps, was wirklich mein Leben grundsätzlich verändert hat, ganz neue Möglichkeiten, ne. Und ich sehe das alles als Riesenchance. Also ich bin eigentlich fest davon überzeugt, muss man sagen, dass Technologien unser Leben massiv vereinfachen und bereichern werden, wenn wir eben lernen, auch damit richtig umzugehen, ne. Also da ist auch wieder das Thema Bildung. Das kommt jetzt bei uns an vielen Stellen heraus ein ganz, ganz großes Thema.

[00:05:04.910] – Maurice
Ja, auf jeden Fall. Und vielfach in den Medien wird ja, wenn man von Technologie spricht, wird ja wirklich nur Social-Media gezeigt. Oder die Konsumentenseite, also Social-Media, Gaming, ne. Die Leute benutzen Technologie, um sich zu unterhalten und diese kreative Seite, dass ich mit Technologie etwas erschaffen kann, ein Programm erschaffen kann, Kunst erschaffen kann, ganz viele verschiedene Dinge, da wird meist nicht so drüber berichtet.

[00:05:30.890] – Franziska
Ja genau, und vielleicht da auch nochmal einzuhaken. Technologie oder im Technologiesektor zu arbeiten bedeutet ja jetzt nicht per se immer, man muss jetzt wirklich der Software Developer sein und den ganzen Tag programmieren. Das ist eine Komponente davon. Aber es gibt ja so viele verschiedene Berufe in dieser Welt, was vielen gar nicht bewusst ist, ne.

[00:05:50.540] – Maurice
Auf jeden Fall. Jetzt warst du irgendwann ja auch mit dem Studium fertig, offensichtlich. Und dann hast du dir wahrscheinlich überlegt, was mache ich denn jetzt? Und da war für dich schon klar, dass du unbedingt was mit Technologie machen willst oder sogar mit Softwareentwicklung?

[00:06:04.370] – Franziska
Genau. Also mir war eigentlich nach dem Studium recht schnell klar, es soll weiter in diese Richtung gehen. Also ich hab nach der Schule ganz klassisch mit einem Wirtschaftsingenieurwesen-Studiengang angefangen und da mich dann recht schnell eben im Informatikbereich auf der einen Seite und im Statistikbereich auf der anderen spezialisiert. Also es ist glaub ich ganz klassisch, Wirtschaftsingenieurwesen ist erstmal sehr breit aufgestellt und man findet dann irgendwie so seine Leidenschaft, ne.

[00:06:31.550] – Maurice
Vertiefungsrichtung.

[00:06:32.840] – Franziska
Genau und bei mir war es dann auch so, ich hab mich im Master, als das dann alles auch deutlich ausgeprägter war, noch dazu entschieden, sozusagen für ein Jahr einen zweiten Master draufzusetzen, da bin ich ins Ausland für gegangen. Da gab’s schon recht früh sehr praxisorientierte Studiengänge. Bei mir war das dann ein Kurs, der hieß „Business Analytics“. Ich bezeichne das immer so als „Hands-on-Data-Science-Projekt-Kurs“, weil du wirklich ein Jahr lang programmiert hast, verschiedene Projekte durchgespielt hast und auch wirklich mit Unternehmen zusammen gearbeitet hast. Und das war für mich dann irgendwie so der letzte Indikator, okay, hier bist du richtig. So diese Richtung Data Science, also Schnittstelle zwischen Computer Science und Statistik und Mathematik. Genau.

[00:07:13.460] – Maurice
Ja perfekt, da kommt ja sozusagen, kommen ja alle deine Stärken dann wieder zum Einsatz, ne, die mathematische Komponente, die statistische Komponente und dennoch darfst du Code schreiben, um das alles zu verknüpfen, miteinander. Und dann musstest du dir überlegen, gehe ich jetzt in die Wissenschaft oder zu einem Unternehmen?

[00:07:29.420] – Franziska
Ja, irgendwie so eine klasse Frage, die sich glaube ich ziemlich viele Leute nach dem Studium dann stellen. Also mir hat das wissenschaftliche Arbeiten immer viel Spaß gemacht, aber nichtsdestotrotz habe ich mir irgendwie beide Welten ein bisschen genauer angeschaut, mir da auch Zeit genommen, um wirklich ja, meine Optionen so bisschen besser kennenzulernen und bin dann eigentlich mehr durch Zufall auf das Traineeprogramm Median von Bertelsmann gestoßen. Das ist ein Talent Programm, was sich eben speziell auf Data Science spezialisiert. Also ich glaube, da auch so das erste und einzige bisher, was ich gefunden habe. Und ja, das hat mich überzeugt. Einfach ohne jetzt hier Eigenwerbung machen zu wollen, weil mir so die Möglichkeit gegeben wurde, ganz ganz viele verschiedene Facetten des Data Science, in auch ganz verschiedenen Industrien, eben kennen zu lernen.

[00:08:15.530] – Maurice
Ja, cool. Das finde ich supergut, dass Unternehmen, meistens etwas vor dem Bildungsapparat erkennen, wohin die Zukunft geht und diese Programme auflegen. Und innerhalb des Programms gibt es noch viele Unabwägbarkeiten, weil es eben sehr neu und sehr jung ist.

[00:08:32.130] – Franziska
Definitiv. Also die neueste war ja die Corona-Krise. Aber selbst das konnte man eben sehr gut managen, einfach weil, das finde ich immer wieder schön, bei digital aufgestellten Teams, die können eben auch sehr schnell auf remote umsteigen. Also das ging ganz easy.

[00:08:46.560] – Maurice
Und jetzt bist du quasi von der Uni in dieses ja, ich möchte nicht sein Traineeprogramm oder ist es ein Traineeprogramm?

[00:08:54.470] – Franziska
Genau. Also ich bezeichne es manchmal eher so als Talent Program, weil Trainee, glaube ich, im Ausland auch oft Praktikum heißt. Und ich finde das darf man nicht verwechseln, ne.

[00:09:04.160] – Maurice
Also wahrscheinlich so ein Job-Einstiegs-Programm. Du hast in relativ kurzer Folge viele verschiedene Stationen durchlaufen und einen guten Einblick in den Konzern bekommen, aber immer mit Fokus auf Daten.

[00:09:15.030] – Franziska
Genau.

[00:09:15.410] – Maurice
Perfekt. So und jetzt bist du ja schon seit einiger Zeit im Job, und haben sich die Erwartungen an das Technologie-Umfeld, die du vielleicht hattest, auch im Job bestätigt. Bist du glücklich mit deiner Wahl?

[00:09:28.190] – Franziska
Definitiv. Also ich hab den Data Science Beruf immer als sehr abwechslungsreich empfunden und das hat sich auf jeden Fall bestätigt. Also es ist ja ein sehr komplexes Gebiet. Ich glaube Maurice, das kannst du auch aus deinen Erfahrungen als Data Ingenieur beispielsweise bestätigen, man lernt eigentlich ja täglich dazu. Man muss sich irgendwie auch immer fortbilden, ne.

[00:09:49.280] – Maurice
Es ist, ich kann es ja sagen, ich hab jetzt schon 10 Jahre Perspektive auf dieses Feld. Es ist eine rasante Entwicklung. Es war damals schon eine rasante Entwicklung, aber man merkt, das explodiert nochmal oder das steigt noch mal exponentiell an. Einfach weil, du hast es schon bei deiner Motivation gesagt, Technologie wird immer wichtiger in verschiedenen Bereichen des Lebens oder in nahezu allen Bereichen des Lebens. Und früher hat man häufig mit einer technologischen Lösung, Datenbank, auf viele Probleme geantwortet. Und in den letzten Jahren sieht man, dass sich so immer weiter Verästelungen und Spezialisierungsformen bilden, also dass sich diese Branche einfach immer weiter, ja spezialisiert auf die einzelnen Anwendungsfälle. Und da es immer mehr Anwendungsfälle im Leben gibt und immer weitere Spezialanwendungen dafür gebaut werden – in Summe wächst dieser Bereich extrem.

[00:10:42.910] – Franziska
Genau. Und ich glaube, da ist es auf der einen Seite natürlich sehr spannend mit dran zu wachsen. Auf der anderen Seite eben auch eine Herausforderung. Also das Lernen hört sozusagen nicht im Studium auf, sondern ich sitze gerade auch wieder an einem neuen Coursera Kurs, um eben noch tiefer in das ganze Thema Cloud Engineering reinzusteigen.

[00:11:01.420] – Maurice
Ich glaube das ist ganz wichtig, was du sagst, also Leben heißt lernen auch für mich. Und so wie du das kennengelernt hast im Studium, dass man im Prinzip einen breiten Überblick hat und dann sein Steckenpferd findet in dieser Galaxie, genauso ist es auch im Technologie-Umfeld. Man kommt relativ schnell an Grenzen, man kann nicht alles können, sondern man muss da sein Spezialfeld finden und auch das ist groß genug. Aber es freut mich außerordentlich, dass du da bisher so einen schönen Weg beschritten hast. Jetzt bist du ja, als weibliche Person in der IT-Umgebung, oftmals in der Unterzahl. Ne, das kannst du wahrscheinlich so unterschreiben.

[00:11:38.920] – Franziska
Gerade im Projektteam bin ich tatsächlich die einzige Frau.

[00:11:42.220] – Maurice
Genau. Also das war schon zu der Zeit, als ich studiert habe, das ist jetzt auch gut 10 Jahre her, so da war es, war der Frauenanteil noch geringer als es heute ist, also es tut sich auf jeden Fall was. Aber die Stereotypen haben richtig durchgeschlagen. Stellst du denn geschlechterspezifische Unterschiede fest, jetzt in deiner tagtäglichen Arbeit?

[00:12:00.790] – Franziska
Also ich fühle mich in der Tech-Branche sehr wohl und das liegt vor allem daran, dass eben der Teamzusammenhalt wahnsinnig gut ist, dass ich nicht das Gefühl eben habe, dass es große geschlechtsspezifische Unterschiede gibt. Es gibt natürlich einige Dinge, wo wir glaub ich, soziokulturell noch so geprägt sind, dass natürlich, ja gewisse Dinge auffallen. Ich glaube, wir alle sind von Rollenklischees nicht ganz befreit und ich glaube, so ein Beispiel, was mir spontan einfällt, ist immer das Thema: Man muss sich als Frau tendenziell öfter beweisen, zumindest am Anfang. Also es kann eine ganz klassische Situation sein, dass man irgendwie in einem Workshop sitzt und man ist eigentlich vielleicht die Expertin für das Thema, aber das wird den anderen im Raum erst durch viele, viele Wortbeiträge bewusst. Und man merkt dann auch so richtig, wie sich das Verhalten gegenüber ändert, ne. Also das ist nur so meine eigene Erfahrung. Aber es wird mir von vielen Bekannten und aus meinem Netzwerk eben auch bestätigt. Und ich denke, das kommt natürlich von zwei Seiten. Einmal eben, wie du es beschreibst, gewisse Stereotypen, von denen wir auch nicht befreit sind und auf der anderen Seite eben, dass vielleicht Frauen eben durch ihre kulturelle Prägung gewisse andere Charakteristika an den Tag legen, um mal Stichworte wie Impostor-Syndrom, was bei Frauen eben stärker ausgeprägt ist, zu nennen oder eben Zurückhaltung generell.

[00:13:21.190] – Maurice
Das wäre jetzt wahrscheinlich gar nicht mal auf den Technologiebereich gemünzt, sondern generisch.

[00:13:26.830] – Franziska
Genau. Also ich denke, Unterschiede bestehen, wenn eben immer noch in ja, in strukturellen Problemen oder strukturellen Dingen, die wir angehen müssen. Technologisch sollte es da keine Unterschiede geben, in der Sache an sich.

[00:13:40.520] – Maurice
Nee, das sehe ich ganz genauso. Also es ist natürlich, als Frau ist man erst mal ungewöhnlich. Ich glaube, das kann man einfach schon mal sagen in dem Bereich. Wobei ich auch schon in Teams gearbeitet habe, wo es wirklich 50:50 verteilt war. Und das war, ich arbeite auch so gerne mit Frauen zusammen, überhaupt kein Problem. Also ich bin, und ich glaube der Tech-Bereich begünstigt das auch so ein bisschen, da zählt halt Fachlichkeit und fachliche Kompetenz sehr viel und man hat generell so ein kollaborativen Ansatz. Eben weil dieses Feld so riesig ist, weiß man okay, alleine bin ich hier verloren, ich muss mit den anderen Menschen zusammenarbeiten und man hat nicht so viele Ellenbogen-Typen.

[00:14:19.720] – Franziska
Das kann ich auf jeden Fall bestätigen. Und ich glaube, das ist auch der Hauptgrund, warum ich mich in meinem Job und dem Umfeld sehr wohlfühle. Es ist ein Miteinander und niemand muss sich auch schämen, dass er irgendwie vielleicht am Anfang natürlich noch nicht die besten Programmiertricks kennt oder sich in gerade diese komplexen Sachverhalte auch immer neu reinarbeiten muss, sondern da ist viel Teamarbeit gefragt und auch immer, ja willkommen, würde ich sagen.

[00:14:44.560] – Maurice
Ja, genau. Also weil eben dieser riesen Bereich als Einzelperson kaum zu beherrschen ist und man darauf angewiesen ist, von Außenstehenden oder was heißt Außenstehenden, anderen Projekt-Mitgliedern, zu lernen und dann eben auch lernen möchte, ne. Also das glaube ich, es gibt keinen IT-Menschen, der sagt Nö, ich hab genug gelernt und lern jetzt nix mehr.

[00:15:03.910] – Franziska
Ist mir noch nicht untergekommen.

[00:15:05.770] – Maurice
Das würde auch nicht lange gutgehen, glaube ich. Was würdest du denn jetzt anderen Frauen empfehlen, die damit liebäugeln, in dem IT-Bereich oder in einem Technologiebereich, es gibt ja auch andere Bereiche, z.B. Physik oder so, Fuß fassen zu wollen.

[00:15:19.930] – Franziska
Also auf jeden Fall erstmal, probiert es einfach aus. Ihr werdet schnell genug merken, ob euch das Spaß macht. Also ich kann auch gerade empfehlen, mal vielleicht ein Praktikum in dem Bereich zu machen, weil man dadurch eben schon mal so eine gewisse Einschätzung bekommt. Ist das was für mich oder nicht? Bestes Beispiel von meiner Seite. Ich habe mein erstes Praktikum bei der Audi AG in der Logistik Planung gemacht und mir war sehr schnell klar, dass ist ein toller Bereich, aber eben nicht mein Bereich und so stellt man diese Dinge eben fest, ne. Und auf der anderen Seite würde ich auch immer sagen, wenn ihr eine Chance bekommt, nehmt diese auf jeden Fall an und sagt nicht nein. Also auch wenn ihr vielleicht im ersten Moment denkt, oh, bin ich dem denn schon gewachsen. Also ein klassisches Beispiel hier sind ja immer so Stellenausschreibungen. Da ist ja allgemein bekannt Frauen bewerben sich erst, wenn sie irgendwie 90 Prozent der Kriterien erfüllen. Niemand erfüllt diese Anforderungsliste. Also es werden ja gefühlt oft fünf Programmiersprachen, dann noch drei Jahre Berufserfahrung et cetera pp gefragt. Und ich würde dann immer sagen, man hat ja auch nichts zu verlieren. Also die Bewerbung wird ja dann gescreent und wenn die Leute dich kennenlernen wollen, dann kommen sie auf dich zu und das ist doch super.

[00:16:31.120] – Maurice
Auf jeden Fall. Dieser offene Ansatz öffnet ganz viele Türen und Möglichkeiten. Ja, ich finde auch eine prima Möglichkeit, um so in diese IT-Welt mal reinzuschnuppern. Sind zum Beispiel Hackathons, die oft von Firmen am Wochenende durchgeführt werden, wo man einfach innerhalb von 48 Stunden in einem Projektteam zu irgendeiner Aufgabenstellung ein Ergebnis liefern muss. Und das muss nicht immer Sourcecode sein. Also gerade auch im Bereich Produktdesign Planung, Präsentation kann man da sehr viel lernen und die Leute sind super offen. Ne, kann kann man sich vorstellen wenn die schon in ihrer Freizeit da hingehen, dann sind das tendenziell interessierte Leute, die auch Technologie lieben. Oder Coursera Kurse oder Udemy Kurse, die es auch noch gibt. Wahrscheinlich auch bei YouTube gibt es jede Menge Material, um sich gewisse Technologien mal anzuschauen oder das einfach mal zu probieren.

[00:17:19.810] – Franziska
Genau. Und vielleicht um nochmal bei dem Hackathon-Thema einzuhaken das ist echt ein guter Punkt. Da kommt auch nochmal dieser Teamspirit eben raus, der in der Tech-Branche eben ganz groß ist. Und ich finde auch, da sind gerade heterogene Teams super wichtig, um eben auch bei diesen innovativen Gedanken, ja alle möglichen Facetten zu berücksichtigen. Bei mir selber war es so, ich hab mich lange nicht getraut, an Hackathons teilzunehmen, eben auch, weil ich dachte, oh, da muss man jetzt bestimmt schon mega gut programmieren können. Und war dann ganz froh, als ich mich das erste Mal getraut habe, weil es wirklich auch viel um eben das gemeinsame Ideen generieren und Brainstorming geht. Und das war einfach echt ein super Wochenende für mich.

[00:17:59.440] – Maurice
Ja, also ich habe auch schon einige gemacht, aber wahrscheinlich ist das jetzt auch wieder so ein Stereotyp. Ich hab mich nie nicht getraut, sondern ich hatte immer am meisten Spaß, wenn ich da hingegangen bin mit mindestens einer Person, die ich irgendwie kannte. Also das wär auch noch eine Empfehlung von mir. Nehmt einen Freund, nehmt eine Freundin mit, meldet euch zusammen an. Oftmals sind diese Hackathons auch kostenlos und ihr lernt, also ihr werdet so viel Spaß haben. Ihr werdet tolle Menschen kennenlernen. Es wird auch aufregend sein, keine Frage. Meistens ist das Essen auch gut. Also das kann ich jetzt so aus meiner Erfahrung sagen, es ist ein rundum gelungenes Wochenende, sehr intensiv, aber das macht super viel Spaß. Auf jeden Fall. Und es ist ein relativ niedrigschwelliger Einstieg in die Technologie und in alle Aspekte davon. Also sowohl Coding als auch Problemanalyse, das ist ja auch ganz wichtig, es geht ja nicht nur ums Programmieren, sondern auch um eine Vorstellung davon zu bekommen, was bauen wir eigentlich hier? Wie ist das sinnvoll? Wie muss die App aussehen? Wie muss die Website aussehen? Design jetzt auch wirklich optisch? Wie muss die Website aussehen oder die App aussehen? Ich hab mal an einem Hackathon für Kinder, war ich Mitorganisator und eine Gruppe von vier Mädels hat für ein Spiel, das Spiel war quasi fertig, hat nur mit dem Level Editor möglichst kreative Levels gebaut. Zwei Tage lang. Und das war super hinterher, also das hätte man so direkt als Produkt verkaufen können, unglaublich. Und die Eltern dieser Kinder haben das selber kaum glauben können, also das war einfach super schönes persönliches Erlebnis von mir.

[00:19:23.290] – Franziska
Ja, cool.

[00:19:24.240] – Maurice
Und wirklich, also ich glaube, was wir beiden sagen können oder in die Welt hinaus rufen können ist: Technologie ist ein super großes, spannendes Feld und niemand muss Angst davor haben und schon gar nicht, sich damit zu beschäftigen und da einzutauchen. Genau. Es ist auch manchmal etwas traurig. Also mir sagte auf diesem Hackathon ein Waldorfschüler, dass, also das ist jetzt auch schon ein paar Jahre her, das war glaube ich 2017, dass bei ihm an der Schule alle elektronischen Geräte verboten sind und man sich damit gar nicht beschäftigen dürfe. Das ist natürlich ein Wahnsinn, wenn man sich das überlegt, dass da Kinder nicht lernen, wie man eine E-Mail schreibt oder im Internet etwas recherchiert, eine Reise bucht, einen Mietwagen besorgt oder so. Also bitte, bitte, liebe Eltern, macht das nicht. Digitale Bildung ist genauso wichtig wie normale Bildung.

[00:20:09.580] – Franziska
Ja, definitiv. Also du sprichst da den super wichtigsten Punkt an, Bildung muss eben in der Schule und so früh wie möglich ansetzen, in jeglichem Bereich. Und wenn der digitale Bereich bei uns mittlerweile so einen Stellenwert einnimmt, dass ja wirklich jeglicher Bereich unseres Lebens davon geprägt ist, dann muss das eben ein zentraler Bestandteil sein.

[00:20:30.300] – Maurice
Auf jeden Fall. Hast du denn schon mal Freundinnen oder Bekannte ermutigt, die vielleicht so an der Schwelle standen und nicht wussten, traue ich mich das, kann ich das? Das du gesagt hast, ja, du musst das probieren?

[00:20:41.340] – Franziska
Also ich bin sehr froh darüber, dass ich in meinem Studium und auch schon in der Schulzeit immer sehr starke weibliche Mentorinnen an der Seite hatte, die mich selber auch darin bestätigt haben, Dinge einfach mal auszuprobieren. Und natürlich ist es mir eine Herzensangelegenheit, das auch weiterzugeben. Also ich sehe mich mittlerweile auch als Mentorin.

[00:21:00.030] – Maurice
Bist du.

[00:21:01.240] – Franziska
Dankeschön. Und mache das auch sehr aktiv. Also ich hab ein Netzwerk, aus Studentinnen, mit denen ich mich da regelmäßig austausche, aber möchte eigentlich auch sehr gerne noch viel mehr, ja ich sag mal in früheren Jahren da ansetzen. Weil, ich glaube auch gerade die Ermutigung von jungen Frauen, das heißt Frauen, die sich irgendwie noch in der Schule befinden, so in der Mittel- und Oberstufe. Das ist ein toller, also ein toller Zeitpunkt, um hier eigentlich anzusetzen.

[00:21:23.400] – Maurice
Genau, und auch um spielerisch das ganze Thema kennenzulernen. Da gibt es ja auch mittlerweile tolle Technologien, diesen Calliope zum Beispiel, ich hoffe, ich spreche das richtig aus. Das ist so ein kleiner Technick Bausatz, den man, ja mit Point-and-Click-Mechanismen programmieren kann. Also verschiedene Sensoren und Aktoren können da miteinander verknüpft werden. Entweder blinken nur Lichter oder das Gerät hat noch andere Optionen und ist relativ günstig und wird an Schulen eingesetzt. Ich hab mal bei einem Event gesehen wie Kinder, die waren aber so im Bereich, würde sagen zwischen 9 und 12 Jahre, es war eine gemischte Gruppe, Jungs wie Mädchen. Sie haben Armbänder programmiert, also so LED Armbänder und die Blinksequenz und die Farbsequenz konnte angepasst werden und das war, also mit erwachsenen Augen könnte man das ja belächeln, aber die hatten so einen unfassbaren Spaß damit und auch eine Kreativität. Also, ja es war eine Freude das zu sehen.

[00:22:19.470] – Franziska
Ja, das ist sehr super. Also das sind ja genau diese Projekte, ja, die ich auch im Kopf habe. Es muss ja nicht immer etwas direkt programmiert werden, was dann einen riesigen Mehrwert schafft, sondern es geht auch erstmal darum, den Spaß an dieser Technologie für sich zu entdecken und überhaupt zu verstehen. Aha, was ist denn möglich, ne?

[00:22:37.830] – Maurice
Auf jeden Fall. Also das ist auch was, was man vielleicht sagen soll. Versucht nicht direkt mit dem selbstfahrenden Auto, das als erstes Projekt anzugehen, sondern irgendwelche kleinen Dinge, ne. Ob es jetzt das blinkende Armband ist, ob es irgendwie eure eigene Webseite ist, wo ihr selber die Urlaubsfotos drauf stellt, ob es eine App ist mit den letzten Karnevalsfotos oder ob ihr euch einfach nur, das ist ja auch technologisch getrieben, ob er euch hinsetzt und zum Beispiel euren eigenen Podcast aufnehmt und selber schneidet und produziert oder selber mit Musikerstellung anfangt. Elektronische Musikerstellung, da gibt es in allen Facetten, Farben und Formen, gibt es da Werkzeuge für. An dieser Stelle möchte ich ein Shout Out an das codiviti-Projektteam, um Irena und Marianne platzieren, ich packe die URL in die Shownotes zu dieser Podcast Episode. Da geht es ja um Kinder, insbesondere Mädchen im grundschulfähigen Alter oder etwas darüber hinaus, die eben an dieses Technologie-Thema herangeführt werden. Da hast du ja auch vor, ich glaube zwei oder drei Wochen, vorgesproche, willst du dazu kurz etwas sagen?

[00:23:42.840] – Franziska
Ja, super gerne. Du hast da ja tatsächlich die Verknüpfung hergestellt. Dafür nochmal vielen Dank. Weil ich finde, das ist ein wahnsinnig tolles Projekt, was die beiden da aufgebaut haben.

[00:23:52.180] – Maurice
Finde ich auch.

[00:23:53.060] – Franziska
Ich hatte eine, ja kleine Rolle da drin, indem ich eben mal vorgestellt habe, was ich gemacht habe im Studium und wie ich mich eben in meine Rolle als Data Scientist entwickelt habe. Und die Mädchen konnten dann mir Fragen dazu stellen und die waren wirklich super interessiert. Man hat gemerkt, dass die sich wirklich durch dieses Projekt für Technik begeistern konnten und es hieß dann auch so, wann legen wir endlich los? Da war ganz viel Power, sag ich mal dahinter. Und das sind eben genau die Projekte, auf die es glaube ich ankommt. Also natürlich geht es generell darum, alle jungen Menschen für Technologie zu begeistern, das will ich auch nochmal betonen. Aber ich hatte ja eben dieses Thema Sozialisierung angesprochen und es ist einfach für Mädchen doch noch ein bisschen schwieriger, mit dem Thema in Kontakt zu kommen und auch dieses nötige Selbstvertrauen da aufzubauen. Und ja, mit solchen Workshops kann da eben massiv viel bewirkt werden. Das finde ich einfach richtig klasse.

[00:24:46.000] – Maurice
Also die Workshops von codiviti, diese digitale Bildung für Kinder, das ist super wichtig. Ich habe, ich weiß nicht, wie deine Erfahrungen sind, aber ich habe auch festgestellt, dass oftmals die größten Blockaden in den Köpfen der Eltern oder der Lehrer lagen, also dass die ganz erstaunt waren, oh, mein Kind kann das, ne einfach, weil die sich selber nicht damit beschäftigt haben und vielleicht je nach Alter auch nicht mehr müssen. Und jetzt fangen die Kinder an, so spielerisch diese Levels zu bauen, Designs zu erstellen, Programme zu schreiben, Videos zu bearbeiten. Das ist auch heute auf jedem Handy möglich. Webseiten zu programmieren, dass die Eltern das gar nicht für möglich gehalten haben, sondern für schwarze Magie, die man nicht so einfach erlernen kann, ich weiß es nicht. Und ich glaube, wir haben hier in Deutschland einen großen Nachholbedarf für Mädchen wie auch für Jungs generell, das Thema Technologie und den kreativen Einsatz von Technologie, also das man selber etwas erschaffen kann. Diesen jungen Menschen näherzubringen, zu zeigen, was ist möglich, um auch als Hochtechnologieland zu bestehen. Weil andere Kulturen tun das und ich meine, man sieht es am Silicon Valley oder an, ja auch vielen, vielen Unternehmen, die jetzt aus China kommen, wie Tik Tok zum Beispiel oder ByteDance, also der Hersteller von Tik Tok, dass da auch ganz schön was im Umbruch ist.

[00:26:01.560] – Franziska
Ja, definitiv. Und ich glaube, es ist ja auch irgendwie der Auftrag eines Landes, seine, ja seine Gesellschaft so auszubilden, dass sie für diese Entwicklungen gewappnet ist und auch egal aus welchen gesellschaftlichen Strukturen sie eben kommen, es muss einfach eine, ja eine gewisse Grundausbildung hier passieren.

[00:26:20.630] – Maurice
Ich denke, es ist ganz wichtig, dass Menschen generell verstehen, wie Technologie funktioniert. Also was macht ein Computer? Warum ist er so schnell bei manchen Sachen und warum kann er einen Hund nicht von einer Katze unterscheiden? Oder warum ist das ein ganz, ganz schwieriges Problem für einen Computer, aber es ist kein schwieriges Problem, eine Milliarde Zahlen zu addieren, ne. Warum? Warum kommt das? Warum ist es so gelagert, wie es ist? Und dass man ein generell solides, technologisches Grundverständnis bekommt.

[00:26:47.040] – Franziska
Weil so kann man ja auch nur, also in einer transparenten Welt, die man auch versteht, kann man ja auch nur sinnvolle und mündige Entscheidungen treffen, ne.

[00:26:56.610] – Maurice
Ja, genau. Und die Angst geht ein bisschen verloren. Also manchmal, das ist auch schon ein bisschen traurig, sieht man Leute vor diesen moderneren Fahrkartenautomaten so ein bisschen verzweifeln, weil sie nicht mehr wissen, wie man das so bedient mit Touchscreen. Und da sitzt keiner mehr drin, der einem die richtige Fahrkarte anreichert, einfach weil es viel günstiger ist, nur so einen Automaten da hinzustellen. So, und für die Jungen ist es heute kein Problem, so ein Gerät zu bedienen und das ist total wichtig, dass das jeder kann. Nahezu alle Berufe werden in Zukunft den Einsatz digitaler Werkzeuge absolut voraussetzen. Also wir sind immer in so einer Blase und für uns ist das völlig normal, eine Videokonferenz durchzuführen, E-Mails zu schreiben, im Internet zu recherchieren, Präsentationen zu machen und die im Internet zu zeigen, mit digitaler Musik, mit digitalen Videos umzugehen, XING, LinkedIn für Jobbewerbungen und so zu benutzen. Das darf man nicht vergessen, dass das für uns total natürlich ist und für viele andere Menschen eben nicht.

[00:27:51.800] – Franziska
Ja, aber es ist durchaus noch erlernbar.

[00:27:54.010] – Maurice
Auf jeden Fall.

[00:27:55.670] – Franziska
Ich finde, für mich war jetzt die Corona Krise tatsächlich ein sehr, ja positives und irgendwie empowerndes Beispiel, weil einfach die Blockade auch Richtung Mobil Office, so Team Konferenzen, ne also Teams-Konferenzen, wo du wirklich dann digital miteinander sprichst. Das ist einfach gefallen durch, ja durch absoluten need das jetzt so einzuführen. Und viele haben ganz neue und bereichernde Elemente auch daran für sich entdecken können, ne.

[00:28:22.970] – Maurice
Auf jeden Fall. Also jung wie alt, ich meine, wenn man sich nicht besuchen kann und eine Videokonferenz die einzige Möglichkeit ist, dass man sich mit der Familie verknüpfen kann, dann geht’s auf einmal, ne. Oder wenn in vielen Unternehmen Homeoffice kein Thema ist, so aber die Leute nicht mehr in das Büro kommen dürfen, weil das Gesundheitsamt abgesperrt hat, dann geht’s auf einmal. Das ist immer, wenn etwas geschehen muss oder man andere Motivationen hat, dann geht es oft dann sehr schnell, ja. Das stimmt auf jeden Fall hoffnungsvoll. Also ich fasse nochmal zusammen, du bist mit deiner Berufsentscheidung auf jeden Fall zufrieden.

[00:28:56.540] – Franziska
Auf jeden Fall und ich möchte auch wirklich nochmal betonen, dass ich glaube, dass gerade eine super Zeit eigentlich für Frauen in der IT-Branche ist. Also ich habe bisher wirklich nur positive Erfahrungen gemacht, viele Mentoren gehabt, die mich gepusht haben und viel Bestätigung. Und das ist doch einfach eine schöne Sache.

[00:29:14.810] – Maurice
Ja, ich würde auch sagen, auch Männer haben in der IT eine gute Zeit oder gute Jobaussichten. Frauen natürlich auch. Und in diesem kollaborativen Umfeld, wer würde da nicht gerne arbeiten?

[00:29:26.210] – Franziska
Genauso sehe ich das auch.

[00:29:28.040] – Maurice
Und vielfältige Aufgaben gibt’s auch. Und Bedarf ist natürlich auch da.

[00:29:31.730] – Franziska
Mir bleibt vielleicht noch zu sagen, wirklich, an alle Frauen oder generell alle IT-Begeisterten da draußen. Wenn euch das Thema reizt schnuppert, einfach mal rein. Ihr werdet glaube ich begeistert werden, von dieser Welt. Und genau ansonsten dir Maurice, herzlichen Dank für die Einladung, das war ein super spannendes und ja, bereicherndes Gespräch. Danke.

[00:29:53.540] – Maurice
Ich gebe das gerne zurück. Vielen, vielen Dank, dass ich dich heute hier im Podcast haben darf. Wenn unsere Zuhörer Fragen haben oder Feedback zur Podcast Episode, können Sie uns gerne eine E-Mail schicken an podcast@skillbyte.de. Wir freuen uns immer über Bewertungen oder wenn ihr den Podcast abonniert. Empfehlt uns auch an eure Freunde und Kollegen weiter. Wenn ihr Informationen zu mehr spannenden Technologie-Themen haben möchtet, schaut auf skillbyte.de/blog vorbei. Franziska, ich wünsche dir noch einen schönen Abend.

[00:30:19.310] – Franziska
Dir auch, danke.

Maurice KnoppSkillbyte Podcast #32: Women in Tech / Frauen in der IT!
Mehr

Skillbyte Podcast #28: Cloud als Strategie, nicht als Technologie!

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Cloud als Strategie, nicht als Technologie!

// Inhalt //
01:20 – Intro Maurice Kemmann von Cloud-Mates.de
02:22 – Kosten von Cloudlösungen
03:09 – Möglichkeiten der Cloud-Migration
14:18 – Herausforderungen für Kunden bei der Cloud Migration
18:11 – Positive und negative Beispiele für Cloud Strategien aus echten Projekten
23:46 – Keine Angst vor Releases!
25:28 – Die Applikation als Basis für die Strategie / Cloud hat eine Lernkurve
27:29 – Retain und Retire inkl. Beispielen zum Datenschutz
34:26 – Prozesse, Betrieb und Monitoring
41:23 – Ausblick für zukünftige Cloud Strategien

Cloud Mates: https://www.cloud-mates.de/

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Wir haben bei einem Kunden, der auch noch aktuell in der Betreuung ist. Da kamen wir an, und die waren überzeugt Ja. Cloud Das ist das Meine, das wollen wir machen, da wollen wir hin. Aber es ist noch keine Strategie entwickelt worden. Wir sagen ja ganz klar Strategie, da hinzugehen. Ich glaube, da war eher mehr die Technik, das Interessante. Und von daher ist wenig Fokus darauf. Und wie bei allen Projekten, und da kann man jetzt in die allgemeine Projektsteuerung gehen, wenn ich keinen Fokus hab.

Wenn ich mir keine Ziele setze, wenn das eher so schwammig ist. Das geht schief. Herzlich willkommen zu unserer Podcast Episode Nr. 28 Cloud als Strategie, nicht als Technologie abonniert unseren Podcast. Wenn Ihr mehr spannende Themen aus dem Technologie Umfeld hören, möchtet ihr eine höhere Frage habt. Wir freuen uns immer sehr über eure Fragen, schreibt uns eine E-Mail an Podcasts D. Lasst uns eine positive Bewertung da und empfehlen weiter, wenn er euch gefällt. Das ist ganz, ganz wichtig für uns.

Ich freue mich ganz besonders auf meinen Studiogast, der ebenfalls Maurice heißt. Maurice Kemmann von Cloud Mates. Hallo Maurice, hallo schönen Abend.

Ich freue mich sehr auf dieses Gespräch, weil mit ihr habe ich ja wirklich ein Veteran in der Rechenzentrums. Planung, Durchführung im Betrieb heute hier mit ganz, ganz viel Erfahrung.

Ja, das kommt daher in 2000, angefangen mit Rechenzentren und ähnlichem. Uns darüber ja 16 Jahre, 17 Jahre bewegt. Dann halt später auch nochmal. Allerdings dann noch mehr. Also 13 Rechenzentren betreut und dabei so meinen Ausstieg gefunden. Und neuerdings sage ich Rechenzentrum adé zumindest im physischen Sinne und widme mich in den Clouds dieser Welt und vor allen Dingen aber dabei, das ja auch in einem Rechenzentrum betrieben wird.

Das ist ja ganz klar, das Cloud auch Rechenzentrum ist. Nur eben nicht das eigene dennauch.

Es ist kein Henson mehr, und ich muss keine Server mehr bestellen. Ich schreib ein bisschen Kohle und hab dann plötzlich eine VM oder sowas ist schon schon interessante Entwicklung. Ich sage mal generell auch von der ganzen Automatisierung her, ich hätte das gerne früher in meinen eigenen Rechenzentren gehabt. Aber naja, wir waren halt immer etwas kleiner als jetzt eine aways oder eine Microsoft oder Google.

Ich glaube, das gilt für die meisten Rechenzentrums Betreiber. Du hast ja dann direkten Einblick. Wie ist das denn von den Kosten für dich als Betreiber oder auch für die Endkunden, für die ihr ja Anwendungen oder Server gehostet habt, wird zu sagen Das ist überhaupt keine Frage, die Cloud ist immer günstiger, oder muss man da abwägen?

Also wenn man auf die Kosten schaut, da muss man schon sehr differenziert reinschauen. Okay, ich sag mal, wenn ich jetzt sehr weit bin, auf dem Weg in die Cloud zu gehen, so sehr alle Technologien alles, was es nutze, habe ich ein sehr großes Einsparungspotenzial. Aber letzten Endes ist das ja nicht die Welt, in der wir uns bewegen. Außerdem sind es Dadaab. Wir machen alles direkt für die Cloud. Wenn ich ein eigenes Rechenzentrum habe oder irgendwo was in Kolonisation hat, dann sieht die Welt natürlich ein bisschen anders aus.

Da ist nicht alles direkt klar.

Das heißt, eure Kunden sind sowieso so unterwegs, dass sie ein Rechenzentrum haben und neue Services neue Cloud Services nach und nach dazunehmen? Genau.

Also eigentlich sind es tatsächlich Migrations Kunden, die schon Vorteile sehen, für sich Benefiz herausgearbeitet haben, aber eigentlich nicht so genau wissen Wo fangen wir jetzt an, weil einfach das Thema auch sehr vielschichtig ist. Ich sage mal Ich persönlich bin jetzt mehr in der Arbeitswelt. Aber A-WM bietet 170, 180 Services an noch nicht aufsetzen kann. Da den überblick zu behalten, ist nicht so ganz einfach. Und den idealen Weg zu finden, ist auch nicht einfach ein Prozess.

Und das ist so der Bereich, in dem wir uns dann tummeln, wo wir dann reinkommen, wo wir unterstützen, unterstützen und diese Migration letztendlich mit den Kunden angehen. Was uns auch so ein bisschen zu dem Thema des heutigen Gesprächs führt. Weil wir ja gesagt haben, es ist eine Strategie weniger Technologie. Es ist natürlich auch eine Technologie.

Aber für den Kunden, den Endkunden in die Cloud gehen will, ist es eher eine strategische Entscheidung, weil es eben nicht nur um Outsourcing von Server Hardware geht, sondern viel mehr durch dieses Service Netzwerk, was ja um die einzelnen Cloud Komponenten entsteht.

Genau den größten Fehler, den man eigentlich machen kann, ist, dass man versucht ein klassisches Rechenzentrum eins zu eins abzubilden. Das ist die klassische Lyft. Entschlüpft, sagt man da neudeutsch zu. Und ja, das heißt, ich habe da eine VM, und ich habe Server. Bildet das genau so mit dem gleichen Aspekts auch wieder in der Cloud ab, und da muss man sagen Oder komme ich wieder zurück auf die Kosten? Das ist in aller Regel teurer, weil ich ja in der Cloud so Vorteile habe wie Pay as you go.

Also ich zahl das, was ich nutze. Aber im Rechenzentrum hab ich ja immer so eine 24 Stunden Nutzung auf die ganzen Specks nicht reserviert. Habe möchte das eins zu eins in der Cloud mache. Dann wird es einfach teurer, weil dafür, das ist nicht der Sinn hinter den klassischen klar.

Ja, das hab ich bei der Anwendungsentwicklung auch schon bemerkt, dass man im Grunde, das sie dieses Paradigma etwas verschiebt. Früher hat man gesagt Okay, die Datenbank ist eh da. Da kann man Abfragen machen ohne Ende. Und jetzt ist es schon so, dass man überlegt Wie mache ich deine Such Query? Oder schwanke ich sozusagen fünf Sekunden an Daten, macht dann einen Badge und schiebt das einmal durch? Statt 5000 Query mache ich dann eine. Anwendungen, die viel Datendurchsatz haben, kann es schon ein Unterschied machen für den Betrieb?

Genau. Es ist halt ein leichtes Umdenken. Es ist ja nicht so, dass ein technisch versierter Entwickler oder Administrator das alles komplett neue Geschichten sind. Aber wenn ich mich halt auch auf klauer stürze, dann hab ich einfach gewisse Möglichkeiten und Optimierungsmöglichkeiten. Und die nutzt man aber nicht nur bei Datenbanken. Das geht ja wirklich in alle Bereiche.

Also nochmal als Cloud maatz hilft Kunden und begleitet Kunden auch Henson bei dem Weg aus dem eigenen Rechenzentrum in die Cloud. Plus der Erstellung der Strategie. Was für Cloud Services machen denn in deinem Rechenzentrums so anwendungs zu Sinn? Und wie kannst du die optimal einsetzen? Genau.

Wir haben so eine Framework. Man kann es doch einfach ein Beratungs Ansatz nennen, wie wir halt vorgehen. Wir schauen uns natürlich erst mal an Was haben wir da für den Kunden? Was hat er an T. Das brechen wir halt runter. In aller Regel durchaus auf Applikationen, um zu schauen Okay. Was setzt dir ein? Wir versuchen, den Applications Runa ausfindig zu machen. Also hat die Hoheit über die Applikation Wer kann uns am meisten erzählen, um erst einmal zu sehen Okay, wie wird sie genutzt?

Welche Lernprozesse werden unterstützt? überhAUPT Welche Prozesse im Unternehmen werden durch die Software unterstützt? Welche Risiken existieren auch, wenn ich eine Applikation überfuhr? Als Beispiel, wenn ich ein Bin ich sehr Vertriebsleute ich bin, dann habe ich häufig ein crm-system, das sehr wichtig ist für meinen ganzen Vertrieb. Da sind alle Informationen drin, und hier hätte man sicherlich ein hohes Risiko bei einer Migration, wenn es denn schief gehen würde. Und das wird halt entsprechend beurteilt, wird festgehalten und auf Grund des Consulting im Vorfeld haben, wird dann letztendlich ein Plan entwickelt, wie man da vorgehen kann.

Das heißt, die Herausforderungen für eure Kunden sind an dieser Stelle ganz klar. Kritische Anwendungen dürfen während der Migration nicht ausfallen.

Genau, oder es muss ein sehr geringer Ausfall sein, also ein Gering. Man hat immer einen Ausfall, also spätestens dann, wenn ich halt umschalten von der bestehenden Applikation auf die neue Halts in der Cloud Umgebung. Aber sowas kann man natürlich gering halten. Man macht es entweder nachts oder am Wochenende, sodass man auch noch immer ein bisschen Zeit habe. Das Schöne ist aber dadurch, dass eine Migration ist, können wir den Hogg, eigentlich den Plouffe of Konzept, parallel zur bestehenden Umgebung aufbauen, und somit lässt sich das eigentlich ausgiebig testen.

Und wenn die Kunden dann einmal die Anwendungen in die Cloud verlagert haben, dann kann man ja mehrere Umgebungen hochfahren. Und ab dann sind die Deployment relativ einfach nachvollziehbar oder durchführbar. Ohne Ausfall?

Genau. Wir versuchen natürlich immer So sehen, ja können wir Sie hier wirklich automatisch wieder wie Staaten? Welche Abhängigkeiten sind dahinter? Das ist immer Teil der Planung und der Analyse. Wir haben letztendlich vom Ansatz her es wurde immer Six Artz genannt, also die 6, wonach so ein bisschen wie die Applikationen und Hosts eingeteilt werden. Das eine ist ein Request, dass es diesen Lyft in Shift Ich mache erst mal eine Eins zu eins übertragung. Das machen wir nicht besonders gerne, weil der Quick Win eigentlich nicht sehr hoch ist.

Also im Zweifelsfall habe ich vielleicht sogar noch höhere Kosten. Macht dann Sinn, wenn man einer eine Applikation oder eine Architektur erst mal kennenlernen muss und viele andere Systeme aber durchaus schon umziehen können, um dann alles umzuziehen. Da macht man halt ein Haus, aber es ist nicht der optimale Fall. Dann gibt es das, die Plattform an der Stelle, das sehr häufig bei Datenbanken stattfindet. Wir hatten eben schon mal das Thema Datenbank. Ich habe zum Beispiel ich sage jetzt mal meine Microsoft Scuol Datenbank, ich Aufsätze.

Ich musste mir da weiß nicht Enterprise Lizenz holen, aus welchen Gründen auch immer. Sie ist aber wenig belastet. Das ist ein Paradebeispiel dafür, dass ich dann zum Beispiel erst auf Aerts Datenbank Service umstellte, wo ich halt nicht mehr eine VM Map oder physischen Server, auf der die Datenbank mit der kompletten Lizenz, sondern ich hatte eine Datenbank Service und zahle per Transaktion. Und leider ist es häufig so, dass unsere Kunden nicht wissen, wieviel Transaktionen pro Sekunde oder so machen.

Da finden wir im Zweifelsfall für sie raus. Das ist dann in der Datenbank. Scuol wird über Scuol gemanagt, also steht auch da drin. Hat man eine Datenbank admin vor Ort, dann weiß er das. Und dann kann man schon mal entscheiden Ist das zum Beispiel eine Möglichkeit der Umstellung? Dafür gibts dann auch Migrations Tools. Sowas lässt sich sehr sehr gut machen und das ist etwas, was ich so als Cloud verstehe. Pay as you go. Ich zahl so viele Transaktionen wie ich habe.

Aber muss man natürlich schauen als Softwareentwickler. Wenn man dorthin geht, dann achtet man natürlich drauf, dass eine eine Suche oder das Abrufen von Daten einfach nicht so kostenintensiv ist.

Sprich Ich hab jetzt nicht so viele verschiedene Abfragen dahinter, um zu einem Ergebnis zu kommen oder das man crasht, das man wiederkehrende Abfragen crasht für einen gewissen Zeitraum das Genner mit zum Kiewel just z.B.. Und nicht jedes Mal die Datenbank abfragt. Genau das war schon bei hochbelasteten Datenbanken, vor allen Dingen bei größeren Firmen ist das auf jeden Fall zu empfehlen.

Ganz klar Per Datenbank ist ein eigener Themenkomplex Wahl. Es gibt ja, du hast es angesprochen Dorsts in einem Rechenzentrum hast du den Server mit der installierten Datenbank plus Lizenz vor oder hältst du vor meinetwegen auch mehrere Datenbanken. Und in der Cloud hast du jetzt unterschiedliche Möglichkeiten. Entweder du fährst da auf einer VM diese Software hoch. Lift ein Schiff, das ist sozusagen die einfachste Form. Aber da profitiert man am wenigsten von. Oder man nimmt so ein Scuol Service, der ja von den Cloud Providern schon angeboten wird.

Also wo man im Grunde eine global, also weltweit verteilte Datenbank erhält, die dann Scuol API davor hat, die man einfach ansprechen kann. Und man bezahlt pro Transaktion sehr, sehr wenig und die Volumina sind auch sehr groß. Das muss man dann gucken, wie sich das lohnt oder wie die Kosten sind. Und dann hast du nichts mehr zu tun mit Software Maintenance, also Updates installieren, das Betriebssystem aktuell zu halten, die Datenbank Software aktuell zu halten, mehr Speicherplatz irgendwann hinzuzufügen, weil die Datenbank wächst.

Einfach Es kostet zwar mehr Geld, aber man muss. Es muss keiner mehr rausfahren, um die Festplatte zu vergrößern, die die Datenbank zu stoppen, die Festplatte vergrößern, die Datenbank wieder zu starten und auf der vergrößerten Festplatte die Anwendung fortführen zu lassen, sondern das geht alles dynamisch. Man bezahlt einfach nur für den genutzten Speicherplatz für die Transaktionen und muss sich im Grunde nicht um die Wartung der Datenbank kümmern.

Genau das fällt tatsächlich fast komplett weg. Wir bieten hier über das reine Umstellen natürlich auch noch so Managed Services an, auch Datenbank Services reinfallen. Das ist immer dann die Frage, ob der Kunde einen eigenen DBA hat. Brauchen Sie das nicht zu machen? Der kann diese Aufgaben locker übernehmen. Aber die Erfahrung zeigt, dass selbst in relativ großen Firmen ist das Datenbanken Know how relativ gering, weil es vorher auch getanzt war. Oder man hat halt einfach gesagt Naja, gut, was sollen wir da schon großartig machen, sodass Parameter wie hydrazin oder sowas nicht beobachtet werden.

Wenn man das haben möchte, dann können wir das auch für Kunden übernehmen, das man einfach sagen kann. Bada. So stelle ich fest, ob die Software auch optimal arbeitet. Das ist zwar schön, dass ich eine Datenbank habe, die fast beliebig skaliert. Aber es entbindet natürlich nicht davon, vernünftige Software darauf zu entwickeln. Und absolut, da können wir natürlich noch unterstützen, was von den 6er gesprochen.

Ich glaube, drei hattest du schon genannt, aber es war das letzte Mal. Die Plattform hat diese Transformation in eine neue Plattform. Es gibt jetzt das Repertoire. Das ist letztendlich auch ein anderes lizenzmodell, also dass man einfach sagt, das passt auch zur Plattform. Bei einer Datenbank, welche Datenbank Lizenz vorhatte und jetzt offen, da hat man Service wie vielleicht auch das lizenzmodell. Letztendlich ja. Ich hab nämlich mit Lizenzen gar nichts mehr am Hut und muss nun nicht mehr alle paar Jahre erneuern und Support und sonstiges dazu holen.

Hat natürlich auch mal leichte Architektur änderungen, aber das betrachtet man halt auch nochmal. Das kann durchaus auch sein, dass es einfach das typische Beispiel auch immer mal wieder die originale Datenbank Oracle um ein anderes Produkt zu nennen. Meine lizensierung fällt auf, weil die auf Jahres basieren und jetzt die ich vor der Entscheidung Soll ich etwas Neues kaufen oder ändert? Irgendwie hat man diese Möglichkeiten natürlich auch in der Cloud. Das gleiche Geld mit fast allen Elitz oder wichtigen Dezenz Anbietern muss man aber gegebenenfalls einfach überprüfen.

Also es funktioniert nicht mit allem. Das ist nicht so die Lösung für alles. Aber da helfen wir natürlich.

Jetzt haben wir viel über Datenbanken gesprochen. Wer sind denn eure Kunden und was haben die für Herausforderungen? Gibt es da so? Muss da, wo du sagen kannst Ja, das ist ein schwerer Brocken für die meisten Kunden? Oder ist es hochgradig individuell?

Sowohl als auch individuell. Natürlich, weil alle Kunden haben unterschiedliche Schwerpunkte. Auch was risiko-management und so weiter angeht. Aber letztendlich Datenbank ist immer cih für die Anwendung. Aber die größte Herausforderung sind natürlich tatsächlich Anwendungen, die so gar nicht in die Cloud passen. Die, sagen wir mal, eher altbacken sind erp-systeme, die teilweise. Ich übertreibe mal gern ein bisschen noch mit dos Lückenfüller rüberkommen. Du hast es natürlich teilweise schwierig.

An der Stelle gibt es das Image ist auf aways gar nicht. Ich muss ehrlich sagen Prinzipiell würden wir das wahrscheinlich hinkriegen. Ich weiß es aber tatsächlich.

Auch für die an diese Kunden ist gedacht, wie das mit Security aussieht. Das mag ich mir gar nicht auszumalen.

Es wird auch weniger an der Stelle. Aber das sind so diese klassischen Kunden für ein Refektorium, das heißt neue Architektur. Ich such mir eine neue Plattform des software-plattform, denn, würde man sagen Pass auf, entweder man sucht. Ein Produkt am Markt, das existent ist, was unseren und seinen Belangen da hinreichendes, ist auch für die Cloud. Ich sag mal, aktuellere Produkte werden fast alle in Richtung Cloud entwickelt. Muss man ja nicht sagen, oder? Aber das ist natürlich dann der Idealfall.

Ich habe eine selbst entwickelte Software und suche mir halt eine Softwareschmiede meines Vertrauens, die mir das direkt laut Radi umsetzen. Das ist natürlich dann der höchste Benefit. Es gibt sehr, sehr gute Programmierer, schmieden dazu. Aber das hängt natürlich immer Kosten-Nutzen-Verhältnis in West. Also ich investiere natürlich dann wieder für die nächsten Jahre. Das muss dann gerade passen. Aber Factoring Ansatz ist der natürlich, der den höchsten Nutzwert eigentlich bringt, weil ich eine veraltete Architektur in aller Regel habe und die in eine komplett neue überführen und dort natürlich aus allen Vorteilen dann letztendlich profitieren kann.

Teichert Jetzt gedacht, das ist fast bei, wenn man hoffnungslos veraltete Software hat. Wie? Man muss eine Service Lösung nehmen, also eine Software as a Service Lösung, und dann irgendwie schauen, dass man die Daten da rein importiert bekommt, weil diesen Rückstand sehr schwer, dann aufzuholen.

Da geht es dann los mit der individuellen Betrachtung. Das kann sehr unterschiedlich sein. Auch ich sage mal eben Banken Umfeld trifft man häufig noch auf Termühlen Emulation im Frontend, komischerweise aber dann in einem Fensterchen mittlerweile drin sind und und, und, und und. Im Backend ist zwar auch häufig auf mainframe basieren, aber dennoch schon neuere Architektur zu finden. Das hat dann aber ich weiß nicht irgendwelche Cross Kompatibilität, die gehalten werden müssen. Da bin ich da manchmal auch überfragt.

Bankkunden Wer noch nicht überführt, muss ich auch der Ehrlichkeit sagen. Ich kenne halt nur, weil wir früher viel mit Banken Kunden zu tun hatten. Da gilt es dann zu überlegen Wie geht man vor? Aber hier mehr schriftlich vorgehen, denn so eine Entwicklung ist ja auch ein Prozess. Die sind dann eher ein, zwei Jahre, je nach Größe und Inhalt der Software. Das muss man sich halt wirklich genau angucken. Aber der Nutzwert ist tatsächlich der aus meiner Sicht höchste und ist natürlich ein optimaler Weg, den zu gehen, weil man es dann state of the art anfangen.

Das halte ich so raus. Eure Kunden sind Mittelständler, aber auch Großunternehmen in allen Lagen der Technik. So kann sein, dass sie 20 Jahre alte Technik haben. Es kann sein, dass sie relativ modern unterwegs sind.

Genau das ist wirklich ganz breitgefächert. Macht eigentlich auch den Spaß aus, weil man natürlich alles nur Nullen und Einsen, aber immer neu zusammengesetzt und dadurch natürlich interessanter, immer neue Herausforderungen. Die Kunst ist es natürlich, aus Kundensicht den besten Weg zu finden, was natürlich auch immer Kostenfaktor und so weiter.

Hast du ein Beispiel für ein Projekt, was du einfach mal ohne den kundennamen zu nennen, was besonders gut funktioniert hat? Oder vielleicht doch etwas, was nicht besonders gut funktioniert hat? Das ist ja auch immer ganz interessant für unsere Zuhörer, das man zeigt ok. Das hat überhaupt nicht geklappt. Wenn ihr in so einer Situation seid, überlegt nochmal, ob das richtige Weg ist und holt euch vorher Hilfe. Und ja, natürlich auch positive Beispiele, dass man sagt Okay, in deren Constellation lohnt sich das auf jeden Fall.

Und man hat sehr, sehr wenig Widerstände zu überwinden, vielleicht etwas Positives und ein negatives Beispiel.

Ich fange mal mit einem negativen an, weil sich daraus durchaus positive Ansätze zumindest definieren lassen. Wir haben bei einem Kunden, der auch noch aktuell in der Betreuung ist. Da kamen wir an und waren überzeugt Ja, Cloud, das ist das Meine, das wollen wir machen, das wollen wir hin. Aber es ist noch keine Strategie entwickelt worden. Wir sagen ja ganz klar Strategie, da hinzugehen. Ich glaube, da war eher mehr die Technik, das Interessante.

Und von daher ist wenig Fokus darauf. Und wie bei allen Projekten, und da kann man jetzt in die allgemeine Projektsteuerung gehen, wenn ich keinen Fokus hab, wenn ich mir keine Ziele setze. Wenn das eher so schwammig ist. Das geht schief, und hier sind wir aber auch uns an, weil wir am Anfang dachten Gut, ja, weil man vorgehen. Man will jetzt erst mal was kennenlernen, und dann gehts weiter. Aber vielleicht auch Coruna bedingt.

Ist das jetzt so ein bisschen aus dem Fokus geraten und ist jetzt so eine never ending story? Hier wird man nochmal neuen Anlauf brauchen, einen Plan aufstellen und einfach mal so sagen Okay, wie ist das? Fangen wir doch mal mit Applikationen an. Gerade wenn ich es kennenlernen will. Wie funktioniert? Klar? Welche Möglichkeiten sind da Applikationen mit wenig Risiko dabei, die ich parallel gut aufziehen kann? Und dann kann die IT-Abteilung des Kunden so wie wir. Man kann sich annähern, findet den Weg und findet halt auch die Rezepte, wie wir die Umsetzung machen wollen, die Migrationen machen wollen, sondern das ist so der negative Aspekt, der aber eigentlich wieder ganz klar vor Augen führt.

Bitte bleib bei diesen Frameworks, wie wir sie auch vorgeben.

Also Fokus und Fokus auf ein Projekt haben. Und auch ich sag mal ehrgeizige Ziele sich vornehmen und dann noch bei der Stange bleiben. Das ist ein ganz wichtiges Voraussetzung für ein erfolgreiches Projekt.

Definitiv. Da entgegen haben wir einen anderen Kunden. Die beiden kann man ganz gut vergleichen, weil erste Berührungspunkte mit der Cloud. Mittelständische Unternehmen, in Deutschland ansässig und hier? Um? Ja, anfangs um die Lösung für Back up Szenarien notfalls Szenarien unternehmen. Und die hatte man erstmal ein klares Ziel definiert, hat gesagt Okay, die anderen Dinge, die finden wir sexy. Aber mit dem wollen wir uns jetzt noch nicht beschäftigen. Wir haben jetzt ein Primärziel, und das haben wir dann umgesetzt.

Auch sehr, sehr schnell. Tatsächlich konnten wir denn den Plouffe auf Konzert machen. Da haben wir ihn dann innerhalb weniger Tage direkt in eine produktive Umgebung überführt und konnten eigentlich so den Kunden sofort zufriedenstellen. Und er sagt Ja, und so wollen wir weiter vorgehen. Wir möchten jetzt gerne, dass das Ablösen, wir neue Dinge identifiziert. Und das wandert jetzt auch in die Cloud. Und da hat einer meines Erachtens schon sehr viel Projekt Erfahrung einfach gehabt, sodass er eigentlich unsere Dinge direkt mit aufgenommen hat und auch so vorgeht.

Und für uns ist das Interessante Ja, wir wachsen mit dem Kunden. Und wir verstehen ihn immer mehr und können auch die Applikationen, die dahinter sind, besser verstehen und somit auch vielleicht Risiken aus unserer Sicht einschätzen. Es gibt auch immer Applikationen. Wo ich den Kunden empfehle, würde ich nicht machen. Also, wenn ich zum Beispiel nicht bereit, denn eine alte Software abzulösen, und wenn ich schlechte Bandbreiten habe, sind zig Faktoren erreichbar. Und noch weiß nicht eine funktionierende Abteilung.

Alles ist gut. Dann würde ich auch sagen Passt auf, dass es. Dieses partielle Bausteinen würde ich jetzt nicht überführen, zumindest jetzt noch nicht.

Never change running system.

Mehr ja. Erst wenn die Zeit gekommen ist, wenn man sagt Ja, ich will die Software jetzt ablösen, dann würde man natürlich wieder auf die neuen Technologien. Aber solange das System Apple Running ist und es keine weiteren Quicken oder Winds gibt, also Kosteneinsparung, Effizienzsteigerungen, was auch immer, dann muss man natürlich auch davon abraten. Und hier war es ganz einfach ein Kunde Mittelschiff, sehr bodenständig. Ich nenne sie immer Schnittchen, Kunden, weil da gibt’s mal Mittagessen, gibt’s immer Schnittchen drauf, und das meine ich auch gar nicht negativ.

Ich finde das. Die wissen genau, was sie wollen und sehen wollen und dass das sehr positiv verlaufen. Muss man sagen, da sagst du was.

Ich hab auch das Gefühl, dass beim mittelständischen Unternehmen der Fokus sehr hoch ist oder tendenziell höher ist, weil ich weiß nicht, weil die einfach mehr darauf angewiesen sind, dass ihre Kerne Prozesse funktionieren müssen, damit sie Geld verdienen und sie nicht so viel eher weiche Ziele haben, sondern meistens ist es ja ein Unternehmen, das genau um einen Zweck gebaut ist. Und alles, was nicht diesem Zweck dient, wird irgendwie rausgeschmissen. Und von daher ist immer sehr schnell klar, in welche Richtung es gehen muss.

Genau so kann ich so unterschreiben, wobei man immer noch eine Sache beobachten muss. Das ist die IT-Abteilung. Das ist immer schön, wenn der Chef oder so sagt Ja, das hört sich gut an, das wollen wir machen. Aber es ist ja eine ganze, ist eine Strategie. Und Strategie muss getragen werden von den Leuten, die sie hinterher auch umsetzen. Das ist dann in aller Regel ja die Abteilung, und die müssen natürlich auch mitziehen. Und wenn man hier neugierig ist, wenn man auch Spaß hat an Technik?

Adam begeistert auch klar und einfach die Automatisierung Unmöglichkeiten. Ich habe die Reporting Monitor. Ich habe so viele Daten nicht auswerten kann, wenn ich mir denn vernünftige kpis schaffe. Also, ich habe wirklich jede Menge Benefiz, aber das macht doch wirklich Spaß.

Das ist auch so eine, merke ich manchmal. Es gibt zum manche Hürden bei meinen Z. Gerade was Fury ließ es angeht, dass man sagt Ja, dann fährst du die Umgebung zweimal hoch und schalte ist um. Da brauchst du keine Angst mehr, families zu haben, und wenn das nicht klappt, nimmst du das alte Image. Das ist ne abschottet und fest, das hat wieder hoch. Und damit Kybernetische ist das ja noch dynamischer. Aber definitiv, dass man wirklich da.

Das freut mich immer ganz besonders, dass man dann diese Aha-Effekt sieht, wenn die Leute das es erst mal machen. Früher hatten wir ein Release alle drei Monate, weil dann mussten alle nachts in die Firma, oder die Leute mussten nachts in die Firma, und alle haben gebetet und sich bei ihren Familien abgemeldet für zwei Tage. Und dann wurde mit Biegen und Brechen das neue Relais ausgespielt. Und jetzt kann du einfach so machen und haßten viel geringeres Risiko, weil du zurückrollen kannst.

Wenn du merkst, das neue Feature braucht mehr CPU Power, kannst du dich einfach hinzu buchen, und man ist halt einfach flexibler.

Wo du es auch anspreche, sobald ich mich mit Thematiken die micro Service ist und so weiter beschäftige, was natürlich meistens bei diesem Refektorium Einsatz kommt. Ich mache etwas neu und ich gehe direkt in diese Welt. Taugt da wirklich ein A? Ich kann hier ganz modular abdecken. Ich muss nicht mehr dieses Jahres Mammut Update machen, wie du geschrieben hast. Alle gehen mit Essen und Trinken für zwei Tage ins Exil und in die Firmen. Quarantäne? Genau.

Ich war einfach Meine einzelne Micro Service tauscht die aus, die kommunizieren nur noch über Schnittstellen. Sie hatten einen hohen Grad von Testmarkt an einer Stelle, und alles wird doch deutlich entspannter oder planbarer und planbarer, was natürlich auch zur Entspannung beiträgt.

Was ich bei dir super finde, ist Du gehst von konkreten Nutzungs Szenarien aus oder von der Applikation. Und schaust Was kann die Cloud mir bieten im Bezug auf diese Applikation? Du schaust sie die Applikationen an, und du gehst nicht von diesem Cloud Hype aus. Also ganz oft in der Werbe, Literatur oder im Internet. Tanja Wie du gesagt hast. Cloud hat 170 Services, und Server lässt und man braucht sich um nichts mehr kümmern. Ja, ja, das ist schon wahr.

Aber man erkauft sich dadurch. Das sind sozusagen die positiven Sachen. Aber man erkauft sich dadurch andere Paradigmen, nach denen man entwickeln muss, die man erst mal lernen muss. Das Thema Stat ist bei Cloud net Anwendungen ganz anders. Da muss man das behandeln als mit Prammers Anwendungen und auch Parallelisierung von Entwicklung, was ja schon immer eine Herausforderung war. Also dass mehrere Freds parallel sich nicht in die Quere kommen und die Anwendung quasi horizontal skaliert. Da muss die Anwendung darauf vorbereitet sein.

Und das ist auch nicht trivial, so eine Architektur aufzusetzen. Und das ist sozusagen der Preis. Der Preis, den man bei einer Cloud Anwendung hat? Definitiv. Das ist nicht immer notwendig. Deswegen auch meine ganz klare Aussage Es ist eine Strategie. Die Services und die konkreten Dinge, das sind die Technologien, die man einsetzen kann, die man nutzen kann. Aber es ist eine Strategie, und wir sagen halt ja. Die Strategie kann durchaus auch beinhalten Ich gehe nicht zu 100 Prozent in die Cloud, sondern nur zu 70 Prozent, was auch immer.

Aber man legt sich da fest, zumindest für einen gewissen Zeitstrahl. Und ich sage man Darüber hinaus wird sowieso wieder was Neues entwickeln. Oder die ganzen Cloud-Anbieter sind so effektiv dabei neue Services erschaffen. In drei Jahren gibts vielleicht wieder doppelt so viel. Und vielleicht trifft dann etwas, was ich machen will, dann besser. Dann ist da ein Service. Ich jetzt zurzeit noch nicht oder unzureichend habe. Und deswegen ist das auch durchaus ein langwieriger Prozess, der immer immer wieder hinterfragt werden muss.

Ich bin nicht sicher, ob du schon alle 6 er gesprochen hast. Ich glaube ihr, wir haben noch zwei übrig. Wobei den einen haben wir ja schon so angeschnitten. Das sind Applikationen, die tatsächlich nicht im migriert werden können. Aus diversen Gründen sei es, dass man Applikationen auch so lang betreiben will, bis sie End of Life ist, und erst dann sich Gedanken macht, dass das Risiko der Migration ist zu hoch. Oder es gibt halt auch ganz einfach politische Compliance.

Wie auch immer Gründe, wo man sagt Nein, die sollen weiter hier und in unserem Rechenzentrum oder bei unserem Rechenzentrum stehen. Und ich sage Je größer eine Umgebung ist, eine IT-Landschaft, desto mehr hat man auch durchaus Applikationen, die darunter fallen. Mackensen Nützliches ist und was sehr häufig vergessen wird, das ist Retailer. Das heisst nicht oder kaum genutzte Applikationen, die einfach weggeschafft werden. Was ist das? Gibts sowas überhaupt? Natürlich, weil fast jeder hat in seinem Rechenzentrum plötzlich VMware oder einen anderen hypervisor laufen.

Schafft sich VMs ohne Ende? Und ja, dann wird halt noch ein Server hin zugestellt, wenn er nicht reicht. Und hier ein bisschen stolz, weil in Anführungszeichen. Kostja nichts. Es wird ja immer nur der Preis für eine Hardware oder für Festplatten gesehen. Wird ja weniger. Ich sag mal, das ganze Operations dahinter gesehen. Und wenn ich dann aber VMs habe, dieser ganze Park ist gewachsen, und ich nutze dann aber nichts davon. Und ich rede ja durchaus von 30 Prozent und manchmal mehr an Ressourcen, die nicht regelmäßig genutzt werden.

Dann Retailer zum Einsatz, und hier haben wir häufig auch ein Quick Win. Also einfach sagen, was? Man könnte ja einfach ausstellen. Wir finden keinen, der dafür verantwortlich ist, weil die läuft seit Jahren. Aber der eingerichtet ist nicht mehr da. Keiner kümmert sich drum. Es werden nur noch abdeckte gepflegt. Aber seit 18 Monaten hat sich niemand eingeloggt. Aber man hat tatsächlich diesen Fall, und da sagen wir ganz einfach abschalten. Das Risiko ist gering.

Und wenn, dann schreit einer. Aber dadurch ist das Risiko gering, dass es das nicht, und das ist durchaus ein Einsparungspotenzial. Und es ist auch einer der ersten ersten, die wir tatsächlich versuchen zu rauszufinden, weil alles, was ich retailer, muss ich nicht erst migrieren, weil das gehört natürlich auch dazu, jetzt nicht in unnötigen Olver zu schaffen.

Also erst mal den Papierkorb rausbringen, sozusagen, um dann zu sehen, was übrig bleibt.

Das ist aber ein klassisches Thema, was Virtualisierung angeht. Das sind meistens dann VMs und gerade auch in größeren Unternehmen, die ja Richtlinien haben. Die kennen dann nur drei Grössen von VM sag ich jetzt mal, die haben je die große, die mittlere und die kleine. Schaut man sich das mal statistisch an, irgendwie kaum kleiner dabei. Fast alles ist mittel und gross, weil irgendein Software-Hersteller mal gesagt hat Ja, wir brauchen aber mindestens so viel und so unser Programm.

Und Deutsch? Und ja, aber dann halt wirklich nicht mehr genutzt, sondern ist relativ viel IT Ressource da reingesteckt. Das ist wirklich einer der häufigsten Punkte in den Eitan, die nicht so gepflegt werden. Es gibt auch die anderen Beispiele. Wo eine Abteilung. Hinterher ist auch Ich sage mal Lebenszyklen für die VMs festlegt. Aber wenn ich es sehr positiv ausdrücken würde, hält sich das ungefähr die Waage. Aus dem Bauch heraus würde ich sagen, dass wir mehr irritieren, als dass da ordentlich gepflegt wird.

Das ist, glaube ich, nicht zu unterschätzen. Auch da fällt mir noch etwas ein. Denn ich habe bei einem aktuellen Kunden das Problem, dass er Daten in die Cloud migrieren möchte, aber er selber mit seinen Endkunden einen Vertrag hat. Steht das kein nicht EU Mitarbeiter diese Daten je anguckt? So, jetzt leite ich Daten in die Cloud und jetzt theoretisch der Cloud Provider oder plant dies zu tun. Der Cloud Provider könnte ja jetzt darauf zugreifen. Kann er nicht in jedem Fall.

Je nachdem, ob ich das verschlüsseln oder wie ich das verschlüsseln. Aber das ist natürlich auch ein Thema, das man sagt Ja, im Moment. Ich kann nicht einfach alles in die Cloud laden, weil der Cloud Provider mehr unter anderem nicht garantieren kann, dass nur EU-Bürger auf diese Daten Zugriff haben.

Genau das ist ein typisches Compliance Thema, was auch je nach Unternehmen relativ hoch aufgänge ist. Auch zu Recht. Da bin ich auch ein absoluter Befürworter, das zu durchleuchten. Man muss halt sehen, erst einmal. Generell kann man erst mal sagen So häufig ist gefordert Das muss auf europäischen oder auf deutschen Server liegen. Das kann ich einschränken. Also ich kann sagen meine, ich benutze nur Server in Frankfurt oder nutze Server in Europa. Das kann ich natürlich schon machen.

Ich kann die Festplatten verschlüsseln, ich kann alles Mögliche verschlüsseln. Ich kann mir Key Management Server buchen, aber das muss man klar sagen, je nach Schutz Bedarf, Feststellung. Auf meine Daten all diese Infrastrukturen kommen ja von dem Cloud Provider Provider sitzt in Amerika und ich sag mal, wenn man Böses denkt, kann man natürlich sagen Na gut, er hat immer eine Backdoor oder er hat die Festplatte verschlüsselt.

Aber der Schlüssel liegt ja auch irgendwo bei dem Provider. Genau, aber letztendlich das Einfachste für ihn wäre. Ich habe halt einfach sowieso den Super Master Ki, und das ist meine meine Backdoor an der Stelle. Da muss man sehr differenziert reingehen. Also, da komme ich so ein bisschen aus der Alten Welt, wo ich mich halt auch sehr viel mit alten grundschutz um IT-Sicherheit Compliance beschäftigt habe. Man macht ja tatsächlich schutzbedürftig Feststellung, wonach man guckt Was hab ich für Daten?

Wo liegen diese Daten? Also z.B. ich bleibe beim Beispiel. Abends hab ich zum Beispiel Account Daten, die liegen durchaus auch in den USA. Das lässt sich nicht verhindern. Das ist halt so eingestellt, wenn ich eine Datenbank in Deutschland suche. Da hat man Service oder eine Weinbuch. Da hat man die Daten liegen natürlich auf europäischen Server. Aber spätestens also Mitarbeiter hat nicht. Erst einmal hat kein Interesse daran, auf die Daten zuzugehen. Aber gerade in der Datenbank rufe ich mir eine Datenbank admin oder an Spezialisten von AVM.

Habe ich keinen Einfluss da drauf? Zumindest im ersten Schritt nicht. Woher der kommt? Die werden natürlich immer aus meiner Zeitzone holen. Es wird in aller Regel europäisch sein, aber hier sind sicherlich Dinge zu betrachten. Da muss man dann ja, das ist die differenzierte Betrachtung. Und wenn es da Zweifel gibt, dann würden wir auch eher sagen Pass auf, Meedia Das Risiko nicht. Man kann es natürlich auch umgehen, aber da muss Hellwege Software mitspielen. Nämlich nämlich eigene Verschlüsselung, Auslösung und Topliga.

Das ich sage jetzt mal das triviales Beispiel wäre jetzt eine Datei Server oder Server. Ich lebt halt nur genug Budget verschlüsselte Dateien ab. Die Schlüssel liegen hier bei mir in Deutschland. Dann ist es mit vertretbarem Aufwand selbst auch für Geheimdienste nach besten Wissen und Gewissen nicht möglich, darauf zuzugreifen. Und da hätte man Sicherheit. Aber man muss ja auch ehrlich sagen Welche Applikation schafft das durchgehend? Von daher ist hier ein kritischer Umgang damit. Ist auf jeden Fall auch von unserer Seite erwünscht, wird gefördert und sollte auf jeden Fall immer beibehalten werden.

Wie ist es denn, wenn die Anwendungen in die Cloud migriert sind und jetzt betrieben werden? Man hat ja sehr viele Möglichkeiten, eine Anwendung zu monitoren, entweder durch Shakes oder durch eingebaute ablösungen, einfach um die ganze Landschaft zu monitoren.

Unterstützt ja, dabei auch. Ja, das ist ein sehr wichtiger Aspekt, der häufig auch missverstanden. Zwar bieten die Provider jede Menge Services und so weiter an, und dann entsteht häufig der Eindruck Naja, das eigentliche Operations, der eigentliche Betrieb, läuft über den Cloud Weida oder wie auch immer, das ist tatsächlich nicht vollständig richtig. Also ich sage jetzt mal kleiner mittelständischer Betrieb fünf Arbeitsplätze, ruft bei KWS an und sagte Ich habe ein Problem, sagte er. Gut an, schmeiß mal hier ordentlich Geld ein, und dann schauen wir uns das ganze Thema mal an.

Bis das gelöst ist, haben hochrangige Spezialisten diesen supertoll. Aber der kennt den Kunden nicht, erkennt nichts von der Umgebung. Das heißt, die Wahrscheinlichkeit, dass er zielgerichtet schnell helfen kann, ist relativ gering. Da kommen wir natürlich ins Spiel. Wir richten zusammen mit den Kunden anhand seiner vorgegebenen kpis, oder? Wir vorschlagen Monitoring, ein Kontrolle und wir reagieren dann darauf. Das ist natürlich eine maschinenteilen aus Weggucken oder ein Service fällt aus. Wir gucken das dann wieder an, Staat kommt aber halt auch so Dinge aus der Datenbank sind schlechte Werte.

Wir gucken mal, woran es liegen könnte. Wir haben im Netz komisches Verhalten. Irgendwas ist hier langsam. Dann fällt das halt auf. Darum kümmern wir uns ihre Pforten natürlich auch. Wir sind also unsere Welt des Operations, des Betriebs. Hat sich schon etwas verändert? Wir müssen noch mehr Reportern, eigentlich, aber wir haben auch mehr Daten. Die Reporter können also deutlich mehr, als wir teilweise früher hatten, und können dem Kunden halt auf der Basis kennenlernen und können auf der Basis Vorschläge machen und optimieren.

Der Betrieb, die überführung in einen Betrieb, ist heute sehr, sehr wichtig für uns. Aber das kennen wir als Firma gar nicht anders. Das haben wir früher mit eigenen Rechenzentren genauso gemacht. Die Arbeit mit der IT-Abteilung des Kunden zusammen beschert Responsibility. Guck mal, wer ist für was zuständig? Und danach wird das aufgetrennt. Und das funktioniert eigentlich sehr, sehr gut und insbesondere, wenn sich das mal eingespielt hat. Das ist auch ein Prozess, der braucht von wenigen Tagen bis in einem Jahr von einer Größe ab, denn den ganzen Umgebung.

Da stimmt sich das ein, und ich glaube, am Ende des Tages hat man dann schon sehr, sehr guten an der Stelle. Genau.

Also in der Cloud. Ist es generell so, dass Hardware fehlt? Ja, sollten nicht mehr auftreten. Aber natürlich kann es immer noch in der Anwendung selber Probleme geben, auf die dann reagiert werden muss. Also Beispiel Irgendwas ist nicht richtig gesichert, und statt eines ein Megabit profil Bildes lädt irgendjemand 50 Megabit hoch oder so was dann zu einem Problem wird an anderen Stelle?

Ja, es gibt auch so klassische Szenarien. Ich habe im Auto Stellingen eingerichtet. Das heißt, ich. Meine Webseite braucht sonst nur zwei Webservices, um redundant zu sein. Und jetzt hab ich auf dem Heise Ticker gerade heute News gepostet, und schon werde ich mit.

Geht die Post, Gena? Und dann geht plötzlich mein mein Auto hoch. Aber ich war damals vorsichtig und hab gesagt Der mehr als 100 Webserver werde ich nie brauchen, um die Anfragen so zu erfüllen. Und dann? Plötzlich wird es auch langsam. Na, dann kann man halt sagen Okay, wir erhöhen jetzt mal gerade die Anzahl. Solange das andauert, können wir im Nachgang nochmal besprechen, wer diese Vata mag. Richtig. Oder andersherum Wir machen den Prozess daraus, dass wir benachrichtigt werden, wenn ihr solche Mitteilungen hat, die potenziell interessant sein können, dass wir im Zweifelsfall auch durchaus mal manuell eingreifen.

Also durchaus auch noch der Fall? Ja, man macht ja eine Begrenzung des Ganzen, malt auch nicht über gewisse Kosten Grenzen zu kommen, was immer Sinn macht. Und dann sagt man Okay, ich hab jetzt aber eine große Veranstaltung, große Pressemitteilung, wie immer. Jetzt muss ich sicher gehen, dass da nichts schief geht. Da macht man es manuell für eine Zeitspanne, und dann stellt man es wieder zurück.

Also dieses semi Automatische würde ich fast als Ideallösung sehen, weil wenn du einfach sagst, du setzt die Autos galligen Gruppe hoch. Statt 100 Maschinen stelle ich es einfach auf hundert. Und wenn mal der Heise Artikel kommt, dann bin ich safe. Kann es immer noch sein, dass man so eine Art DDoS Attacke bekommt? Einfach unfassbar viele Anfragen auf ein Webdienst abgegeben werden und dann würde man ja das Geld bezahlen für diese 1000 Server und wenn man das einfach blind einstellen würde.

Also ich bin sowieso immer ein Freund davon, dass Automatisierung ist toll. Es erleichtert Unmengen, insbesondere heute bei Google, und man entwirft eine Plattform, schiebt sie raus. Oder doch nicht? Man wirft sie wieder weg. Also alles ist sehr easy, sehr schnell. Aber ich bin immer ein Freund davon, dass halt auch noch ein Mensch drauf guckt, bei der im Endeffekt besser entscheiden kann bei gewissen Szenarien. Was ist das jetzt? Gerade wenn etwas häufig Vorfeld greifen, auch Maschinen, löning ki, Algorithmen an anderer Stelle, die haben dann gelernt irgendwelche Relationen, Information, Relation.

Und dann? Dann kann ich darauf auch reagieren. Aber bei so spontanen, erstmalig auftretenden Fällen, wie auch immer da ist ein Mensch, denke ich, noch eine ganz gute Alternative.

Mir fällt ein Projekt von mir selber ein. Da hatte ich in mehreren Wochen Anwendungen entschlackt und hat dann ungefähr eine 30 prozentige Steigerung in der Arbeitsgeschwindigkeit erzielt. Es war eine interaktive Anwendung, das heißt, die Nutzer waren so zwei, 300 Leute gleichzeitig immer auf der Anbindung aktiv, haben halt gespürt, dass die Anwendung besser reagiert und das zügig ihres Arbeiten möglich ist. Und dann hab ich mal vor ein Nachrichten unternehmen, dann hab ich die neue Version abends online gestellt oder liest, und ich komme am nächsten Morgen rein ins Büro und gucke ok.

Wie sieht es denn aus? Sondern hab ich genau die gleiche alte Last wieder, als hätte ich diese Optimierung nie gemacht. Ich hab mich gefragt Also wirklich Einzelstunden? Wie kann es sein, den Fehler gesucht? Was ist das Problem? Und dann habe ich herausgefunden, dass genau an diesem Morgen ein Flugzeugabsturz stattgefunden hat. Und das statt 200! Auf einmal 5500 Leute gleichzeitig die Anwendung benutzt haben Ich habe das gleiche lãst profil hatte wie Vortags, wo die alte Software noch lief.

Was dann wiederum sehr gut war. Aber ich hab zuerst nicht verstanden, warum. Warum die Zahlen nicht deutlich besser sind oder die Performance deutlich besser ist.

Aber du hast für eine Firma gearbeitet, du kãnntest du es mit Eckdaten, dann hinter der Entscheidung. Daran könnte es liegen. Man das jetzt bei nem Dienstleister, der so gar keinen Bezug zu einem hat, der käme ja nicht da drauf, weil er gar nicht weiß, was man macht. Ich glaube, da war, was du als Mensch dann in dem Moment fast unbezahlbar.

Ich möchte einfach sagen Manchmal ist menschliche Intelligenz halt wichtig, um zu verstehen Warum ist der Effekt so, wie er ist? Und das hätte jetzt ein automatisiertes System nicht unter Umständen so erkennen können. Was glaubst du denn in Zukunft? Wohin geht die Reise noch? Was sagt eine Glaskugel?

Kann ich ja sagen. Ich fang einfach mal in der Vergangenheit an, wo ich gesagt, habe ich viele sehr skeptisch gegenüber. Klar, die ersten klar, Anfänge. Was aber daran lag, dass vieles noch im Unklaren war. Es war ein gewisser Hype. Für viele war allerdings Cloud mehr Storage Anbieter. Da konnte ich meine Bilder hochladen und meine Dateien. Viel mehr war da nicht. Wenn ich mir anschaue, wie schnell sich hier eine neue IT-Landschaft entwickelt hat und wie gut ist, funktioniert bei durchaus Kritik würdigen Aspekten.

Aber, muss ich ganz ehrlich sagen, glaube ich schon, dass es jetzt ein halbmayr ist. Man sieht, es ist ein Geschäftsmodell. Es entstehen immer mehr Firmen, so wie wir auch in diesem Umfeld. Ich glaube, es ist noch ein längerer Prozess, bis hohe Prozentsätze der Wortlauts gewandert sind. Aber es wird passieren. Man wird sehr, sehr viele Birkenholz. Wird man in die Cloud wandern? Das klassische kleine Rechenzentrum wird aussterben. In meinen Augen aus.

Es hat eine Nische, in der Claudia mich jetzt nicht tätig sind. Es wird es immer noch etwas geben. Aber das sind dann wirklich reine Nischenanbieter.

Oder man braucht Kerth Spezial Anforderungen, besonders viele GPUs, die in der Cloud halt teuer sind, weil sie mich massenweise eingekauft werden. Und wenn ich sie 24 Stunden am Tag brauche, lohnt sich das einfach wieder die Sachen selber zu kaufen.

Genau das sind natürlich so Punkte, aber das meine ich auch so mit einer Nische. Aber was die beiden Wortlauts angeht im Markt ist. Ich denke, da geht der Trend absolut hin. Das wird immer mehr kommen. Die Software geht über die Applikation, wie wir ja auch schon heute viel gesprochen haben. Und die Applikation ist heute schon schwierig, individual Entwickler zu finden, die noch so Oldschool entwickeln. Sicherlich, aber ich habe mit großen Software-Hersteller gesprochen, alle mindestens 1000, 200, 300 Mitarbeiter, Softwareentwickler.

Und da wird kein Oldschool mehr entwickelt. Die machen alles nur noch Clouds und von daher ist es gar nicht so eine große Glaskugel. Das ist einfach auf der Zeitachse die Glaskugel. Wie schnell passiert ist. Also ich denke nicht, dass das von heute auf morgen geht, ist halt ein Prozess. Aber es wird passieren, was ich auch beobachte.

Bei unseren Kunden ist das. Man tastet sich manchmal ran an die neuen Anwendungen werden in so eine kubanisches Umgebung zum Beispiel. Und da ist es ja dann wiederum ein sehr kleiner Schritt zu sagen Okay. Diese Copernicus Umgebung läuft bei mir im Rechenzentrum oder läuft in der Cloud A oder B oder C. Gerade wenn man noch nicht weiß, welcher Anbieter macht das Rennen? Wobei ich glaube, das kann man schon ein bisschen antizipieren, dass da zwei ganz besonders hervor stechen werden die nächsten Jahre, oder ist jedenfalls mein Tipp.

Es wird so sein, und man muss sich einfach mal die gängigen Marktanalysen anschauen. Es ist schon sehr erstaunlich der Unterschied zwischen Platz 1 und Platz 2 noch erstaunlicher ist, wenn man reingeschaut. Unterschied zwischen 2 und 3, denn plötzlich ist mit Google am Platz drei. Und ich sage mal Ich weiß nicht, was für ein Bild du von Google hast, aber für mich so ein absoluter tech Riese. Aber die spielen da halt nur den dritten Platz und müssen aufpassen, dass Chinesen wie Alibaba oder Soda nicht aufholen, weil die drängen jetzt auch in den europäischen Markt, und die sind ja auch sehr teuer.

Aber die Big Player bieten schon hervorragende Services an, insbesondere für die Welt, die du gerade beschrieben hast. Und hier kann ich dann als Entwickler oder auch als Kunde sagen Pass auf, ich schaue mir einfach am Ende des Tages an, wenn alles servas ist. Soweit nicht leicht migrieren kann. Wo hab ich meine besten Kosten nutzen? Structure an der Stelle, und dann kommt da auch mehr Konkurrenzkampf noch in Markt. Im Moment ist noch nicht so viel Konkurrenzkampf im Markt, teilt sich gut auf.

Aber ich glaube, in Zukunft wird es da mehr Konkurrenzkampf geben. Und das wird im Zweifelsfall in niedrigeren Preisen oder durchsichtige und Preismodell gipfeln als mein absolut subjektiver Eindruck.

Der Cloud Provider ist Technologieführer dafür preislich etwas teurer. Wer aways? Ganz klar. Wobei man da ja auch deutliche Rabatte bekommt, wenn man gewisse Ressourcen fest für ein Jahr bucht oder gar für drei Jahre bucht. Ich glaube, dann gibts 60 Prozent Rabatt. hws waren die ersten, die profitieren. Das haben auch meiner Ansicht nach das. Angebot und die Profitierenden nach wie vor von auf dem zweiten Platz im absoluten Sauseschritt. In den letzten ein, zwei Jahren hat Microsoft aufgeholt.

Ich glaube, das kommt durch die. Microsoft ist in den Firmen groß, die mittleren und kleinen Firmen natürlich schon super präsent durch die Office Lösungen, durch die Windows Lösung. Und da ist dieses Cloud Ding ein cheek Punkt mehr im Vertrag. Haben Sie da schon guten Kontakt zu den Unternehmen und an dritter Stelle Google? Ich finde die Google Cloud ziemlich gut, muss ich sagen. Ich habe auch schon mit der gearbeitet. Aber ich glaube, Google ist ein Teck Konzern, der supergut Technologie macht.

Aber ich glaube Marketing mäßig zumindest im Cloud Bereich. Da ist nicht so viel Platz. Dort sind auf der einen Seite den Technologieführer, auf der anderen Seite den mit den Unternehmenskunden. So, wer bleibt da noch? Der Cloud macht?

Das ist meiner Ansicht nach die blöde dritte Position von Google, das sie nicht so richtig klar positioniert sind. Und diese Oracle, IBM Cloud eben. Mir ist noch niemand über den Weg gelaufen, der die wirklich produktiv einsetzt. Ich denke, das sind die haben ihre Daseinsberechtigung in irgendwelchen Nischen oder vielleicht in anderen Märkten. Könnte mir vorstellen, dass im Mittleren Osten Nahen Osten das Orakel noch ganz stark ist, aber auch nicht da sind, glaube ich, eher ueberall, wo ich diese klassischen hybride Ansätze habe.

Oder wenn ich mit IBM ein absoluter Technoide ist, mit Unmengen an Angeboten, und das ich in Bestandskunden dann noch ein bisschen Cloud lief. Also ungefähr so okey wird auch weiter wohl existieren, aber nicht Weltmarkt relevant sein. Oracle hat halt ein wesentliches Produkt, bietet ein bisschen was drumherum. Aber ich glaube, er hat auch ein bisschen ein Imageproblem. Aber das muss jeder für sich entscheiden. Und tatsächlich Um wieder an den Anfang zu springen, versuchen es mit weit über 40 Prozent absolut Marktführer, weil sie am längsten am Markt sind, die meisten Services haben und sich halt auch nichts verbauen.

Also ich kann von komplett Microsoft Umgebung bis hin zu komplett Unix oder was auch immer. Ich kann alles entsprechend umsetzen. Asea empfinde ich, ohne dass ich jetzt ein echter Experte bin, als sehr stark. Sind auch stark im Wachstum. Und genau wie du sagst es die Unternehmenskunden die reine Microsoft Umgebung haben, die keine Hybrid oder sonstigen Technologien verwenden, was ihr kleiner eine Firma ist, also kleiner mittlerer Mittelstand durchaus der Fall sein kann. Ich sage mal so schon aus dem Bauch heraus würde ich da wahrscheinlich eher in diese Richtung gehen.

Aber man muss sagen, viele Kunden haben dann doch noch hier bisschen, da etwas. Und wenn man dann einfach sieht Okay, ich will halt wirklich Cloud Ansatz wählen. Ich will diese Strategie ganz konsequent verfolgen. Und ich versuche dann eher, klassische Mittel abzulösen durch Service. Dann landet bei Aretz, weil die Menge an Service ist. Die Innovation, die dahintersteht. Das, muss man wirklich sagen, ist momentan noch out. Und da wird selbst Microsoft noch etwas brauchen, um da in diese Richtung zu kommen.

Aber wie gesagt, es gibt immer überraschungen. Das sind alles sehr große Konzerne, und ich fände es ja auch spannend, wenn da noch mal irgendwelche überraschungen eintreten.

Auf jeden Fall. Für den Endkunden kann es ja nur positiv sein, entweder durch den Preis oder durch die Innovation, die er dann nutzen kann.

Genau. Der Endkunde wird der Sieger sein. Definitiv. Wenn unsere Zuhörer Fragen haben oder Feedback zu der aktuellen Folge hat, können Sie uns gerne eine E-Mail an Podcast senden. Bitte bewertet diese Podcast Episode und lasst uns einen Kommentar dafür. Weitere spannende Technologie Themen schaut gerne auf Skill bei Slash Blog vorbei Bries. Ich bedanke mich ganz ganz herzlich bei dir.

Ich danke dir Maurice.

Maurice KnoppSkillbyte Podcast #28: Cloud als Strategie, nicht als Technologie!
Mehr

Skillbyte Podcast #6: Must-have Skills, Technologien und Weiterbildung für Full-Stack Entwickler

In diesem Podcast geht es um das Thema: Must-have Skills, Technologien und Weiterbildung für Full-Stack Entwickler

// Inhalt //
1. Was ist ein Full-Stack Entwickler?
2. Welche Skills hat ein Full-Stack Entwickler?
3. Welche Technologien setzt ein Full-Stack Entwickler ein?
4. Wie bildet sich ein Full-Stack Entwickler weiter?
5. Skillbyte als Full-Stack Experten

Wir freuen uns wenn Sie unseren Podcast abonnieren! Besuchen Sie uns auch genre auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #6: Must-have Skills, Technologien und Weiterbildung für Full-Stack Entwickler
Mehr