i08.md

R1: Was tust du denn so fachlich in deinem Job? Also bist du irgendwie Tester, Teammanager, DevOps, Microservice—

I8: Ich bin Cloud-Foundation-Architect heißt das. Das ist eine Gruppe von fünf Teams. Ein paar Teams haben eigene Services, also die machen wirklich DevOps im reinsten Sinne mehr oder weniger. Dann gibt es ein paar Teams, die machen so ein Mittelding, da wo noch eine Ops-Abteilung dazwischenhängt und dann gibt es eins von den Teams oder zwei von den Teams, die machen — also das ist wirklich die alte Welt, die alte Monolithenwelt, wo es Entwickler gibt, die nicht wissen, wie die Umgebung funktioniert und wir machen, wir sind so dann die Schnittstelle zwischen Ops und den Businessentwicklern. Also in meinen fünf Teams, die sind wirklich alles dabei: Reines DevOps bis Old School.

R1: Und in welcher Domäne da arbeitest du? Also Domäne meinen wir jetzt Webentwicklung, Frontend, Backend —

I8: Backend. Alles Backendentwicklung.

R1: Und die Rolle in der Softwareentwicklung war jetzt Projektleiter oder dann Architekt dann so ein —

I8: Das ist nicht Projektleitung. Also wir liefern ja, wir sind ja eine SaaS-Company, das heißt da gibt es zwei Teile. Einmal die Projekte, die wirklich für den Kunden irgendwas implementieren, das sind wir nicht, sondern wir stellen wirklich das Produkt her, was in der Cloud verfügbar ist und dann vom Kunden benutzt wird um da sein Zeug zu konfigurieren, also ich stelle sozusagen noch zur Verfügung wie er das System konfiguriert, was er alles braucht und Schnittstellen und so. Das ist eigentlich unser Part mehr oder weniger.

R1: Okay, also mehr als Architekt. Ja, welchen Anteil an der täglichen Arbeit ist denn noch die Softwareentwicklung und das programmieren?

I8: Das wird jetzt gerade weniger. Bis vor einem halben Jahr habe ich so 60 %, 70 % meiner Zeit entwickelt. Und Architekt bin ich jetzt seit einem halben Jahr, äh viertel Jahr ungefähr und da muss man mehr sehen, dass die Teams miteinander arbeiten, kommunizieren, Konzepte ausarbeiten, sowas. Also da ist mehr der Kommunikationsbedarf dann höher. Und dann Anforderungen einsammeln. Technische Anforderungen, Konfiguration ist da ein großes Thema zum Beispiel.

R1: Wie viele Jahre in der Softwareentwicklung hast du denn schon?

I8: 19 bin ich jetzt.

R1: Und seit wann hier?

I8: Seit fünf Jahren als die Aquise — ah ne, vor drei Jahren wurden wir aufgekauft. Vorher hieß ja die Firma, da bin ich seit fünf Jahren und diese Firma wurde ja von abgespalten und da war ich vorher gewesen, also ist die selbe Codebasis. Ich arbeite jetzt seit 20 Jahren an der selben Codebasis. In extrem verschiedenen Inkarnationen. Also ich kenne noch den Unterschied zwischen SaaS und Premise, also wenn man das als CD verkauft. Den ganzen historischen Gedank — Leben dahinter, wie man Konfiguration früher gemacht, mit Properties und dann war man fertig und sowas. Also das Verständnis hat sich auch gewandelt.

R1: Mit welchen Frameworks und Tools arbeitest du denn für gewöhnlich?

I8: Jetzt in dem Bereich oder allgemein?

R1: Schon in dem Bereich, ja genau.

I8: Also in dem Bereicht gibt es mehrere Sachen. Das eine ist das klassische Git, wo man Properties eincheckt und dann werden die irgendwohin deployt und werden die dort ausgelesen. Entwicklungsumgebung ist dann IntelliJ, also die gängigen IDEs, was die Entwickler haben um was zu editieren. Dann gibt es Monitoring-Funktionalitäten, wo man überprüft, ob die Konfiguration angekommen ist. Oder wenn wir, wenn jetzt Ops sagt okay, das gefällt uns nicht, da müssen wir mal aus Performancegründen was ändern oder die Performance-Engineers, dass die bestimmte Konfigurationen ändern. Weil diese Feedbackschleife zu lang wäre, da werden die jetzt — es gibt ja zwei Möglichkeiten das zu machen. Entweder die arbeiten autark und entscheiden einfach und machen, wir überprüfen sozusagen in der Software, dass das eine valide Konfiguration ist und dann haben wir so eine Monitoring-Funktionalität, das ist ein Grafana heißt das, wo wir sehen welche Konfigurationen wurden appliet, aber nur für die, die uns interessieren mehr oder weniger. Das heißt wir schreiben also zusätzlich zu dem, was man konfigurieren kann, dass man das auch monitoren kann. Dass man dann gucken kann später, wie viele von den 10.000 Instanzen haben das so konfiguriert, wie viele haben das so konfiguriert und so weiter. Oder Feature Flags: Wie viele sind angeschalten und wie viele sind ausgeschalten. Da gibt es so ein Board, wo man das so übersichtlich sieht. Aber für Produktionsinstanzen natürlich nur. Für Entwicklerinstanzen haben wir das nicht, also was da jeder Entwickler macht, wissen wir eigentlich gar nicht. Das fehlt eigentlich.

R1: Okay, also Grafana wäre dann das —

I8: Grafana ist das Hauptmonitoring-Tool. Wir haben auch eigene Tools entwickelt um solche Informationen zu sammeln.

R1: Was verstehst du unter dem Begriff Konfiguration?

I8: Also Konfiguration ist aus meiner Sicht ein ganz, ganz schwieriges Thema im Sinne, wenn man das jetzt definieren möchte. Weil es geht ja angefangen von der Defaulteinstellung der Entwickler — also ich weiß, dass ich eine Library nehme, da kann man Konfigurationen applien, wie man sie verwenden möchte, dann checkt man die ein und ich weiß, dass die überall genau diese eine Konfiguration verwendet und die wird sich auch nie ändern. Und wenn dann vielleicht mal eine neue Version rauskommt von der Library, dann ändere ich die, checke die mit dem Code ein und dann geht es nach draußen. Das ist die statischste von allen. Und die andere Dimension ist, dass der Kunde zur Laufzeit für eine konkrete Instanz das bestimmte Verhalten, wegen mir am Check-Out-Flow, konfigurieren kann oder keine Ahnung, wenn der im Business-Manager konfigurieren will, wie die Editoren, wie lange die zum Beispiel editieren dürfen oder wie Batch-Prozesse konfiguriert werden, Scheduling, solche Parameter, wo das sehr sehr dynamisch ist. Also es kann auch bestimmte Bereiche sein, wo in einem bestimmten Zeitrahmen gilt folgende Konfiguration und dann eine andere. Das ist die andere Seite von der Konfiguration aus meiner Sicht. Wobei diese sehr dynamische, man schlecht sagen kann, ist das jetzt Konfiguration oder sind das ganz normale Business-Features? Das verschwimmt so mit ein bisschen, wenn man all das — man hat einen Prozess, der hat verschiedene Verhalten, also Abzweigungen wo das hingehen kann und mit der Konfiguration kann man das ändern und dann ist der Life-Cycle von der Konfiguration sehr statisch, wie dynamisch ist das? So deswegen ist das Spektrum da extrem weit. Und dann kann man es noch sehen von einer anderen Dimension, von den Stakeholdern. Wer führt diese Konfiguration ein? Also wer sagt, dass es diese Verzweigung gibt, mache so, mache so. Das sind ja entweder die Entwickler oder die Ops-Leute und und und und und. Bis hin zu denen, die dann die konkreten Values ownen. Also wir zum Beispiel sagen im Produkt, die Entwickler sagen „Ich kann meinen Application-Server mit der VM-Size konfigurieren.". Welche dann appliet wird, das wissen wir nicht. Also wir wissen, wir sagen „Okay, wir haben getestet, das mit von — das ist das Minimum, was ihr haben könnt, das ist das Maximum. Was ihr dazwischen macht, geben wir vielleicht Guidance, wo wir sagen können, okay wenn so und so viel Produkte im Shop sind, dann müsst ihr ein bisschen höher machen, wenn so und so viele User reinkommen, concurrent session, dann gibt es immer so eine Guideline, wie man das machen kann, aber das machen letztendlich die Ops-Leute, die dann sagen „ich weiß das ist der konkrete Kunde, das haben wir gemessen, das sind unsere Performance-Metriken und jetzt ändern wir mal die Konfiguration" und die ownen dann die Values und verantworten die dann auch. Wenn die diesen Rahmen verlassen, dann ist das wieder eine Kommunikation zwischen uns, wo die sagen, wir haben das jetzt so korrekt eingestellt, wie ihr das dokumentiert habt, aber es funktioniert nicht. Dann müssen wir wieder zurück und gucken warum ist das so, ist das ein Sonderfall, haben wir was vergessen und so weiter. Also das ist so die — die Values haben einen eigenen Lifecycle, die Konfiguration selber um den Code, der dann darauf das verwendet irgendwie hat einen eigenen Lifecycle und die Leute, die das dann benutzen. Also die verschiedenen, die Businessnutzer. Die sage ich mal die Konfiguration dann aushalten müssen. Der eine verantwortet das Schalten und die anderen müssen damit leben halt und sagen dann „Hallo Admin, kannst du mal für meine Box irgendwas anschalten, weil ich brauche mal ein neues Feature" oder sowas, Feature-Toggles zum Beispiel, aus Businessgründen wäre das eine Möglichkeit. Das sind sehr — und das muss man pro Konfiguration überlegen, wer ist was eigentlich?

R1: Hast du jetzt glaube ich meistens auf fachlicher Konfiguration gesprochen, wir unterscheiden oft zwischen fachlicher und technischer Konfiguration und, okay VMware-Features wären vielleicht auch technische und wo wir jetzt auch so ein bisschen hingucken ist CI/CD, Docker und so weiter, Virtualisierung. Spielt das da bei euch auch eine Rolle oder was ist so das Verhältnis von fachlicher, technischer?

I8: Das ist, also wenn man es ganz abstrahiert hängt das aus meiner Sicht nur von den Stakeholders ab, von den Stakeholdergruppen. Also für den Entwickler ist es, glaube ich, wenn man eine Konfiguration einführt, wie auch immer die aussieht, ob das jetzt eine Businesskonfiguration ist für einen Businessnutzer, der zur Laufzeit etwas ändert oder jetzt der Build-Engineer, der sein Docker-Image konfigurieren will, letztendlich was man da tut, ist sehr sehr ähnlich. Das ist bloß ein anderer Stakeholder, der bestimmte Anforderungen hat, wie der Lifecycle von den Values ist und von der Konfiguration. Und die, also man muss auch dann überlegen, das muss validiert werden, gechecked werden und so weiter. Gültigkeitsbereiche und so weiter. Und das ist, das sind spezielle Gruppen, die kommunizieren auch untereinander unterschiedlich. Also wenn dir der Build-Engineer sagt, ich brauche mal eine Konfiguration für mein Docker-Image, weil ich meine VM besser konfigurieren will, ist das etwas anderes, als wenn ein Produktmanager mit einem Kunden redet, der dann mit dem PO redet und der dann mit dem Entwickler redet. Da ist der Informationsfluss ein ganz anderer um so eine Konfiguration einzuführen. So, das zweite ist, einem Build-Engineer kann man zutrauen, dass der ein Gefühl für die Technik hat. Das heißt, da validiert man nicht so sehr. Da knallt es dann halt in der Entwicklungsumgebung, dann failt der Buildstep fehl, da ruft der an „warum ist denn das?", dann sagen wir „na warte mal, die beiden Zahlen harmonieren nicht so miteinander, pass das mal an", während beim Businessnutzer können wir jetzt nicht sagen, probier mal aus, lass es knallen und gucke mal, weil da auch Geld dran hängt. Deswegen ist da große Aufmerksamkeit — also die Validierung ganz ganz wichtig, dass der nur valide Konfigurationen applien kann. Während beim Build-Engineer ist wahrscheinlich... Also ich arbeite jetzt gerade, ich konfiguriere gerade die Docker-Images und so weiter, das ist sehr fragil, da muss man sehr viel technisches Wissen haben und dann wissen, was voneinander abhängt und ein Gefühl dafür entwickeln und hoffen, dass die Dokumentation wenigstens gut genug ist. Das wird ja sehr stiefmütterlich behandelt, weil da hängt ja kein Umsatz dran oder irgendwas.

R1: Ja, da haben wir auch interessante — kann ich dir vielleicht auch so bisher schon Einsichten gehabt. Manche sagen genau das gleiche, dass es sehr kompliziert ist, fragil und es hängt viel zusammen, andere sagen das ist absolut easy Docker irgendwie zu machen. Hängt das vielleicht an der Komplexität der Aufgabe ab oder vielleicht, dass sich noch nicht gewisse Tools oder best Practices oder sowas gibt, wo man sich dran langhangeln kann?

I8: Das Problem bei, also ich kann mir gut vorstellen wenn ich jetzt ein eigenes Projekt owne, einen eigenen kleinen Service und die ganze Buildchain oder so, ist das total einfach. Wenn wir aber 120, 160 Entwickler haben, die alle in verschiedenen Locations arbeiten, zu unterschiedlichen Zeiten und die sich nicht absprechen, wie sie ihr Docker konfigurieren und jeder sein eigenen — wir haben jetzt bei unserem Buildprozess, ich versuche jetzt gerade so sieben, acht verschiedene Docker-Images, die während des Builds gebraucht werden, die dann auch deployt werden, die in Testinstanzen gebraucht werden, vielleicht sogar noch mehr, zu harmonisieren. Da geht es dann zum Beispiel um JDK-Austausch. Ganz einfache Sache eigentlich. Und ich sitze jetzt schon seit 14 Tagen dran und kämpfe damit. Der eine hat das so gemacht, da liegt das Java-Home da, das andere ist so konfiguriert, jedes ist anders konfiguriert, muss man sich nicht miteinander absprechen und wenn man jetzt so einen globalen, durch alle Images durchgehen muss, eine globale Sicht auf einmal drauf hat, wird das extrem kompliziert, weil man die Abhängigkeiten kennen muss, die Nutzergruppen untereinander kennen muss und jedes Docker-Image komplett verstehen muss, damit man weiß, wie es funktioniert. Deswegen, wenn es eins ist, ist es total einfach und wenn man weiß wie der Code ist und wie das aufgebaut ist. Wenn man aber sechs, acht, die man gar nicht kennt und erstmal in den Source-Code reingucken muss, wie das geht, dann wird es kompliziert.

R1: Hast du auch mit Konfiguration von monolothischen Systemen zu tun?

I8: Ja, das halt das eine Team, wir sind ja overall schon seit 20 Jahren. Gefühlt.

R1: Hat sich denn seitdem was verbessert (I8: Ja) oder verschlechtert?

I8: Ja, verbessert. Also da geht es, beim Monolithen ist ja das Hauptproblem die Abhängigkeiten untereinander. Also durch die ein— Schaffung von Services, ich mag den Term Microservices überhaupt nicht, weil das ist wie so ein Marketing-Begriff. Für mich, wenn jemand sagt, bau mal Microservices, die sind gut, dann ist das für mich jemand, der keine Ahnung von Technik hat. Weil man kann— es gibt keine Definition, was ein Microservice ist. Wenn man Services nimmt, dann versucht man das Problem zu zerlegen, was im Monolithen gelöst wurde. Wenn man jetzt eine neue Architektur aufbaut und Services baut, kriegt man noch eine ganz andere Kategorie von Problemen. Ein Beispiel ist, es gibt Vor- und Nachteile. Ich finde nicht, Monolithen sind schlecht, ich finde nur nicht Services sind schlecht. Ich finde immer je nach Anwendungsfall, sollte man eins von den beiden nehmen. Also wenn ich jetzt zum Beispiel ein Startup-Unternehmen bin und ich muss jetzt mal so schnell wie möglich irgendwas an den Markt bringen und was ausprobieren, würde ich immer mit einem Monolithen anfangen, weil man wesentlich schneller ist. Während, wenn ich sage ich habe jetzt 10.000 Instanzen und dann kommen jetzt — die Kunden werden immer größer, größer, größer und agieren immer weltweiter, wo man in Amerika vor Ort sein, in China oder irgendwas, dann ist ein Monolith weiß Gott nicht die beste Lösung, die man da aussuchen kann. Da sollte man versuchen aus Skalierungsgründen das rauszuziehen. Man muss bedenken, wenn man so Services konfiguriert, dass das sehr sehr komplex ist. Und jetzt kommen wir zu der Konfiguration. Warum? Je mehr ein System entkoppelt ist, umso mehr oder umso bessere Tests braucht man in der Laufzeitumgebung im Produktionssystem. Zum Beispiel ist, wenn jetzt das eine Team sagt „Och, ich will jetzt mal — ich konfiguriere das jetzt mal um, weil ich denke das ist für mich gut.", heißt das nicht, dass das für das Gesamtsystem gut ist. Das hat man im Monolithen genauso, bloß dass man da, derjenige, der es umkonfiguriert und den Monolithen und sein Modul testen will, sieht das, dass das andere auch nicht funktioniert, weil der wahrscheinlich die selbe Buildchain benutzt. Wenn der aber, wenn man jetzt hundert Microservices hat und ich kann nicht die alle hundert Microservices mit meiner neuen Konfiguration ausprobieren, dann wird das schwierig. Das heißt selbst Code, Konfigurationsänderungen die auszurollen kann sehr kompliziert werden. Da braucht man andere Strategien um das zu tun. Weil man dann zur Laufzeit das testen muss mehr oder weniger. Beim Monolithen ist das aus meiner Sicht einfacher, weil man, weil ich ja alles habe: Ich habe die ganze Information in meinem Rechner drinnen und da kriege ich einen großen Anteil von Problemen schon beim Entwickeln mit. So, das ist eigentlich die Herausforderung, die wir haben.

R1: Und was hat sich jetzt verbessert?

I8: Verbessert hat sich dahingehend, dass es extrem viele neue Frameworks gibt. Früher gab es nur die Properties und das war alles. Und wie man die Properties geladen hat, wer die geändert hat und wer die geownt hat, das war eigentlich relativ frei. Also die ersten Versionen an denen ich da gearbeitet habe, da war so, die haben alles versucht konfigurabel in die Properties auszulagern und dann hat man dem Kunden gesagt, hier, das sind die Properties, hier sind die Beschreibungen, viel Spaß. Wenn man Glück hatte, hat der Entwickler noch dran gedacht, die zu validieren und irgendwelche Bereiche einzustellen, dass der, der das verwaltet hat und installiert hat, versteht worum das geht. Jetzt ist es so — also früher war es so gewesen, wir haben die Software produziert, haben die konfigurierbar gemacht, haben es jemandem gegeben und Kunden mit einem Techniker, der keine Ahnung, was dadrinnen passiert, der nicht im Entwicklungsprozess drinnen war und dem gesagt, jetzt viel Spaß, konfigurierbar. Und da war ein extrem großer Informationsverlust. Das hat meistens auch dazu geführt, als Beispiel, ein konkretes Beispiel, ein Projekt war so ein Großkunde gewesen und dann hatten wir einen Fehler gemacht gehabt, in der Software hatten wir eine falsche Defaultvalues gegeben oder ungünstige. Sagen wir mal für Großkunden ungünstige, für kleine war es egal. Und dann hatten wir denen gesagt, pass mal auf, kannst du mal diese Konfiguration ändern, wenn ihr das macht, seid ihr rattenschnell und ihr braucht weniger Ressourcen. Und das war vor Cybermonday und da haben die gesagt „Ne, ne, ne, das machen jetzt nicht, weil dieses Risiko und die Seiteneffekte, die da passieren können, die sind so hoch, die kann keiner abschätzen. Das könnt ihr jetzt vielleicht sagen auf eurer Entwicklungsumgebung, aber bei uns in Produktion ist das eine ganz andere Geschichte.¨ und da ist es so, dass die lieber Dinge machen, die sie schon immer gemacht haben. Also der Klassiker ist, die skalieren, die legen einfach zehn App-Server, zwanzig App-Server dazu, als dass sie eine Konfiguration ändern und nicht wissen, was, wenn ich das ändere, woanders knallt. Das ist diese Angst davor, das sind typische Ops-Leute. Die machen Server hinzu und wieder weg, das sind die gängigen Praktiken, die da passieren, während eine Konfiguration ändern, ein Property, was noch nie geändert wurde, ist ein hohes Risiko. So und jetzt in der DevOps-Umgebung ist es ja so, dadurch dass der Entwickler weiß und zugucken kann, wie sein System funktioniert, kann er auch davon lernen. Und diese Kopplung, das hat aber mehr mit dem Businessmodell auch zu tun, die hat das extrem verbessert. Also das war mein großer Wechsel gewesen vor fünf Jahren. Bis dato habe ich immer diese CD ausgeliefert und habe gehofft und da haben die mir Stack-Traces geschickt und ich musste erraten, was da so passieren könnte und darüber philosophieren und versucht das in unserer Umgebung nachzustellen. Das hat aber nicht immer funktioniert. Bis hin, wo ich jetzt, also wo ich dann rübergewechselt bin in die SaaS-Company, habe ich extrem viel getan um Informationen aus dem System zu tun. Das habe ich vorher nicht gemacht. Und dadurch habe ich eigentlich ein viel besseres Gefühl, was da passiert und eine viel bessere Insight und kann viel bessere Ratschläge geben, wie was zu konfigurieren ist oder was überhaupt zu konfigurieren ist, was man vielleicht gar nicht konfigurieren sollte.

R1: In wie weit müssen denn bei euch Tools, Frameworks und Infrastruktur konfiguriert werden? Haben jetzt schon gehört, fast alles, oder?

I8: Ja, also wir haben so ziemlich alle Umgebungen, die es gibt. Die einzige Vereinfachung, die wir haben, dass wir nicht mehr alle OS unterstützen. Also historisch war mal gesehen, dass man mindestens oder drei OS — vor zwanzig Jahren war es so: Windows, SunOS oder HP-UX, also ein Unix-System und ein Linux. Dann sind ja die alten SunOS und HP-UX sind ausgestorben, dann gibt es nur noch Linux und Windows und zum Schluss waren eigentlich, hat sich Linux jetzt komplett durchgesetzt. Deswegen ist ja bei Windows jetzt der Kernel mit Linux drin und so weiter. Ist ja eigentlich nur noch Linux. Als Entwicklungsumgebung nehmen wir hier ein macOS, was jetzt auch so ein Unix ist, deswegen ist der Schritt mit Linux und macOS jetzt nicht so groß. Der größte Teil ist fast dasselbe. Dahingehend haben sich die Umgebungen vereinfacht, konsolidiert. Was komplexer geworden ist, sind die Laufzeitumgebungen. Also von früher war es Bare Metal, sagt man, das haben wir jetzt immer noch in unseren alten Datencentern, hin zu einer Virtualisierung wie VMware und OpenStack und so weiter, hin zur schmaleren Virtualisierung mit Docker. Jetzt ist der nächste Schritt Kubernetes und mal sehen, was als nächstes kommt. Keine Ahnung, was dann, was da für Hardware ist. Dass man gar keinen Kontakt mehr zur Hardware überhaupt noch hat. Also das hat sich komplett geändert. Und jetzt, wenn man von Entwicklungsprozessen die Software, also ich schreibe jetzt Code, wo der überall laufen muss, geht das von einer Entwicklungsumgebung, wo man so ressourcenschonend wie möglich unterwegs ist im macOS und einfach zu benutzen und dynamisch nachladbar, hin zu einer Testumgebung, wo schon Dockerisierung da ist und wo man natürlich die Funktion testet, hin zu einer Load-Testumgebung, wo schon productionnah ist und hin zu verschiedenen, mit Kundendaten und skalierten Systemen. Also das sind — der eine Code läuft in sehr sehr unterschiedlichen Umgebungen und mit ganz unterschiedlichem Zweck. Ich sag mal, auch beim Kunden selber. Der Kunde hat ja nicht nur eine Umgebung, der hat mehrere Umgebungen, wo er seinen eigenen Code testet oder bestimmte Datenvarianten von Katalogen zum Beispiel und so weiter. Promotions und so. Deswegen ist der Code, den man schreibt, je konfigurierbarer der ist, umso besser ist. Man muss sich aber natürlich Gedanken machen, Lifecycle von Konfiguration, wer konfiguriert das, wie stark muss ich validieren und so weiter.

R1: Gibt es denn Interaktionen zwischen den ganzen Konfigurationen?

I8: Leider Gottes ist das nicht so. Also meistens ist das immer so, weil das unterschiedliche Teams meistens machen, dass man nicht sagen kann, ich führe jetzt ein Property ein und jetzt will ich mal von allen Konfigurationen, wo meine Software lebt wissen, wo das denn wie, wer was konfiguriert und warum.

R1: Achso, mit Interaktion meinte ich eher, wenn ich was drehe, auf einmal passiert da ­— ne, und etwas anderes ist auch noch angeschaltet, dann passiert erst ein Fehler. Also man hat irgendwie Abhängigkeiten zwischen unterschiedlichen, meinetwegen im Dockerfile steht was und dann steht was im Properties-File von Spring Boot —

I8: Abhängigkeiten zwischen den Properties.

R1: Ja, genau.

I8: Das ist, ich glaube das gibt es noch gar nicht. Also was wir momentan machen, jetzt wie gesagt beim Entwickler —

R1: Also die gibt es bloß, die kennt ihr nicht, oder?

I8: Ne, es gibt noch keinen Standard dafür glaube ich. Also es gibt Konfigurationsserver, da macht man das folgendermaßen, also es gibt mehrere Arten, wie man das lösen kann, das Problem. Das eine ist, wie gesagt, man hat immer so eine Testsuite, wenn ich jetzt als Entwickler so ein technisches Property builde, dann knallt die, dann guckt einer rein im (?25:14 ), editiert das, der Feedbackcycle ziemlich langsam. Und Abhängigkeiten, muss man das ganze Produkt verstehen und so weiter. Oder man fängt an das in Software zu gießen und diese Regeln, die Abhängigkeit sind, zu validieren vorher. Wenn man dann das validiert, kann man beim Hochfahren sagen ich fahre jetzt nicht hoch, weil da fehlt noch irgendwas. Also wenn das entweder falsche Werte drin stehen oder Abhängigkeiten nicht stimmen, das ist die einfachste Variante, aber das ist nicht günstig für ein Produktionssystem, wo der Ops-Engineer dann gar nicht weiß, was er da machen soll und die Konfiguration woanders steht. Das ist mehr für den Businessnutzer, wo wir dann ein UI bauen, wo der irgendwas konfigurieren kann und das UI führt den in die korrekte Konfiguration. Und da investieren auch ganz ganz viel, dass die UI kapselt eigentlich dann. Meistens. Für Businessnutzer. Das können wir natürlich nicht für alles machen, weil das lohnt sich einfach nicht und man hat nicht immer für jede Umgebung dieses UI, was dann — das ist ja jedes Mal ein anderes System, ein anderer Grund warum man das konfiguriert. Das ist ja sehr unterschiedlich.

R1: Kann es denn passieren, dass bei euch dann, dass es so ist, dass der DevOps-Mensch dann seinen CI-Server irgendwie falsch konfiguriert hat, oder es läuft in 99 % aller Fälle, aber in dem einen Prozent der Fälle gibt es einen, meinetwegen Feature-Toggle, und dann erst schmiert das ab?

I8: Ja. 26:38 Gibt es. Das ist das tägliche Brot. Also momentan, dadurch, dass wir so viele Entwickler sind, haben wir, die haben sehr, sehr viele, als Beispiel nehmen wir mal Feature-Toggles, sehr, sehr viele verschiedene Konfigurationen und wenn man es jetzt genau nimmt, müsste man sämtliche Kombinationen von diesen Feature-Toggles durchtesten. Wenn wir aber 120 haben, brauchen wir nicht drüber reden, dass das nicht testbar ist. Deswegen versuchen wir eigentlich immer so, dass jemand, der einen Feature-Toggle einführt, beide Varianten in Unittests zu gießen für dieses eine Feature-Toggle. Wir kriegen aber nicht implizite Abhängigkeiten, wenn die nicht miteinander harmonieren. Wir hoffen, dass das im Code der Entwickler mit bedenkt und dann vielleicht das in den Test reinschreibt, aber wir kriegen es nicht, also so, dass der in eine QA-Abteilung gibt, mit allen Testclustern und dann alles durchkombiniert, was möglich ist, was der Entwickler vergessen hat vielleicht, das ist, das muss der Entwickler wissen. Und verantworten mehr oder weniger.

R1: Wie würdest du denn den Stellenwert, beziehungsweise die Wichtigkeit von Konfiguration im Software-Engineering oder bei der Softwareentwicklung sehen?

I8: Also aus meiner Sicht ist das, wird das immer wichtiger, weil die — man versucht ja immer weniger Code zu schreiben und lieber durch Konfiguration sozusagen sein Ziel zu erreichen mehr oder weniger. Gerade wenn man jetzt, wenn man eine Marktkonsolidierung hat und verschiedene Businessmodelle in einem System abbilden will. Je mehr Businessmodelle, umso mehr Konfiguration. Das heißt, als jemand angefangen hat zum Beispiel, vor 2004 nicht so wie [] gesagt, die haben gesagt, wir konzentrieren uns auf Shops mit Fashion. Und dadurch hat sich eine ganze Latte an Vereinfachungen ergeben..Also die haben ja damals den Source Code von [] genommen und haben dann das alles ausgebaut, was sie nicht brauchten. 28:29 [] hatte da eher breit aufgefächert, weil sie die ersten waren und haben immer mehr Businessmodelle unterstützt und dann wurde das Produkt immer größer, größer, größer, der Monolith ist immer mehr gewachsen. Und das war dann für wenige Leute nur noch greifbar, was da überhaupt eigentlich passiert. So dass dann jemand, der zum Beispiel einfach einen Shop betreibt in einem Land, war das ein riesen Klops da drin um eine Seite da zu betreiben, das war schwer zu vermitteln mehr oder weniger. Für Großkunden, die weltweit agieren ist das, die haben da — da haben noch Features gefehlt mehr oder weniger. Also das ist sehr, sehr schwierig das dann unter einen Hut zu bringen. Deswegen ist da, das hängt wirklich stark davon ab wie viel man damit abbildet. Einfacher je weniger und spezieller, aber dann ist es auch nur für den einen Usecase. Oder dann komplexer, dann ist meistens immer durch Konfiguration.

R1: Und technische Konfiguration genauso?

I8: Technische Konfiguration ist jetzt wie gesagt einfacher geworden, durch die Betriebssysteme und auch durch die Standards, die sich jetzt durchdrücken. Kommen wir wieder, Beispiel da drüben, da ist es so, wir wissen gar nicht wie das Datencenter aufgebaut ist. Da kann es sein, dass da auf einmal zwischen App-Server und Datenbank auf einmal ein Firewall ist und bei allen anderen Kunden nicht, als Beispiel. Oder die haben, wir hatten, jetzt mal wirklich ein ganz einfaches Beispiel, einen Kunden, der sitzt in Köln. Das ist eine einfache Telekom gewesen Unternehmen, also nicht die wirkliche Telekom, aber so ein Subunternehmen. Da haben wir die Datenbank, jetzt mal als Beispiel und nicht den App-Server, was eigentlich das selbe Prinzip ist, da haben wir versucht die Datenbank zu konfigurieren, dass der gleiche Last auf drei Festplatten sozusagen ausgleicht. Und eine Woche später bin ich nach Amerika geflogen zu einem Kunden, die drei verschiedene Datencenter — Hochverfügbarkeit, da gab es keine Downtime — die haben die Monster-Oraclelizenz gehabt, haben einen Haufen da investiert, da waren vielleicht das 50-, 60-fache an Datenbanken dagewesen für ein System. Und nicht bloß um drei Festplatten. Also so ist die Dimension, also was ein Oracle zum Beispiel abdeckt als Software. Das ist immer noch der eine Kernel der Datenbank und Storages anbindet und hochkonfigurierbar macht. Und deswegen macht ein Oracle es extrem schwer zu konfigurieren oder schwer zu verstehen für einfache Unternehmen. Die haben dann schon Vereinfachungen eingebaut, so kleinere Produkte, aber das ist ein gutes Beispiel von den Datenbanken. Und bei den App-Servern ist eigentlich genau dasselbe Prinzip.

R1: Gibt es Unterschiede in den verschiedenen Softwarelebensphasen bezüglich der Wichtigkeit oder Stellenwert von Konfiguration?

I8: Welche Lebensphasen?

R1: Requirements, Design, Implementierung, Testing...

I8: Achso, okay. Das machen wir sehr, sehr gerne. Und zwar wenn wir, ich nenne mal ein Beispiel, wir haben — im JDK ändert sich der Garbage-Collector. Wichtige Komponente, der die Objekte immer wegräumt und der hat ja — in jedem JDK verbessern sie den. Mit diesen Verbesserungen ist das Memory-Management ein unterschiedliches und wir wissen eigentlich nicht so richtig, welche Auswirkungen das hat. Also jede Änderung ist ein anderes Verhalten und das hat eine Änderung auf Performance, was gecacht wird und so weiter. Was jetzt passiert ist, also was man macht als Entwickler, wenn man noch nicht weiß, wie es ist und wie die richtigen Value, sofort als Konfiguration raus. Dann macht man das konfigurierbar, sagt seinem Testingeneur „Kannst du mal verschiedene Konfigurationen durchtesten?", weil das einfacher ist, als zu sagen „Pass mal auf, ich schicke dir mal zehn Branches und du probierst mal alle zehn Branches durch.". Das ist ein Grund, warum man diese Konfiguration einführt. Was sich dann rauskristallisiert ist, dass es Konfigurationen gibt, wo man sagt, die sind dann irgendwann konstant. Die bleiben meistens drinnen liegen, lassen wir so wie es ist, vielleicht ändert es sich ja beim nächsten JDK und so weiter, da ist die Änderungsrate relativ gering. Und dann gibt es aber welche, wo man sagt, das geht gar nicht anders. Das hängt wirklich davon ab, von den Daten der Kunden. Da kann es dann beim Kunden wieder konstant sein, dass sich beim Kunden sich das auch nie wieder ändert und dann drinnen bleibt. Und dann gibt es Situationen, wie Flashsales, Cybermonday und so weiter, wo man für eine bestimmte Period of time dann sagt, jetzt müssen wir da mal was ändern. Größeren Speicher und dann wieder runtergehen, weil wir die Ressourcen nicht brauchen. Das ist sehr, sehr unterschiedlich. Also vom Lifecycle, wenn ich neue Software einführe, versucht man immer natürlich das bequem zu machen, nicht dass ich jedes Mal neu deployen muss und dann den — irgendeinen anderen Code oder das andere Verhalten zu deployen und deswegen ist eigentlich fast alles, was wir machen, ich denke mal 80, 90 % ist irgendwie konfigurierbar. Entweder durch Properties, durch Feature-Toggles, durch was auch immer, Preferences, Laufzeitverhalten und so weiter. Das hat sich übrigens auch geändert. Dass das diese Konfigurationen da, also diese Möglichkeiten, die man da hat.

33:23

R1: Und 80, 90 Prozent konfigurierbar, über was für Mengen Code reden wir denn da?

I8: Das hängt ja von der Firma ab. Also hier die produzieren wie viele Entwickler da drinne sind, aber aus Risikogründen ist es sehr selten, dass wir sagen ich ändere irgendwas — Bugfixes ja —, aber wenn ich ein neues Feature baue, ist meistens hinter einem Feature-Toggle. Wo ich sage das Modul siehst du erst, wenn ich hier irgendwas anschalte und dann für bestimmte Kunden rollen wir das aus. Und wenn die alle gesagt haben, ist alles gut, dann nehmen wir es raus, dann ist es für alle Kunden verfügbar.

R1: Wurdest du denn während deines Studiums oder deiner Ausbildung auf so eine Konfigierbarkeitssachen—

I8: Null.

R1: —vorbereitet. Okay. Sollte sowas denn unterrichtet werden eigentlich?

I8: Ich denke in der Softwareentwicklung — also ich stelle ja viele Leute ein. Ich führe sehr viele Einstellungsgespräche momentan und das, was meistens immer, oder als ich noch im Studium war, da war, da gab es zwei Bereiche. Einer das entwickeln an sich und das andere war damals gewesen, die Infrastruktur und die Technologien, die dahinter waren und dann war es das eigentlich schon. Mit dem DevOps-Gedanke hat sich da auch die Anforderungen geändert. Weil wenn ich jetzt — auch, ich kenne jetzt auch ältere Entwickler, die sich erstmal dieses Umdenken, dass sie auf einmal Laufzeitumgebung auf einmal ownen, dass sie nicht nur die Technologie verstehen, was da passiert, sondern auch sagen, Empfehlung geben für die Konfiguration oder selber die Konfiguration applien und so weiter und das verantworten und Strategie. Das ist ein ganz anderes Mindset und die durchzudiskutieren. Also ich finde, man sollte wirklich dahingehend die Ausbildung verbessern. Und vor allen Dingen die Prozesse, die wären da sinn— wie, nicht nur wie — also man hat ja Objektorientierung eingeführt um zu sagen wie designe ich sowas, aber auch in der Ausbildung, wie betreibe ich. Also was sind SLEs, gibt es ja manche, das sind immer solche Spezialisierungen, (?35:25) die extra waren, aber das ist ja eigentlich alles zusammen. Wenn ich eine SLE von 99, drei Neunen habe, dann muss ich wissen, was bedeutet denn das. Und wenn ich da deploye, was wie muss ich dann deployen, was ist denn Deployment dann, groß, Risiko, Fehlerraten und so weiter, was da alles dran ist. Ich finde es aber auch nicht so schlimm, wenn man das im Berufsleben macht, weil man die Prozesse, die jetzt sich etabliert haben am Markt, die helfen einem schon, dass ein Junior-Softwareengineer erstmal was eincheckt und zeitig auf die Nase fällt, weil da zu viele Tests davor sind, dass der dann mit dem Entwickeln so lernt, was es denn so alles gibt und was er bedenken soll. Das ist beides.

R1: Das wäre eigentlich dieses eine Anfangs— jetzt geht es um arbeiten mit Konfiguration. Wir haben jetzt natürlich schon einiges schon so ein bisschen abgearbeitet, aber erste Frage: Wie werden bei euch Konfigurationen verwaltet und dokumentiert?

I8: Jetzt gibt es da zwei oder mehrere Welten. Es gibt eine ganze Latte von Konfigurationen, die — aber das hängt davon ab, wer konfiguriert das? Also was sind die Stakeholder. Wenn ich jetzt zum Beispiel — mein Team halt der Stakeholder ist, dann führe ich das Property ein, mache eine kurze Dokumentation drüber und möglichst findet man noch den Code dazu, dass die da reingucken können und welche Values sind da gültig und so weiter. Wenn ich noch gut bin, sage ich noch eine gute Exception mit Error Trace, wenn er was falsches einträgt. Das ist so das minimalste. Dann gibt es die andere Variante, wo man sagt, da wollen wir mitteilen dem Support-Engineer, wenn wir Konfigurationsänderungen machen, dass der was sieht. Dass die nicht nur für den Entwickler in dem Property-File, sondern von anderen Stakeholdern zumindest gesehen wird und Änderungen auch mitbekommen werden. Also zum Beispiel wenn wir, das haben wir mal so eingebaut, wenn der Server hochfährt, eine andere Konfiguration kriegt, dass man das im Log reinschreibt, das wurde geändert seit der letzten Inkarnation. Dann ist jemand, der Fehleranalyse betreibt, hilfreich, dass der versteht „ah, das ist eine Verhaltung(?). Wir haben es zwar nicht deployt, aber wir haben etwas umkonfiguriert, das hat potentiell einen anderen Codepfad und deswegen verhält sich das System anders."

R1: Wo wird das dokumentiert?

I8: In Logfiles meistens. Im einfachsten Fall. Der nächste wäre, wie gesagt die Metriken, die wir eingebaut und dann die Tools, die dazu waren, wo man sagt, wie ist denn die Einstellung? Oder wenn man Vergleiche macht, zwei Systeme, wie ist da die Einstellung und wie ist da die Einstellung? Es ist sehr, sehr unterschiedlich und hängt wirklich stark von der Konfiguration ab. Bis hin zum Businessnutzer, wo wir tracken wenn der irgendeine Änderung macht, wir wissen nicht warum, aber wir zumindest wissen, okay seitdem ist irgendwas fehlgeschlagen, da ist dann der Error grad hochgekommen und dann sehen wir, ah, da wurde doch die Änderung gemacht, sodass man relativ schnell den Fehler findet. Deswegen ist meistens, im Produktionssystem ist, wenn man Fehleranalyse betreibt, guckt man immer, was hat denn sich geändert, das passiert ja nicht spontan. Das kann einmal sein Deployment, Skalierung, Infrastruktur, Lastverhalten, Konfigurationsänderung, Datenänderung, sowas. Das sind immer so die, wo man immer guckt. Man versucht immer inkrementell rauszukriegen, wenn es gestern lief und heute nicht, dann muss irgendwas dazwischen passiert werden. Eine Sonneneruption wird es nicht sein. Das ist ein gutes Beispiel. Deswegen sind so Sachen, die man zum Beispiel — Hah, schönes Beispiel, ich kenne da einige — das lustigste, was ich mal gehört habe, als schöne Story, da war ein Oracle-Consultant unterwegs und der hat gesagt, ich habe einen Kunden gehabt, der hat angerufen und gesagt, Donnerstag wenn es regnet ist die Datenbank langsam. Und da musste er anfahren und gucken warum Donnerstag, wenn es regnet die Datenbank langsam — er war da, da war die Sonne scheinen, alles fein und dann hat er analysiert, analysiert, analysiert und dann hat sich herausgestellt, dass es — die Datenbank hat einen Optimizer drin, der dynamisch Konfiguration sich merkt. Also früher war das so gewesen, da musste man statisch sagen der Executionplan wird so ausgeführt und der Executionplan so, hat man einmal gegossen. Dann musste man manuell ganz viel konfigurieren und weil das aber kaum einer verstanden hat und einen Haufen Spezialwissen, hat Oracle angefangen, wir bauen mal eine intelligente Komponente rein, die das alleine rauskriegt. Das ist jetzt so die nächste Inkarnation, wo man dynamisch rauskriegt wie sich das System verhält. Und da war es so gewesen, abhängig von dem, der hat ja gelernt wie das funktioniert, wer zuerst was macht hat er entweder die Konfiguration oder die Konfiguration genommen. Das heißt immer Maintenance (?39:54 ), Datenbank wurde hochgefahren und dann wenn es geregnet hat, ist ein Mitarbeiter nicht mit dem Fahrrad gefahren, sondern mit dem Auto, war schneller auf Arbeit, hat seine Queries gemacht, die waren gut für ihn, aber für alle anderen schlecht. Das war der Hintergrund. Wo man merkt so, selbst wenn man das dynamisch macht und hochintelligent und das in Software gießt, es gibt Limitations. So und dann ist aber dieses es regnet selbst das ein Anhaltspunkt für ein System um Fehleranalyse zu betreiben. Alleine dieser Fakt, dass die sagen wenn es regnet ist der langsam, ist schon ein riesen hilfreicher Sache als der, der hinkommt und sagt, moment, was kann denn der Grund sein? Als lernen, also sind so Konfiguration und ausrechnen der Konfiguration. Was man jetzt auch gesehen hat in der Vergangenheit, dass diese Konfigurationsmöglichkeiten immer weniger, dass man das zwar konfigurieren kann, aber Komponenten draufgibt, die dynamisch errechnen, was die optimale ist, das dynamisch machen. Und die haben natürlich auch Bugs.

R1: Was ist denn der größte Vorteil von eurer Verwaltung bezüglich Konfiguration?

I8: Der Hauptgrund ist der Feedbackcycle eigentlich. Also diejenigen, die die Values ownen sozusagen, also die Werte, die da angelegt werden und der, der was ändert, dass der schnellstmöglich Feedback kriegt, ob die erfolgreich ist oder nicht. Das kann auch (?41:21) wenn er was ausprobiert, aber zumindest, dass der nicht sagt, „Ich stelle jetzt mal was ein und ich hoffe, dass das besser ist." Der Feedback ist ganz, ganz wichtig aus meiner Sicht. Und idealerweise ist es bevor er appliet wird und sagt, ne, das ist total falsch, dass er gar nicht das applien kann oder wenn er sagt, ich probiere mal mit einer größeren VM-Size aus und gucke mal, wie sich das verhält, das wissen wir jetzt nicht konkret. Und dann muss er mappen, diese Konfiguration auf Metriken, die vielleicht gar nichts mit der Konfiguration zu tun haben. Also Request-Response-Zeiten zum Beispiel oder Speicherverbrauch, Ressourcenverbrauch und so weiter.

R1: Okay, und der größte Nachteil? 41:52

I8: Der Nachteil ist momentan, dass das alles manuell gemacht wird. Also da muss jeder Entwickler, es gibt da keine allgemeines Pattern oder keine, ich würde jetzt mal, eindeutige Sprache oder Konzepte, wo man sagt das macht man heutzutage nur so. Das ändert sich wirklich alle paar Jahre. Also früher war ja Puppet und Chef der große Hype, jetzt ist es Docker, dann kommt Kubernetes. Ich bin gespannt auf die nächste Inkarnation, da wird wahrscheinlich ein KI-System dahinter sein, was dann sagt ich lerne das alles.

R1: Gibt es spezielle Tools denn zur Verwaltung der Konfiguration?

I8: Genau, es gibt welche, aber die sind, das ist sehr, sehr unterschiedlich. Also je nach Konfiguration ist das ist das sehr, sehr unterschiedlich was man braucht. Es gibt einen Haufen Möglichkeiten da was zu tun, aber was — also momentan setzt sich durch Docker mit Umgebungsvariablen. Das war vor fünf Jahren schlimm Umgebungsvariablen zu machen in der JVM. Bloß, weil sich die Umgebung geändert hat, versuchen wir im Sinne wirklich Environments. Mit wem Rechner rede ich, war früher immer in Propertys ausgelagert und jetzt ist es eher Tendenz Umgebungsvariablen.

R1: Und wie verwaltet ihr wiederum die Dockerfiles? Also wie verwaltet ihr praktisch die Configuration Files?

I8: Configuration as Code ist das große Schlagwort da in dem Punkt. Also wenn wir versuchen zumindest, dass keiner mehr im Ziel— wie sagt man immer? Die sind read-only die Instanzen, also unveränderbar, immutable Deployments. Und wenn irgendwann eine Änderung machen muss, muss er irgendwo was einchecken. Dann sieht man wer hat was und warum gemacht. Dann wird das appliet die Konfiguration und dann kann man gucken und dann hat man wieder mehr Informationen, dass was geändert wurde, den Grund warum es sich geändert hat und man kann mit demjenigen reden, wer hat das geändert und fragen warum hast du das denn jetzt gemacht? Gibt es da noch einen Hintergrund?43:44 Das sind ganz wichtige Informationen.

R1: Also wenn jetzt — also ihr geht immer über eine Art CI/CD-Infrastruktur drüber?

I8: Das ist unser Ziel, sind wir noch nicht, aber in die neuen Umgebungen alle, die jetzt in Public Cloud gehen, die machen das so. Da gibt es keine Möglichkeit—

R1: Also bei jedem Umkonfigurierungsschritt checkt ihr ein praktisch dann? Okay. Ja, wie kommuniziert ihr denn Konfiguration in Team?

I8: Das hängt davon ab auch wieder, was man ändert und warum. Also wenn man jetzt zum Beispiel, wenn ich weiß, dass, nehmen wir mal an, was könnten wir denn machen? (?44:25) gutes Beispiel? Es gibt doch wieder die Auswirkungen. Jedes Mal wenn ich jetzt eine Konfiguration ändere, muss ich mir Gedanken machen, was hat das für eine Auswirkung? Und dann kommen wieder die Stakeholders, die davon entweder profitieren oder nicht profitieren oder was anderes machen müssen und zumindest die muss ich darüber informieren. Das ist aber jedes Mal manuell, das kann man nicht automatisch ausrechnen.

R1: Also per Email, Telefon..?

I8: Per Email, bei Slack in unserem internen Teamchannel, Release-Notes zum Beispiel werden noch verwendet oder wir haben auch, wenn man sich bei uns im Backoffice-Tool einloggt, dann Nachrichten, dass wir haben jetzt eine neue Software ausgerollt, das sind die Änderungen, die wir gemacht haben. Dass der so ein bisschen Gefühl kriegt, was sich geändert hat und warum.

R1: Und was ist da der Vorteil von den Sachen, die ihr da macht?

I8: Na, es ist wichtig für die Leute, die das System betreiben. Dass die wissen, wenn irgendwas nicht geht, das ist immer die Fehleranalyse. Als auch, das ist ein bisschen Marketing, wenn etwas besser geht, dass die wissen warum. Lustigerweise haben wir das immer vernachlässigt. Also das haben wir immer nicht für wichtig gehalten, ich habe euer System verbessert, ist doch schön. Und dann hatte ich mal mit einem unserer größten Kunden zu tun gehabt und der hat — waren wir im Gespräch gewesen und dann gab es mal Probleme mit ihren Instanzen und dann habe ich das alles aufgenommen und habe Internas verbessert. Weil ich das aber nicht kommuniziert war, hat der Kunde gesagt, „Na ihr macht ja gar nichts, wir sollen alles machen und wir haben eine Haufen Tasks und ihr macht gar nichts. Das geht ja gar nicht." Und dann habe ich gesagt „Ne ne ne, wir machen das schon." und dann habe ich denen mal eine Insight gegeben, was das für ein Rattenschwanz dran war und dann hat sich rausgestellt, dass wir viel, viel mehr gemacht haben als er, wir hatten es bloß nicht kommuniziert gehabt. Und das war für den Kunden aber so so wichtig, dass denen das, wie groß die Mannschaft ist, die dran arbeitet und vor allen Dingen, das Resultat der Änderung. Hat das wirklich was gebracht oder war das irgendein Seiteneffekt, die auch positiv waren zum Beispiel. Und das war wichtig für den Kunden zu verstehen, der damit leben muss mehr oder weniger. Wenn ich zum Beispiel in der Werkstatt bin, mein Auto abgebe und die da irgendwie neue Hardware da auswechseln, will ich das ja auch wissen. Und wenn vielleicht einen neuen Turbolader oder die Reifen ändern, dann (?46:30 ) das ist wichtig, dass man das kommuniziert sowas. Und so eine automatische Anzeige für bestimmte Sachen fände ich mittlerweile, wir haben es nicht überall drinnen, meistens wird es manuell gemacht, aber in bestimmten Inkarnationen haben wir das jetzt schon drinnen, dass man das nachvollziehen kann.

R1: Und der Nachteil?

I8: Der Nachteil ist, es gibt Situationen — Eigentlich gibt es mehr Vorteile als Nachteile. Es gibt manchmal Situationen, politische Gründe warum das eigentlich nicht machen möchte. Wo man — Security ist so ein gutes Beispiel. Ganz, ganz kritisch. Also man muss aus Security-Gründen etwas ausschalten, anschalten, irgendwas oder sich an Standards halten, weil dann Probleme gibt und die Kunden interessiert meistens Security nicht. Also das ist immer der — Im Web, also wenn ich mir überlege, 2000, wie naiv wir damals vor 20 Jahren im Web die Seiten entwickelt haben und was sich seitdem an Security geändert hat, ist das schon, also das, ich sage mal vor 10 Jahren würde ich locker, vor 5 Jahren wahrscheinlich, ist das Netz komplett offen gewesen für jemanden, der sich auskennt. Das ist glaube ich wirklich — was jetzt an Sicherheitslücken rausgekommen ist, ist der Wahnsinn. Und manchmal ist es besser, dass man Informationen erstmal geheim hält, damit das nicht groß auffällig — wir werden jetzt nicht sagen „Okay, wir haben eine Fehlkonfiguration gemacht. Wir haben aus Versehen vergessen dieses Property zu setzen damit keiner invaliden Code hochlädt." Das kommuniziert man natürlich nicht. Intern ist das ganz heikel, das wird auch ganz restriktiv gemacht, dass das ja keiner weiß.

R1: Aber dann steht es ja schon im Repository drin, oder? Wenn jemand die Konfiguration—

I8: Wenn jemand auf dem Repository guckt, da hoffen wir, dass wir schneller deployen als dass jemand diese Sicherheitslücke ausnutzt. Das geht aber nicht anders. Das ist immer so ein Henne-Ei-Problem. Repository muss natürlich jeder getrackt werden, der Änderungen gemacht hat. Erst recht security-relevante. Man kann auch sagen da war noch gar keine Lücke, aber ich baue ein Security-Feature ein. Muss natürlich da, hier das dokumentiert, wer hat das warum eingebaut. Weil das kann ja auch eine Lücke sein. Das ist sehr, sehr schwer. Also Securitybereich ist ein ganz eigenes Thema, riesengroßes in dem Bereich.

R1: Werden bei Codereviews auch bei euch Configuration Files —

I8: Ja.

R1: ...reviewt und wie ist der Prozess dahinter?

I8: Das ist genauso wie der Code. Also das ist eigentlich — also was auch passiert, dass beim Review festgestellt wird, warte mal, du machst du die Änderung, ist dir das Risiko bewusst, was passieren kann? Der Reviewer guckt dann drauf und sagt ja warte mal, kann man das zurückrollen, wenn man das Deploymentnetz, das hochfährt und das — in den Umgebungen nicht geht. Oder wir machen Annahmen über Umgebungen, wo wir nicht genau wissen. Das ist bei 99 % überall wo man guckt das richtige, aber es kann sein, dass eine sehr, sehr alte Instanz, die seit 15 Jahren läuft, dass die das eben noch nicht konfiguriert hat. Da ist ein Review sehr, sehr, wo man sagt, jetzt brauchen wir einen Feature-Toggle ringsrum, dass man das ausschalten kann. Zumindest zur Laufzeit. Damit wir schnell reagieren können. Was passiert. Aber es ist auf jeden Fall, bei den Entwicklern ist das wie Code. Das ist dasselbe, selbe Anforderungen.

R1: Habt ihr irgendwelche Kriterien und spezielle Zeitpunkte in denen ihr Konfigurationsoptionen plant und dann implementiert?

I8: Ja, das hängt auch wieder mal von der Komponente ab. Da kann ich wieder ein konkretes Beispiel nennen. Wir haben manche, in der Vergangenheit wurden manche Probleme in der Infrastruktur gelöst, die der Kunde hatte. Aus Security-Gründen haben die Put Blocks, sogenannte. Also da ging es darum, dass jemand nicht Code uploaden kann im Produktionssystem. Das haben die damals in Firewallkonfiguration gelöst. Rausgestellt hat sich danach, dass die nicht nur den Code-Upload ausgeschaltet haben, sondern alles andere auch. Also was man im REST-APIs jetzt braucht. So und jetzt hat man da eine Konfiguration appliet und die müsste jetzt so verallgemeinert werden. Das schafft aber der Firewall nicht. Deswegen mussten wir das dann in einen anderen Layer verschieben. Das Projekt hört sich ganz einfach an, dass man diese Konfiguration, das File da nimmt, A macht, daraus ein B macht im anderen und dann geht das. Also ein bisschen Code dazu schreibt. Der Aufwand war, das Code schreiben war drei Tage, Monitoring zu machen, dass 10.000 Instanzen korrekt konfiguriert sind — also man muss so sagen, das ist die alte Konfiguration. Die muss rüberkopiert werden in die neue Konfiguration. Dann muss monitoren, dass das überall auch passiert ist, weil meistens Ops-Engineers sind da, haben wir gemacht und dann sagen wir Entwickler „Ne, auf der Instanz und auf der Instanz—". Wir haben von 10.000 Instanzen drei gefunden, wo das nicht passiert ist. Oder da wurden ganze Pods, Datencenter vergessen. Menschliches Versagen einfach nur. Ist aber normal, wir sind alle Menschen, wir machen auch Fehler. Deswegen versuchen wir das immer sowas zu validieren und dann wir eine Overload-Strategie, wo wir dann sagen jetzt schalten wir es mal für einen Pod aus und dann sukzessive für den nächsten, gucken dass das alles geht und haben natürlich, validieren das, dass die neue Funktion appliet wird und dass alles funktioniert. Das kann sehr, sehr komplex werden. Konfigurationsänderung. Also wenn man das wirklich systematisch für zehntausende Instanzen macht. Das kann aber auch manchmal ganz einfach sein, wenn wir sagen, ach, ob da jetzt drei oder vier steht, wir tragen da irgendwas ein, rollen es aus und hoffen, dass da nichts passiert. Also wo wir sehr confident sind, dass das alles total einfach ist.

R1: Wie viel Aufwand betreibt ihr denn zur Entwicklungszeit eines Systems um Konfigurationsoptionen einzubauen?

I8: Gibt es auch wieder verschiedene, hängt von dem Use-Case ab. Auch wieder ein konkretes Beispiel, wo vielleicht drei oder vier Tage der eigentliche Code, der neue Code da ist, der laufen soll und nur die Konfigurationsänderung war mit Kommunikation ein riesen Projekt. Also nicht der Code an sich, aber die Kommunikation mit dem Ops-Engineer, wer was zu tun hat, war das Verhältnis ungefähr gefühlt, Diskussion und Code war 90 zu 10. 90 % Diskussion wie, was, wer, wann, wie, warum, in welcher Reihenfolge, mit welchen Pods, das durchdiskutieren und coden war ganz wenig. Anderes Beispiel war auch gewesen, wo wir einfach nur ein Directory von einem Punkt zum anderen verschoben haben, aber da waren ganz viele Prozesse drauf und damit man Rollbackfähigkeit machen und wir nicht wussten, ob wir Codeteile gefunden haben, die auf die neue Location gehen, haben wir alles umgehangen, es kann aber immer noch sein, dass irgendein Code, den wir vergessen haben — menschliches Versagen — trotzdem auf den alten geht. Das man immer noch sagen kann, symbolischer Link, umhängen, anderes Environment, das Zurückrollen, da war auch ein Verhältnis locker von — dieses Feature-Toggle einbauen und hin- und herswitchen waren 90 % das Featuretoggle, 10 % der eigentliche neue Code noch. Das sind die Extremwerte wirklich. Normalerweise ist, der normale Fall ist eigentlich also einen if-Block ringsrums und neuen Code aufzurufen, das geht einher. Das ist wie normales coden, das kann man eigentlich gar nicht klassifizieren. Das hängt immer vom Risiko ab. Das Risiko ist da ein ganz, ganz wichtiges Thema. Was passiert, wenn man sich irrt. Und daraus ergibt sich ganz viel wer, was, wie, wann, mit welchem Lifecycle konfigurieren wir.

R1: Und wenn wir jetzt bei der initialen Einrichtung einer Konfiguration für ein Tool oder für so eine Deploymentchain und weiter, wie viel Aufwand würdet ihr da mit rein?

I8: Das hängt natürlich immer wieder von den Installationen ab. Das kann man sehr schön an Demandware sehen. Früher hatten die drei Kunden gehabt, da haben nicht viel investiert in — haben dich angerufen, guck mal in Logfiles, fertig erledigt. Bei 10.000 Instanzen ist dieser Anteil der Formalien das hängt von der wie viele Systeme ich habe und wie viele Leute daran arbeiten, die mitarbeiten. Wie viele Stakeholder davon abhängen und dann leiden mehr oder weniger. Wenn es auch mal — wie gesagt mit den drei Instanzen, das hört sich jetzt nicht viel an. Letztendlich, auch wenn es, wenn man sagt das ist eine Quote von 99,999irgendwas und dann 7 % irgendwie, wo ich sage ist es erfolgreich gewesen, ein erfolgreiches Projekt? Nein. Wir werden Sonntag nachts raus, wenn das Deployment läuft und die drei Instanzen nicht gehen, stehen wir auf der Matte. Und deswegen haben wir ein persönliches Interesse daran, dass das läuft, also zu 100 % eigentlich. Wobei das auch zwischen den Kulturen sehr unterschiedlich ist. Also jetzt mal so ein kulturelles Problem. Wir Deutsche sind da extrem pessimistisch. Deswegen sind wir gute Engineers für solche Systeme, weil wir da wenig Noise verursachen im Sinne, dass irgendwas nicht geht. Während die Amerikaner sind sehr mutiger. Auch mal so als kulturell hat das auch was, wo die sagen ach, ist ja nicht so schlimm, dann (?55:11) mal runter. Und firmenpolitisch. Ansehen ist extrem wichtig da in dem Fall. Wenn jetzt, hat man bei Google gesehen glaube ich. Und bei Microsoft. Die haben ja Public-Cloud-Implementierungen und bei Microsoft ist es vor kurzem passiert, dass mal ihre Datenbank, ein großer Datenverlust war. Das war auch eine Konfigurationsänderung. Die hatten selber jetzt auch Konfigurationsfehler gehabt, wo man eben dynamisch die geändert hat bei einer Datenbank und das hat ja securitymäßig riesen Auswirkungen gehabt auf unsere Kunden und da mussten wir gut reagieren drauf. Also das ist, wie gesagt das Risiko ist da ganz wichtig. Also wenn ich ein kleines Unternehmen bin, was ein Startup ist, mit einer Software, die nicht so wichtig ist, ist das fein. Groß agierende Unternehmen, die haben, das geht sofort in die Zeitung und da war mal Microsoft für drei, sechs Stunden weg. Oder Google war vor kurzem gewesen, mit dem Google Docs und dem Mailclient, war mal für eine Stunde oder zwei Stunden weg. Das ging durch weltweit, in alle Presse. Bei kleinen Unternehmen — ich habe schon Kunden gesehen, damals drüben bei denen, da war der Shop 9 Stunden down, die haben das nicht mal gemerkt. Also das war ein deutsches Unternehmen und jetzt mal wirklich die Aussage von dem war „Ach, wir haben Verträge mit den Kunden. Die können gar nicht weg, weil die Kündigungsfrist ist drei Monate und dann müssen die eben später kommen." Das ist wie ich bin mal kurz Kaffee trinken, eine rauchen am Store. So sehen die das. Während die anderen, die den Umsatz messen und dann genau sagen warte mal, zu der Zeit haben wir so und so einen Umsatz, das macht so und so viele Millionen. Ihr seid dran Schuld, Kohle her.

R1: Wie viel Aufwand betreibt ihr denn, wenn so Versionsänderungen kommen. Oder andere Konfigurationsabhängige Änderungen. Also jetzt war ja Spring Boot von 1 auf 2 zum Beispiel.

I8: Genau. Also bei, die kleineren ist ganz relativ gering. Wir haben unsere Testsuite dazu laufen. Also so Security-Patches ist relativ einfach. Dann gibt es eben Minor Updates, die gehen meistens. Die Kompatibilität ist nur marginal, ist noch relativ einfach, sind so kleine Projekte. Also ich sage mal ein Sprint, zwei Sprints. Also in einem Monat ist das durch. Wenn man jetzt sagt JDK 11 wird ein Riesenprojekt, das wird über ein halbes Jahr dauern denke ich mal. Tomcat-Upgrade zum Beispiel ist ein riesen, riesen Projekt, weil da meistens auch das Verhalten sich ändert. Gerade Cookie-Handling und sowas. JDK 11 sind die Librarys unterschiedlich. Müssen wir rauskriegen die ganzen anhängigen Librarys, das ist, das sind richtig monströse Projekte. Also jedes Team muss dann gucken, dass sein Code noch funktioniert. Riesiger Kommunikationsaufwand. Reihenfolge betrachten. Docker-Images upgraden. Die ganze Laufzeitumgebung. Dass überall dasselbe deployt ist. Rückschaltfähigkeiten. Also das ist richtig, richtig fett.

R1: Ja, was ist denn für euch der größte Faktor, der den Konfigurationsaufwand bestimmt?

I8: Das kann man an der Konfiguration nicht festmachen denke ich. Das eine ist, wenn man einmal eine Infrastruktur hat um Konfiguration zu validieren — also wir haben ja wie gesagt verschiedene Arten von Konfiguration, wo ich sage eine Property alles fein, hin zu ein UI, wo man schon vorher einen Haufen Logik reinmacht, dass nichts falsches konfiguriert wird und wo man die Konfiguration vielleicht auch testen kann. Man wählt ja dann die jeweilige aus nach was denn das für eine Auswirkungen hat, die Values. Also ist das Risiko groß die Änderung zu machen, dann investiert man wesentlich mehr, ist die Änderung klein, wenn da irgendwas ist, dann geringer. Oder von der Testabdeckung. Das ist auch ein ganz wichtiges Kriterium. Also wenn ich sehe, ich habe da zwei Pfade und da sind bloß die beiden Code-Schnipsel und wir haben in Unittests beide durchgetestet und nach außen ist umgebungsunabhängig, dann brauche ich jetzt nicht groß noch irgendwas mit (?59:21 )-Strategien machen. Bisschen kommunizieren, fertig, erledigt. Sobald man aber mal eine Environment-abhängigkeit hat oder Unbekannten, wie zum Beispiel, jetzt kommen hier ein Haufen Requests für uns ran und die Komponente, die die Requests entgegennimmt und die parst und validiert und dass das alles korrekt ist, wir man die ändert, wie der Tomcat, dann ist das sehr groß. Weil wir wissen ja was geht, wir wissen aber nicht, was im implizit so geht. Also wenn jetzt im Header mehr schicken oder Characters in Headers, gerade international mit Japan und China, wenn auf einmal andere Unicodes reinkommen oder wenn sich Zeitzonen in Chile ändern regelmäßig — das ist so ein Ding — das sind so Herausforderungen, die man hat gerade wenn man weltweit unterwegs — ich weiß doch nicht, was in Chile, wie da E-Commerce funktioniert. Da hoffe ich, dass wir genug implementiert haben das hinzukonfigurieren. Als Beispiel. Das ist wirklich, also wirklich die Values ist mehr da entscheidend als die Konfiguration an sich. Das ist nur ein Tool um das Risiko zu minimieren aus meiner Sicht.

R1: Jetzt noch mal eine spannende Frage, da kannst du glaube ich noch was zu erzählen, benutzt ihr denn Konfigurierbarkeit um nicht-funktionale Eigenschaften wie Performance zu tunen?

I8: Ja, natürlich. Ganz viel. Also das ist, da besteht die Herausforderung drin, erstens ist es extrem technisch, es gibt nur einen ganz kleinen Kreis, der versteht überhaupt, welche Values kann ich da eintragen und warum und wie sind die Abhängigkeiten zwischen den Sachen. (?1:00:57) ist da hochkomplex. Also brauchen wir wirklich, das sind die besten Leute eigentlich, die wir haben. Die darauf gucken, wissen, alle Metriken kennen, alle Codeteile, die damit zu tun haben, wie das zusammenspielt, die ganzen Technologien dahinter kenn und ein Modell haben im Kopf wie das funktioniert. Also technische Konfiguration ist, also aus Performancegründen ist sehr, sehr schwer, weil die auch noch iterativ ist. Also man kann, also das ist immer der Irrglaube wie man ein Businessfeature entwickelt mal so. Man hat einen Sprint, man definiert was man haben will, dann sagt man, dann implementiert man los, da ist die UI da, dann klickt man, dann ist es da. Bei Performance ist es so, man kann jetzt nicht sagen heute ist mir so, wir haben festgestellt je schneller der Shop ist, deswegen sehe ich mal zu, dass wir jetzt die Antwortzeiten eine Millisekunde ist. Weil da gibt es ja technische Grenzen und Gründe. Und dann fängt man an zu diskutieren und dann das eine ist die festzulegen, die non-functional Requirements, dass man da hinkommt und das andere ist, wie komme ich denn jetzt dahin? Da muss man erstmal so eine Baseline machen, dann fügt man Code hinzu, dann muss man den mit dem alten vergleichen, das Verhalten und gucken, ob das besser wird. Und wenn man nicht nur eine Schraube dreht, sondern fünf, sechs, sieben, acht Schrauben, weil die alle miteinander zusammenhängen. Kann man sich vorstellen, wie tune ich denn jetzt einen Formel-1-Wagen, was die da machen. Das ist sehr, sehr schwer.

R1: Habt ihr da, ist das mehr manuell oder habt ihr da auch Machine Learning dran und so weiter?

I8: Bei uns ist das sehr manuell momentan noch. Also ich denke darüber nach, das zu tun, im Sinne von, dass wir sagen einmal kann man es manuell einstellen und dann legt man noch eine andere Komponente drauf, die einfach mal verschiedene Kombinationen durchtestet. Aber das wäre eine ganz eigene Abteilung, die das macht und die Daten liefert, analysiert, Learning-Algorithmen drauf. Weil diese KI, die dahinter steht, die braucht viele Daten. Also KI funktioniert nur — man braucht ein Mindestmaß an richtig vielen Daten und dann die Daten, die man hat, müssen auch noch das richtige enthalten. Das ist ganz schwer.

R1: Da können wir uns vielleicht 1:02:58 nach dem Interview auch noch mal unterhalten, weil genau das haben wir auch genau drauf spezialisiert.

I8: Ja, sehr schön. Brauchen wir.

R1: Auf die Optimierung von Konfigurationen für Performance und so weiter.

I8: Ja, das brauchen wir. Das brauchen wir. Das brauchen wir. Das macht unser — das machen nicht wir beim [Projekt], aber das macht [das andere Projekt] (?1:03:13). Die haben ein eigenes Team, die KI nehmen um zu erkennen, ob neu skaliert werden muss. Die haben da schon so Grafiken, wo die bestimmte Parameter machen. Weil das ist sehr speziell.

R1: Gut. Naja, kann man das noch mal—

I8: Also sehr, sehr gerne. Da bin ich sofort, leuchten da meine Augen. Bin ich sofort dabei. Helfe ich gerne.

R1: Kommen wir vielleicht noch mal vorbei und dann können mal einen Vortrag halten, was wir so gemacht haben.

I8: Also ja, wirklich.

R1: Super. Okay, jetzt sind wir bei den Konfigurationsfehlern. Stellt die Konfiguration von Systemen, Tools, Infrastruktur, Frameworks und so weiter euch vor Probleme bezüglich Fehlern?

I8: Ja. Also ich denke mal es ist auch historisch gewachsen, die, ich sage jetzt mal die verfluchten Properties, es ist ja immer noch die Basis, wo man irgendwo ein Textfile hat, wo man etwas reinschreibt und dann kann man irgendwas reinschreiben. Tippfehler. Also ein gutes Beispiel, wir haben ein Property gehabt, was bestimmte Cache-Sizes konfiguriert hat beim Kunden und das haben wir optimiert und haben wir die erste Optimierung gemacht, wurde besser, machen wir eine zweite, sind wir uns sukzessive haben wir uns an die Konfiguration angenähert. Also schön alles manuell, nicht Machine Learning und haben gesagt „Oh, jetzt machen wir die letzte. Das wird die finale." und dann konfigurieren die und knallt es auf einmal. Wir: „Was ist denn nun los?" und haben analysiert und fertig und Hintergrund war gewesen, da war ein Leerzeichen zu viel in der Konfiguration. Und sowas finden, das ist... da verliert man den Glauben. Und wenn man da Metriken hat und Feedbackschleifen, kann man, kriegt man, erfahrene Entwickler kriegen das relativ schnell raus. Aber für jemanden, der dann das System kriegt, das ist der Horror. Wenn so nicht sichtbare Zeichen Auswirkungen auf irgendwas haben.

R1: Was sind denn deiner Meinung nach die schwerwiegendsten Probleme? Die die meiste Zeit vielleicht in Anspruch nehmen oder die die meisten Auswirkungen auf die Kunden haben oder so.

I8: Die schwerwiegendsten Probleme denke ich mal sind immer die, wo man keine Konfiguration hat. Also wenn der Entwickler sagt ich weiß doch wie es geht, bei mir geht es auf dem Laptop und dann knallt es beim Kunden, dann steht man nämlich da. Weil das ist ein riesen Aufwand dann. Man kann da nicht — man kann entweder zurückrollen, wenn Glück hat, wenn es zeitig genug auftritt. Das haben wir ja noch so eingeführt, aber dieser Rückrollprozess ist sehr aufwändig. Schlimmer wird es wenn Datenverlust ist. Dann muss man Recovery fahren. Da sind ganz viele Leute involviert, hohes Risiko, Frustration beim Kunden, ein bisschen Gesichtsverlust noch beim Kunden und so weiter. Und das sind eigentlich — Datenverlust ist das schlimme. Wenn eine Konfiguration Datenverlust bringt.

R1: Habt ihr da so ein Beispiel?

I8: Ein böses Beispiel. Ist sogar mal mein Bereicht gewesen. Das war so, wenn man in so einen 20 Jahre alten Mono — der ist ja schon 22 Jahre alt — 22 Jahre alten Monolithen hat, dann ist natürlich nicht, dass 22 Jahre lang Leute daran arbeiten, wie ich, sondern da sind mal da mal einer zwei Jahre, dann mal drei Jahre. Und dann entsteht viel Code, den keiner versteht. Das sind so Codestyles und so weiter sind da ganz wichtig. Und wenn man dann — irgendeiner erbt den ja. Und wenn man keine ordentliche — dann denkt man so, die Klasse die macht schon irgendwas. Ich weiß nicht, was sie macht. Wie die im Kundenfall, wie die ausgerollt war, man weiß nichts darüber. Und dann fängt man an Annahmen zu treffen, wo man sich selbst belügt, weil man den Code nicht anfasst. Man fasst nicht gerne fremden Code an. Und dann hat man ein echtes Problem. Weil das ist da passiert. Ich hatte so eine Klasse, die hat mir nicht gehört, hab da immer vertraut, dass die läuft, weil die seit zehn Jahren lief. Baue ich immer alles ringsrum und hatte aber den Effekt gehabt, dass jemand dann die ausversehen aufgerufen hat, in einem ganz anderen Kontext und das hat dazu geführt, dass der einfach anfing alle Daten zu löschen. Das war die Löschlogik um einen Katalog zu löschen, die wurde aber appliet auf ganz andere Sachen und dann waren ganz wichtige Tabellen auf einmal weg.

R1: Und das war ein Konfiguratiosfehler, oder?

I8: Ja. War auch ein Konfigurationsfehler. Also es kann immer Code und Code sein. Es ist — also Code, als jetzt in der Entwicklung. Ob das jetzt im Property-File steht, der einen Pfad macht, letztendlich ist immer ein if-Statement irgendwie dahinter. Im einfachsten Fall. Es kann auch manchmal so ein paar andere Werte sein oder ein Switch, aber meistens ist es ein if-Switch irgendwas und dann hat man einen anderen Codepfad. Das ist — ob ich den Code deploye oder mit if freischalte ist dann auch wurscht. Deswegen ist da Code und Konfiguration — das hat sich auch geändert seit zwanzig Jahren — es wird gleich behandelt. Früher hat man beim Support angerufen „Konfiguriert es doch um, ist doch euer Bier. Ich hab dir den Value nicht eingestellt." Aber das ich hätte es programmieren müssen, dass ich sage wenn der hochfährt ne das machst du jetzt mal nicht oder ignoriere die invalide Konfiguration, das hat man damals nicht so, als Junior-Softwareengineer, habe ich nicht so gedacht.

R1: Was sind die Probleme und Ursachen für Schwierigkeiten bei der Konfiguration?

I8: Also es ist zum einen, also das ist jetzt mein Gefühl, also das ist jetzt wirklich sehr subjektiv, also würde ich jetzt nicht mehr allgemein sprechen, aber ich denke mal, wenn man zum Beispiel ein Properties hat, so man frei irgendwas eintragen kann und keine Validierung hat schon beim Editieren, ist das immer mit Risiko. Das ist, man merkt halt, man hat ja so eine Testsuite, die baut man durch, aber ich mache eine Konfiguration, dann lasse ich es durchbauen, dann ist es rot und dann „ach, da hab ich einen falschen Wert eingetragen oder ein Leerzeichen oder falsche Annahmen gemacht, dass das nicht funktioniert" und so weiter. Es gibt, ich denke mal viele Konfigurationen, wo man schon vorher Validatoren einbauen kann. Aber das muss man erstmal machen. Also Docker hat da nichts. Das sind alles Textfiles. Und dann mal ausversehen drauf gedrückt beim Einchecken vorher, an Enter rangekommen, wo man sich umgedreht hat, weil jemand was gefragt hat, macht dann, checkt ein und dann knallt es und dann wieder von vorne. Das macht jetzt nichts kaputt, aber es ist nervig. Und dauert, frisst Zeit einfach. Entwicklungszeit. Das ist so, was wirklich nervig ist. Ansonsten Schwierigkeiten bei Konfiguration? Was auch schwierig ist, Konfiguration ist das eine Thema, aber zu validieren was kofiguriert denn sie. Das Mapping zu wenn du diese Konfiguration änderst, gehst du ins Grafana und guckst dir folgende Metriken an, ob das besser geworden ist. Das hat ja nichts mehr mit der Konfiguration zu tun, sondern mit dem freigeschalteten Code.

R1: Ja, das Tracing praktisch.

I8: Genau. Also dass man — ist es denn wirklich besser? Also das geht einher, gerade bei Performancesachen. Also ich habe — das sieht man sehr, sehr viel, dass der Entwickler sagt „Ich habe im Java-Buch gelesen, dass man das so macht und dass das viel schneller ist." und dann haben wir Kurse gehabt hier, wo man dem erklärt, dass das beim Kompilieren dieses, das was er geschrieben hat, der sowieso macht. Aber ob man so schreibt, so schreibt, oder so schreibt ist egal, kommt immer derselbe Bytecode raus. Nur mit dem Unterschied, er hat das dann so geschrieben, dass das kaum einer lesen kann. Zum Beispiel solche Sachen. Also diese Schleife zu was bewirkt der Code das ist wirklich schwer zu verstehen. Und dann gibt es auch Frameworks, wie zum Beispiel (?1:10:33), haben wir wieder ausgebaut, eingebaut, wieder ausgebaut, wo man gar nicht mehr sieht im Code, dass da noch im Bytecode was geändert wird unten drunter. Das ist der Horror, wenn man sowas baut.

R1: Kannst du denn ein schwierig zu konfigurierendes Tool oder Framework nennen? Und warum genau das?

I8: Docker. Nein, das war nur Spaß. Schwierig zu konfigurierendes Tool? Die Buildchain eines Monolithen. Also das ist zum Beispiel — ist ein schönes Studentenprojekt wahrscheinlich — wir haben ungefähr, locker, um den Monolithen zu bauen, Repositorys. Git-Repositorys. Die sind erstmal, hat man (?1:11:20 ), da steht Code drin, der wird irgendwie durch einen Buildprozess durchgebaut und dann kommt ein Artefakt raus. Das ist von einem Jar, hin zum Dockerimage, hin zum tar, tar.gz, oder irgendwas. Das sind ganz verschiedene binäre Sachen. Jetzt hat man immer, das ist jetzt mein Problem gerade, im Sourcecode-Repository eine ganze Liste, die von irgendeinem anderen Server ausgeführt, der ist ein Jenkin jetzt, der irgendwas produziert, dann hat man irgendwas binäres. Die Sourcecode hängt irgendwie miteinander zusammen. Die Jenkins müssen in irgendeiner bestimmten Reihenfolge ausgeführt werden und die binären Repositorys hängen miteinander irgendwie zusammen. Ich habe noch kein Tool gesehen, dass mir das visualisiert.

R2: Was meinst du mit binären Repositorys?

I8: Also Nexus oder (?1:12:02) bei Docker. Das sind immer so Sachen, wo da, irgendwas produziertes liegt dann da drinnen. Gezippt, fertig, binär ausführbar und das muss dann irgendwo hin deployt werden und gemacht werden. Und das zu konfigurieren und zu sehen und einen Überblick zu schaffen, gerade bei so einem riesigen Monolithen oder vielleicht noch bei Services vielleicht noch verrückter, weil die ja noch loser gekoppelt sind und Abhängigkeiten da vielleicht ganz anders funktionieren. Das ist wirklich, also wenn man, je loser gekoppelt und aber Abhängigkeiten, implizite Runtimeabhängigkeiten, umso schlimmer wird es. Weil man kriegt ja erst das Feedback wenn alles deployt ist. Ob das funktioniert. Man merkt das ja vorher nicht.

R1: Was sind für dich denn Konfigurationsfehler und wie unterscheiden die sich von normalen Bugs?

I8: Also Konfigurationsfehler... für mich ist das dasselbe. Also — aufpassen! Jetzt muss ich mal langsam überlegen. Jetzt muss ich über die verschiedenen Arten von Konfiguration nachdenken. Ist die Konfiguration mit dem Sourcecode eingecheckt, ist Bug und Konfiguration ist das dasselbe für mich. Das macht keinen Unterschied, weil da der selbe Prozess dahinter hängt um das zu fixen. Du musst auschecken, ändern, einchecken, gucken ob wie es geht, fertig, erledigt. Dann gibt es die Laufzeitkonfiguration, wo man sagt, wo der Bug eigentlich die Validierung ist. Fehlerhafte Validierung. Also wir hatten auch schon Sachen gehabt, wo man eigentlich mehr besser konfigurieren könnte und die Validierung zu restriktiv war. Da musste ich erst die UI ändern, damit noch eine Zahl dazu kommt, die man konfigurieren kann. Und das dritte ist, bei einer Konfiguration Abhängigkeiten, also diese Seiteneffekte, ich glaube nicht, dass wir, dass es da allgemeine. Also ganz schwer zu finden sind solche Sachen, wenn ich jetzt, im Monolithen vor allen Dingen, da was zu schraube, dass es da vorne knallt. Das hat man bei Services wahrscheinlich auch. Ich lösche eine Version von einer API und dann knallt ein anderer Server. Bei mir ist alles grün, kommt ja nichts mehr an, kein Request, sieht toll aus. Das ist übrigens auch ein schönes Thema auch für den Services(?1:14:29). Wenn ich jetzt eine Firma bin und jeder baut da Services und da sind mal 300, 400 Services und dann gibt es einen, einen Entwickler, der sitzt da, baut einen Service und der kriegt noch Requests, kann sagen hier, so kommt das an. Kann ich mir gut vorstellen, dass es irgendwann mal Services gibt, die gar nicht mehr gebraucht werden. Dass das so eine selbstlebende Beweihräucherung ist.

R1: Welche Auswirkungen von Konfigurationsfehlern sind denn häufig bei euch. Also auch Performance möglich, aber auch keine Ahnung.

I8: Also Perfomance, das passiert schon öfters. Wir versuchen jetzt so Profile anzulegen, wo man sagt es gibt, ich spinne jetzt mal rum, ich weiß jetzt nicht genau die Zahlen, aber sagen wir mal 20, 30 Properties, die irgendwie miteinander zusammenhängen. Und die müssen dimensioniert werden, wie die Zahlen da drinnen stehen und dann sagt er wir machen drei Templates. Es gibt einmal die, die und die. Bronze, Silber, Gold. Und nur die wird appliet, weil wir die schon durchgetestet haben und Erfahrung mit anderen Kunden haben. Wenn jetzt jeder da selber losgeht und ne, bei dem einen Kunden weiß ich, mache ich was anderes da wird das immer schierig das — also wie gesagt, Performance ist wirklich schwer. Was heißt denn Performance? Antwortzeit vom Request? Von welchen Requests? Ressourcenverbrauch zählt auch mit dazu. Das ist so, Performance alleine ist ja schon ein kompliziertes Thema.

R1: Hast du selber schon Konfigurationsfehler erlebt und was sind dann besondere, vielleicht nicht nur schwerwiegende, aber vielleicht so ein besonderer Fehler mal.

I8: Ja gut, da hatte ich jetzt schon ein paar Beispiele. Also mit dem Regen, das ist so ein typischer, das sind ja, da gibt es ja ganz viele verschiedene Arten, also — was könnte denn besonders sein noch?

R1: Vielleicht einer, der sich gut versteckt hat oder —

I8: Ja, ein gutes Beispiel: Wir haben, ist jetzt auch vor kurzem aufgetreten, nehmen wir eine Datenbank und die Application-Server, die müssen ja auch konfiguriert sein, wie die miteinander reden. Der Datenbank sagt man du kannst 5000 Connections annehmen. Und je nachdem wie viele App-Server ich davor stelle und die skaliere, müssen die die Datenbank, die abhängige, auch natürlich das können. Jetzt gibt es noch ein Pool im Applicationserver um die Connections zu reusen und da gibt es so eine Konfiguration, was ist die minimale Anzahl und was ist die größte Anzahl, was du kannst. Man sollte tunlichst das hinkriegen, dass die die Summe aller maximalen Anzahl vom Appserver einhergeht mit der Oracle-Datenbank. Jetzt liegen die zum Beispiel in verschiedenen Systemen. Mir ist kein Validierungstool, dass das validieren kann überhaupt. Also jetzt, es gibt Standards draußen, HP OpenView oder solche Monitoringtools, die wo man das machen kann, wahrscheinlich auch so Regeln einbauen, aber das muss man alles manuell programmieren und das haben wir glaube ich gar nicht. Bei uns knallt es, dann gucken, dann gibt es ein Ticket und so weiter. Eine spezielle Konfiguration, war die ?1:17:27, die fand ich gar nicht so wichtig. Ob da jetzt noch drei oder fünf, ist ja egal, irgendeine fährt da hoch, hat eine Mindestanzahl, hat sich aber da rausgestellt, das war Fehlkonfiguration, weil wenn jetzt alle 50 App-Server drei haben, drei Mal fünf sind 150 und jetzt kommt auf einmal Requests rein. Das ist so, der Taglast geht los oder ein Flashsale, die sagen jetzt, okay jetzt verkaufen wir mal hier Fernsehfreischaltung, irgendwelche (?1:17:52). Dann kommen auf einmal ganz viele Leute zu selben Zeit. Das kann man im Fernsehen messen übrigens. Deswegen sollten eigentlich, jetzt beim Kunden zum Beispiel, dass die Leute, die so eine Werbung freischalten, sollten die auch sagen „Passt mal auf hier, Ops-Leute, zu der und der Zeit läuft diese Werbung. Wundert euch nicht. Das ist keine Attacke. Das ist keine DoS-Attacke". Nicht, dass die denken oh, ist eine DoS-Attacke, wir cutten mal den Traffic. Das ist auch passiert beim Kunden zum Beispiel. Also Missverständis über ­— weil die dachten wir werden attackiert, oh mein Gott, keiner was Bescheid gesagt, machen sie dicht und dann ist der ganze Umsatz flöten gegangen, naja. Und da war es so gewesen, dass die drei eingestellt waren und dann kamen die alle rein und dann kam die Datenbank nicht hinterher so schnell wie möglich die Connections anzulegen. Das kostet auch Zeit. Und dann sind ein Haufen Fehler passiert. Das passiert aber nur einmal bei einem Kunden, nur sonnabend früh. Und damit habe ich festgestellt, weil es bei ihm fehlgeschlagen ist, dass — das war durch einen neuen Code, den wir eingeführt haben. Der ist dann fehlgeschlagen. Dann haben wir den analysiert und dann war es der Hintergrund, was ich raugekriegt habe, dadurch haben wir rausgekriegt, dass wir eigentlich ein Performance-Problem haben. Bei allen Kunden. Wir konnten es bloß nie messen. Wir haben hier nicht die Visibility gehabt. Zum Beispiel, wir haben da eine Konfiguration, aber keine dazugehörigen Metriken. Also das ist—

R1: Ja klar, was man nicht messen kann, kann man auch nicht—

I8: Das sieht man nicht. Dann hofft man, dass das geht. Dann glaubt — das ist so wie eine Religion halt.

R1: Gibt es denn einen Unterschied zwischen falscher und schlechter Konfiguration?

I8: Ja. Falsche Konfiguration ist für mich das geht gar nicht, das funktional überhaupt nicht und schlecht heißt naja, verbraucht mehr Ressourcen und ist ein bisschen langsamer. Sowas zum Beispiel. Das ist der Klassiker. Cache zu klein konfiguriert. Kann man besser machen. Höher schrauben. Also funktioniert, ist alles da. Der Kunde wartet ein My länger, aber, und bei uns rödeln die Leute rum, aber—

R1: Und das ist dann da mit dem Beispiel mit dem (?1:19:47) denn eine schlechte oder eine falsche Konfiguration?

I8: Das ist eine schlechte Konfiguration aus meiner Sicht. Also keine falsche, aber eine schlechte, weil meistens geht es ja. Und das hat sich auch wieder eingefangen, also das ist ja, war bloß dann Error-Rate hoch und das System hat darauf reagiert und das kann damit umgehen danach.

R1: Wie häufig treten denn bei euch Konfigurationsfehler denn auf bei der Arbeit?

I8: Also ich wette, also das kann man nicht messen, weil dazu zählt ja auch ich ändere meine lokale Entwicklungsumgebung und da zählt ja auch zum Beispiel Git-Repositorys oder irgendwas, das ist ja jedes Mal ein anderes Fehlerbild, was man da kriegt. Ich wette das passiert jedem Entwickler zehn Mal am Tag irgendwie, wenn er irgendwas — kommt darauf an, was man als Konfiguration sieht wieder, wahrscheinlich. Aber sehr, sehr häufig. Bin ich mir ziemlich sicher. Das ist, was ich meine mit wenn ich dann mal was anfassen will, dass ich schnellstmöglich Feedback kriege und weil Entwickler meistens mit Properties-Files, reinen Text und keine Validatoren, arbeitet, hat er täglich damit zu kämpfen denke ich.

R1: Wann kriegt ihr denn so typischerweise Konfigurationsfehler? Am Anfang, wenn ihr euch mit etwas beschäftigt oder erst wenn es deployt ist oder?

I8: In allen Inkarnationen wieder. Also von lokal auf der Entwicklungskiste, dann kompiliert er vielleicht nicht, weil falsches Repository, bis hin zu wir hoffen, dass wir alle möglichen Konfigurationsfehler in der Buildchain erwischen und dann gibt es aber welche in dem Environment, wo man mit Metriken nachvollziehen, ob das so eingehalten wird oder nicht.

R1: Gibt es Unterschiede bei Konfiguratiosnfehlern zwischen fachlicher und technischer Konfiguration?

I8: Ja, weil die fachliche Konfiguration — das sind andere Stakeholder, die dahinter sind. Die fachliche, die haben einen ganz anderen, andere Ziele um das zu konfigurieren, lass es mich mal so ausdrücken. Wenn es nach der fachlichen Konfiguration gehe, gäbe es keine Caches. Die würden sagen Caches sind alles blöde, wir wollen immer die aktuellsten Daten, wenn ich irgendwas ändere, ist es sofort sichtbar für alle auf der Welt. Und dann kommen die Techniker und sagen „Ne, machen wir nicht". Und das ist ein riesen Unterschied. Und dann ist wieder die Diskussion, wie lange kann der Cache leben, wie aktuell muss das sein, was ist noch verkraftbar und so weiter. Und deswegen ist es ein riesen Unterschied, weil die, die haben konträre Ziele. Also das ist auch der Gedanke von Ops und Entwicklern. Der Entwickler will Feature raus, raus, raus, raus, Op sagt, ey rührt das System nicht an, ich bin froh, dass ich jetzt Wochenende habe. Das ist ja das Ziel, was man damit machen kann, ist da ja das Problem.

R1: Wie gehst du denn typischerweise vor um Konfigurationsfehler zu finden und zu beheben?

I8: Meistens, Reihenfolge ist — also eigentlich weiß man ja nicht, dass es ein Konfigurationsfehler ist. Also es gibt, oder sagen wir mal es gibt zwei Sachen, die man machen kann. Wenn man Feedback hat und der sagt das ist falsch konfiguriert, rot, dann suche ich den Code dazu, der das ausliest und dann versuche, gucken welche validen Values und so weiter. Also meistens immer erstmal Konfiguration mit dem Code zu mappen mehr oder weniger. Oder umgedreht, ich habe einen Fehler, gucke in den Code rein, „Ah, das kann man konfigurieren.", dann gehe ich zu der Konfiguration und ändere das. Da gibt es aber kein die Konfiguration ist rot, die ist da, wo du sie konfigurierst vielleicht miskonfiguriert, ist ein Fehler in der Konfiguration, aber dann über den Codepfad und den Error—

R1: Das ist jetzt aber alles bei Optionen, die ihr selber eingebaut habt im Code. Was ist denn, wenn es jetzt eine Spring-Boot-Konfiguration ist oder so. Oder eine Oracle-Konfiguration.

I8: Na Oracle ist, das haben wir ja auch gehabt, wenn jetzt hier die DBAs zum Beispiel. Die kennen ja nicht unsere Applikation, was wir damit machen und die stellen irgendwas ein. Dann kriegen wir meistens irgendwelche Fehler, dass irgendwas nicht funktioniert und dann fangen wir an, analysieren und überlegen. Dann reden wir über die über die technische Dokumentation mehr, dass es diese Konfigurationsmöglichkeiten gibt. Wenn wir Glück haben, kommen wir selber drauf und können das selber validieren. Also wir haben so bestimmte Rechte können wir jetzt schon gucken, mit dem Leuten reden, dann kriegen wir schon viele Informationen raus.

R1: Und StackOverflow oder sowas bei andersartigen?

I8: Ja, das ist ja der Klassiker. Also die—

R1: Wird schon immer nicht genannt, bei unseren Interviews.

I8: Ne, also StackOverflow ist wahrscheinlich — ist nicht nur StackOverflow. Meistens macht man Google und Google ist auf StackOverflow. So ist die Reihenfolge. Man sagt oh, es gibt eine Konfiguration — das machen wir mit Tomcat-Konfigurationen, das ist sehr, also mögliche Konfigurationen zu finden um Performance-Probleme zu beheben geht ausschließlich darüber. Das ist immer, irgendeiner hat das Problem schon gehabt und dann löst man das. So als Inputquelle für gültige Values, ja. Sehr, sehr, also ist die Regel.

R2: Oder vielleicht mit Kollegen sprechen?

I8: Das auch. Ja also es gibt die erfahrenen Entwickler, die kommen dann meistens „Was sind denn die Werte?" oder mit Performance-Engineering, die schon mal irgendwas custom ange— aber der erste ist immer wahrscheinlich „Was kann man konfigurieren?" und dann ist der zweite Schritt wahrscheinlich „Ah, es gibt das Property. Was ist denn eingestellt bei den Kunden, bei anderen?". Dann vergleicht man das oder probiert es selber aus.

R2: Also erst Dokumentation, dann googeln?

I8: Erst Google. Google ist immer offen, wirklich bei jedem. Dokumentation — also jetzt zu sagen, dass — diese Diskussion hatte ich auch schon mit vielen Leuten gehabt. „Das kann man mit Dokumentation erschlagen." Äh, ne. Kann man nicht. Also es sollte intuitiv sein, man muss in dem Moment, wo man es appliet, sollte man — also jetzt bei, für einen Businessentwickler — sollte sehen, dass es rot, gelb oder irgendwas, Nachrichten, vielleicht die Dokumentation gleich daneben haben, dass er nicht erstmal eine ganz andere Webseite, die UI kennen muss und so weiter und dadrinnen suchen noch und zufällig das — deswegen haben wir bei uns in der UI ist das gängige Pattern, dass man da so ein Fragezeichen hat, wo man draufklicken kann und dann sich das anschauen, was da valide ist. Das hilft dann. Wenn das nicht da ist, ist schlecht. Haben wir aber auch. Historisch gesehen, war schon früher immer so gewesen.

R1: Welche Strategien habt ihr denn um Konfigurationsfehlern vorzubeugen?

I8: Das ist wie gesagt die Validierung davor. Also es kommt wieder von je nachdem was man konfiguriert. Bei den Businessentwicklern sind es wirklich die Validierungen im UI. Das ist das wichtigste. Und die Dokumentation, die dann dran ist, dass der das versteht. Bei den Entwicklern ist es eher die Buildchain, wo der Unittests drauf schreibt, und derjenige, der die Komponente gebaut hat und die Konfiguration eingeführt hat, dass der sagt, das sind meine validen und dann knallt ein Unittest. Sowas machen wir meistens.

R1: Wie habt denn ihr bei der — die Validierung, habt da ihr selber das per Hand geschrieben oder ist da so ein SAT-Solver dahinter?

I8: Das ist, bis jetzt kenne ich noch kein gutes Framework, was das kann. Also ich kenne einige, viele haben es mit XML probiert, aber das ist irgendwie komischerweise nicht so gerne gesehen im Sinne von, weil da hat man ja zumindest kann man Datentypen angeben, man kann sagen welche Reihenfolge und so weiter. Aber das reicht nicht für Konfiguration aus meiner Sicht. Weil man hat ja Abhängigkeiten zwischen den Konfigurationen und wenn der Wert so ist und der andere so, dann geht das nicht, aber wenn der ein bisschen höher — das ist immer nur auf das eine Konfigurationsvalue, aber das ist ja, die hängen ja alle miteinander zusammen. Da bräuchte man so eine andere Komponente, die das da durchcheckt.

R2: Also ihr habt da auch kein eigenes Tool, sondern ihr schreibt das so wie es gerade für die Konfiguration gerade passt?

I8: Nur für die Businessentwickler, aber nicht für die Entwickler. Die Entwickler machen meistens das über JUnit-Tests. Würde ich denken jetzt. Oder ich irre mich und ich habe was vergessen, aber —

R1: Testcontainer oder so. Für das Framework.

I8: Ne. Also wenn Unittest. Also wir, es gibt doch die Annahme mit SonarQube, dass man da auch bestimmte Regeln da kontrollieren kann, aber SonarQube — der Ruf ist besser als es ist aus meiner Sicht. Weil man muss ja diese Regeln pflegen, man könnte den Build jetzt fehlschlagen, wenn man einen alten Monolithen, alten Code hat, dann muss man den erstmal umbauen, damit man diese Regeln applien kann. Dann kann man das für neuen Code machen, dann hat aber einer nur schnell mal Code formatiert, dann knallt der wegen formatierter Code da, obwohl er hat da gar nichts geändert und — also SonarQube kann man so als zusätzliche Inputquelle sich zum inspirieren lassen für QA, aber im Buildprozess würde ich das niemandem empfehlen, weil das wirklich bremst auch. Wenn man neue Projekte anfängt und gleich von vorneherein SonarQube macht, dann ist das eine andere Option sowas zu validieren und neue Regeln zu applien. Aber für Monolithen ist das Quark.

R1: Ja, dann sind wir jetzt schon beim Verbesserungsbedarf. Also viele hatten halt vorher — also bei anderen Interviews — gesagt, Dokumentation muss irgendwie verbessert werden.

I8: Ach, ja.

R1: Was erwartest du denn von einer guten Dokumentation, dass es vielleicht benutzbar ist oder so? Oder ist das gar nicht wirklich —

I8: Also das gilt für alle eigentlich: Also wenn ich irgendwas dokumentiere, sollte die Dokumentation immer aktuell sein. Das ist so das größte, erste Problem. Wie halte ich die aktuell? Und der einzige Grund die richtig aktuell zu halten ist, dass die mit dem Code eingecheckt in dem Moment wo die Änderung da ist. Wenn die in verschiedene Repositorys ist das schon veraltet, die Dokumentation. Definitiv. So, jetzt man dann die Dokumentation geändert und dann muss die Dokumentation so sein, dass da wo ich das konfiguriere (?1:29:04) gelinkt, dass man da gleich draufkommt. Wenn die auf einem anderen Server, in irgendeinem Dokument ist, benutzt die keiner. Definitiv. Und die Dokumentation, wenn die sagen das muss mehr dokumentiert werden, also mehr im Sinne von, dass alles dokumentiert, vollständig im Sinne die Properties, ja. Die muss aber so einfach geschrieben werden, nicht, dass da ein riesen Text steht. Und da kommt aber auch die Grenze gleich dazu. Wenn man komplexe Sachen einstellt, die kann man manchmal nicht da so beschreiben. Da gehört einfach mal ein bisschen dazu. Also jetzt eine Garbagecollector-Konfiguration, da kann man auch nichts dokumentieren. Man kann eine Garbagecollector-Dokumentation, wie der funktioniert um mögliche Values, Bereiche machen, aber was man dann messen und Metriken und zu beschreiben, wenn du das und das einstellst, musst du davon die Metriken um zu gucken um irgendwas. Da gibt es ganz teure Tools für, die kosten 8000 Euro, die das nur anzeigen die Metriken. Geschweige denn Empfehlungen darauf geben. Das ist — das hängt davon ab. Einfache Sachen möglichst einfach validieren vorher, Dokumentation wenn es nicht (?1:30:13), aber ein Validierer würde schon viel helfen. So bei Properties, wo du sagst das ist ein Int oder ein Boolean. Ich kann auch Spaces.

R1: Welche Verbesserungen würdest du dir denn wünschen von, Hinsicht der Konfiguration von Softwaresystemen? Also generell erstmal so.

I8: Meistens ist ja die Konfiguration ist ja sehr, sehr customisiert. Es gibt da beim Docker zum Beispiel da — was ist denn da die Konfiguration beim Docker? Das macht jeder anders. Da gibt es so best Practices, aber was wie wann konkret konfiguriert wird? Ich sage jetzt mal, ein Dockercontainer mit CentOS, Maven, Java drinnen würde man annehmen, dass es den als Standard gibt, aber wie viele gibt es denn da draußen? Wir haben alleine schon drei in der Firma, wo ich mich frage warum. Mal willst du Ressourcen sparen, mal brauchst du aber noch was anderes, weil es als Basis für die nächste Generation von Software ist, also es ist, ich glaube nicht, dass es da eine allgemeingültige Lösung gibt, aber es gibt für bestimmte Use Cases, wie jetzt zum Beispiel wie gesagt jetzt die Buildumgebung. Wo ich sage ich habe eine Git, also drei Tools — Git, Jenkins, Quayund Nexus, oder vier Tools, die alle miteinander zu tun haben, unterschiedliche Systeme, aber ein Tool, das sicherstellt, dass die alle, die der Zusammenhang harmoniert, zum Beispiel. Sowas, so eine globalen, die gibt es wahrscheinlich bei Tivoli, aber das muss man auch wieder alles manuell konfigurieren. Weil diese — der eine nimmt Nexus, der andere nimmt Artifactory, dann Git und Subversion. Weil jede dieser Komponenten kann dann ausgetauscht werden. Jenkins, Bamboo.

R1: Wäre es da vielleicht sinnvoll, dass man ein bisschen das vorgibt, dass alle nur Git und alle kriegen eine vorkonfigurierte Jenkinsinstanz und —

I8: Na bei uns ist das so. Wir haben Git, Jenkins und Nexus und Quay, weil Quay ist nun bei Docker und Jenkins ist für die Jar-Files und vielleicht irgendwelche anderen Artefakte. Aber dann, es gibt kein Tool draußen, was genau diese Chain kann. Obwohl die jetzt nicht so weit hergeholt ist. Also wahrscheinlich gibt es eins und aber ich kenne das vielleicht nicht, aber habe mich jetzt auch noch nicht damit beschäftigt groß. Aber das ist zum Beispiel für mich, jetzt wenn ich das, meine jetzige Arbeit, wir haben es gerade nicht. Kann sein, dass es was draußen gibt. Schön wäre es. Oder genauso beim Garbagecollector. Gut, da gibt es das Tool, Garbagecollector-Konfiguration, kann man kaufen, muss man wieder connecten, viel Geld ausgeben, dann hat man Grafiken. Dann braucht man das Lastverhalten, da muss man viel Wissen, welche Last man wie was konfigurieren um sagen kann, dass diese Kurve besser als diese Kurve ist.

R1: Und was würde dir helfen schneller Konfigurationsfehler zu finden? Oder zu beheben?

I8: Also Validatoren ist das einfache, das hatten wir ja schon mehrfach jetzt. Das wäre, hier falsches eingetragen. Da man jetzt diese Möglichkeit nicht hat vorher, also weil ja ich nicht dieses Value angebe, sondern irgendeiner draußen und der das gar nicht weiß und die Möglichkeit und der dachte sich da was dabei. Ich sage mal, um das rauszukriegen, welche Informationen sind denn wichtig? Es gibt da meistens einen Grund warum die das tun. Da sind ja meistens auch Ticketsysteme dran, wo man sagt warum wurde diese Konfiguration gemacht? Wir haben zum Beispiel historische Konfigurationen, die irgendwann mal vor drei oder vier Monaten mal gemacht wurde, irgendwelche Feature-Toggles, die irgendwelche Emergency-Switches sind und alten Code ausschalten. Und jetzt wollen wir diesen Feature-Toggle ausbauen, wir wissen aber nicht warum der noch an ist. Meistens vergessen. Weil der Lifecycle nicht richtig definiert wurde oder nicht rangeschrieben warum oder da hat er mal schnell was ausprobiert oder — also der Grund ist zum Beispiel eine wichtige Sache. Der Grund wer hat was warum geändert. Das sind für komplexe Systeme, also wenn der Entwickler das nicht macht, das ist sehr wichtig. Dafür gibt es Configuration as Code. Wer hat das eingecheckt? Was, welches Konfigurationsproperty? Und wann ist es appliet worden? Kriegt man auch noch raus, wenn die Deploymentcircle(?), wann das appliet wurde. Dann hat kriegt man — deswegen ist Configuration as Code mit Git nicht schlecht.

R1: Aber ihr habt dann bei dem Lifecycle, habt ihr jetzt nicht irgendwie eine Möglichkeit zu sagen nur bitte bis dann und dann oder? Das ist kein Automatismus, oder?

I8: Deswegen führen wir ja jetzt — Split.io ist so ein Tool, was wir versuchen zu integrieren gerade. Also früher war das ja alles nur, alles über Properties und dann hat man gemerkt, naja das eine Property ist eine Performance-Optimierung und das andere ist ein Feature-Toggle, was einen bestimmten Lifecycle hat. Beim Performance, das bleibt für immer, das soll auch so bleiben. Und beim Feature-Toggle ist eine Seite, wo du dynamisch mal systematisch aufräumen willst. Wo du noch eine Probe-Workflow hast und mit Kunden sprichst. Möglichst jetzt nicht ein Deployment drin hast und so weiter. Maintenance wenn du einen Zeitpunkt mit dabei und so weiter. Oder mal eine Stunde freischalten, wieder wegschalten. Das sind ganz andere Anforderungen.