R1: Das Ziel ist es in diesem Interview den Stand oder die Praxis bei der Konfiguration von echten Softwareentwickler zu bekommen. Das Problem ist, dass im akademischen Bereich es nicht ganz klar ist wie wichtig, also welche Rolle spielt denn die Konfiguration bezüglich der Wichtigkeit im täglichen Leben und was für Probleme bestehen denn überhaupt bezüglich Konfiguration. Und dieses Interview soll uns dabei helfen diese Dinge näher zu beleuchten und später… Das Problem ist dass in der Akademie dieses Wissen fehlt was in der Praxis gemacht wird und diese Serie von Interview soll uns dabei helfen praktisch den wahren Gründen und wahren Problem auf den Weg zu führen und, dass wir auch unsere Forschung in diese Richtung auch ausrichten können. Genau, jetzt werden wir im Folgenden erstmal allgemeine Fragen stellen zu Softwareentwicklung um dann so später Sie als Interviewpartner hier praktisch einordnen zu können und dann kommen wir auf Konfiguration über, was es für eine Bedeutung für Sie hat was es für Sie vom Verständnis ist, Konfigurationsfehler kommen als nächstes und dann sag ich mal spezielle Fragen Microservice-Umfeld falls Sie da sind und wo vielleicht Verbesserungsbedarf besteht. Ok, ist erstmal noch was unklar?
I1: Ne, passt.
R1: Ok, super. Dann würde ich sagen, fangen wir einfach mit der ersten Frage an. Ach so, vielleicht doch einfach, da dass ein Vor-, ein Präinterview ist vor den echten Interviews wäre es schön wenn wir auch direkt Feedback dann oder wenn deine Fragen komisch sind, dass man das einfach diskutieren können, wo wir dann halt vielleicht Frangen präzisieren können und (R2: (…)) und wir somit unseren Fragebogen verbessern können. Oder die Struktur, etc. Ok. Also, in welcher Domäne arbeiten sie hauptsächlich?
I1: Ich bin IT-Consultant für Individualsoftware-Entwicklung und für generell den Software-Entwicklungsprozess. Und wir helfen halt Kunden ja praktisch von der Idee zu einem lauffähigen Produkt zu kommen.
R1: Ok, wenn man jetzt noch ein bisschen weiter geht, würde man Sie vielleicht so, sind Sie vielleicht Backend-Entwickler, DevOps, im Security-Bereich, Frontend-Entwicklung, wo würden Sie sich da vielleicht einordnen?
I1: Ich würde jetzt sagen, ich komme aus der Backend-Entwicklung und das verbreitert sich ja grad überall, also wenn man reiner Backend-Entwickler, jetzt in Zukunft wird das ja kaum noch irgendwie gebraucht werden und man merkt halt auch in der Praxis, dass man sowieso mit anderen Themen viel zu tun hat. Was natürlich auch dadurch bedingt is, dass die Backend-Frameworks immer besser geworden sind. Ja also früher könnte man da noch Vollzeitjobs rechtfertigen, heute sind die halt einfach auch extrem gut und deswegen ist so mein zweites Thema verstärkt DevOps, Continuous Integration, Continuous Delivery, man könnte vielleicht sogar sagen irgendwie sowas wie, was hab ich gelesen, Software Delivery Expert. Das habe ich jetzt schon ein paar mal gelesen als Berufsbezeichnung/Jobbezeichnung. Und nebenher immer auch mal so ein bisschen Frontend-Themen, die halt mit rein kommen.
R1: Okay, vielleicht kannst Du kurz mal sagen können mit welchem Frameworks und Tools arbeiten sie für gewöhnlich? Also vielleicht mal so fünf Beispiele nennen oder so.
I1: Genau, also ich bin viel mit im Java Umfeld unterwegs, Backend-technisch mit Spring, Spring-Framework, Spring-Boot, Spring Integration, also diese ganze Spring-Universum sag ich mal. Spring-Cloud, was da alles so dranhängt. Und dann halt mit verwandten Technologien, die man da halt benutzt im Backend. Also Messaging, RabbitMQ, ActiveMQ, Kafka oder halt Datenbanken. Dann halt irgendwie sowas wie entweder JDBC oder SQL. Auch mal NoSQL-Datenbanken. Genau, und halt Webservices viel. Zur Anbindung von Frontend- oder von irgendwelchen anderen Softwarekomponenten, die halt von, meistens von anderen Kunden dann genutzt werden oder angeboten werden und die einzubinden. Und dann halt sowas wie SOAP und REST. Das wäre so der ganze Backend-Teil und, ja, Frontend wird in letzter Zeit ja eigentlich immer zwischen zwei hauptsächlich, der Kampf sozusagen geführt, zwischen React und Vue.js, wobei ich immer für Vue.js bin, weil es ziemlich schlank ist in der Einführung, kommt aber auf den Kunden auf an. Und in dem ganzen DevOps, Continuous Integration
R2: Was heißt denn der Kampf zwischen zwei?
I1: Naja, es gibt ja gerade drei große Frontend-Frameworks, die so grad, also wenn sich die Kunden so ein bisschen ausdenken sie haben jetzt mit PHP5 Anwendung beispielsweise, die die letzten 15 Jahre gewachsen ist und wollen heute jetzt mit ner komplett neuen Plattform anfangen. Dann überlegt man eigentlich immer zwischen Angular, React und Vue.js, das sind so diese großen drei. Und dann gibt’s halt immer Tabellen und dann wird halt gesagt das sind unsere Anforderungen und was nehmen wir denn jetzt und so. Wenn es jetzt eher Richtung Mobile App geht, dann gehen viele Richtung React, weil da das Framework ziemlich gut ausgebaut ist.
R2: Ja.
I1: Aber wenn jetzt, manche fahren jetzt kommt's aber wieder auf die Migrationsstrategie an, fangen dann so ne kein, also eigentlich alle fahren kein Big Bang und wollen ihre bestehende Anwendung integrieren. Da hat wieder Vue.js Vorteile, weil dass ich sehr gut in bestehende Sachen integrieren lässt. Genau. Ja, und diese ganze DevOps-Schiene ist halt viel in diesem Infrastructure-as-Code Tools, sowas wie Ansible. Da bin ich stark unterwegs, gibt viele Kunden, die habe auch noch Puppet und Chef, das ist aber eher schon älter muss man sagen und wird viel migriert zu Ansible. Und da halt viel mit was da alles so rumfliegt: Vagrant, GitLab, GitHub, Jenkins, Travis und so weiter.
R1: Okay, was ist denn ihre Rolle in der Softwareentwicklung?
I1: Meistens hat man relativ viele Hüte, früher war das ja sehr strikt getrennt in den althergebrachten Softwareentwicklungsprozessen. Sowas wie, da gab es halt den Software-Architekten und es gab den Projektmanager und es gab noch was weiß für Rollen, den QS-Manager, den Testmanager, Release-Manager und so weiter. Aber durch die immer mehr fortschreitende Adaption von agilen Entwicklungsprozessen hat man eigentlich immer relativ kleine Teams, die alles abdecken müssen und da ist es meistens so, dass man Die Aufgaben so verteilt, im Idealfall, das es auch zu denen Talenten und Fähigkeiten passt. Und da kann ich mich eigentlich immer sehr gut mit dem, der Softwarearchitektur einbringen. Das ist meistens so mein Thema, das, da kann ich auch die Finger nicht von lassen. Und dann ist halt viel auch Software-Entwicklung selber, also einfach Developer wäre so ne Rolle. Genau, und halt dieses, ja, Software-Delivery Expert, wo ich halt viel in diesem Infrastruktur-Thema unterwegs bin, was auch immer viel heißt sich damit so klassischen Adminrollen zu unterhalten und eigentlich die immer mehr ins Team zu ziehen. Weil grad diese Microservice-Ansätze, die jetzt gefahren werden zielen ja darauf ab, dass wirklich alles im Team gemacht wird, also 'Build it, you run it' so nach dem Motto und man merkt auch durch diese schnellen agieren Prozesse, wo man dann irgendwie in 2-Wochen-Sprints oder so voranschreitet, man hat so schnell Ergebnisse, dass man keinen Fall irgendwie warten kann auf irgendne Infrastruktur-Abteilung, die irgendwie sagt „oh, ihr habt einen Server bestellt, in drei Wochen habt ihr den regulär, aber leider, da wir keinen RAM mehr im ESXI-Cluster verfügbar haben, habt ihr den 2 Monaten“, das geht halt gar nicht also das heißt man muss auch die da mit reinziehen und
R2: Was gibt es so für Rollen?
I1: Also was es oft noch gibt sind halt diese klassischem Scrum-Rollen, also Scrum wird meistens gemacht irgendwie, also es gibt war auch ein paar wenige, die kann man machen, was ich favorisieren würde, aber die meisten machen Scrum… wenn sie agil denken und da gibt es halt dann so Product-Owner, ist meistens immer gesetzt, den Scrum-Master, der so ein bisschen auf die Prozesse achtet und dann gibt es schon auch so, ich sag mal, ja, es gibt schon Leute, die eher Frontend-lastig sind, so diese Frontend-Developer, es gibt schon die Backend-Developer, aber es gibt auch immer mehr Fullstack-Developer, dann gibt es natürlich sowas wie die jetzt eher aus der Fachlichkeit kommen, sowas wie Designer, oder überhaupt Fachexperten für eine Domäne und auch so, ich sag mal eher die jetzt vielleicht Fokus auf Testing haben. Also was man früher so als (…) Testmanager oder so bezeichnet hat.
R1: Okay, vielleicht letzte allgemeine Frage: Wie viele Jahre Erfahrung haben Sie denn als Software-Entwicklung?
I1: Jetzt genau 10, also 10 Berufsjahre Erfahrung und wenn man noch so ein bisschen das duale Studium dazu zählt, könnte man auch vielleicht 1,5 Jahre dranhängen, aber so 10 offizielle.
R1: Okay, gehen wir mal zum Konfiguration, jetzt speziell, was verstehen Sie überhaupt unter dem Begriff Konfiguration?
R2: Ich würde erstmal vielleicht, noch mal jetzt die allgemeine Kategorie ein bisschen reflektieren. Ob dir da irgendwas fehlt.
I1: Achso, den Einführungsteil?
R2: Genau, halt so allgemein wenn es darum geht den Kontext zu setzen. Fehlt dir da irgendwas? Oder ist zu viel drin?
I1: Ne, ich glaube ihr braucht ja so ein bisschen ne Einführung. Was ist das überhaupt für ein Mensch und was… um dann bewerten zu können was sind dann, was nützt die Antwort danach.
R2: Fehlt dir noch was? Also was fragst du denn jemanden, der bei dir anfangen möchte oder der in dein Team möchte? Was fragst du den dann?
I1: Ja gut, wenn jetzt bei mir jemand anfangen möchte, frage ich natürlich auch viel nach den weicheren Kriterien, wie irgendwie Motivation für irgendwelche Dinge oder warum bewirbst du dich hier und sowas. Das ist ja jetzt hier irgendwie nicht so interessant.
R2: Eher so technische Sachen?
I1: Genau, aber die technischen Sachen… Ja, meistens geht man noch tiefer rein, (…) dann fragt man halt mal irgendwelche Details mal zu irgendeiner Technologie jetzt. Wenn der sagt, der kann irgendwie Kubernetes… bis zum Erbrechen, dann fragt mal halt „gut, wie richtet man denn so ein Netzwerk da ein?“ oder sowas. Aber ich finde das jetzt eigentlich ganz gut vom Umfang. Das sollte glaube ich auch nicht zu lang werden. Also ich könnte auch stundenlang erzählen oder so, also (lachen). Das könnte bestimmt bei dem ein oder anderen auch noch länger werden.
R1: Okay, aber das war auch so klar mit Rolle und so weiter und Domäne? Also du hast genau das
I1: Vielleicht, also das einzige was ihr vielleicht machen könntet, wären ein, zwei Beispiele. So als… vielleicht versteht jemand unter Rolle noch was anderes, aber an sich fand ich es gut, also.
R1: Das war genauso geantwortet, wie es gedacht haben. Wir haben auch Beispiele noch da, die hätten wir dann gegeben.
I1: Okay gut, jaja.
R1: Genau. Okay. Dann geht es weiter… Richtung Konfiguration. Ja, generell was verstehen Sie unter dem Begriff Konfiguration?
I1: Ja, also man kann so ein bisschen, wenn ich jetzt mal zurückblicke, ist es ja immer das Thema, dass man ja sehr viel kodieren kann, also man eigentlich immer alles schreiben, das Problem ist, dass halt die Software oft in verschiedenen Kontexten eingesetzt wird und dann, also einmal in verschiedenen Kontexten, das ist mal das Thema 1 für das ich konfiguriere und da können wir vielleicht auch gleich noch mal näher noch drauf eingehen, was so ein Kontext wäre und das zweite wäre, ich habe nicht immer das Knowhow verfügbar um die Software anzupassen. Also um den Code anzupassen. Und zwar geht der sehr schnell verloren, also dieses Know-How geht sehr schnell verloren aus einem Projekt, aus einem Unternehmen. Meistens sogar bei den Leuten selber, die es geschrieben haben. Also ich mach dann immer so diese Witze, wenn man dann über Test-Driven-Development und sowas redet mit dem Kunden warum man das machen sollte, dann mache ich immer so diese Witze, dass ich sage, also ich weiß eigentlich in zwei Wochen gar nicht mehr, was ich da gemacht habe, was natürlich nicht ganz ehrlich ist, aber schon ein großer Teil ist dann vielleicht weg und das ist halt auch ein Grund, dass ich was konfigurierbar mache, was ich sowieso öfter irgendwie anpassen… müsste. Genau, das wäre der zweite Aspekt und der dritte Aspekt ist natürlich wenn ich was, ja wie soll ich sagen, es gibt ja noch so ein weitergehendes Konzept mit dem Convention over Configuration, das ist immer so ein bisschen irreführend, weil man denkt, okay da mache ich jetzt ne… was heißt das eigentlich? Aber eigentlich ist das ja sozusagen, wenn man jetzt eine Software hätte, die man gar nicht konfigurieren kann, dann hätte man eine konfigurierbare Software und dann wäre das für mich so ein Schritt 3, also dann hätte ich sozusagen vorkonfigurierte Software. Und das ist ja auch so ein wichtiges Thema, gerade in der aktuellen Software-Entwicklung, also eigentlich das wichtigste Thema wenn ich jetzt denke Serverless oder so, das ist eigentlich auch maximal vorkonfiguriert.
Genau. Ja und bei dem ersten Thema natürlich, also diesen Kontexten, da ist es halt immer so, man hat ja meisten verschiedene Entwicklungsumgebungen, von der Developmentumgebung. Also schon mal angefangen von der lokalen Entwicklungsumgebung, bei einem selber auf der Workstation, auf dem Laptop, bis hin zu der wo alle integrieren, zu einer Fachtestumgebung, Präproduktionsumgebung, wie man die jetzt alle nennt, bis zur produktiven Umgebung. Und die haben meistens ja nicht eine Datenbank oder so, sondern halt jeweils ne eigene Datenbank, die haben eigene Load-Balancer, eigene… Zertifikate, eigene umgebungsabhängige Sachen und die muss ich ja irgendwie berücksichtigen können. Also, dass ich mal minimal irgendwie eine Database-URL oder so konfigurieren kann. Sonst wäre ja die Software… also es wäre halt sehr schwierig das irgendwie hinzukriegen.
R1: Okay, ja in wie weit spielt denn Konfiguration für Sie in der täglichen Arbeit eine Rolle?
I1: Hm, das ist eine gute Frage. Wie ich ja eben schon gesagt habe mit dem Convention over Configuration, was sich eigentlich immer mehr durchsetzt, also dass ich so einen, ich weiß nicht genau, ob das jetzt nur daher kommt, dass man auf Konferenzen schnell was zeigen will in fünf Minuten, aber jedenfalls… ne, das ist ja schon so, dass man halt nicht für jedes Problem immer ständig nen Experten da sitzen hat und deswegen ist die Richtung ja schon ganz gut. Das Problem daran ist, dass diese ganze Convention ist ja trotzdem Konfiguration, ist also trotzdem, hat trotzdem eine Auswirkung auf die Software. Also im Code wird die ja irgendwie benutzt diese Konfiguration. Das heißt, ich muss im Zweifelsfall dann wieder da auch einsteigen können und tief reingehen können. Und was war die Ursprungsfrage?
R1: Wie weit Sie in der täglichen Arbeit…
I1: Achso, ja genau. Und das ist genau das Thema, was wahrscheinlich… sehr hohen Prozentsatz ausmacht. Ich würde sagen mehr als entwickeln. Mehr als programmieren… viel mehr als programmieren. Eigentlich
R2: Wie viel denn pro Woche?
I1: Das ist eine gute Frage, also ich… also aus dem Bauch raus ist es wahrscheinlich, das hört sich jetzt so viel an, aber ich würde mal sagen mindestens irgendwie so 60 % oder so. Ist man eigentlich nur am konfigurieren.
R2: Du hast jetzt gesagt aus dem Bauch heraus.
I1: Na, das hört sich so hoch an jetzt für mich. Ich müsste das mal irgendwie verifizieren, aber (lacht) also auf jeden Fall mehr als ich entwickle würde ich sagen. Aber das kann natürlich auch an meiner spezifischen Rolle liegen, weil ich dann natürlich dann auch immer wieder bei sowas gefragt werde, ah, ich hab hier irgendwie einen Docker-Container und der redet nicht mit dem Elastic Search, wie mache ich das denn jetzt? Das mag jetzt für jemanden, der sozusagen vielleicht in einem Entwicklungsteam ist, wo der jetzt jemanden wie mich irgendwie drin hat und der dann sozusagen dafür sorgt, dass die ganze Entwicklung irgendwie läuft, also dass klar ist wo ich irgendwie meinen Code einchecke, in welcher Entwicklungsumgebung ich arbeite, wie ich das machen muss, dass mein Code bis zur Produktion kommt. Wenn das alles für den geklärt ist, kann der vielleicht in einer gegebenen Programmiersprache mit gegebenen Frameworks irgendwie mehr programmieren. Mit Sicherheit, also… wobei das dann halt auch viel so, ich sag mal diese typische, genau, das war ja so ein bisschen diese Frage, welche Rolle hat man sozusagen, ich würde sogar den, diese Entwicklerrollen noch mal unterteilen wollen, nämlich in die Fachentwickler, sag ich jetzt mal. Also, der wirklich fachliche Funktionen rausentwickelt die ganze Zeit, sich auch fachlicher besser auskennt, also das auch ganz oft häufig beim Kunden so, dass man wirklich so, sehr fachbereichsnahe Entwickler hat, die vielleicht sogar aus dem Fachbereich kommen, sich extrem gut in der Fachlichkeit auskennen, aber dafür nicht ganz so gut in diesen ganzen Tools und so weiter, die wollen auch gar nicht wissen wie jetzt Docker oder irgendwas im Detail funktioniert. Die wollen einfach nur eine Entwicklungsumgebung und dann, sag ich mal, loskodieren können. Und das passt eigentlich ganz gut meistens zu dem Skill, den wir dann so ein bisschen reinbringen. Weil wir ja keine Ahnung von der Fachlichkeit haben, eigentlich, aber so diesen ganzen technischen Aspekt mit reinbringen. Genau.
R1: Vielleicht eine Anschlussfrage daran. Wenn man so ein Scrum-Team sieht, ist ja beschränkt, ist so ein, ja, technischer Entwickler pro Team notwendig heutzutage oder kann man, also wie wichtig ist jetzt nach ihrer Einschätzung die Konfiguration für so ein Scrum-Team sag ich jetzt mal.
I1: Ich würde schon sagen, dass es sehr wichtig ist, also es versucht zwar die Branche aktuell sozusagen weniger wichtig zu machen indem die Tools immer besser werden, die man so hat. Also wenn man jetzt an Serverless denkt sozusagen, man bekommt alles hingestellt und muss wirklich nur noch kodieren. Aber bis das mal so weit ist, dass das wirklich in der breiten Masse eingesetzt wird, ist es glaube ich schon sehr wichtig, weil, also dieser hohe Anteil von man hat mit Konfiguration von Frameworks zu tun, sagt ja auch irgendwie was über die Wichtigkeit aus und die vielen Fragen, die man dann so bekommt im Team, sind ja auch irgendwie so ein Grad-Messer. Und wie gesagt, die moderne Software-Entwicklung im Unternehmen beschäftigt sich halt sehr viel mit irgendwie der Benutzung von Frameworks und gar nicht so sehr jetzt mit irgendwelchen Programmiersprachendetails. Das ist halt… Also wenn man so diese klassischen… wie soll ich denn sagen? Also wenn Sie mich jetzt fragen würden, irgendwelche Basic-Sachen zu irgendeiner Programmiersprache, ich würde wahrscheinlich durchfallen. Durch jede Prüfung. Weil ich mich einfach kaum noch damit beschäftige. Das ist wirklich krass, also… (lacht).
R2: Schreib mal eine For-Schleife.
I1: Na gut, das kriege ich noch hin, aber… (…)
R1: Dann, zurück zu Konfiguration. Haben Sie, wenn man jetzt überlegt, man kann ja in einem monolithischen System was konfigurieren und man kann aber auch Tool oder Framework oder die Infrastruktur konfigurieren. Mit was für Arten für Konfigurationen haben Sie typischerweise zu tun. Also konfigurieren Sie ein System, Monolith, ein monolithisches System oder doch eher ein System von Systemen?
I1: Das geht eigentlich immer mehr in die Richtung Systeme, also mehrere Systeme, also Monolithen ist im Grunde immer das was immer schon da steht beim Kunden, wo er weg will und das heißt er macht aus dem Problem, was er gerade hat, viele davon. Also multipliziert die einfach und man versucht dann mit den Sachen, die man einführt das irgendwie zu reduzieren. Also damit umzugehen. Das ist eigentlich immer so wieder der, also diese, das hat eigentlich einen riesen Vorteil für dieses ganze Thema Continuous Integration/Continuous Delivery, das hat sich nicht so sehr ganz dolle weh getan damals beim Monolithen sozusagen und jetzt tut es aber viel mehr weh und deswegen führen das auch alle ein… Automatisch, weil man sonst gar nicht mehr entwickelt. Sonst nur noch sagt „Wie finde ich eigentlich Fehler in meinem System?“.
R2: Gibt es da noch mehrere Arten der Konfiguration? Oder wirklich nur die zwei Kategorien?
I1: Ich hänge glaube ich noch bei der… die Frage von ihm (R1) war doch, welche Tools konkret, oder? (…) da bin ich jetzt irgendwie unsicher.
R1: Also ich hätte jetzt vielleicht gedacht, wenn ich jetzt zum Beispiel eine Datenbank habe, dann kann ich die für sich konfigurieren. Die ich benutze. (R1: Ja. Ja.) Und dann läuft die schneller oder langsamer zum Beispiel oder so (R1: Achso, ja). Und jetzt habe ich aber einen Microservice, wo ich jetzt ganz viele Sachen konfigurieren muss, was… spielt das überhaupt, diese eine Datenbank-Konfiguration überhaupt noch eine Rolle oder nicht? Oder
I1: Ja, immer wenn sie kaputt ist. Also immer wenn die. Also eigentlich, man könnte es jetzt salopp sagen, wenn die Convention nicht funktioniert. Also wenn das vorkonfigurierte nicht ausreicht sozusagen, oder irgendwie kaputt geht oder irgendwelche Fehler entstehen. Das hat natürlich auch den riesen großen Nachteil, dass man, also das hat, man hat ja vorher beim Monolithen, den hatte man vielleicht noch komplett irgendwie im Griff, man hat einmal alles so gesehen, was da drin ist. Und jetzt hat man fast gar nicht mehr die Chance dazu, also man guckt eigentlich eher so Schlaglicht-mäßig in die Komponenten rein und ist auch extrem drauf angewiesen, das war ja früher auch immer wieder das Thema, dass in diesen monolithischen Anwendungen wurde auch einfach viel selber geschrieben. Also da hat man sich halt selber ausgedacht, wie jetzt der Datenbank-Layer aussieht, oder der ORM-Mapper, oder, weil das können wir viel besser als irgendwie tausend Open-Source-Entwickler. Das ist ja ganz oft, dieses „not invented here“-Problem, aber das geht jetzt nicht mehr. Wenn ich jetzt nicht ne Anwendung aufmache und weiß „okay, in src/main/java oder sonstwo liegen die Sourcen und in src/main/test liegen die Tests dazu“, also wenn ich nicht so ein bisschen weiß, das ist die Default-Struktur, dann… wie soll ich dann noch rausfinden, also wenn das komplett einmal die Struktur ist ja auch schon mal wichtig. Ist auch für diese ganzen Konfigurationen — genau, also diese Struktur ist mega wichtig für die Konfiguration, dass man so allgemein gültige Ordnerstrukturen und sowas hat, da fängt es ja schon an. Wenn ich jetzt irgendein Projekt aufmache und dann gucke ich rein und hab so eine völlig kryptisch, verschachtelte Struktur vor mir, dann denke ich so „hm“. Ja, also sowas wenn ich jetzt ein Werkzeug wie Maven oder Gradle oder so benutze, dann gehe ich halt davon aus, dass im Root-Directory die Root-pom.xml oder build.gradle liegt. Wenn die jetzt irgendwo sonstwo wäre, würde ich nicht damit zurecht kommen und die Tools auch selber ja nicht. Weil die auch selber davon ausgehen. Genauso ein Dockerfile, das würde ich da auch vermuten oder, also erwarten. Das ist sogar technisch so gelöst, dass das Dockerfile sich gar nicht bauen lässt, wenn das nicht unterhalb, das kann immer nicht sozusagen den, die Directorys hochwärts greifen, sondern immer nur tiefer rein. Aber das war halt früher üblich. Da hatte jedes Projekt halt seine eigene Struktur und es gab einen Developer, der das wusste und die anderen haben ihn halt gefragt. Dazu ist heute gar keine Zeit mehr.
R2: Das heißt das ändert sich jetzt so langsam, dass es weg ist von den monolithischen Systemen und hin zu den Tools, Frameworks und so weiter (I1: Ja, genau). Ist das noch so 50:50, oder?
I1: Oh, das ist eine gute Frage. Also gefühlt für mich ist es, über 90 % Microservice-Architekturen, aber das liegt auch daran, dass ich da halt in die Richtung auch immer engagiert werde. Und viel, was noch da ist, ist, wahrscheinlich ist es andersrum. Also das ist, also was wirklich in der Realität irgendwo läuft ist bestimmt andersrum. Mit Sicherheit. (…) Und auch die großen, die Unternehmen, die da immer genannt werden, die jetzt eine Microservice-Architektur propagieren, die kommen auch von einem Monolithen. Also, leuchtendes Beispiel ist ja immer Netflix. Die hatten erst einen Monolithen, der hat dann nicht skaliert und deswegen haben sie Microservices gemacht. Das muss man auch immer jedem Kunden nochmal sagen, so habt ihr das auch, das Problem? (lacht) Manchmal könnte vielleicht auch ein gut geschnittener Monolith, ein Microlith oder so, könnte vielleicht auch okay sein. Weil da muss man ja immer aufpassen bei diesen, (…), aber die Microservice-Geschichte heißt ja tatsächlich, dass ich das, was ich vielleicht vorher auch schon modularisiert habe, jetzt auch noch modular deploye, also auf verschiedene Server. Und wenn es jetzt nur Dockercontainer sind, aber das impliziert halt sofort ein verteiltes System mit entsprechenden Herausforderungen: das Netzwerk ist reliable und so, diese ganzen (…) of Distributed (…).
R1: Okay, wenn man jetzt noch mal den Stellenwert von einer Konfiguration sehen, wie würden Sie das denn, (…) die Wichtigkeit im Software-Engineering, weil man, vielleicht so ein Hintergrund nochmal zur Frage, man hat jetzt ja in der Lehre meistens nicht großartig Konfigurationen als Thema. Was für einen Stellenwert würde das dann bei der Softwareentwicklung/Software Engineering generell für Sie einnehmen?
I1: Na, ich würde sagen durch die aktuelle Strömung in der Architektur, in sowas wie Microservices, wird das halt immer wichtiger eigentlich. Weil, wenn die Dinger nicht konfiguriert werden ist halt, irgendwie Essig mit der Entwicklung, ne? Es muss ja immer irgendwie und je komplexer die Systeme werden, also je verteilter sag ich mal und dadurch komplexer und die Probleme, die ich dann, also ich nutze dann Tools um die Probleme dann irgendwie einzufangen. So ein einfaches Beispiel ist wenn ich jetzt eine Spring Boot Applikation hochfahre und die arbeitet für sich alleine, dann ist das alles total einfach. Sobald ich anfange mehrere davon hochzufahren, kommt so der klassische „oh, da nehmen wir jetzt Spring Cloud“. So, und dann, ja okay, nehmen wir Spring Cloud und dann hat jede dieser Spring Boot Applikationen, wo man dann Spring Cloud mit reinzieht auf einmal so ne Properties-Datei nicht mehr zwei Einträge, sondern halt… 50. Alles Konfigurationen. Und alles nur dafür da, dass man die Tools, die dafür da sind das Leben einfacher zu machen, konfiguriert. Das heißt die… das ist ja exponentielles Wachstum von zwei auf fünfzig ist ja so (…) — Explosion von Konfigurationsdingen. Die auch alle kaputt gehen können. Also deswegen würde ich ja sagen, es wird immer wichtiger. Und je weiter höher man die Abstraktionsebene geht, das ist ja jetzt erstmal sozusagen nur noch auf Serverebene, ich verteile selber… aber wenn ich das jetzt noch mit einbeziehe, ich habe irgendeinen Serverlessanbieter oder so, der hat das ja auch drunter das Problem. Der hat ganz viele Probleme drunter und da ist es ja wahrscheinlich noch mehr, was dann alles zusammen spielen muss.
R1: Okay…
I1: Und dann ist immer das große Problem, wir reden ja wahrscheinlich oft von der Softwareentwicklungsphase, das heißt der Projektphase: agiles Projekt, Budget ist grad da, alle gucken auf den Code. Was passiert wenn das Projekt ausläuft? Dann… dann kommt man vom Entwicklungs- in den Maintenancemodus oder so, reduziert das Entwicklungsteam von 20 Leuten auf 2, oder so. Und dann müssen die diese Software warten. Und dann wird das Problem noch krasser, weil… die ganzen Librarys und so laufen ja weiterhin, also die werden ja auch, die haben ja irgendwelche Sicherheitslücken, müssen geupdatet werden, sonstwas… und dann haben die einen Fehler. Irgendwo. Und müssen dann auf alleine, irgendwie 200 Microservices oder so… ja, der Trend geht ja wirklich dahin jede Funktion praktisch in einen eigenen Microservice zu packen und dann… haben die ein echtes Thema damit. Also dann ist es definitiv so, dass Konfiguration viel viel wichtiger ist, als man vielleicht so im Studium vielleicht auch annimmt, oder so. Da hatte ich auch kaum damit zu tun, das war irgendwie immer gegeben…
R2: Also könnte man eigentlich schon ne ganze Vorlesung über das Semester damit füllen?
I1: Ich würde sagen ja. Wenn man das zumindest mit den Hintergründen verknüpft warum das jetzt immer wichtiger wird und vielleicht auch darauf mal so ein Schlaglicht setzt, weil man kann ja schlecht sagen, das ist wegen den Microservices, man muss ja dann auch sagen was ist das überhaupt. Das heißt das ist dann auch immer so ein bisschen Software-Architektur oder überhaupt was passiert sozusagen in der Software-Entwicklung allgemein am Markt, wo entwickelt sich die Welt hin. So ein bisschen, ja.
R1: Okay, ja, stellt die Konfiguration von diesen System oder Tools und Infrastruktur, Frameworks, etc. Sie vor Probleme? Also was sind denn praktisch die, erstmal die schwierigsten Probleme oder das schwierigste Problem, vielleicht erstmal und dann… können wir weiter.
I1: Ja, das Hauptproblem ist immer die Integration mehrerer Frameworks. Also das ist auch das, was meistens am schlechtesten dokumentiert ist. Also die Tools an sich sind von schlecht bis sehr gut dokumentiert und als, ich sag mal, ja vernünftiger IT-Consultant versucht man natürlich dem Kunden Tools zu empfehlen, die gut dokumentiert sind, damit sie auch noch selber noch damit leben können und nimmt dann halt wirklich eher die Tools raus, wo man dann sagt „oh, das ist nicht mehr maintained, interessiert sich keiner mehr dafür, sollte man vielleicht nicht benutzen“ oder so, sondern lieber wo es potentiell viele Stackoverflow-Antworten, viele Blogposts und sowas gibt. Was allerdings dann weniger wird ist dann schon, wenn man sagt ich will jetzt zwei verschiedene Tools integrieren, dann hat man oft noch Glück, dass es da hier und da schon noch was gibt, aber im Endeffekt, die Architektur, die man dann beim Kunden aufbaut besteht nicht aus zwei Tools, sondern aus… weiß ich nicht, ne? Also die, die man selber vielleicht für einen Technologie-Stack auswählt, das mal mindestens eine Liste von zehn Sachen und diese zehn Sachen zu integrieren ist schon die Aufgabe und dann haben auch die zehn Sachen ja wieder Dependencies und Abhängigkeiten, die sie ohne, dass man das jetzt groß weiß einfach reinziehen. Wenn ich mir so eine Standard-Pom von so einem Spring Boot-Projekt angucke und in der IDE auf „effective pom“ klicke, dann wird mir ganz schlecht, weil… der zieht das halbe Internet rein. Das ist dann nur so ein, wenn da irgendwo so ein Bausteinchen wackelt davon…
R2: Was ist pom?
B2: Dieses Projekt-Object-Model von Maven. Diese, wo praktisch beschrieben ist welche ganzen Abhängigkeiten (R2: okay) meine… Und achso genau, und die effective pom zeigt dir auch noch die transienten Abhängigkeiten, also die die deine Bibliotheken dann auch noch mitbringen.
R2: Gibt es dann noch andere Probleme oder wirklich die Integration (…)
B2: Integration, genau die Integration ist ein wichtiges Problem und dann halt wenn, also wenn… also das ist sozusagen das Startproblem wenn ich loslege mit dem Projekt. Und was dann, das geht ja dann, wird ja dann weniger, weil irgendwann habe ich ja mal so einen Stack konfiguriert. Was dann aber viel mehr wird ist genau dieses Thema „irgendwo muss ich jetzt eine Bibliothek updaten“… ich muss sie irgendwie, warum auch immer, also ich brauche neue Features vielleicht von dem Framework, oder es gibt Security-Probleme oder sowas, oder der Support wird, läuft aus von meinem Hersteller, wenn ich nicht diese und jene Oracle-Version einsetze oder sowas. Das ist ja so typisch. Oder auf der neuen Xy-Server-Version läuft nur noch die und die Version, dann muss ich updaten. Und dann ist ja das Problem meistens, dass natürlich, man kennt das ja von sich selber, also dass in einem Framework, was ich mal entwickelt habe vor zwei Jahren, das würde ich ja heute niemals mehr so schreiben. Die API war totaler Crap. Das würde ich heute… ne? Und die war vollkommen inperformant, heute würde ich es komplett anders machen. Vielleicht auch noch in einer anderen Programmiersprache. Und das machen jetzt alle von den ganzen zehn machen das… ungefähr alle… ja, das ist eine gute Frage wann die das machen, vielleicht einmal alle zwei Jahre, sag ich mal einfach, machen die so einen richten Rewrite. So, und dann auch die ganzen transienten Abhängigkeiten, die machen das auch so. Plus… ich habe ja gesagt man versucht immer so… gut dokumentierte Tools zu nehmen, davon sind (.) mindestens… (…) also Bauchentscheidung, aber mindestens 30 % der Frameworks werden nicht mehr maintained, das heißt ich muss irgendwann das Framework wechseln. So und, also das ist eigentlich fast genauso schlimm. Ein Upgrade eines bestehenden Frameworks auf eine neue Majorversion würde ich fast genauso schlimm sehen, wie irgendwie ein ganz anderes Framework einzusetzen für ein bestimmtes Problem, weil meistens ändert sich komplett die API oder sie haben intern so viel umgebaut, dass das, was ich eigentlich drüber gebaut habe, nicht mehr funktioniert. Gerade bei mir gestern passiert, ich habe so ein Framework benutzt — Spring Cloud Sleuth — was dafür da ist so Tracing-Informationen durch ganz viele Microservices durch ganz viele Microservices automatisch zu generieren, durchzuschleifen und mir irgendwie für eine Auswertung bereit zu halten. Und da habe ich halt Zeitmessungen drauf aufgesetzt, auf die API. So ein… eigentlich ganz simple Millisekunden, die ich da abgefragt habe. Und die API, die neue, gibt es nicht mehr. Keine Chance. Drei, vier Stunden reinversenkt. Ich war dann irgendwo mitten in der, sie haben halt intern umgebaut, die hatten halt vorher irgendwas selbergeschrieben und dann haben sie jetzt Zipkin, OpenZipkin Brave benutzt und Brave hat das nicht intern und dann steht da halt ganz oft „ja, gibt es jetzt nicht mehr. Das gibt es nicht mehr, das gibt es nicht mehr. Musst du halt das nutzen, musst du da gucken“. Sie haben aber irgendwie oben in ihrer API haben sie ein neues Objekt eingeführt, was irgendwie dann doch nicht das Zipkin nutzt und dann geht gar nichts mehr. Das war irgendwie… das ist so ein typisches Beispiel wo man dann ewig dransitzt und eigentlich… (R1: Ist das jetzt ein Konfiguration) Wobei, das war jetzt kein Konfigurations-, sondern ein API-Problem. Aber Konfigurationsthemen hatten wir dann trotzdem, weil sich auch, wenn sich irgendwas ändert, kann sich ja genauso gut die Konfiguration ändern. Speziell in diesem ganzen Spring-Cloud-Umfeld ist es ja üblich, dass eben genau dieser zwei-Jahres-Rythmus mindestens eingehalten wird und dann alles anders ist und da wurde jetzt letztens gerade erst mit Spring Boot und Cloud 2 wurde der ganze Matrix-API umgebaut, das heißt diese ganzen Infastruktur-Leute, die jetzt darauf aufgesetzt haben, haben jetzt ein Problem, weil es immer komplett anders läuft… (…) jetzt irgendwelche Systemüberwachungen oder so. Das muss man ja auch alles aufsetzen und irgendwo dranhängen damit irgendwelche Admins vielleicht nachts rausgeklingelt werden wenn der Bestellprozess nicht mehr funktioniert oder so und das ist dann meistens nur ne Konfigurationssache, aber ja. Ist eigentlich, achso da habe ich mal eine Gegenfrage: Wenn ich jetzt so ein, Spring ist eigentlich ein gutes Beispiel, also früher wurden ja, hat man so Java-Code gehabt und dann hat man außerhalb von diesem Java-Code hatte man ne XML-Datei und hat damit konfiguriert, die Software. Also hat gesagt, dass sind meine Beans, meine Spring-Beans, das ist mein Application-Kontext und so weiter. Und dann ist das ja mal irgendwann, XML war nicht mehr so hip und dann ist das sozusagen in den Code gewandert mit Annotationen. Und so Klassen, also man theoretisch diese Klassen auch einfach, also den Inhalt der dieser Klassen kann man auch irgendwie überall im Code verstreuen, aber meistens wenn man es vernünftig macht, macht man so eine Configuration-Class oder vielleicht sogar eine Hierarchie davon, was das, was man früher in XML konfiguriert hat, das war ja dann ganz ersichtlich auf jeden Fall Konfiguration, weil es ein extra File war vielleicht oder so, was dann jetzt extra Klassen sind. Aber das ist ja auch Konfiguration… also, es ist zwar Code, aber es ist Konfiguration. Und ich glaube das wird bei anderen Tools auch so sein, dass viele viele Konfigurationen irgendwie in den Code wandern, weil es ja auch noch diesen, diese… wie sagt man? Diese Strömung gibt „everything as code“ eigentlich. Also wird es wahrscheinlich sogar noch zunehmen. Das heißt es ist dann nicht mehr so einfach rauszufinden, habe ich es jetzt mit Code-Code zu tun oder mit Konfigurations-Code? Und der macht natürlich dann auch Probleme, ne? Weil wie benutze ich die Spring-Konfiguration zum Beispiel ändert sich auch ständig. Und manchmal kommen vielleicht coole Sachen dazu, die ich unbedingt benutzen will oder so. Wo ich vielleicht… genau, das ist auch so ein Problem, das hatten wir ja sogar in dem Beispiel-Projekt an der Bauhaus-Uni, wo wir eigentlich so einen lokalen Entwicklungsprozess gebraucht haben, wir hatten dieses Frontend, was irgendwie auf nem Node-JS-Server bereitgestellt wird und das Spring-Backend. Und hatten dann diese Cores(?)-Probleme, diese Command-Object-Request-Irgendwas, ne? Diese wo dann diese Single-Origin-Policy irgendwie vom Browser sagt „ne, darfst du nicht aufrufen“ und da gibt es jetzt mittlerweile eine „add cross-origin“-Annotation, die einem komplett mal alle Probleme löst. Aber vorher hatte ich da irgendwie drei Seiten Code geschrieben. In zwei verschiedenen Programmiersprachen. Was, also, das ist ja auch so ein… das konfiguriere ich jetzt mit diesem „add cross-origin“. Das ist für mich eine Konfiguration, aber dahinter passiert ja dann Magic.
R3: Ist das immer, also das ist ja jetzt einfach das im Code zu konfigurieren. Ist das dann immer einfach? Also macht es denn Sinn generell alles im Code, also oder mehr Sachen im Code…
I1: Also ich würde sogar sagen, es verleitet halt, wie jetzt in dem Beispiel gesagt, dazu, dass man die Konfiguration über den ganzen Code verstreut. Also wenn ich da nicht ganz harte Richtlinien sozusagen im Team, also Richtlinien ist immer so ein hartes Wort, aber bei diesem Fall würde ich wirklich tatsächlich irgendwie, dass man so ein Code of Conduct oder so dafür einrichtet oder irgendwie sich darauf einigt, weil sonst hat man ein echtes Problem wenn dann der ganze, die ganze Implementierung irgendwie nur noch überall nur noch verstreut Konfigurationen enthält und wie kriegt man das wieder irgendwie zusammen. Also, speziell… es ist auch sehr wichtig, dass man da halt irgendwie Testgetrieben vorgeht, dann merkt man das immer sehr schnell wenn dann die Leute überall ihren… ihre Konfiguration verstreuen, weil meistens im Test möchte man halt die Konfigurationsklasse dafür oder die Konfiguration mit reinziehen um halt den Kontext herzustellen und wenn das dann nicht geht, dann merkt man „aha, du hast gar keine Konfigurationsklasse, du hast einfach irgendwie alles im Code verstreut“, dann… ja. Ich glaube konfigurierbare Software zu bauen ist halt auch so ein best-practice in der Softwareentwicklung… was man einfach tun sollte. Aus vielen Gründen. Und ja, das halt irgendwie herzustellen, das ist dann wieder so eine Frage, wie man das macht. Test-driven Development wäre eine so eine Möglichkeit… die dem Entwickler gleich selber auf die Füße fällt. Wenn der jetzt sagt „naja, meine Software ist nicht konfigurierbar“, aber das krieg ich ja nicht mit. Das fällt erst im Betrieb auf die Füße, weil da nicht in der Produktivdatenbank reingehen kann, dann ist das vielleicht zu spät, aber…
R1: Okay, was ist denn… nach ihrer Erfahrung besonders so ein besonders schwer zu konfigurierendes Framework oder Tool und warum ist denn das schwer konfigurierbar?
I1: Hm, schwer konfigurierbares Tool… mir fallen jetzt sofort Spring Cloud Netflix ein… was wie gesagt diese Konfigurationsparameter von zwei auf fünfzig gefühlt hebt. Das ist unter anderem glaube ich deshalb schwer… also einmal hat man halt genau diese Probleme drunter ja liegen, die das wegkapseln soll, der verteilten… von verteilten Systemen. Das heißt man hat auf einmal, muss ich halt irgendwelche Endpunkte von allen möglichen Dingen eintragen, ich muss ihm halt sagen „da ist deine Service-Registry und da ist dein was-weiß-ich-Endpunkt und hier nimm mal bitte noch das Spring Boot Admin, der da läuft, aber eigentlich sollst du das gar nicht wissen, also fragst du über die Registry ab“ und naja, dann kann ich allen noch Timeouts vergeben wie sie untereinander registrieren und wie sie dann aber eigentlich auch den fachlichen Request und sowas. Und das riesige Problem dabei ist auch, es ist sehr… verglichen mit den Spring Boot Sachen sehr schlecht dokumentiert. Also es gibt exponentiell mehr Konfigurationsmöglichkeiten, die sehr viel schlechter dokumentiert sind. Das ist so ein Ding, das macht es halt extrem schwer. Genauso wenn ich jetzt Richtung Infrasktrutur/DevOps und so denke, da fällt mir sofort Jenkins ein. Jenkins ist nämlich so ein Ding, was sich eher schlecht konfigurieren lässt oder sagen wir mal so, es hat extrem viele Bausteine, die ich beachten muss um dieses Ding in so einer… wie soll ich sagen, Infrastructure as Code-Manier hochzuziehen… weil es einfach… es ist halt irgendwie immer ne Krücke das Ding zu… was zum Beispiel GitLab viel besser macht, also… wobei das bei Jenkins glaube ich eher die Historie ist, das Ding gibt es schon ewig und wird immer wieder Abwärtskompatibel weiterentwickelt.
R2: Was macht GitLab besser?
I1: Naja, da kann ich halt tatsächlich das meiste konfigurieren, also…
R2: Jenkins ist schwer zu konfigurieren, weil man es nicht konfigurieren kann?
I1: Naja… man kann es nicht mit einer einheitlichen Schnittstelle wirklich komplett konfigurieren. Also das wichtige ist eingentlich, dass man irgendwas… wenn das irgendwie sagen wir mal hier ein Konfigurations…API hat, dass man das dann darüber auch vollständig konfigurieren kann und das ist bei Jenkins nicht so. Da gibt es halt ganz viele… wenn ich jetzt irgendwie das eine Thema kann ich da konfigurieren, das nächste muss ich das machen, das nächste muss ich an der anderen Stelle machen und hier muss ich dann eigentlich noch mal manuell dann da klicken, was ich natürlich nicht will, weil ich will es ja komplett hochziehen ohne, dass jemand draufguckt. Und dann, das macht GitLab halt besser, das kann ich tatsächlich… und was mir auch einfällt, das ist jetzt zum Beispiel Kubernetes, wenn man sowas selber betreiben will und hochziehen will, dann ist das auch Hölle komplex und… da ist es tatsächlich auch so, diese vielen Moving Parts, die das halt mitbringt, also es sind eigentlich immer, wenn ich ganz viele Dinger habe, die ich irgendwie zusammen konfigurieren muss, ganz viele einzelne Teile, dann wird es halt komplex… mit der Konfiguration. Also… weil keine Ahnung, das zerfällt ja in… das kann man ja vergleichen mit Docker Swarm, das ist ja auch so ein Container Scheduler, da hab ich halt im Endeffekt einfach nur dieses Dockerding, was ich irgendwie zusammen(?) benutzen muss (R1: (?)) ja, und bei Kubernetes habe ich irgendwie, keine Ahnung, zwanzig Komponenten, die ich erstmal irgendwie integrieren muss. Die aber alle Wechselwirkungen haben und alle richtig zueinander stehen müssen und so.
R2: Also sozusagen wieder als würdest du viele kleine Tools wieder konfigurieren, also ist eigentlich das nur eine Ebene tiefer.
I1: Ja, genau.
R2: Okay… also das heißt die Tools, die schwer zu konfigurieren sind, sind die die im Prinzip wieder zerfallen (I1: Ja) in kleine Tools.
I1: Ja, genau. Weil da muss ich mit jeder Konfigurations-API von jedem Tool rumschlagen und das auch richtig machen und…
R2: Machen das die meisten so, oder?
I1: Na, viele versuchen dann halt das irgendwie zu umgehen und versuchen halt sowas, wo ich dann sozusagen mal ganz platt gesagt ein ausführbares Programm habe, was ich dann irgendwie konfiguriere und das macht dann alles im Hintergrund für mich. Zum Beispiel Kubernetes-Installer oder sowas oder gerade Vectide aus der Cloud irgendwo einfach benutzen, die Schnittstelle und fertig. Und gar nicht groß… naja, konfigurieren schon, die haben dann halt irgendne Weboberfläche, wo du da so die wichtigsten Sachen vergibst. Irgendwie den Clusternamen und die IP-Address-Range und dann sagst du „create“ und das war's. Und alles im Hintergrund läuft irgendwie für dich… transparent.
R2: Okay… So, dann gehen wir mal weiter. Es gibt ja Konfigurationsabhängigkeiten über Framework-/Toolgrenzen hinweg. In wie weit spielen die denn eine Rolle für, erstmal für die persönliche Arbeit?
I1: Genau, über die Tools hinweg ist, also eigentlich würde ich das sagen, wenn ich jetzt die Frage richtig verstehe, ist jetzt praktisch das gleiche Thema, wie… ich hab mehrere Tools in meinem Stack und die muss ich halt integrieren und das ist eigentlich, wie gesagt, pro Tool ist das immer sehr gut dokumentiert… und vielleicht noch mit dem am meisten verwendeten Nachbartool ist auch noch ganz gut dokumentiert und dann hört es auf.
R2: Und wie beeinflusst das deine persönliche Arbeit? Weil du hast ja vorhin gesagt (I1: Genau, also) du hast drei Stunden oder vier Stunden gestern versenkt.
I1: Da geht eigentlich die meiste Zeit rein, weil… das Tool für sich ist eigentlich immer relativ schnell… aufgesetzt oder man kann halt gut nachlesen oder sich einarbeiten, da gibt es auch viele Kurse und so, aber grad diese Integration… von mehreren Tools ist halt wahrscheinlich sogar mit die Hauptarbeit dann. Weil da ist halt dann auch immer ein bisschen Forschung und Entwicklung sozusagen, wie es immer so schön heißt. Wo man nicht so… (?) schwer auch dem Projektmanagement dann zu kommunizieren. Weil man dann sagen muss „ich hab keine Ahnung wie lange das dauert. Keiner hat eine Ahnung wie lange das dauert.“ (lacht) „Wir sollten es aber tun und dann…“ (…) Ja, also… das ist schon ein wesentlicher Teil und wesentlicher Arbeitstreiber.
R2: Wie beeinflusst das die Fehler? Fehlerfreiheit?
I1: Auch dementsprechend stark, weil alles was sozusagen… also oft sind das dann Pfade, die nicht so oft gegangen werden. Also komischerweise sogar sehr häufig, also das ist eigentlich eine ganz komische Erfahrung, die ich aber schon oft gemacht habe, gerade wenn man sagt „naja, wir wollen jetzt ein neues Projekt starten, was nehmen wir denn für einen Tech-Stack?“ und dann sagt man „okay, wir nehmen das hier, wir nehmen das hier, wir nehmen das, wir nehmen das, wir nehmen das“ und alles ist, sagen wir mal, de facto Standard gerade. Dann gehe ich mal in meinem naiven, jugendlichen Leichtsinn davon aus naja, dann muss das ja auch gut zusammenarbeiten… Nein (lacht) und es ist nicht dokumentiert oder sehr wenig dokumentiert…
R2: Also das heißt die Dokumentation ist eigentlich das Hauptproblem.
I1: Genau. Also sei es jetzt direkt vom Hersteller oder von dem Tool irgendwie auf der Webseite oder halt auch bei irgendwelchen Sachen wie Stackoverflow oder… ja.
R1: Gibt es auch… Gründe das vielleicht das auch gar nicht zusammenpasst, also?
I1: Genau, das kann auch rauskommen. Also… es kann ja sogar sein, man hat das Tool vielleicht gar nicht richtig verstanden. Was es überhaupt macht. Also man geht davon aus, ich nehme jetzt ein Tool um Messaging zu machen und dann stellt sich raus, das ist vielleicht für was ganz anderes gedacht. Und dann hat man natürlich irgendwie ein Problem, aber… manchmal ist das auch nicht so ersichtlich, also… weil natürlich auch wieder Herstellerinteressen dahinter stehen und… das hatte ich auch am Dienstag bei dem Startup… war genau dieses Thema. Wir haben zwei Probleme, das eine ist Infrastrukturmonitoring und das andere ist fachliches Logging/Logkorrelation über mehrere Anwendungen. Und ganz, wenn man die Themen für sich betrachtet, könnte man sagen, die aktuellen State-of-the-Art-Tools für das eine Problem ist Prometheus, für das Monitoring und für das Logging/Logkorrelationen Elastic Search oder überhaupt der ganze Elastic-Stack. So, wenn man jetzt aber auf die Webseiten guckt, dann sind da auf einmal nicht nur diese Themen die sie, für die sie sozusagen gedacht waren drauf, sondern sind, beim Elastic Stack sagen wir mal, ganz viele Monitoring-Themen. Und dann sitzt man da mit dem Kunden und der sagt „guck mal, die können ja auch Monitoring“ — „Ja, (lacht) kann man auch machen, das wollen die auch, dass man das so macht, aber vielleicht ist es mit dem anderen Tool besser.“ das heißt es gibt dann auch noch dahinter dann irgendwelche Interessen, die da versuchen vielleicht… wo also Unternehmen dahinter stehen, die wollen dann einfach nen breiteren Markt… haben, durchdringen… wachsen und so weiter und dann… wird das also auch verwässert. Also es gibt da keinen klaren Blick drauf, man muss denen eigentlich immer wieder… schaffen, das ist eigentlich… Hauptarbeit sozusagen dabei. In der Beratung. Aber das hat jetzt mit Konfiguration vielleicht weniger zu tun.
R2: Wie beeinflusst das dann das Deployment, diese ganzen Abhängigkeiten?
I1: Ja auch stark, ne? Weil ich muss ja das… also das Deployment setzt ja dann voraus… also modernes Deployment läuft kontinuierlich ab, das heißt also möglichst fünf mal am Tag geht man in Produktion mit Änderungen. Oder vielleicht, man geht sogar dahin, dass jeder Commit eines Entwicklers direkt nach Produktion geht. Und dann muss ja dieser ganze Prozess vollständig automatisiert sein, also da kann keiner mehr irgendwo ne Hand anlegen, höchstens maximal noch sagen „okay, das soll jetzt 20 % der Leute schon erreichen“, so mit so einem Blue-Green- oder Canary-Deployment und wir testen das jetzt mal in so einer kleinen Gruppe. Das kann man vielleicht noch konfigurieren, aber der Rest ist komplett automatisiert. Und dann muss natürlich auch das… diese ganzen Bestandteile müssen alle vollständig automatisiert deploybar sein und eben auch automatisiert konfigurierbar sein. Also das hängt dann dran. Das heißt es ist extrem wichtig für das Deployment, dass die Konfiguration dann passt.
R2: Wahrscheinlich dann auch genauso für das Testing, oder?
I1: Für das Testing… ist es vorallem dann… Unit-Tests machen meistens sichtbar, ob man irgendeine Sache überhaupt unittesten kann. Wenn das nicht sozusagen konfigurierbar ist, dann… wird es halt schwierig irgendwie.
R1: Also vielleicht eine andere Frage dann
(PAUSE)
R1: Ist eigentlich noch die Konfiguration, spielt die beim Team-Meeting, also wenn wir jetzt mal so ein Scrum-Meeting haben oder sowas, eine besondere Rolle oder wird das einfach weggedrückt irgendwie?
I1: Ich würde sagen eher… weniger, also eher so in dem Ding, dass man sagt es gibt da ein Problem und wir müssen da mal draufgucken, aber dann die weitere Diskussion, die Lösung ist dann eher so mit diesem, genau diesem technischen Entwickler oder den technischen Entwicklern… davon gibt es meistens auch nicht so viele. Also meine Erfahrung ist, Fachentwickler sind meistens mehr da. Also wenn ich in so einem Team habe, dann habe ich vielleicht sechs Fachentwickler und zwei, drei die sich eher so um diese… technischen Themen und… hab ich vielleicht vorhin auch vergessen bei den Rollen, also eher dieses Lead-Developer, die vielleicht auch sagen so entwickel ich überhaupt, also man kann ja auch so und so entwickeln. (…) rein auch im Code, wie testgetrieben oder wie gehe ich vor oder so. Und das beschränkt sich dann eher auf einen kleinen Kreis, die das dann lösen und dann zum nächsten Scrum-Meeting wieder mitbringen und sagen „hey… läuft jetzt“ oder so.
R1: Vielleicht eine Anschlussfrage: (…) gesagt, dass es (…) immer ne sehr starke Rolle für die Fehlerfreiheit, für das Deployment, eigentlich für alles, es ist eine extrem starke Rolle und trotzdem ist das anscheinend ne untergeordnete Rolle im Scrum-Meeting jetzt zum Beispiel. Ist das ein Widerspruch? Würde man sich da wünschen, dass das mehr thematisiert wird, oder?
I1: Das berührt eine ganz alte… ne ganz alte Wunde bei mir, weil ich schon immer eher an diesem technischen, ich sage jetzt mal, früher hieß das klassisch Framework-Entwickler oder so, also das gab es auch immer, meistens hat sich das schon in der Organisationsstruktur gezeigt, es gab zum Beispiel zehn Fachentwicklerteams, die aufgeteilt waren nach den Funktionen des Unternehmens zum Beispiel, also für Marketing gab es ne Abteilung, für was weiß ich, ne? Für Backendprocessing gab es ne Abteilung und so weiter. Und ein Team war dann sozusagen für die komplette Software-Entwicklung, also wie entwickelt man, mit welchen Tools und so weiter, zuständig. Und das ist immer unterrepräsentiert, weil im Unternehmen habe ich ja Business-Ziele. Und die Business-Ziele schlagen sich auch heute im, natürlich im Scrum wieder und ganz oft ist es aber so, dass dann das Backlog halt gefüllt ist mit fachlichen Zielen, fachlichen Userstorys, was auch immer und du hast aber auch technische Userstorys. Und das ist für mich ein total ungelöstes Thema, wenn man sozusagen keinen Scrum-Master hat, der immer wieder drauf achtet das zumindest sowas wie 30 % der Items oder der Tickets dann immer auch technische oder Architektur-Themen, dann hat man immer das riesen Problem, dass die anlaufen. Also die sammeln sich als Bodensatz im Backlog und werden immer mehr und die technischen Schulden halten aber, das versteht oft der fachliche Teil eher nicht, dass diese, sich ansammelnden technischen Schulden dafür sorgen, dass die fachlichen Tickets viel langsamer, immer weiter langsamer und viel weniger umgesetzt werden können, weil ich mich immer wieder mit irgendwelchen Workarounds beschäftige, die halt da sind, die da sein müssen, weil die technischen Sachen nicht so laufen wie sie sollen. Das heißt, aus meiner Sicht ist das halt ein riesen Thema in dem… dass das halt eigentlich keine große Rolle spielt, obwohl das extrem viel ausmacht, wie ich meine Softwarearchitektur gestalte auf das, was ich dann hinterher im Business machen kann. Das ist halt dann immer so eine extrem große Herausforderung. Gerade auch, ich sag mal, bei vielen Kunden, wo ich jetzt unterwegs war, das waren halt Finanzdienstleister. Wo man erst so langsam, langsam versteht, dass das Kerngeschäft eines Finanzdienstleisters vielleicht doch IT ist. Und nicht nur irgendso eine Shared-Service-Abteilung, die ich am besten noch outsource. …
Aber es ist ein ungelöstes Problem… also aus meiner Sicht.
R1: Sehr gut, ja… vielleicht, wir hatten ja vorhin noch nach einem schwer einzelnes Tool zu sprechen, vielleicht nochmal, vielleicht ganz kurz eine Antwort oder so, gibt es es spezielle Kombinationen aus Frameworks/Tools und so weiter, die schwer zu konfigurieren sind? Und warum?
I1: (lacht) Kombinationen, da fällt mir gar nichts ein (sarkastisch) (lacht).
R2: Also die Frage muss dann weiter nach oben. (Zustimmung der anderen)
R1: Ja, also… oder gibt es vielleicht
I1: Irgendwie hatten wir, die doch auch schon mal so in abgewandelter Form.
R2: Ja okay, dann hören wir noch mal rein denke ich.
R1: Okay… also die Frage ist eher so
I1: … vielleicht war die Frage, die vorhin war, glaube ich, Frage welche Tools sind an sich schwer zu (R1: Ja, genau) konfigurieren und jetzt welche Tools sind in Kombination schwer zu konfigurieren (R1: Ja). Die gleichen. Wenn ich die konfiguriere, wird es noch schlimmer.
(Lachen)
R1: Das ist doch eine kurze und knappe Antwort.
I1: Also wird es noch viel schlimmer. Und dann habe ich noch mehr ein Problem wenn das im Scrum-Meeting kein Thema ist.
R1: Ah okay. Wie werden eigentlich Konfigurationen verwaltet?
I1: Oh (lachen) und dann hatte das Interview noch eine zusätzliche Stunde.
(Lachen)
I1: Tatsächlich vor zehn Jahren, als ich angefangen habe, war Konfiguration immer noch so ein nice-to-have, was man gerne… was die Leute, die so best-practice-mäßig unterwegs waren, einfach gemacht haben, weil sie wussten, dass man wir das brauchen und viele hatten halt noch nicht konfigurierbare Software gebaut oder die Konfiguration irgendwie ignoriert oder irgendwo hingeschrieben oder was weiß ich. In irgendwelchen Files, die halt keiner kannte. Möglichst außerhalb des Versionskontrollsystems… was war die Frage?
R1: Wie wird es verwaltet?
I1: Ja genau, also die Verwaltung ist ein… riesen Thema, was auch immer meistens unbeantwortet blieb in der ganzen Zeit, die ich jetzt in der Software-Entwicklung bin, weil die Konfiguration hat ja, ist ja direkt abhängig vom Code. Also wenn ich jetzt irgendwas am Code ändere… also die Konfiguration wird ja meistens irgendwie eingelesen in den Code und wird da irgendwie verwendet. Und wenn ich… also… wenn ich den Code jetzt ändere und ich habe irgendeine Konfiguration, die nicht mehr zum Code passt, dann habe ich ja ein Problem. Das kann ja potentiell ständig passieren wenn sich Code-Änderungen ergeben können. Das heißt, ich muss eigentlich die Konfiguration immer in Abhängigkeit vom Code verwalten und da Code im Versionskontrollsystem liegt, sollte Konfiguration auch immer im Versionskontrollsystem verwaltet werden. Am besten irgendwie direkt verknüpft. Oder zumindest nah beieinander oder so. Das war früher oft nicht so und das war ein riesen Thema. Da wollten auch viele Hersteller das irgendwie lösen mit sogenannten Configuration-Management-Databases und die sollten riesig eingeführt werden in Big-Bang-Sachen in Unternehmen. Das hat nie geklappt, ich hab es nie gesehen, dass das geklappt hat. Weil die Hersteller das meistens versuchen generisch irgendwie zu lösen, das Thema. Und das hat aber nie funktioniert, weil die ganzen einzelnen Software-Entwicklungsprozesse einfach komplett verschieden waren und diese ganzen Anforderung abzudecken war mega schwierig. Jetzt mit dieser ganzen Thematik Microservices, DevOps, Continuous Delivery und so weiter, ist es oft so, dass diese Infrastructure as Code Tools oder DevOps-Tools das einfach mit dabei haben, wie man Konfigurationen verwaltet. Weil die genau wissen, die haben ja das Problem… ich muss nicht nur was deployen, sondern ich muss es auch entsprechend konfigurieren. Das heißt heute wenn wir zum Beispiel in einem Projekt so Tools, wie Ansible einsetzen, dann empfehle ich halt auch immer (…) die Konfigurationen da direkt dort auch abbilden. Ist immer am einfachsten. Und führt halt dazu, dass das Zeug im Versionskontrollsystem steht und führt dann zu so lustigen Anrufen, wenn die Infrastruktur-Admins dann bei dir anrufen und sagen „Ähm du, wir hatten doch mal diesen Server da. Ich weiß, ihr macht doch das mit dem Ansible. Kannst du noch mal da in den (?) gucken, da steht doch wie die IP und (lacht) die, der Datenbankname war von diesem und jenem… Produkt oder so, dass er dann.“ Also, das wird dann automatisch irgendwie genutzt. Also Versionskontrollsystem ist am besten.
R1: Okay, wenn ich jetzt sagen wir mal überlege, jetzt hat man, jedes Tools hat seine eigene Datei und so weiter, alles liegt in Versionskontrolle und so weiter Systemen(?)… also bedeutet das es wird… man hat eine globale Übersicht, oder man hat keine globale Übersicht, oder man braucht sie nicht, oder?
I1: Das ist eine gute Frage. Ich würde fast sagen, man braucht diese globale… wozu braucht man denn die globale Sicht? Das wäre jetzt die erste Frage. Also ich glaube man braucht die Sicht immer dafür um ein Stück Software, was irgendwie laufen muss damit das läuft. Dafür brauche ich die komplette Sicht auf diese Software. Wenn die jetzt mal in einem Beispiel aus fünf Microservices besteht, die jeweils einzeln konfiguriert sind, dann brauche eine Sicht auf alle fünf Microservices. Dann muss halt die gesamte Konfiguration für diesen Anwendungsteil da sein. Damit der Anwendungsteil läuft, braucht er aber nicht vielleicht eine ganz andere Software, die auf irgendwie monolithisch basiert irgendwo anders auf irgendeinem anderen Server liegt, da brauche ich vielleicht die Sicht nicht drauf. Das ist auch… das ist auch glaube ich unrealistisch, dass man das jemals kriegt. Also in großen Unternehmen ist es glaube ich einfach komplett utopisch, dass man, ja… dass man jemals so eine Gesamtsicht kriegt. Also das war ja aus meiner Sicht einer der Gründe, warum auch diese Einführung von diesen Configuration-Management-DBs gescheitert ist, weil das ist so weit weg von den Businesszielen. Also wenn schon diese technischen Themen, da eigentlich dafür da sind um das Projekt nach vorne zu bringen nicht Thema des Scrum-Meetings sind… dann muss man sich mal überlegen, dass sind noch, noch viele Schritte zurück zu sagen, ich tue jetzt irgendwelche Configuration Items über das gesamte Unternehmen zusammenführen. Das hat einfach überhaupt nichts mit dem Business zu tun und dann wird es nicht gemacht.
R1: Ah, okay… Ok, bloß noch mal zum klarstellen, also Konfigurationen werden auch nicht im Team kommuniziert oder so?
I1: Was heißt kommuniziert? Wo man jetzt was einstellen müsste damit irgendwas geht, oder?
R1: Ja, oder
R2: Wird das irgendwie besprochen in Meetings oder weiß ein anderes Teammitglied welche Konfigurationen und Abhängigkeiten
I1: Also oft gibt es halt irgendwie Wikis, wo schon steht wenn du jetzt in dem Teilbereich bist, du beschäftigst dich mit Docker, da gibt es schon meistens schon so eine FAQ und dann wird meistens verwiesen dann direkt auf die entsprechenden Stellen im Versionskontrollsystem. Das ist eigentlich so üblich. Und wenn ich das halt alles im Versionskontrollsystem habe, kann ich sogar nachschauen wenn es nicht dokumentiert ist. Das ist ja immer dann schon Doku. Weil es ist da drin. Wenn es außerhalb ist, keine Chance. Wenn das nur irgendeiner weiß, der dann vielleicht gerade im Urlaub oder krank ist, dann.
R1: Ok, also wird das nicht gesagt, wenn ich jetzt nicht gesagt wenn ich jetzt mal meinen Port ändere… im nächsten Meeting… Achtung, ich habe jetzt meinen Port geändert, sondern man muss dann selber…
I1: Naja gut, also solche Schnittstellenthemen, die werden schon kommuniziert oft. Klar. Also das ist, also wenn das irgendwie Auswirkungen auf die Zusammenarbeit im Team hat, oder zwischen Komponenten, die jetzt mehrere Leute betreffen, dann wird das schon kommuniziert. Dann ist das auch sehr schnell auf einmal Thema im Scrum-Meeting. Das ist vielleicht ganz witzig. Also solange es nur als technische Schuld irgendwo im Backlog liegt, ist das so „pff, naja diese technischen blabla, ja das müssen wir jetzt nicht machen. Ich will jetzt meinen Button haben!“, ja? So. Damit der Fachbereich glücklich ist. Aber sobald irgendwas nicht geht, kriegt man auf einmal, ich meine das kann jetzt dazu führen, dass man dann eine gewisse Taktik entwickelt, aber dann kriegt man auf einmal sogar ganze Sprints wo man nur technische Themen macht. Ne, weil dann ist es ja auf einmal wichtig. Wenn wirklich alles steht, dann darf man machen. (lacht) Ein Schelm, wer sich jetzt denkt, dass… nein, also, aber das ist schon so ein Thema und klar, an diesen Schnittstellen ist es immer (???)
R2: Funktioniert denn diese Art der Kommunikation, oder ist das eher problematisch?
I1: Die ist in sofern problematisch, weil sie meistens… irgendein Tech-Entwickler/Lead-Entwickler oder was auch immer, technischer… Kollege ändert was und sagt „ich hab im Kubernetes-Cluster im CNI-Plugin… von CubeDNS auf was weiß ich umgestellt“ und die anderen Fachentwickler sitzen da… mit offenem Mund und… großen Augen. Ne, so. Und oft ist gar nicht so unbedingt erkennbar für die, also es kommt wieder auf den Menschen drauf an, der das macht, aber oft sind dann diese sehr, sehr technisch orientierten Leute vielleicht auch eher… ein bisschen introvertiert, autistisch verlanlagt und die erzählen dann technische Details, die die anderen nicht verstehen. Aber die Auswirkungen, die die anderen spüren werden, von denen sagen sie nichts. (lacht) Und das ist natürlich ein Problem.
R1: Okay, vielleicht auf für dich noch wichtig für deine, das steht jetzt nicht so direkt drauf. Bei der Kommunikation, ist das dann generell eher so im Person-to-Person, also steht man sich gegenüber oder gibt es auch, oder E-Mail, oder…
I1: Achso, ich habe jetzt viel von agilen Prozessen geredet, ne? Es gibt natürlich auch noch ganz, ganz, also da ist es ja, das sind alles kleine Probleme sag ich mal, weil man da miteinander redet. Aber in großen Organisationsstrukturen, wo diese Konfigurationen, die für ein Softwaresystem notwendig ist, über mehrere Abteilungen oder Teams verteilt ist… Oh Gott, oh Gott. Da kann es sogar sein (R2: Hast du das schon erlebt?) Ja, schon oft. Da kann es sogar sein, dass irgendwas geändert wird in der Konfiguration und keiner kriegt es mit von den anderen. Also das wird dann vielleicht irgendwo in ein Teamwiki geschrieben… weil das die Richtlinie war, dass man jetzt dokumentieren muss und auf das Teamwiki hat leider keiner außerhalb des Teams Zugriff. Und von jetzt auf gleich geht gar nichts mehr und das Problem ist aber, das andere Team, das Softwareentwicklungs-Team ist vielleicht dafür, für den Service verantwortlich, dass das Ding irgendwie da ist oder funktioniert und es geht aber nichts mehr und dann… sozusagen… dann gibt es ein riesen Problem, weil… das passiert ganz oft mit diesen, sagen wir mal, Infrastruktur-Themen, die man jetzt nicht so… die man einfach nicht auf dem Schirm hat, also sowas wie eine Netzwerk-Konfiguration oder so. Ja, irgendwelche Firewall-Regeln oder, oder irgendwelche Webapplication-Firewalls, die jetzt auf einmal Sachen filtern, die sie vorher nicht gefiltert haben, das sind so ganz, ganz beliebte Sachen. Die… wo auch die Leute, die das konfigurieren überhaupt keinen Einblick haben, was das für Auswirkungen hat. Das, was man machen müssen, weil irgendwelche Vorgaben sind aus sicherheitstechnischen oder von irgendwelchen Audits oder so. Ja, und dann… und meistens treten diese Dinge natürlich geballt auf. Also mehrere von diesen Dingen auf einmal. Weil irgendwie ein Audit jetzt und gleichzeitig ist irgendwie ein Projektabschluss und bei dem ist noch, was weiß ich, das Framework gerade kaputt, weil irgendeine Abhängigkeit kaputt ist und das kommt alles natürlich zusammen. Also Murphys Gesetz ist es auch immer.
R1: Okay, jetzt haben wir eigentlich diese Rubrik abgeschlossen. Ich glaube die nächste können wir auch ein bisschen auch kürzer halten, weil wir schon vieles… eigentlich schon mit behandelt haben. Genau, also das wäre jetzt Konfigurationsfehler. Da haben wir jetzt schon viel drüber geredet. Aber vielleicht noch mal grob, was sind denn Konfigurationsfehler… ne Einschätzung, also wie würde man das sagen „das ist jetzt hier ein Konfigurationsfehler.“?
I1: Ja, also wenn vielleicht die, die Konfiguration nicht mehr zur Softwareversion passt, oder wenn die Konfiguration vielleicht augenscheinlich funktioniert… das richtige Ergebnis herbeiführt, aber vielleicht irgendwelche Wechselwirkungen/Nebenwirkungen hat, die man nicht sieht. Also ich konfiguriere das so, dass meine Software geht und damit, dafür mache ich aber jetzt irgendein Security-Problem auf oder so. … Oder Performance-Problem. Das ist glaube ich das, was am häufigsten passiert wenn ich mal so drüber nachdenke. Also irgendeine, irgendein… irgendeine Konfiguration führt dazu, dass meine Software zwar erstmal läuft und da guckt auch keiner mehr drauf, weil das läuft auch so durch in allen Tests, alle Tests sind super. Wenn ich dann vielleicht keine automatisierten Performancetests habe, dann geht das nach Produktion und auf einmal… macht halt diese Software zum Beispiel statt vorher irgendwie gepoolte Datenbank-Connections nutzt das jetzt halt immer persistente Verbindungen, die einzeln neu aufgemacht werden, jedesmal wenn hier auf die Datenbank zugegriffen wird und leider wird in der Software halt 200 mal auf die Datenbank zugegriffen pro Webservice-Call und jetzt kommen halt 10.000 Webservice-Calls. Parallel pro Sekunde und jedesmal gehen, also dann fährt man mal einmal komplett die Produktion an die Wand und hat halt ein Konfigurationsding, was an sich, lokal sah das gut aus, auch auf dem Continuous Integration Server noch und dann ist halt aber… die Produktion.
R2: Das ist also mit der schwerwiegendste Fehler? Oder der schlimmste?
I1: Ja, das sind, das sind so solche Sachen sind, sind oft. Aber was war der schwerwiegendste Fehler? … Ja, eigentlich meistens sind es diese Performance-Sachen oder, dass halt Teile der Service-Funktion irgendwie abgeklemmt werden ausversehen. Das halt, vielleicht geht irgendso ein, mein Use-Case, den ich immer so auch noch mal durchklicke, der funktioniert irgendwie… ganz gut. Sieht normal aus. Aber dann in einem, irgendeinem Zusammenhang funktioniert jetzt halt gar nichts mehr oder so. Das ist halt… aber das ist auch sehr schwer im Griff zu behalten in so einem riesen Software-Zoo.
R2: Und wie oft treten so Fehler auf?
I1: Gute Frage, also das kommt glaube ich immer auf die Teamgröße/Unternehmensgröße und so an. In dem letzten Unternehmen wo ich war, das war nicht so groß… da hatte man tatsächlich die meisten Probleme haben zwei, die zwei hauptsächlichen Entwicklungsteams… verursacht sage ich jetzt mal, also… die haben halt gearbeitet und weil wer sägt, da fallen Späne oder so. Aber… wenn ich das jetzt in einer großen Organisation sehe… also große Organisationen werden eigentlich automatisch irgendwie gefühlt langsamer, weil sie halt irgendwie den ganzen Zoo auch irgendwie einfangen müssen. Das ist irgendwie, glaube ich, bisschen fast naturgemäß. Außer man setzt halt wirklich massiv diese ganzen Vorgehensweisen ein, wie Test-Driven Development und continuous, continuous, continuous und irgendwie Blue-Green und sonstwas.
R1: Kannst du das irgendwie so quantifizieren wie oft das jetzt auftreten.
I1: Ah, das ist schwierig. Also, wie oft tritt das auf? Also wie gesagt, immer Murphy, das heißt immer geballt. Also ich würde mal sagen, also so… also da in diesem Unternehmen, das waren halt insgesamt 150 Leute und die zwei Entwicklungsteams hatten vielleicht jeweils so zehn, zwölf Leute, 15 Leute. Das heißt bei 30 Leuten und da trat das vielleicht so alle… zwei bis vier Wochen mal auf, dass mal so richtig schön was eingecheckt wurde, was… dann auch durchgelaufen ist. Und ich würde aber sagen (R1: Bis zur Produktion?) Genau, was bis zur Produktion durchgelaufen ist und man kann ja noch sagen, was sind so Konfigurationsfehler oder irgendwelche Fehler, die dann, das ist schon häufiger vorgekommen, also da kann es schon sein, dass das mal so einmal am Tag oder so. Tut schon jemand was einchecken, was irgendwie Stuss ist und dann… bleibt auch mal irgendwas stehen oder so.
R1: Das wird aber vorher abgefangen, meistens?
I1: Ja, man versucht das dann abzufangen, aber… manchmal ist aber auch das Abfangen teurer als dass es auftritt. Wenn du jetzt zu viele Akzeptanztests und Oberflächentests baust, dann musst du die halt auch warten. Die sind halt extrem wartungsintensiv und dann muss man halt immer abwägen was baue ich jetzt wirklich. Genau, da fällt mir was ein, was wir gar nicht hatten vorhin. Ne Konfiguration, gerade bei diesen Maven, also wenn ich jetzt Microservices baue, dann habe ich ja Services, die für sich erstmal stehen. Aber im Grunde kann man ja sagen, dass sind ja wie gesagt diese Probleme, die ich mit Monolithen hatte, multipliziert, wenn ich jetzt in einen so einen Service reingucke, dann ist der ja oft trotzdem noch modular an sich aufgebaut. Das heißt der hat jetzt verschiedene Abhängigkeiten und die Abhängigkeit kann jetzt sein… dass man das, was ich halt vorhin gedacht habe, dass man irgendeine Maven-Bibliothek oder irgendeine Library reinzieht, die man halt nutzt, die ist jetzt am Markt, Open-Source verfügbar ist. Aber es ist ganz oft auch so — da kommt der Framework-Entwickler — dass ich innerhalb des Teams oder innerhalb des Unternehmens halt Frameworks baue, die ich anderen Entwicklern zur Verfügung stelle. Und die haben ja einen eigenen Entwicklungszyklus und werden aber mit den gleichen Mechanismen eingebunden. Das heißt die haben irgendwo ein Git-Repository, daraus wird irgendwie per Build-Prozess, jetzt Maven oder Gradle oder sowas, ein Artefakt erzeugt, das wird in irgendein Repository gestellt, wie so ein Nexus oder sowas, oder Artefactory. Und aus diesem Artifactory ziehen sich das wieder andere in ihre Software und nutzen das. Und da kann natürlich, da passiert auch unglaublich viel. Also zum Beispiel ganz, ganz und das ist glaube ich noch schlimmer als diese Performance-Dinge und so, ja ich glaube das ist das schlimmste Problem… ist, wenn ich sage ich habe ein fachliches Datenmodell, also sagen wir mal ich bin jetzt in einer Versicherung und habe halt so diese ganzen Dinge, die ich da habe, hier Kunde und (?) und Antrag und Auftrag und sowas. Und die haben irgendwelche fachlichen Attribute. Und das Ding wird halt entwickelt von zwei, drei Leuten, die das halt so ein bisschen im Auge behalten und dann… ändern die das. So, und das nutzt jetzt jede von diesen Microservices — das ist natürlich ein Anti-Pattern, das würde ja nie einer so bauen, weil alle haben das DBD-Buch bis zum Erbrechen gelesen und verstanden (sarkastisch) … nicht. Also nutzen das jetzt alle Microservices und da kann ich ja in jedem Microservice sagen ich nutze jetzt dieses fachliche Framework in der Version. Und da können ja auch, also da können und passieren so viele Fehler. Weil jetzt ändert der, der eine Microservice hat die Anforderung jetzt im Backlog irgendeine Userstory jetzt abzubilden. Dafür braucht er drei neue Felder in diesem fachlichen Datenmodell. Das wird jetzt geändert, der zieht das bei sich rein, dann stellt man fest ach ne, ich muss auch noch drei bestehende Felder ändern. Dann zieht der das bei sich rein, dann wird das fachliche Feature entwickelt, der Sprint ist rum, alles ist schön. Dann kommt der nächste Microservice, der ist im nächsten Sprint dran, gibt es es wieder Änderungen an dem Datenmodell, der nimmt das, merkt schon „oh, da hat sich ja was geändert. oh, hm, da muss mal drei Tests anpassen. Ah, das geht nicht mehr so. Ah, ja, das wird schon irgendwie gehen. Ich füge noch meine drei Felder noch hinzu und ändere noch fünf andere und erstelle eine neue Version.“. Und dann irgendwann, zwei Monate später, keiner hat mehr an das Ding gedacht und keiner an diese Änderungen, passiert irgendwas. Dass vielleicht irgendeine SQL-Injection, steht in diesem fachlichen Datenmodell drin, also alle müssen auf einmal dieses neue, die neuste Version nutzen. Von dem Datenmodell. Und ziehen das gedankenlos halt rein, suche einfach „latest“ beim, im Artifactory „ah ja, da sind fünf Versionen, da gibt es ja schon fünf neue Versionen, nehmen wir einfach mal die neuste“ und dann geht gar nichts mehr. Alle ziehen das rein und überall brechen alle Tests zusammen, keiner weiß was passiert hier eigentlich. Da fehlen dann irgendwelche, das kompiliert nicht mehr, die Tests laufen nicht mehr, wenn man es irgendwie compilefähig gemacht und keiner weiß mehr… was los ist. Und das kann man dann so… alle… zwei, drei Wochen wieder machen. Weil es immer wieder passiert. Das ist eigentlich… und das ist ja auch konfiguriert, also ich konfiguriere das in meiner pom.xml, neue Version vom fachlichen Datenmodell und ist nur eine Konfiguration und das zerschießt alle.
R2: Das ist jetzt aber kein Konfigurationsfehler, oder?
I1: Naja… ja, was ist das? Also ich (R1: Fachlicher Fehler, oder?) konfiguriere es, aber es ist ein… ja… macht vielleicht sichtbar, also das ist halt wahrscheinlich das Problem, man muss erstmal Konfigurationsfehler definieren. (R1: Genau) Ist das ein Fehler, der passiert, weil ich was konfiguriere, oder es ist es ein Fehler, weil die Softwarearchitektur Banane ist, oder?
R2: Naja, darum fragen wir dich, was du dazu meinst, was ein Fehler ist. Also speziell jetzt ein Konfigurationsfehler.
I1: Ja, also ich würde es wahrscheinlich schon eher in die Richtung drehen, dass man jetzt sagt ich konfiguriere irgendein Framework falsch oder so.
R1: Ja, dann kommen wir nämlich gleich, das passt nämlich eigentlich gut zur nächsten Frage… vielleicht können wir dem noch mal auf den Grund gehen. In wie weit unterscheiden sich denn Konfigurationsfehler oder -probleme von normalen Software-Bugs? Oder Fehler, die vielleicht durch fachliche Tests gefunden werden können. Und wie weit unterscheiden die sich vielleicht in der Anzahl und in der… zeitlichen Aufwand für Lokalisieren dieses Fehlers und deren Behebung?
I1: Also ich glaube fachliche Fehler sind in der Anzahl schon mehr. Die sind aber auch schneller zu beheben meistens, weil ich dann vielleicht sage okay ich habe jetzt hier irgendwie, ich sage jetzt mal die if-Abfrage ist falsch, die passiert irgendwie auf dem falschen Wert oder irgendwas frage ich halt falsch hier ab oder, oder… dann ist das meistens schneller zu beheben. Ah, wir haben aber eins vergessen. Wir haben eins vergessen in der ganzen Diskussion, das fällt mir aber gerade bei der Frage auf. Das wäre vielleicht noch ganz interessant für den Fragebogen, ob man das vielleicht irgendwo vorher abfängt sozusagen. Und zwar, gibt es ja nicht nur die, aber ich komme jetzt drauf wegen fachlichem Datenmodell, es gibt ja nicht nur die technische Konfiguration von Docker, Kubernetes, Spring Cloud, was weiß ich, sondern es gibt ja auch fachliche Konfigurationen. Also es gibt, das haben wir sogar relativ häufig schon eingesetzt, dass man sagt man hat wieder Finanzdienstleister, die bauen irgendeine Software und die haben zum Beispiel irgendwelche Zinssätze, die die innerhalb von Berechnungen verwenden oder Altersgrenzen, ganz beliebt, oder Mindestalter, Maximalalter… maximale Einkommensgrenzen, sonstwas, sowas. Was sich potentiell einmal im Jahr ändert wenn irgendso eine Basel II, Basel III, Basel IV und hier gibt es noch diese gesetzliche Änderung und so. Und das wird dann sehr gerne konfiguriert. Also wir haben damals zum Beispiel dem einen Kunden haben wir einen… Tooling eingesetzt, was auf so einem OpenG-Standard basiert, also so ähnlich wie BPMN gibt es so einen DMN, Domain Model and Notation, was eigentlich in der Implementierung her nichts anderes als eine Entscheidungstabelle ist. Was aber meistens ausreicht, weil ich irgendwie sage ich habe hier einen Eingangsparameter, wenn der kommt, dann nimm die Konfiguration. Ist aber sehr mächtig, weil wenn ich das alles als if-then-else runterprogrammiere, dann steht das halt so im Code. Wenn ich aber sage, ich dynamisiere das über so eine fachliche Konfiguration, dann habe ich halt mehrere Vorteile. Ich kann zum Beispiel auch diese Entscheidungstabelle mit dem Fachbereich entwickeln. Also der versteht die sogar, der kann die selber sogar im Extremfall sogar pflegen, ohne die Software zu ändern. Ist auch eine Konfiguration. Ja, aber ich weiß nicht, ob das so vom Thema her passt. (R2: Das gehört schon mit dazu, zur Konfiguration) Also das gehört eigentlich schon eigentlich schon dazu, ist halt jetzt eher fachlich motiviert dann.
R1: Und das würden aber die fachlichen Entwickler schon… betreffen, oder?
I1: Jaja, also…
R1: Also wir haben ja einen (?)-Entwickler, die fachlichen Entwickler. Das heißt, die beschäftigen sich im Grunde ja auch dann mit Konfigurationen.
I1: Genau, die beschäftigen sich auch mit Konfiguration. Also was die technischen Entwickler, in dem Fall also ich, was ich da gemacht habe, war dieses Framework bereitzustellen, zu sagen wie benutzt man das und, aber dann die eigentlichen fachlichen Inhalte da einzufügen, also welche Grenzen gibt es und das dann so zu benutzen, das war dann Fachentwickleraufgabe. Und da kann natürlich dadurch, dass ich es konfigurieren kann auch wieder Fehler passieren. Das heißt ich muss natürlich diese Konfiguration, also im Endeffekt kommt bei diesem DMN-Standard so ein XML raus, das muss auch wieder in die Versionskontrolle. Weil es muss zur Software passen. Und wenn sich die Software ändert und das Ding, und ich brauch halt wieder massiv Testing.
R1: Gibt es da Interaktion eigentlich, zwischen fachlicher Konfiguration und technischer Konfiguration?
I1: Ne, eigentlich nicht. Eher weniger.
R1: Also vielleicht, dass ich, wenn ich das Datenmodell ändere, brauche ich eine andere Datenbank oder sowas.
I1: Ja, okay. Datenbank ist sowieso noch mal ein eigenes spannendes Thema. Und Daten, Datenmodelle, Datenbanken. Weil, was viele Unternehmen dann nicht haben, also sie konfigurieren alles mögliche, aber ihre Datenbank ist irgendwie, da gibt es irgendwie so ein paar SQL-Skripte, die die anlegen und die Schemata anlegen und sowas, aber die liegen halt nirgendwo versioniert und vorallem wenn sich die Software ändert, wird das nicht geändert und so. Das muss dann immer einer manuell einspielen. Und da versucht man aber auch immer die Sachen Richtung… dass man irgendwie sowas, wie Flyway oder Liquibase einsetzt, dass dann diese Schema-Updates auch noch mit in der Versionskontrolle liegen. Aber… dann hätte es ja irgendwie sowas, also das hat so eine technische Komponente, wie benutze ich Liquibase, wie richte ich das ein? Aber eigentlich ist es ja fachlich motiviert. Ich brauche irgendwie neue Felder. Damit ich es in der Datenbank speichern kann oder so. Aber so richtig… so richtige Wechselwirkungen, hm… also ne Wechselwirkung wäre für mich wenn das eine sich ändert, muss ich das andere ändern. Also wenn ich das jetzt richtig verstehe mit Wechselwirkungen. Das kann ich jetzt nicht so richtig erkennen, weil das eine löst erstmal ein technisches Problem, also wie nutze ich zum Beispiel überhaupt Liquibase oder wie nutze ich überhaupt Docker mit Vagrant und Spring Boot oder so und das andere ist, ich ändere jetzt irgendwie einen Zinsparameter und oder brauche ein neues Feld oder so.
R1: Was mir da als Beispiel einfällt ist halt, ich habe jetzt in der Fachlichkeit einen Parameter , der dafür sorgt, dass ich jetzt mehr Last habe auf dem Server und dadurch muss ich mehr
I1: Ah, okay. Ja, stimmt. (R1: Instanzen hochfahren) Das ist natürlich… also es kann natürlich… ja… hm… also das passiert ja auch relativ häufig, dass man zum Beispiel man bringt ein Produkt an den Markt, die Architektur ist für eine gewisse Last ausgelegt und nach zwei, drei Jahren wird das auf einmal massiv gekauft oder so und überhaupt erst mal richtig benutzt und dann reicht vielleicht das ganze nicht mehr aus, aber das ist dann nicht nur ein Konfigurationsproblem.
R1: Also ich hätte jetzt vielleicht, wenn wir bei Netflix bleiben, die haben fachliche Konfiguration wäre vielleicht die Auflösung der Videos, die (?) verschicken. Und je nachdem was ich da konfiguriere muss ich ja wahrscheinlich meine Infrastruktur konfigurieren. Aber
I1: Ja… ja, oder vielleicht auch bei einer Bank, ne? Ich mache jetzt irgendwie den Zinssatz mache ich so attraktiv, dass auf einmal alle irgendwie den Bausparvertrag wollen oder sowas. Gut, dann habe ich erst dadurch eigentlich ein Infrastrukturproblem. (R1: Ja, aber das ist eher selten). Aber es ist… ja, das ist dann fast eher kein direkter Zusammenhang, sondern sowas wie eine… weiß ich nicht, also… das passiert dann halt. Das sieht wie eine Abhängigkeit aus, aber… ja. Ich würde auch nicht sagen, dass das dann ein Konfigurationsproblem ist. Das ist meistens dann eher „habe ich die Software so skalierbar gebaut, dass es geht oder nicht?“. Und dann habe ich viele Probleme wenn ich es nicht gemacht habe. Eins davon ist Konfigurationsprobleme, aber ich hab garantiert noch mehr.
R1: Vielleicht bloß noch ein letzter Punkt dazu, zu den na hier… zu den Unterschieden. Die Behebung… waren ja irgendwie… stärker. Was, wie lange dauert es denn so einen Konfigurationsfehler jetzt zu beheben und was sind da praktisch typische Vorgehensweisen um das jetzt zu beheben?
I1: Naja, meistens hat man ja, also das größte Problem hatte ich ja schon so beschrieben als dieses ich muss jetzt mehrere Sachen integrieren oder ich bin dann weiter fortgeschritten im Lebenszyklus der Software und irgendwas wird geupdatet oder ändert sich oder ich ein neues Framework einnehmen und dann ist eigentlich oft die Vorgehensweise, dass man so sucht, so sehr zu isolieren erstmal das Problem, dass man sagt erstmal das Problem überhaupt zu verstehen. Dass man möglichst viele von den Tools außen rum erstmal wegnimmt, die irgendwie auch noch mit reinspielen und erstmal die zwei Dinger findet, die jetzt nicht zusammen wollen. Und dass man das erstmal löst, für sich. Komplett am besten auch losgelöst von der Kundeninfrastruktur und was die alles noch drumrum bauen und haben und speziell, sondern wirklich am besten auf reiner, dass man erstmal die, ich sage immer so schön, die Frage erstmal formulieren kann. Die man bei Google eingibt. Das ist eigentlich schon immer die… mindestens 50 % der Tätigkeit (?) behaupten ja eigentlich mehr. Eigentlich 70 % der Tätigkeit ist überhaupt erstmal die Frage formulieren zu können. Weil wenn ich die formulieren kann, dann bin ich auch sehr schnell bei einer Lösung. Meistens gibt es dann sogar schon ne Stackoverflow-Frage dafür, aber… bis ich erstmal weiß, was ich überhaupt sozusagen suchen muss, das ist…
R2: Okay, also typischerweise um so einen Konfigurationsfehler zu finden ist halt solange rumzuspielen bis man ne Google-Frage stellen kann, sozusagen?
I1: Solange isolieren, also immer weiter… also sozusagen die Zwiebel so lange schälen bis nur noch der absolute Kern da liegt und dann wieder jede Schale wieder dranzusetzen. Dass dann am Ende wieder die ganze Anwendung draus wird. Also das ist eigentlich immer wieder die… so ein typisches Problem ist zum Beispiel… ich kann eine Webseite nicht mehr aufrufen. So, und jetzt weiß ich halt, ich habe darunter zehn Server und ich benutze Docker und Kubernetes oder sowas. Dann würde ich halt wirklich anfangen und sagen ok, jetzt gehen wir mal in den einen Dockercontainer, der ganz hinten steht, ganz hinten der Backend-Webserver und geh da rein und versuchen jetzt direkt im Dockercontainer erstmal die Webseite aufzurufen. Wenn das funktioniert, dann gehen wir raus aus dem Dockercontainer und versuchen das aufzurufen, wenn das funktioniert, gehe ich raus aus der Maschine und versuche es… von draußen auf die Maschine, wenn das funktioniert, versuche ich das in dem Spring Cloud Cluster aufzurufen, wenn das funktioniert, nehme ich den Loadbalancer, der davor… nehme ich noch irgendwie ne Kubernetes API und dann, ne? Also ich arbeite mich weiter nach außen und irgendwann habe ich wieder alles dabei, mit Login und sonst was und irgendwas davon wird es ja sein.
R2: Okay, wie gehst du sonst noch vor um Fehler zu finden? Also du hast jetzt gesagt googeln wahrscheinlich, auf Stackoverflow nachgucken
I1: Naja gut, vieles ist natürlich Erfahrung dann auch irgendwie. Dann gibt es natürlich noch sowas wie Remote-Debugging, wenn es jetzt irgendwie Software ist, die man selber im Griff hat. Wo man den Code hat. Dann… kann man das natürlich versuchen. Aber halt auch viel erstmal lokal nachstellen. Also das ist ja auch so ein Isolierungsschritt, dass es nicht auf irgendeinem Server ist, der wieder irgendwie außerhalb meiner… des eigenen Rahmens ist, ja die Isolation ist es eigentlich auf das Wesentliche. Ich glaub… was gibt es noch für Strategien?
R2: Gespräche mit Kollegen?
I1: Ja klar, natürlich. Also das ist sogar natürlich immer Schritt 1, also… das kommt dann natürlich auch immer im Scrum-Meeting, also so ich, so würde ich es hier jetzt aufschlagen. Entweder Scrum-Meeting oder man hat halt irgendso ein … das wird ja Second Level Support, also so angerufen. Und jemand hat die Telefondings auf sich und der legt einen Hörer auf und sagt „hey… Jonas,“, jetzt in dem Fall, „ich hab hier den und den Fehler, kannst du mal gucken?“. Und dann fängt es eigentlich an, so ein bisschen die… also meistens kommt es schon irgendwie kommunikativ an oder per Email oder… oder irgendein externer… man hat da irgendwie so eine Business-to-Business Webservice-Geschichte und dann kriegt man halt eine Email, hier wir haben den und den Fehler. Könnt ihr mal gucken?
R2: Aber das ist ja jetzt wie du einen Fehler bekommst, sozusagen. (I1: Ja) Und wenn du den lösen möchtest, redest du da auch mit den Kollegen, oder (I1: Achso) ist es wirklich eher, dass du für dich guckst?
I1: Ne, meistens ist natürlich reden am schnellsten. Das kommt aber auch immer auf die… es kommt auf einen selber drauf an und kommt auf die Kollegen drauf an. Also, ich hab eigentlich oft die Erfahrung gemacht, dass es am allerschnellsten ist, wenn man das kommunikativ löst, weil viele Fehler sind doch irgendwo schon bekannt. Oder sind schon mal aufgetreten. Es kann aber durchaus sein, dass entweder die Kollegen nicht so kommunikativ sind… oder, dass… ja, vielleicht, dass es auch nicht irgendwie dokumentiert ist, oder dass es irgendwie wieder vergessen wurde, oder was weiß ich. Oder war, vielleicht ist es auch noch gar nicht, es ist noch gar nicht bekannt. Es ist noch gar nicht aufgetreten. Das gibt es auch. Und manchmal gibt es auch Fehler, die sind noch gar nicht mal irgendwo aufgetreten. Also die hatte tatsächlich noch keiner. Weil diese spezielle Frameworkkombination hat einfach sonst keiner. Dann hat man aber eigentlich vorher was in der Beratung falsch gemacht, aber es kann trotzdem auftreten. Ja, weil man hat ja immer irgendwelche Annahmen. Man will zwar das beste, aber dann hat man halt irgendwas ausgesucht, was… dann doch nicht so weit verbreitet war, wie man… dachte.
R1: Okay, letzte Frage zu den Fehlern: Wie beugt man die denn am besten vor? Konfigurationsfehler.
I1: Ja, tatsächlich ist eine Strategie nicht unbedingt immer nur Bleeding-Edge-Bibliotheken zu verwenden, sondern halt zu sagen, gut… ich nehme jetzt nicht den neuen heißesten Scheiß Blinki-Blinki, sondern… das war ja genau das, was ich vorhin auch meinte mit diesem Spring Cloud Sleuth. Also eigentlich habe ich das, dieses Update, hab ich jetzt ein halbes, dreiviertel Jahr habe ich das ausgesessen. Das gibt es jetzt schon lange, Spring Boot 2. Aber ich wusste halt, naja, wenn Spring Boot 2 erstmal geupdatet ist, dann kommt die ganze Kaskade danach ja noch. Dann müssen ja erstmal noch die anderen, die das alle benutzen, müssen auch noch updaten und dann muss noch, ne? Also so. Und trotzdem waren immer noch Fehler da. Also das ist immer so ein Abwägen dann. Vielleicht jetzt nicht so ganz… frische Ware zu benutzen. Aber halt auch nicht total abgehangene. Man will ja schon irgendwie noch… das ist immer so Abwägen, also.
R1: Und was noch?
I1: Am besten ist so wenig wie möglich Moving Parts im System zu haben. Also jeder, der kommt und sagt „Ich brauche unbedingt Kubernetes“, sagst du erstmal „Warum? Was willst du damit machen? Brauchst du diese ganzen Dinger, diese ganzen Einzeldinger oder reicht dir vielleicht einfache ein simpler, simples Dockerfile oder Dockercompose oder so… aus.“. Also immer reduzieren, Komplexität reduzieren. Weil (R2: Also eine Anforderungsanalyse sozusagen noch mal machen?) ja wenn wenn man schon sagt, dass sozusagen das Problem ist immer wenn mehr integriert werden muss, dann ist die Lösung natürlich weniger zu integrieren. Also wenn ich… wenn viele Knoten Probleme machen, nehme ich halt wenige. Wenn es geht. Aber oftmals werden halt für irgendwelche… Anwendungen, werden da Sachen aufgerufen, wo man halt sagt, das ist jetzt mit Elefanten auf Spatzen… geschossen oder so… (lacht).
R1: Also weitere? Testen oder irgendwas?
I1: Genau. Oder was halt auch immer ganz wichtig ist, ist halt so ein Proof of Concept, also dass man halt sofort nach der Auswahl, oder eigentlich schon während der Auswahl am besten… eigentlich die ganze Zeit immer alles ausprobiert. Experimentation sozusagen, also immer wieder das Zeug zusammensteckt, die Annahmen validiert… nicht glaubt einfach, was im Blogpost steht, auch wenn es 500 dazu gibt. Naja, wenn es vielleicht zehn dazu gibt. Das irgendwann auszuprobieren. Weil es kann sich ja auch schon wieder in nem halben Jahr die ganze Welt geändert haben und dann sind diese Sachen, die da stehen, die waren mal richtig, aber sind jetzt nicht mehr so. Also keine reine PowerPoint-Schlacht.
R1: Eigentlich jetzt letztes Thema: Verbesserungsbedarf.
R2: Bei Konfigurationen.
R1: Bei Konfigurationen.
R2: Nicht beim Fragebogen.
R1: Genau. Ja, welche Verbesserungen würden Sie sich denn hinsichtlich der Konfiguration von Softwaresystemen wünschen? Oder von Frameworks und Tools.
I1: Vorsicht bei API-Änderungen.
R2: Du hattest ja vorhin auch Dokumentation irgendwann angesprochen und gesagt, dass es sowas (?)
I1: Ja, Dokumentation muss eigentlich immer sein und immer aktuell sein. Wo die natürlich alles versuchen sollten zu nutzen, was es irgendwie gibt. Wenn ich Webservices nutze dann nutze ich irgendwie mindestens sowas wie REST, Spring REST Docs oder sowas, wo sozusagen die Dokumentation als kaputt im CI-System gekennzeichnet wird, wenn ich Code ändere, der nicht zur Dokumentation passt und solche Sachen. Also möglichst auch die Dokumentation automatisieren. Soweit es halt geht.
R1: Was kann man sich noch an Verbesserungen wünschen? (?)
R2: Du hast so eine Datenbank angesprochen am Anfang… das Hersteller versucht haben eine generische Lösung zu finden. Würde das funktionieren? Wenn man es richtig macht, also kann man das richtig machen?
I1: Also ich glaube wenn man so weit wie möglich vorne immer anfängt. Also die Probleme entstehen ja meistens wenn der Entwickler irgendwas eingibt, was dann nicht mehr hinten raus irgendwie zusammenpasst. Dann wäre es natürlich am besten wenn ganz vorne schon angefangen wird, also angesetzt wird. Am besten halt in der IDE. Wenn er seinen Code eingibt oder seine Konfiguration und halt direkt ein Popup aufgeht „Ja, das kannst du so konfigurieren. Es sieht auch gut aus, kannst du auch einchecken, aber du weißt schon, dass in 90 % der Fälle dann hinterher ein mega Performanceproblem entsteht wenn du das tust.“. Das wäre natürlich super. Also so eine Art…sage ich jetzt mal. Es gibt ja sowas wie Sonar oder so, gibt es ja heute schon, dass du das auch lokal in deiner IDE anwenden kannst. Und dann sagt er „ja, die Methode, die du jetzt geschrieben hast, die kannst du so schreiben, die kompiliert, aber… ist nicht so eine gute Idee, weil“, ne? Könnte man das ja genauso mit Konfiguration haben. Und das nächste wäre natürlich… um das zu vermeiden wäre natürlich irgendwie, dass immer massiv alles, jeden (?)-Commit halt sofort… irgendwie gegen eine… ja, alles laufen zu lassen, was ich habe. Am besten die ganze Anwendung hochziehen, einmal durchtesten, das (?) wieder runterschmeißen.
R1: Wird das nicht schon gemacht, ist das?
I1: Ja, das wird oft gemacht. Klar. Das ist natürlich auch ein… wir müssen ja auch irgendwie, sagen wir mal, momentan schon irgendwie… dem Kunden Lösungsstrategien anbieten und das ist halt das, was grad das beste ist, dass man halt möglichst alles immer wieder testet und kontinuierlich integriert. Genau, also so dieses, ich glaube dieses Adit-IDE-Plugin oder so. Das wäre natürlich super. Und dann natürlich vielleicht sowas wie… also ich spinne jetzt mal, was natürlich auch super wäre: Das Problem ist ja immer wenn mehrere Tools miteinander integriert werden. Das sind halt sowieso Konfigurations-, äh so viele Kombinationsmöglichkeiten, ja, am Ende, dass es immer irgendwie einen blinden Fleck geben wird. Da wäre es natürlich cool wenn es sozusagen irgendwas gäbe, was einfach immer alle, ich sage mal so eine Tabelle macht, ja? Frontends, mögliche Backends, mögliche Datenbanken, mögliche Webservice-Schnittstellen, mögliche weiß ich nicht was, da kann man sich ja eine unendliche Tabelle ausdenken und einfach alles immer wieder durchpermutiert. Und alles mal zusammensteckt und für alles so ein Blueprint baut. Das man da eigentlich möglichst sagt, wenn ich jetzt sage ich will das Frontend, mit dem, mit dem, mit dem und dem und sagt, klick, generier mir mal die, die Konfiguration oder so. Die richtige. Das wäre natürlich auch nicht schlecht. Also so eine Art Startup-Skeleton-Prototyping-Dinger oder so.
R1: Was würde denn dann speziell helfen wenn, um Fehler zu identifizieren, vielleicht eine Verbesserung. Also du hast ja gesagt… Schalen, also Zwiebelschalenprinzip, kann man das vielleicht in deiner Einschätzung automatisieren oder so? Oder?
I1: Ja, vielleicht kann man das auch automatisieren. Also entweder, man könnte schon mal automatisieren zu sagen… das jetzt mal als Hilfestellung, demjenigen, der am Bildschirm sitzt… irgendwie mitzugeben. Zu sagen, das ist jetzt irgendwie Datenbank-Fehler, probier doch mal das. Oder so. Bis hin zu, man führt das dann schon durch, also isoliert das irgendwie schon automatisch. Und versucht dann da schon irgendwelche Schlüsse zu machen. Oder sogar bis dahin versucht es dann schon zu lösen. Das Problem.
R1: Ok, dann haben wir jetzt eigentlich alles. Ok, ich denke dann haben wir es.