Sieben Deployment Sünden
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 95 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32299 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FrOSCon 201748 / 95
4
8
9
15
20
22
23
24
25
27
29
32
36
37
38
39
40
45
46
47
48
49
50
51
53
54
59
63
64
65
74
75
76
79
83
84
86
87
88
89
91
92
93
94
95
00:00
FreewareOpen sourceEvent horizonSoftware developerPermianMiniDiscComputer networkJava appletLogicSet (mathematics)Plateau's problemScalabilityDistribution (mathematics)System programmingSet (mathematics)Noten <Programm>TypForm (programming)Operating systemService (economics)ArmSystems <München>Plane (geometry)CodeTOUR <Programm>Finite setBoom (sailing)WordVersion <Informatik>Execution unitTwitterXMLComputer animation
09:09
Service (economics)DiagramDatabaseTwitterComplex (psychology)Physical systemSystem programmingSoftwareModularityComputing platformEnterprise architectureLoginCorrelation and dependenceCross-correlationGoogolFacebookBuildingDisintegrationContinuous integrationAutomatonModularityCalculationSoftwareMUDVerteiltes SystemKleines SystemGoogleRoute of administrationService (economics)DatabaseCarriagewayContinuous integrationSystems <München>Software bugSlide rulePoint (geometry)Product (category theory)Computer data loggingPositionPasswordPlane (geometry)EstimatorDemosceneDesigner <Programm>ArmDemonCoalitionBoom (sailing)Outline of industrial organizationState of matterMicrosoftLoginFacebookLecture/Conference
18:12
TwitterDemonRobotMiniDiscCodeProcess (computing)Virtual machinePhysical systemArchitectureMedical imagingComputer-generated imageryNumberTournament (medieval)Lattice (order)CAN busStrategy gameSystem callGoogolSystem programmingFocus (optics)Elasticity (physics)UnicastingverfahrenVelocityPhysical lawJenkins CISystems <München>BackupService (economics)Copula (linguistics)Product (category theory)TOUR <Programm>Active DirectoryInstanz <Informatik>Process (computing)State of matterConfiguration spaceDatabaseMobile appMicrosoftClefRoute of administrationSoftware bugLaptopGoogleStructural loadInstallable File SystemFacebookWORKS SuiteLecture/Conference
27:14
Elasticity (physics)UnicastingverfahrenServer (computing)Point cloudArchitectureCodeSoftwareSpring (hydrology)BootingGame theoryInstance (computer science)DatabaseSpeciesSystems <München>AutomationProduct (category theory)Similarity (geometry)ForceServer (computing)WordEigenvalues and eigenvectorsVirtueller ServerArmService (economics)Computing platformLoginPoint cloudSound <Multimedia>LaufzeitMilitary rankCarriagewayComputer data loggingUniformer RaumMicrosoftVersion <Informatik>ZugriffWikiProviderEnterprise architectureLecture/Conference
36:16
Software developerCloud computingOscillationSoftwarePoint cloudService (economics)Server (computing)Jenkins CIJBossContinuous integrationLaptopDesktopCalculationClient (computing)Terminal equipmentString (computer science)ComputerDebuggerProgramming languageScrum (software development)Video gameMetric systemSound effectSeries (mathematics)Moment (mathematics)Plane (geometry)Lecture/Conference
45:18
FreewareOpen sourceEvent horizonComputer animation
Transcript: German(auto-generated)
00:07
Dann kommen wir auch zum letzten Talk in diesem Hörsaal an diesem Tag. Und Philipp wird uns die sieben Deployment-Sünden vortragen. Viel Spaß dabei. Danke. Keine Sorge, es wird eher leichtgewichtig sein.
00:25
Also ich mache mich eigentlich primär über verschiedene Technologien lustig. Also es ist für den Ausgang des Abends hoffentlich genau das Richtige. Philipp, wie man schon hört, aus Österreich. Also ich bin aus Wien. Ich werde versuchen keine komischen Worte zu verwenden, die man hier nicht versteht. Ansonsten schreit bitte.
00:42
Ja, und dann schauen wir uns an, was es so beim Deployment für Probleme geben kann oder könnte. Ich arbeite für die Firma Elastic, Elasticsearch, Elasticstack etc. Wobei darum geht es heute eigentlich gar nicht so wirklich. Das sind wirklich mehr so Deployment-Dinge, die man tun kann oder nicht tun kann. Und mal schauen, ob ihr euch irgendwo wiederfindet bei gewissen Sünden oder auch nicht.
01:04
Und das Ganze wird natürlich auf den besten Film dafür aufbauen, also Seven. Und ihr könnt dann auch immer gleich raten, welches welche Sünde ist. Also gibt es irgendwelche Geständnisse, bevor wir beginnen? Oder wollen mal alle zuhören? Ja, gut. Wir reden dann über die Geständnisse am Schluss nochmal.
01:23
Welche Sünde ist das? Völlerei, genau. Glattoni. Overindulgence is overconsumption of anything. Also zu viel von allem. Zum Beispiel alle Dependencies.
01:40
Wer verwendet Java? Irgendwer? Java, Java, Java. Traut sich irgendwer? Okay. Das ist so meine erste Assoziation, was dann möglicherweise kommen könnte. Dann hat man irgendwann so ein Java-File, das 200 Megabyte groß ist. Oder das hatte ich zumindest bei meiner vorigen Firma. Dass dann jedes Deployment immer ein großes Spaß war, weil jedes Ding so groß war. Einerseits braucht das viel Disk und Netzwerk.
02:01
Andererseits braucht es dann auch recht viel Memory. Und das lag dann aber teilweise nicht nur an uns, sondern auch an unseren Dependencies. Also das, was wir zum Beispiel hatten, wir haben glaube ich von AWS nur S3 oder so verwendet. Und sobald man dann ein einziges S3-Service verwenden wollte, musste man immer diese ganze Java-Dependency da mitnehmen.
02:21
Und die hatte dann irgendwann 13 Megabyte nur für ein einzelnes Service. Und dann sind sie irgendwann draufgekommen, das funktioniert so nicht. Und dann haben wir das Ganze begonnen, in kleinere Einheiten aufzuspitten. Mittlerweile hat man nur noch so ein schlankes Base-Jar. Und kann sich dann wirklich hin dazu laden, das was man haben möchte. Aber das ist so der typische Fall von der Clarity, wo man mehr und mehr Services baut. Wo das Ganze dann immer größer und größer wird.
02:41
Und man dann irgendwann nicht mehr damit arbeiten möchte. Und der nächste Schritt ist dann mehr oder weniger, dass man alles in einen Docker-Container packt. Und dann hat man nicht nur das Jar, sondern auch noch die JWM auch noch dazu gepackt. Und ein halbes Betriebssystem. Es gibt dann allerdings auch ein bisschen so den gegenteiligen Trend. Es gibt dieses Zitat, vielleicht oder auch nicht Zitat, wie auch immer von Bill Gates,
03:03
mit den 640.000, was auch immer. Und zum Beispiel im Node-Ökosystem ist dann die Challenge, dass man ein Projekt mit weniger als 640.000 Dependencies baut. Was jetzt zuerst völlig übertrieben klingt, bis man sich dann mal anschaut,
03:20
welche Dependencies es denn so im Node-Ökosystem gibt. Ich meine nicht, ob das schon mal wer gesehen hat. Es hat jemand für Emojis ein Package pro Emoji gebaut. Und was ich da auch faszinierend finde, ist, dass A ist jedes von diesen Dingen unit getestet. Und B braucht man drei Stellen bei der Versionsnummer für Emojis. Ansonsten dürfte es offensichtlich da nicht mehr gehen.
03:41
Und es gibt wirklich für jedes einzelne Emoji, das es so gibt, gibt es dann ein NPM-Package. Ich meine nicht, ob man da irgendwo Geld dafür bekommt, um NPM-Packages hochzuladen, aber es dürfte irgendwie so ausschauen. Also das ist aktuell so ein bisschen der gegenteilige Trend, dass es möglicherweise nicht nur zu groß wird, sondern im Node-Ökosystem wird es möglicherweise ein bisschen zu klein, wo dann drei Zeilen Code sind bereits eine eigene Dependency.
04:03
Da war das Left-Pad, gab es noch mal, wo jemand, um Links mit Leerzeichen aufzufüllen, eine Library hatte, die dann von vielen verwendet wurde. Der hatte dann irgendwelche Streitereien um Urheberrechte oder so und hat dann alles seine Dependencies zurückgezogen. Und darauf waren dann das halbe Node-Ökosystem kaputt,
04:21
auch weil so viele diese Dependency irgendwo drinnen hatten, transitiv. Das Alternativprojekt ist dann, oder was man alternativ machen kann, ist, dass man alle Projekte zusammen fasst. Wobei momentan haben wir eher den gegenteiligen Trend, dass man überhaupt nichts mehr zusammen fasst und alles als Microservice macht. Und dass dann alles mehr oder weniger nur ein paar Zeilen Code hat.
04:43
Und das ist dann die typische Idee, glaube ich, wenn irgendwer sagt, man möchte Microservices verwenden. So schaut dann die Architektur nachher ungefähr aus. Da hat man dann schön paketiert, alles so in einem Boot. Und das ist dann die Gesamtarchitektur, die man so in seinem System hat. Das verwende ich auch ganz gerne. Die, die da sozusagen den einfachen Weg heraus haben wollen,
05:02
die sagen dann einfach unsere Microservices haben einfach kurze Namen. Und damit sind sie dann auch sehr micro. Wobei, warum sollte man beim Micro überhaupt aufhören? Man kann ja einfach noch weiter machen. Der nächste Schritt sind dann die Nanoservices, Pico, Femto, Otto und Jokto. Jokto war das kleinste, was ich finden konnte, wenn man dann irgendwann die Jokto-Services erreicht hat,
05:22
dann hat man sozusagen, glaube ich, die beste Architektur, die man sich vorstellen kann. Das sind dann nur noch drei Zeilen Code pro Projekt, die überbleiben, glaube ich. Aber das sind dann die Jokto-Services. Hartner, Gardner, Halbcycle. Ich glaube, das ist das Einzige Gute, was Gardner je herausgebracht hat. Oder das Einzige, was je dann zugetroffen hat in der Zukunft.
05:44
Am Anfang hat man immer dieses, die großen Hoffnungen. Dann fällt man irgendwann in dieses Tal der Illusion hinunter und irgendwann erreicht man dann das Plateau der Produktivität. Und bei Microservices bin ich mir noch nicht ganz sicher, wo die meisten sind. Ich glaube, da stehen sehr viele kurz vor diesem Abhang. Das wird sich dann in den nächsten ein, zwei Jahren sehen.
06:02
Ich warte schon darauf, wo dann all diese Talks kommen, von wegen, nein, nimm wieder Microservices. Der Monolith war so großartig. Klar, Microservices helfen, wenn man viele Leute hat, viele Dependencies, das Ganze irgendwie individuell skalieren muss. Das ist klar, aber das Problem hat auch nicht unbedingt jeder.
06:20
Werden die Microservices all meine Probleme lösen? Tenmiancell eher nicht. Denn, dass man sich da wieder mal in Erinnerung rufen kann, irgendwann vor Jahrzehnten haben die Leute auch schon recht viel über IT-Systeme gewusst. Man hat es nur mittlerweile vergessen. Auch weil die meisten einfach irgendwie in der IT sehr jung sind oder der Generationswechsel sehr schnell.
06:41
Und da geht dann immer dieses gesamte Wissen verloren. Und das wird dann sehr schmerzhaft. Irgendwann erwirbt man dieses Wissen dann wiederum aufs Neue. Deshalb hier dieser Hinweis. Es gibt diese acht Probleme von verteilten Systemen. Wer dann die neuere Version haben möchte, war Notes und Discipline Systems for Young Bloods von Jeff Hodges.
07:01
Der hat lange Zeit bei Twitter gearbeitet. Wer kann sich noch an den Twitter Failwale erinnern? Ja, ist aber auch schon recht lange her. Also die haben recht schmerzhaft gelernt, wie denn ihre anfangs monolithische Rails-Applikation erst umgefallen ist. Dann haben sie die monolithische Rails-Applikation auf verteilte Skala umgestellt. Dann ist es noch immer dauernd umgefallen.
07:21
Und dann haben sie durch einen längeren schmerzhaften Prozess gelernt, wie sie es denn richtig machen können. Hauptfazit von Jeff Hodges, dann ist mehr oder weniger das Hauptproblem an verteilten Systemen ist nicht, dass irgendwie zusätzliche Latenz oder so dazukommt. Sondern, dass einfach viele Teile individuell sehr leicht kaputt gehen können und dass eigentlich dauernd irgendwas kaputt ist in so einem großen verteilten System.
07:43
Und damit muss man einfach leben können. Und am Anfang konnten sie das nicht. Also da haben sie dann so Beispiele gebracht, z.B. einen Translation Service. Und weil irgendein Bug im Translation Service für japanisch war, hat dann einfach gar nichts mehr funktioniert. Und dann haben sie dann mit der Zeit gelernt, man muss einfach mit diesen Fehlern umgehen lernen. Das habe ich letztens gesehen, das finde ich super.
08:02
Das ist die deutsche Variante von The Five Nines, von verteilten Systemen, die man so haben könnte. Nein, nein, nein, nein, nein. Das ist dann genau der Zustand, den man hat, wenn man irgendeinen hochgradig verteilten System hat. Dann der nächste Punkt, den viele aufbringen, ist, das hatten ja doch alles schon mal SOA. Wer erinnert sich noch an SOA?
08:21
Wer hat SOAP gemacht? Ja, da sieht man das Alter. Damals gab es den SOA-Hype, der ist mittlerweile ein bisschen abgeklungen. Heute könnte man das Ganze wieder mit Microservice machen. Aber wenn man nicht ein SOA gemacht hat, dann war es nicht richtig. Dann hat man gesagt, wir nennen es halt SOA.
08:43
Was auch immer das heißt. Heute nennt man es einfach Microservice und danach ist dann alles gut. Das muss mittlerweile auch jeder haben. Das Ende von SOA oder von SOAP war dann mehr oder weniger dieses WS-Totes-Stern. Da gab es dann, ich weiß nicht, wie viele Dutzend WS-Security-Transaction-Schieß-Micht-Tot.
09:00
Für alles gab es ein WS-Standard, den dann keiner so richtig implementiert hat. Das war dann mehr oder weniger das großartige Ende von dem ganzen SOAP-Ökosystem. Wobei man mittlerweile irgendwann draufkommt, dieses ganze Restzeug und so. Manchmal wäre es irgendwie ganz cool, doch wieder ein Schema zu haben und es gibt dieses JSON-Schema und so. Es braucht alles auch noch ein bisschen.
09:21
Ja, Wireshark. Wir haben ja nicht den Wireshark. Ist super cool, wenn man irgendwas Monolithisches hat, oder? Sobald es dann verteilt wird, ist Wireshark wiederum wesentlich weniger cool. Weil da muss man eigentlich an den verschiedensten Punkten beginnen, zusammen, oder mal die Netzwerkpakete zusammen, dann kann man sie zusammen aggregieren und dann kann man seinen Wireshark drauf loslassen und dann kann man wie in einem Krimi
09:41
mehr oder weniger versuchen, alles zusammenzusammeln. Da gibt es auch dieses schöne Zitat über verteilte Systeme sind so wie ein Krimi. Da kann man sich einfach alles dann suchen. Da kann man da ein paar Spuren, dort ein paar Spuren und im Endeffekt kann man dann sehen, warum ist denn mein System tot? Und wenn man dann lange genug gesucht hat, dann findet man heraus, warum das System entsteht.
10:01
Wer hat denn die Idee, was das ist? Das ist halt blöd. Die Zweiter sind zwar super alleine, aber wenn man dann das große verteilte System hat und das große, oder in unserem Fall
10:20
die Datenbank, wenn dann die Datenbank down ist und alle kleinen Microservices da dranhängen, dann haben wir die Microservices doch wieder nicht zu viel gebracht. Also wenn ich irgendwie so diese große Datenbank habe, die noch hinter allem andern steht, dann kann ich vorne verteilen und aufsplitten, was ich möchte. Die kleinen Dinge vorne werden auch nicht lange überleben. Ja, und dann gibt es dieses schöne Zitat,
10:42
man sollte sich da nicht mal überlegen, das Ganze aufzusplitten. Man sollte mal beginnen, eine schön modulare, monolithische Applikation zu bauen. Und nachher kann man sie dann aufsplitten. Finde ich ein recht schönes Zitat von Martin Fowler, der auch sehr stark in diesem Microservice Umfeld drinnen ist, aber der dann trotzdem, wie gesagt, es macht trotzdem nicht
11:01
Sinn, bei jedem Projekt mit Microservices zu beginnen. So viel zum Grillen. Und das nächste, was man sich dann auch bei Microservices immer in Erinnerung rufen muss, ist, das war die Architektur etwa 2005, auch wenn ihr die Details nicht lesen könnt. Das überblickt man noch recht gut. Und das ist dann die
11:22
Architektur 2016, 2017, was auch immer. Das überblickt man dann wesentlich weniger schlecht. Also es ist schon ein gewisser Trade-off, was denn diese hochgradig verteilte Applikation an Komplexität mitbringt. Und ob ich das wirklich haben möchte, speziell bei kleinen Applikationen.
11:40
Eine andere Dimension mehr oder weniger, die man haben kann, ist einerseits hat man diese Deployment-Units, das ist dann das große Monolith oder die kleinen Microservices. Aber das ist möglicherweise nicht die ganze Wahrheit. Man kann sich das alternativ dann noch auf die Modularität hin anschauen, dass man hat entweder der monolithische Big Ball of Mud oder der verteilte Big Ball of Mud. Sind aber beide
12:01
scheiße. Das heißt, man kann dann möglicherweise ein monolithisches kleines System haben, oder monolithisches System oder dieses verteiltes System. Aber dass man gute Modularität sozusagen als Grundbasis hat, liegt nicht nur in wie klein man die Scheibchen schneidet. Die Modularität
12:20
steht und fällt nicht mit den Scheibchen. Und das andere ist, dass der Monolith einfach momentan ein Imageproblem hat. Das heißt, wenn man das Ganze wieder schöner benennen würde, so wie Mega-Plattform, Uwe-Container oder Stereolith, das wird sich in ein paar Jahren wiederkommen. Dann werden die Leute sagen, dass mit diesem Microservices zwar alles ein Blödsinn,
12:42
aber wir machen das Ganze jetzt mit, keine Ahnung, wie auch immer, man es nennt neu. Ich wäre ja für Server-Full. Aber dazu kommen wir dann später auch nochmal kurz im Serverless. Und der Enterprise-Ansatz, die müssen nämlich auch alles ganz cool machen wie immer.
13:00
Man sagt, das Ganze heißt dann dieser Microlith und dann packt man einfach was auch immer man vorher gemacht in einen Docker-Container und dann ist es auch wieder super. Wobei zu Docker kommen wir nachher auch noch. Ja, das ist so, das ist etwas, das finde ich wiederum sinnvoll oder da versuchen wir auch Produkte rundherum zu haben. Wenn ich alles hochgradig verteile, brauche ich mal
13:21
ein zentrales Logging und nachher muss ich irgendwie durch mein gesamtes System nachverfolgen können, was macht denn ein Call und was ist zum Beispiel langsam oder wo geht das Ganze schief? Wenn ich nicht entsprechend viel in diese Überwachung investiere, wird mir diese ganze hochgradige Verteilung nichts bringen. Zum Beispiel Netflix, ich habe seit einem Prozentgrad gerade vergessen,
13:41
aber die haben einen deutlich zweistelligen Bereich aller Ressourcen, investieren sie nur in das Monitoring von ihren Systemen. Die sind hochgradig verteilt, aber das ist auch ein Investment, also man kann nicht einfach nur verteilen und dann das Zeug so vor sich hinwerken lassen. Man muss auch entsprechend dann investieren in das Tooling und in die Überwachung von diesen hochgradig verteilten Dingen.
14:02
Ja, Sam Newman, der ist auch ganz groß im Thema Microservices, der sagt auch, für große Teams macht es total Sinn, aber bei kleinen Teams ist er auch eher skeptisch als Verfechter der Microservices. Ob es wirklich so sinnvoll ist, dass man dann fünf Services pro Team mit Mitglied hat, ist möglicherweise nicht mehr unbedingt das, was das Original
14:21
Ziel war. Und alle können jetzt gemeinsam mit mir sagen, wir sind nicht Microsoft, Facebook, Google etc. Nur weil ich deren Ansätze kopiere, werde ich dann nicht genauso erfolgreich wie die sein. Funktioniert leider nicht so. Ja, die Sünde ist leicht, die Gier.
14:41
Wenn man von irgendetwas alles nimmt, was es denn so gibt, und da habe ich nur eine einzige Slide dazu, oder das ist meine Assoziation damit. Hat das irgendwer mal verwendet? Mir die Freude, ja, es sind doch einige. Bei mir war das, glaube ich, 2007 oder so, ich weiß gar nicht mehr, war das Version 3.
15:00
Ich kann mich nicht erinnern, ich weiß nur, das Ding hat fünf Minuten auf meinem Rechner gebraucht zum Starten. Jedes Redeployment hat 90 Sekunden gedauert und nach vier Redeploys war ich mit einem Out of Memory und habe dann nochmal mit fünf Minuten begonnen, nach Hoch zu starten. Das war kein so spaßiger Entwicklungsansatz, das hat sich aber mittlerweile eigentlich auch wieder alles gebessert mit Wildfly.
15:21
Welche Sünde ist das? Die ist sehr dunkel. Wer hat sieben Minuten Zeit gesehen? Genau, die Trägheit oder wie auch immer da die richtige Übersetzung ist, wobei Sloth ist natürlich der schönste Begriff dafür. Ja, das sollte man so nicht präg sein. Wann wollen wir bessere Software
15:41
deliveren? Continuously. Das heißt, da ist die Idee immer continuous, was auch immer. Da gibt es ja nachher die verschiedensten Begriffe. Da gibt es ja zuerst die continuous integration. Wir bauen mal jeden Push und testen den. Also jedes Mal, wenn ich auf mein Git-System pushe oder meinetwegen auch mit Subversion ein commit mache,
16:01
dass ich das danach teste und baue. Dann gibt es continuous delivery. Ich deploye automatisch auf ein Testsystem, aber auf Produktion deploye ich nur händisch. Und der letzte Schritt mehr oder weniger ist ein continuous deployment. Ich deploye
16:21
auch automatisch auf Produktion. Macht das irgendwer? Automatisches deployment auf Produktion. Ein halber. Ja, so das typische Bild ist in der Theorie schön, in der Praxis sind dann die meisten doch zu konservativ dafür. Wobei ich auch nicht einmal glaube, dass das unbedingt jeder so braucht. Wenn man irgendwo ist, wo es darum geht, möglichst schnell
16:41
alle 10 Minuten ein Feature hinausschießen zu können, okay, meinetwegen, aber die meisten Branchen sind dann doch nicht ganz so gelagert. Schaut dann irgendwie so aus, sollte es eigentlich sich automatisch abspielen. Genau, das ist dann die Idee meiner Software. Dass ich meine Software mehr oder weniger so automatisch ausrolle. Ich habe mehr oder weniger gar nicht mehr Zeit innen zu halten, um mich umzuschauen, was so passiert.
17:03
Ich rolle einfach meine Software laufend aus. Und wenn man dann noch ein paar Passworts drauf haben möchte, also zuerst muss man Agile haben, dann kann man Continuous Integration machen, dann Delivery, Deployment und danach sitzt dann DevOps. Was auch immer DevOps ist. Die meisten Firmen, die keine Ahnung haben,
17:21
was DevOps ist, die haben dann eine Position dafür ausgeschrieben. Und die suchen den berühmtberichtigen DevOps- Engineer und der findet dann vielleicht irgendwann heraus, was dieses DevOps eigentlich ist. Möglicherweise ist es das. Dass die Deployments auch voll automatisiert sind.
17:40
Das war dann die Idee. Oder es gibt doch diesen schönen Ansatz, der Weidewei-Deploy. Es ist einfach schippen, komme, was wolle. Einfach hinaus damit. Ist egal, ob da Bugs drin sind, aber das ist das andere. Das ist glaube ich wesentlich verbreiteter als das Domain Driven Design. Das ist das, was die Leute wirklich machen.
18:01
Die, die, die, das wäre schön und da gibt es das Buch und die Leute referenzieren immer das Buch oder haben das Buch irgendwo im Regal stehen. Aber das ist, was wirklich passiert danach. Das andere System, mit dem ich schon viel gearbeitet habe, zu dem ich auch ein sehr valentes Feld des HBS Jenkins, wo es diese schöne Beschreibung gibt, die drei Zustände, in denen Jenkins
18:22
sein kann. Der Jenkins, der einfach aus Absicht fehlschlägt. Dann den Jenkins, der ist einfach irgendwie aus Inkompetenz kaputt. Und Jenkins für keinen richtigen Grund. Also ich habe eigentlich eineinhalb Kollegen, die nichts anderes als Jenkins machen und die würden das
18:41
sofort unterschreiben. Die träumen auch jede Nacht davon, dass sie Jenkins durch irgendein anderes System ersetzen. Es sind nur alle anderen mindestens genauso schlecht. Das ist irgendwie so ein Henne-Ei-Problem, aus dem wir noch nicht ganz herausgekommen sind. Was aber ganz cool ist, was man generell machen sollte, ist, dass man seine Konfiguration nicht in seine Fakte hineinpackt.
19:02
Weil sonst muss man bei jedem Change immer alles neu zusammenbauen. Das ist ein bisschen mühsam. Und das, wo ich auch ganz stark dafür bin, ist, dass man seine Secrets nie irgendwo hineinkommitted. Das ist immer das, wo man irgendein privates GitHub-Projekt hat. Da hat man dann gesagt, ah, das ist eh nur privat, da kommite ich jetzt meinen AWS-Key hinein.
19:21
Und zwei Jahre später denkt man sich, ah, das war eigentlich ein cooles Projekt, könnte man mal open-sourcen. Und plötzlich starten dann 100 Instanzen irgendwelche Bitcoins zu meinen. Weil da irgendwo noch der Key drinnen war. Und die Angreifer sind da auch nicht ganz dumm, die scannen dann automatisch die GitHub- Accounts, also die öffentlichen Nach-AWS-Keys. Mittlerweile scannt
19:41
AWS zum Beispiel auch. Und dann ist ein Wettlauf, wer findet den Key zuerst? Auf dem man sich möglicherweise nicht einlassen möchte. Es gibt wesentlich coolere Produkte, die heißen alle Vault von verschiedenen Herstellern, also Hashacop, Ansible, was auch immer Vault. Die versuchen dann die Secrets irgendwie woanders zu
20:01
speichern und möglichst sicher. So. Das ist jetzt wirklich zu dunkel. Welche Sünde ist das? Last. Das ist die unkontrollierbare Wunsch, irgendetwas zu tun oder zu verwenden. Und in der IT ist das glaube ich eine der verbreitetsten Sünden.
20:23
Das ist das hier. Da sehen sich wahrscheinlich die meisten irgendwo wieder. Eines der Dinge, das ich da immer habe, ist dieses hier, Docker. Die, die einmal den Quartal deployen, die wollen unbedingt Docker verwenden.
20:43
Kann man machen, muss man nicht machen, weil dann im Endeffekt schaut es dann ohne dies wieder so aus. Das nächste Problem ist dann diese Docker-Containers, in der Theorie hier hat man dann einen Prozess pro Docker-Container. Wenn ein ein Docker-Container 700 Megabyte groß ist, ist das Ganze beim Ausrollen dann auch immer weniger cool.
21:02
Ja, deshalb ist das Ganze auch dieser Wahl. Und der Wahl schaut eigentlich so aus, der sollte das auch automatisch spielen. Kann auch lächeln. Und wir sind alle dieser kleine Nemophische da vorne. Und das ist der große böse Docker. Und irgendwann werden wir uns dieser große böse Docker auffressen mit Haut und Haar mehr oder weniger. Warum möchte ich das überhaupt
21:21
haben? Da gibt es dieses klassische Problem bei den Works on my Machine. Ich nehme an, jeder hatte schon mal so einen Kollegen, ich hatte den auch mal. Bei dem hat immer auf seiner Maschine alles immer funktioniert, nur woanders nicht. Der letzte logische Schritt, was man ihm dann auch immer sagen muss diesem Kollegen, ist gut, mach ein Backup von deinen E-Mails, weil dein Laptop geht jetzt in Produktion.
21:41
Das ist offensichtlich das einzige System, auf dem das Ganze funktioniert. Da bleibt dann nichts anderes über. Docker versucht das Ganze natürlich zum Gehen und das ist, verstehe ich auch total, macht Sinn, ist auch sehr angenehm, zum Beispiel für Testsysteme.
22:00
Wer kann sich noch erinnern, früher hat es immer diese Test-Setups gegeben, oder wenn man neu in eine Firma gekommen ist, dann hat man mal eine Woche versucht, alle Services zum Laufen zu bringen. Und da gab es eine ganz alte Dokumentation, die überhaupt nicht mehr gestimmt hat. Mittlerweile hat man da ein paar Docker-Container, das sollte das wesentlich schmerzbefreiter gehen. Was cool ist, für Development nur in Produktion,
22:21
ist es dann nicht immer so cool. Das Problem ist, man kann dann alles schöne sein. Der Docker-Container packen, nur was macht man dann? Also das ist immer ein Docker-Container. Jeder für sich funktioniert immer sehr gut. Es ist nur noch nicht so das ganz, das Endziel mehr oder weniger erreicht von einer Applikation. Der andere schöne Vergleich ist, es sind alles in der Docker-Container, deshalb ist alles
22:40
gleich und alles ist einfach. Das ist so wie alles in Reifen. Sie brennen zwar, aber es sind alles Reifen. Deshalb ist das System großartig einfach. Oder was so viele sagen, Containers everywhere. Also man kann einfach alles in seine Container hinein packen und dadurch wird das Leben deutlich besser. Und dann gibt es immer die Leute, die sagen, aber es ist immer ein Prozess.
23:02
Das Problem ist, nur dieser Prozess hat dann plötzlich einen eigenen Network-Stack und hat auch einen eigenen Storage-Layer, die dann alle furchtbare Bugs immer aufweisen, die man vorher nie hatte. Oder das ist zumindest ein Problem, in das wir gerade bei persistenten Applikationen immer reinlaufen. Und dann gibt es immer die Leute,
23:20
irgendwann erreicht man dann diesen Zustand. Also ich sehe, einige sind hier recht jung, die sind wahrscheinlich noch nicht so alt dafür, aber andere sind vielleicht schon ein bisschen älter. Die können sich dann hier wieder erkennen. Und das, was man da immer festhalten muss, ist, eine kaputte Architektur wird durch Docker nicht gerettet.
23:43
Also jedes von diesen Dingen hier ist mehr oder weniger ein Docker-Container. Und jeder Docker-Container für sich ist eigentlich ganz gut dabei. Aber die gesamte Architektur tut sich dann irgendwie doch nicht so gut. Das ist ungefähr die Architektur, die man dann hat, wenn man einfach so Docker-Container
24:00
links und rechts für uns sich hinwirft. Das andere Problem ist, manchmal muss man dann irgendwie trotzdem als eine Docker-Container noch automatisch neu bauen können, wenn es irgendwie eine blöde Security-Problem gibt, so wie wenn es in G-Lib-C, nicht auf L-Pine, muss ja L, aber das ist eigentlich noch viel schlimmer.
24:20
Zumindest von der Erprobtheit her. Wenn es dann irgendwann ein Security-Problem gibt, dann muss man erst recht wieder alle Container neu bauen und ausreiten. Wer hat eine Idee, was das ist? Man kann zum Glück alles, also man kann auch seine Cobalt-Applikation in Docker packen.
24:42
Ob das die Cobalt-Probleme dann lösen wird, ist die andere Frage, aber man kann natürlich. Und das Ganze ist dann so, die ideale Kombination ist natürlich Microservice und Container. Und es gibt da den perfekten Dilbert-Comic dafür, wo sie feststellen, so was ist da Cargo-Cult? Und dann sagt man einfach, man
25:00
macht genau das. Und nachher ist man direkt bei den Profits. Oder beim Gewinn. Das ist der Ansatz dann. Man kopiert einfach was wir vorher schon hatten. Ich bin nicht Google, Facebook oder Microsoft oder wie auch immer. Aber wenn ich deren Ansätze kopiere, dann werde ich genau so erfolgreich sein. Möglicherweise nicht.
25:22
Gibt es diesen schönen oder dieses häufige Problem, wenn die Lösung immer nur Docker ist, ist es möglicherweise auch nicht unbedingt die Lösung für alles. Ich kenne den mehr, Kyle Kingsbury. Das ist der, der Datenbanken professionell kaputt macht, der immer verteilte Systeme testet.
25:40
Der hat auch immer Probleme mit irgendwelchen Systemen. Ich glaube, Docker ist da auch dabei. Und das andere ist mit dem Cargo-Cult, nur weil Google irgendwas macht, macht man trotzdem nicht immer nur was Google macht. Kelsey Hightower, der ist Hauptkubernetes Advokat oder Developer Advocate von Google und Kubernetes. Der sagt auch,
26:01
wenn man nur Kubernetes verwendet, weil Google Kubernetes verwendet, ist das möglicherweise nicht die richtige Strategie, weil sie schreiben auch ihre eigenen Dateisysteme. Wer hat hier schon ein Dateisystem geschrieben? Ja. Also ich nicht, nein das war möglicherweise nicht so die Idee oder das, was man unbedingt machen möchte.
26:22
Ja. Und dann gibt es halt immer die Leute, die sagen ja, der Cargo-Cult ist halt ein bisschen so Geschwindigkeit, Hauptsache ist es schnell. Ob es dann nachher funktioniert, ist dann zweitrangig, was möglicherweise auch nicht ganz so die Idee war von jedem System, das man haben möchte. Docker Run. Was könnte hier ein Problem sein?
26:46
Das sind unsere Images. Das haben wir nämlich dann irgendwann geändert. Eingenommen, ich starte heute drei Container so, und die finden sich dann auch automatisch und bauen einen Cluster. Und in einem halben Jahr oder so möchte ich dann zwei zusätzliche
27:01
Container dazuhängen, weil ich einfach mehr Performance brauche. Was könnte das Problem sein? Bitte? Ich werde wahrscheinlich meinen Cluster furchtbar abschießen, weil ich hier implizit immer Latest bekomme. Und das gerade bei irgendwas, was eine Datenmark ist, ist das dann nicht so gut.
27:21
Also wenn ihr jetzt aktuell hättet ihr Elasticsearch 5.5.2 und in einem halben Jahr kriegt ihr dann 6 irgendwas. Und damit würde ich mir absolut den Cluster zerschießen dann. Oder zumindest die zwei neuen Nodes würden nicht in den Cluster hineinkommen, weil einfach die Versionen nicht zusammenpassen. Das ist immer so, bei
27:40
Docker Containern ist auch immer Latest. Hauptsache schnell, wir überlegen uns nicht groß, welche Version wir hier haben müssen. Aber wir nehmen immer Latest. Deshalb bieten wir mittlerweile auch keinen Latest Tag mehr an. Bei uns muss man mittlerweile immer explizit die Version definieren, die man so ausrollen möchte. Einfach ist eine Spur mehr Arbeit, aber damit man sich später nicht seinen Cluster abschießt, unabsichtlich.
28:02
Dann gibt's auch diesen schönen Ansatz. Das wird jetzt die Java Enterprise Edition Schiene nicht zu freuen. Aber man kann auch einfach seine Java jetzt verwenden und zieht die dann mehr oder weniger als Container oder mehr oder weniger. Sonst ist die Dependency halt Java. Statt einer Docker Runtime hat man einfach die JVM.
28:21
Und alles andere ist aber dann in das Java-File hineingepackaged. Und man spart sich dann die ganzen großen Installationsprobleme und das JBoss-Problem von ganz vorher. Und dann gibt's noch dieses Serverless-Ding. Das finde ich ein super Zitat. Eine Microsoft has cried out in terror und alles war nachher Serverless.
28:41
Also es ist nicht so, dass Serverless schlecht wäre oder so, aber es ist momentan halt auch so ein absolutes Hype-Thema. Momentan sind wir serverless, codeless und dann architectureless. Man wird dann alles los, was man nicht braucht. Wobei Serverless ja genauso wie die Cloud, es sind nur nicht mehr die eigenen Computer
29:01
und bei Serverless sind es nur nicht mehr die eigenen Server, die das Ganze dann am Laufen halten. Also es gibt schon noch irgendwo einen Server dahinter. Und dann ist immer diese Diskussion ist das platform-as-a-service reborn? Ich kann mich erinnern vor 10 Jahren oder so, da wurde mir an der Uni mal so erklärt, ja, also dieses infrastructure-as-a-service, das ist mehr oder weniger
29:22
nur so ein Zwischenschritt und alle werden platform-as-a-service machen. Und dann kam irgendwie so ein bisschen so ein platform-as-a-service-Winter, wo ja Herr Roku gibt's nach wie vor, aber alle anderen, die das probiert haben oder die, die es mal vor 10 Jahren probiert haben, da gibt's die meisten nicht mehr. Ist Serverless jetzt mehr oder weniger das neue Aufkeimen von diesem platform-as-a-service? Und man könnte sagen, ja,
29:40
aber nur unter der Voraussetzung, dass die platform-as-a-service auch in, keine Ahnung, 20 Millisekunden gestartet werden kann, dann eine halbe Sekunde läuft und entsprechend abgerechnet wird, dann ist es mehr oder weniger platform-as-a-service neu aufgelegt. Also mit Serverless kann man schon sehr coole Dinge machen, gerade die irgendwelche Jobs, die nur so einmal in der Woche oder einmal am Tag laufen, oder irgendwie
30:02
requestbasiert sind, ist schon ein sehr cooler Ansatz und wir machen intern auch eigentlich sehr viel damit oder möglichst viel, einfach damit wir uns selber nicht mehr um irgendwelche Server kümmern müssen. So, Pride ist jetzt auch wenig überraschend. Man glaubt man das irgendwie besser als wer anderer. Wer kennt dieses Problem?
30:21
Oder fragen wir einmal anders. Wer hier würde sich DEV zuordnen? Wer würde sich hier OBS zuordnen? Okay. Kennt OBS das Problem? Oder den in OBS sind? Ja, ja. Gibt es halt das klassische Thema, hier haben wir DEV, hier haben wir OBS, wir werfen es über die Mauer und nachher ist es das OBS Problem. Deshalb
30:42
sagt man nachher einfach DEV OBS, man schreibt auch immer, man schreibt DEV OBS drauf. Aber ich verwehre mich weiterhin dagegen, dass DEV OBS irgendwie eine konkrete Technologie ist. Sondern es versucht genau dieses Problem mehr oder weniger zu umgehen, das man mal hatte. Und dann gibt es die, die sagen, ja wir machen DEV OBS. Aber wir machen es ohne all dieses andere unnötige
31:02
Zeugs. Das wird ein typischer Enterprise Ansatz, wo man dann nachher irgendwo DEV OBS draufschreibt. Welcher Sinn ist das? Oder was ist das? Ist nicht Kevin Spacey, das war jetzt nicht die Antwort. Wer kann sich erinnern?
31:22
Der Nate, genau. Da gibt es irgendwie diesen Ansatz, dass man alles selber baut. Da hatte ich auch mal einen Kollegen, der wollte auch, ich weiß nicht genau warum, aber der wollte einfach nichts externes verwenden. Der hat dann, das war so einer, den hat man keine zwei Tage unbeausichtigt lassen können, den musste man immer fragen, was machst du denn, um ihn rechtzeitig zu stoppen, wenn er irgendwas ganz eigenartiges
31:42
gemacht hat. Einmal hat er mich nicht aufgepasst, da hat er in einem halben Tag dann begonnen, ins eigenes Encoding zu schreiben. Er war irgendwie mit allen anderen Encodings aus irgendeinem Grund unzufrieden, den sonst keiner nachvollziehen konnte. Das ist so dieses typische Craft everything yourself. Wobei momentan versucht man da eh ein bisschen davon
32:02
wegzugehen, also gerade im Java-Bereich gab es ja auch lange dieses, man hat ein Pom-Pfeil erstellt und irgendwie gab es diesen Pom-Guru, der hat dann eine Woche lang irgendwie die richtigen Dependencies zusammengestellt, mittlerweile mit Spring Boot zum Beispiel, ist das einfach sozusagen, hat jemand einen sinnvollen Satz an Dependencies gefunden, die zusammenarbeiten
32:21
und bringt dann regelmäßig neue Versionen heraus, die auch wieder sinnvoll zusammenarbeiten. Das versucht dann dieartige Probleme zu lösen, dass man alles selber immer baut und jeder das Rad damit neu erfindet. Das andere ist dann Pets vs. Kettle. Wer kennt Pets vs. Kettle? Das sind gar nicht so viele.
32:41
Also die Haustiere, das ist mehr oder weniger der alte Ansatz. Bei den Haustieren kann sich wahrscheinlich fast jeder noch erinnern, oder ich kann mich zumindest erinnern, irgendwann habe ich meinen ersten virtuellen Server irgendwo gemietet, das war ein Haustier. Es hat einen Namen bekommen und das wurde dann mehr oder weniger von Hand weg gepflegt und aufgezogen.
33:01
Da hat man alle Pakete drauf installiert und wenn es diesem Server schlecht gegangen ist, dann hat man ihn wieder gepflegt und versucht irgendwie zu richten. Das ist das Haustier. Und der andere Ansatz dann ist diese Viehzucht oder wie auch immer. Das Vieh hat keinen Namen. Das Vieh wird auch nicht von Hand aufs Große gezogen, sondern irgendwie
33:22
automatisiert. Und wenn irgendein Stück viel krank ist, dann wird es geschlachtet, damit die restliche Herde nicht infiziert und wird einfach ersetzt durch ein ähnliches baugleiches Modell. Und das ist genau der Infrastrukturansatz, dass man das versucht wieder nachzuvollziehen. Hat natürlich auch immer Ausnahmen.
33:46
Gewisse Services haben dann manche sind dann doch wieder Hats, die man pflegen muss. Zur Automatisierung kann man dann verwenden keine Ahnung, wenn man die Cloud Provider automatisieren will bietet sich glaube ich mittlerweile primär Terraform an.
34:02
Sonst Automatisierung, Ansible, Puppet, Chef, was auch immer man haben möchte. Aber idealerweise hat man nicht mehr diese Systeme, wo man weiß, da habe ich mal in irgendein Wiki was hineindokumentiert, aber wenn dieses System heute stirbt, brauche ich eine Woche um es genau wieder so herzustellen. Oder möglicherweise kann ich es nie wieder genau so herstellen und nur so ähnlich,
34:22
weil die Dokumentation ist völlig veraltet und total lückenhaft mittlerweile. Das ist ein Zustand, den man idealerweise nicht mehr hat. Man kann irgendwann wesentlich besser schlafen, wenn man das System nicht mehr so aufbauen muss. Deshalb, automate all the things. Und das andere ist, dass man idealerweise diesen Drift vermeidet, dass man
34:41
ein System automatisch aufsetzt. Aber nachher lockt man sich dann bei SSH ein und macht durch diesen einen Befehl und diesen anderen Befehl. Und irgendwann ist das System dann wieder absolut unreproduzierbar. Der ganz harte Ansatz ist, dass manche sagen dann, es sollte SSH Zugriff auf die Server gar nicht erlaubt sein. Was dann manchmal auch nicht ganz so praxistauglich ist,
35:02
wenn man irgendwelche Sachen nie bangen muss. Aber das ist dann der eine Ansatz, um Drift zu vermeiden. Der andere Ansatz um Drift zu vermeiden, ist wesentlich kreativer. Wenn man kein Development System hat, sondern nur Produktion, dann kann es auch kein Drift geben.
35:21
Das ist natürlich die richtige Lösung für all diese Probleme. Dann spart man sich diese ganzen Automatisierungskram und diesen Drift Problem kann man einfach so machen. Was ist das? Nicht Brad Pitt, sondern 777
35:40
Wie war die Übersetzung? Nein, ich weiß nicht. Wut war falsch. Das beginnt oft beim Logging und Monitoring. Das ist dann immer die Erkenntnis, ich sollte, aber ich tue nicht. Beziehungsweise andere Leute zeigen dann immer, solange ich das System nicht richtig monitore, funktioniert alles. Erst wenn ich beginne richtig zu monitorn, dann funktioniert es nicht mehr.
36:03
Da kann man sich vorher immer gut in Sicherheit wiegen. Da versuchen wir, Produkte herum vorzustellen. Da kann man auch dazu gerne Fragen beantworten. Aber ja, ich nehme an, das ist das, was man immer versucht. Damit versucht man die Überwachungsprobleme dann nachher zu umgehen. So, wir sind in Einstein fertig.
36:23
Das, was man immer versucht. Die ideale Lösung ist immer schwierig. Also wenn jetzt alle sagen, die ideale Lösung heute ist Docker und Microservices, dann sollte man so wieder, wer wollte, ein bisschen skeptisch sein. Weil die ideale Lösung für alle gibt es für mich nicht. Es gibt immer so einen Trend, dem laufen alle hinterher.
36:40
Und dann gibt es diese Pendelbewegungen und dann laufen alle wieder weg vor diesem Trend eine Zeit lang. Einmal zentralisiert man alles, dann verteilt man alles wieder. Ich habe das irgendwann so bei Computern so gesehen, am Anfang gab es nur die Terminals und da hat man sich zu irgendeinem Rechner verbunden. Dann hat man irgendwann seinen schönen Desktop gehabt und hat dort alles zentral gehabt. Und dann gab es irgendwelche Thin Clients,
37:02
wo man wieder alles zum Server hin verschoben hat. Mittlerweile haben wir da alles auf ihrem Laptop oder verschieben es mittlerweile wieder in die Cloud zurück, das ist immer so ein Hin und Her. Bei jedem Technologietrend habe ich immer das Gefühl, es wogt immer so hin und her, von dem einen in extrem zum anderen. Und man lernt dann immer wieder das selbe, was man eigentlich schon wusste.
37:21
Aber man muss es immer wieder neu erfahren, um daran zu glauben, weil man könnte ja sonst einen Trend verpassen. Wir haben so ein bisschen verschiedensten Sünden gesehen. Wir hatten Glatoni, beziehungsweise bei Glatoni haben wir eigentlich das Gegenteil auch gesehen, wo man dann in zu kleine Scheibchen unterteilt hat, entweder mit Not-Dependencies
37:40
oder mit seinen Microservices. Die Hubgear, das war der JBoss, sei nicht die JBoss. Die Faulheit war, wenn man nicht automatisch zumindest seine Software baut und testet, kann man natürlich in verschiedenen anderen Abstufungen machen, man kann es automatisch auf Test ausrollen, man kann es automatisch auf Produktion ausrollen. Aber man sollte auf jeden Fall irgendwie automatisch
38:01
bauen, testen und dann auch diese Test-Failures nachher behandeln. Nur wenn man die Continuous Integration gemacht hat und dann der Jenkins immer rot ist, dann hat der Jenkins auch nicht viel Sinn gehabt. Es gibt nämlich auch Leute, die das so handhaben. Was war Envy?
38:25
Mittlerweile glaube ich, kann man sich gerade im Deployments-Szenario nicht mehr ganz so erlauben, zu sagen, naja, das ist jetzt nicht mehr mein Problem. Werner Vogel, der CTO von Amazon, der hat dieses schöne Zitat geprägt, you build it, you run it. Also der, wie auch immer, für einen Service baut,
38:41
ist dann nachher auch für den Betrieb zuständig. Und es ist dann teilweise sehr heilsam, weil plötzlich ist es für die Entwickler wesentlich weniger oder wesentlich wichtiger, dass das Ganze stabil läuft, wenn sie sonst in der Nacht gepaget werden, wenn das System nicht funktioniert. Oder wenn irgendwelche Metriken nicht so funktionieren, wie sie sollen. Das kann dann durchaus heilsam sein.
39:02
Fast. Nicht immer nur den letzten Trend verwenden. Pride. Ich glaube, das war das, ich bin... Nein, Ref war ich. Ich habe nicht gemonitort. Was habe ich bei Pride gehabt? Hab ich bereits wieder vergessen.
39:21
Ah, genau, Pride. Ich sollte nicht alles selbst bauen. Also sowohl weder meine Infrastruktur, noch meine Services oder meine Software. Also wer beginnt, sein eigenes Enkoding zu schreiben, war vielleicht nicht der richtige Ansatz. Oder wer heute beginnt, ich weiß nicht, irgendwelche Low Level Frameworks selber zu schreiben, vielleicht kann man seine Zeit auch
39:41
irgendwie besser investieren. Wobei, in der Freizeit ist eben unbenommen, was er macht. So, wer sich nicht mehr an den Film 7 erinnern kann, es gibt eine 8-Bit-Variante, die glaube ich 4 Minuten oder so dauert, die im 8-Bit-Look von Computerspielen genauer nochmal zeigt, wie das funktioniert hat, finde ich auch sehr sehenswert.
40:02
So, ich glaube wir haben für Confessions genug Zeit. Irgendwelche Confessions oder Fragen, ich nehme ja auch Fragen. Aber Confessions bevorzugt. Wer verwendet Docker in Development? Wer verwendet Docker in Produktion?
40:22
Ok, das wären weniger, das übliche Bild. Sonst Geständnisse. Andere Sünden. Keine Sünden. Man muss anders fragen. Wer kennt jemand? Ah ja, genau.
40:43
Wer hat schon einmal von anderen Sünden gehört? Also nicht einmal im eigenen Büro oder so, sondern woanders. Einfach woanders. Ok?
41:14
Das ist, ok, das war keine Frage, ich wiederhole jetzt das aber auch nicht. Ja, das ist natürlich cool. Da kann man dann nur hoffen, dass man nicht die falschen Technologien
41:22
verbrennt, dass die dann nachher nicht auf die Blackliste kommen. Wobei ich kann dann bei Agile ist ja oft so ein wichtiger Punkt diese Ansicht die Retrospektive. Ich kann dann diesen Ansatz, man macht dann keine Retrospektive, weil es gab hier keine Fehler. Das ist dann auch dass man möglichst diesen
41:42
diese lesson learned oder sowas, könnte denn schiefgegangen sein, dass man das möglichst ausblendet, damit es auch nur ja keine Fehlschläge gegeben hat. Das ist auch ein guter Punkt. Aber verbrannte ihr das natürlich auch nicht, wenn man sagt die Technologie oder der Ansatz. Ok. Und statt Scrum ist jetzt wieder der Waterfall oder?
42:31
Bietet sich natürlich dann beim Microservices an, wo man dann kleine Services hat, dann kann man sie jede Woche neu refactoren. Idealerweise wechselt man auch regelmäßig dann die Programmiersprache.
42:42
Das macht es dann wesentlich leichter beim Debuggen und auch beim Hiren, wenn man 10 Technologien braucht. Um nur ein kleines Service dann zu checken. Ja? Klar. Legacy. Gibt's denn nicht auch irgendwie so ein Zitat? Die Legacy hat sich zumindest bewährt.
43:04
Hat dann vielen Neuentwicklungen doch auch einiges voraus. Ja klar. Sonst? Fragen, Sünden, Beichten.
43:37
Funktioniert auf meinem System. Also an und nach geht es.
43:49
Problem wird woanders sein. Ganz läuft auf OpenStack, im Docker. Und? Das muss über Docker, das muss OpenStack sein. Nee, meine Applikation funktioniert.
44:01
Hast du erst gemacht? Na gut, wenn wir so argumentieren, dann so. Ende des Liedes war es, er hatte nicht entsprechend den Endstring. Beendung von Strings war irgendwie noch eine Implementation von vor 20 Jahren, weil auch
44:20
Legacy ist das Produkt, mit dem da gesprochen wird. Und quasi Ende des Strings wurde von seinem Tool nicht abgefahren. Aber, auch sind schuld. Wobei, ist klar, ist noch cooler, wenn man es dann nicht selber betreibt, sondern direkt dem Kunden gibt, weil dann spart man sich die Obstprobleme im Haus. Dann ist alles ein Kundenproblem. Das ist eigentlich dann noch viel
44:42
coolerer Ansatz. Das ist ja natürlich blöd. Ist halt, ist auch wieder kacke. Sehr, sehr nett. Gut, dann war's das von mir.
45:01
Ich habe noch einen Haufen Sticker da vorne, falls ihr mehr Sticker braucht. Ich bin noch für Fragen heute Morgen da. Sonst einmal danke.