DevOps

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Stefan Tilkov: Hallo und herzlich Willkommen zu einer neuen Episode des innoQ-Podcasts. Heute mit Oliver Wolf, hallo Oli.

Oliver Wolf: Hallo Stefan.

Stefan Tilkov: Und zwar zum Thema „Organisatorische Aspekte von DevOps”. Zumindest haben wir uns das vorgenommen. Mal gucken, ob wir da auch landen, das weiß man bei uns nie so genau.

Oliver Wolf: Ein bisschen über Technik sprechen wir wahrscheinlich auch, aber nicht so im Detail. Das machen wir ein andermal.

Stefan Tilkov: Ok. Dann fangen wir doch vielleicht kurz an, indem du dich vorstellst.

Oliver Wolf: Ja, also mein Name ist Oliver, ich bin bei innoQ seit 2011, Mitte

1. Bin hier als Consultant in verschiedenen Projekten unterwegs, hauptsächlich mit dem Fokus auf Softwarearchitektur, in den verschiedensten Ausprägungen. Aber mich interessiert eben auch das Thema DevOps, weil es natürlich auch sehr stark einher geht mit Architektur. Bestimmte Architekturen eignen sich dafür, so einen Ansatz zu verfolgen, andere Architekturen weniger. Deswegen kann man das so voneinander nicht trennen, deswegen interessiert mich das Thema auf jeden Fall auch.

Stefan Tilkov: Ok. Dann lass uns doch kurz damit starten, das mal zu definieren.

Oliver Wolf: Ja. Also der Begriff ist schon ein bisschen älter. Den hat ein belgischer Entwickler geprägt, vor einigen Jahren. Er hatte nämlich eine Konferenz erstmalig veranstaltet, genau mit diesem Schlagwort, mit diesem Titel. Und die Idee dabei war – oder ist auch heute noch natürlich –, die Entwicklung von Software und den Betrieb von Systemen enger zusammen zu bringen. Das waren ja bisher in klassischen Organisationen immer sehr getrennte Dinge. Das wissen wir alle aus unserer Projekterfahrung denke ich, dass gerade in großen Organisationen Entwicklung und Betrieb einfach zwei Welten sind, die miteinander nichts zu tun haben. Es gibt dann irgendwelche Schnittstellen, über die mal irgendwas über den Zaun geworfen wird, von der Entwicklung in den Betrieb, aber ansonsten gibt es da relativ wenig Kommunikation, relativ wenig Rückkopplung und das ist genau ein Ziel dieser DevOps-Bewegung, diese Dinge stärker miteinander wieder in Verbindung zu bringen. Also idealerweise ein und dieselbe Person / Personengruppe in beiden Rollen zu sehen.

Stefan Tilkov: Lass mich nochmal ein bisschen Advocatus Diaboli spielen. Das ist doch eigentlich ganz toll, diese Trennung, weil die sorgt dafür, dass Dinge nur sehr geordnet in den Betrieb gehen. Und in der Entwicklung, da verändere ich Sachen, da will ich alles mögliche anders machen und großartig innovativ sein und mit tollen, neuen Sachen rumspielen. Und in einem Betrieb möchte ich eine Nummer konservativer sein und dafür sorgen, dass die Sachen auch laufen und deswegen ist das gut, dass es da eine strikte Trennung gibt und ich die Dinge erstmal sehr genau ansehe, bevor ich sie in den Wirk-Betrieb übernehme. Warum sollte das jemand schlecht finden?

Oliver Wolf: Naja, weil dieser jemand vielleicht einfach andere Anforderungen an das Tempo hat, in dem Dinge funktionieren. Weil wenn wir uns anschauen, wie viele unserer auch aktuellen Kunden noch funktionieren, große Unternehmen, die vielleicht Anwendungen für den internen Bedarf entwickeln, die – naja wo Anforderungen einfach relativ langsam dazu kommen, wo sich das Geschäft relativ langsam wandelt, da mag das ein vernünftiger Ansatz sein, da funktioniert das auch noch ganz gut. Wir haben es aber natürlich heute zunehmend mit Unternehmen zu tun – das ist ja kein Phänomen der letzten paar Jahre, sondern schon ein bisschen länger – durch den Internetboom mit Unternehmen, die einfach sehr schnell auf einen sich verändernden Markt reagieren müssen. Nehmen wir so Unternehmen wie Facebook, wie Flickr, wie Etsy, wie all diese großen Internetfirmen, die wirklich Millionen, Zig Millionen von Kunden haben, die sich in einem extrem starken Wettbewerb befinden, die sehr schnell ihr Geschäftsmodell auch anpassen müssen auf das, was passiert. Für die ist einfach ein Änderungszyklus von einem halben Jahr, was wir so in Großunternehmen oft finden als Release-Termine, nicht mehr praktikabel. Die müssen schneller reagieren können und das erfordert einfach eine andere Art zu arbeiten.

Stefan Tilkov: Das heißt, ein Hauptziel ist, Dinge schneller durchlaufen zu lassen. Kann man das so sagen, dass das das zentrale Ziel ist?

Oliver Wolf: Das kann man so sagen. Die Durchlaufzeit eines neuen Features von der Idee bis in den Betrieb einfach zu verkürzen. Das ist – ja aus meiner Sicht – eines der ganz wichtigen oder der aller wichtigsten Ziele dabei.

Stefan Tilkov: Suggestivfrage: Glaubst du, dass das wirklich nur Facebook und andere interessiert oder ist das nicht vielleicht auch was für die klassischen Unternehmen?

Oliver Wolf: Das ist sicher auch was für die klassischen Unternehmen. Es erfordert natürlich auch in den ein Unternehmen Umdenken, gerade an den Stellen, wo Anforderungen stehen. Also der gesamte Durchlauf, in dem gesamten Prozess, muss natürlich verschnellert werden. Das ist nicht nur damit getan, Dinge aus der Entwicklung schneller in die Produktion zu bringen. Es heißt natürlich auch, dass der Weg von der Anforderung bis überhaupt erstmal die Entwicklung davon erfährt und diese Dinge umsetzen kann, auch beschleunigt werden. Das ist natürlich in klassischen Unternehmen auch oft ein sehr langer Weg. Wo dann in Gremien irgendwas entschieden wird und das betrifft den ganzen Weg.

Stefan Tilkov: Ok. Du hast ja gesagt, du möchtest lieber über die organisatorischen Aspekte sprechen als über das Technische. Aber lass uns vielleicht ganz kurz mal vielleicht exemplarisch schildern, wie das denn aussehen würde, wenn man das schon vollständig umgesetzt hätte. Was wäre denn dann das perfekte Tooling und der perfekte Durchlauf einer Anforderung in Produktion?

Oliver Wolf: Ich meine, wir sind ja heute schon glücklicherweise in den allermeisten Organisationen an dem Punkt, dass wir sowas wie Continuous Integration betreiben. Das heißt, wir haben heute schon die Situation, dass Änderungen am Code sehr schnell umgesetzt werden in laufende Software, die getestet wird, so dass der Entwickler eine schnelle Rückmeldung darüber bekommt, ob seine Änderung erfolgreich war, ob er irgendwelche neuen Probleme erzeugt hat usw. Im Prinzip geht’s bei den Techniken und Praktiken der DevOps zunächst mal darum, diese Kette von Verarbeitungsschritten zu erweitern. Zu erweitern über den Test hinaus bis in den Betrieb oder zumindest mal so etwas wie ein Pre-Production. Also ein Staging-System, wo man die Änderung in einer Umgebung, die dem Live-System weitgehend entspricht, sich ansehen kann. Also den Weg von der Änderung einer Codezeile bis hin zu einem laufenden Stück Software in einem Produktionssystem zu automatisieren, das ist im Prinzip das, was da technisch dahinter steht. Das nennt man Continuous Delivery und ist letztendlich einfach nur ein Weiterdenken, eine Weiterentwicklung dessen, was wir technisch heute haben schon.

Stefan Tilkov: Ok, was ist der Unterschied zwischen Continuous Delivery und Continuous Deployment?

Oliver Wolf: Continuous Deployment kann auch ein Deployment sein in Systeme, die noch nicht das Produktionssystem sind. Also Deployment sagt ja nur, ich möchte nicht nur einen Integrationstest ausführen mit dem, was ich da erzeugt habe, sondern ich möchte tatsächlich ein echtes Deployment in eine Laufzeitumgebung haben, wo ich dann Systemtests ausführen kann, mit allen Systemkomponenten dabei. Continuous Delivery geht einfach noch einen Schritt weiter und sagt, das ganze soll eben auch kontinuierlich, mit jeder Codeänderung, automatisiert getestet ausgeliefert werden, also praktisch dem Nutzer zur Verfügung gestellt werden, dem Endnutzer.

Stefan Tilkov: Das heißt, Continuous Delivery geht weiter als Continuous Deployment?

Oliver Wolf: Das ist zumindest meine Interpretation dieser Begriffe.

Stefan Tilkov: Das sollten wir nochmal eruieren, weil ich habe es genau andersrum in Erinnerung.

Oliver Wolf: Aha.

Stefan Tilkov: Das sind aber auch nur Wörter, eigentlich ist es – wir können es nochmal nach gucken, aber eigentlich ist es egal. Also das eine geht sozusagen bis kurz davor und das andere geht tatsächlich in Produktion.

Oliver Wolf: Das, genau.

Stefan Tilkov: Na gut. Wenn ich mir das technisch vorstelle, dann bedeutet das, dass mehr Tests automatisiert durchgeführt werden? Ist das eine richtige Vorstellung?

Oliver Wolf: Absolut. Das ist eine absolut zwingende Voraussetzung. Denn ich habe natürlich, wenn ich diesen Anspruch habe, auch kleinste Änderungen sofort praktisch dem Nutzer verfügbar zu machen, um schnell Feedback darauf zu bekommen, gar nicht die Möglichkeit, große manuelle Tests durchzuführen. Die Zeit ist dann einfach nicht da. Das heißt, hier ist wirklich eine sehr, sehr gute Abdeckung mit automatischen Tests erforderlich, damit das ganze funktionieren kann.

Stefan Tilkov: Wie sieht es mit Integration aus? Bedeutet das, dass Teams parallel an unterschiedlichen Dingen entwickeln, die nachher zusammen integriert werden oder arbeiten alle auf demselben Strang oder wie ist das?

Oliver Wolf: Genau, die Idee ist natürlich, dass alle auf demselben Strang im wesentlichen arbeiten. Also gerade in dieses Verhindern von möglicherweise aufwendigen Integrationsschritten, Merges aus verschiedenen Branches, wo in verschiedene Teams parallel gearbeitet wird, die traditionell erstmal sehr aufwendig sein können, wenn Änderungen groß sind, ist eben genau etwas, was man vermeiden möchte.

Stefan Tilkov: Ok. Und der letzte Bezug, der mir noch einfallen würde, vielleicht kannst du dazu auch was sagen, wäre zum Thema: Automatisierung im Betrieb, also so Infrastruktur-Zeugs und sowas. Wie passt das da noch mit rein?

Oliver Wolf: Das sind eigentlich zwei Aspekte. Das eine ist, dass man natürlich, dass es immer wichtiger wird, wenn man das macht, das z. B. die Konfiguration von Laufzeitsystemen – also sei es virtuelle Maschinen, sei es tatsächlich physische Maschinen – stärker automatisiert werden muss, als heute. Also wir haben ja heute oft die Situation, dass Systemedministratoren in stundenlanger, liebevoller Kleinarbeit irgendwie Systeme konfigurieren. Das ist natürlich etwas, wenn man da das Tempo, das Durchlauftempo erhöhen möchte, einfach nicht mehr möglich ist. Das heißt, man braucht hier eine weitgehendere Automatisierung, um Systeme einzurichten. Da spielen dann so Softwareprodukte wie Puppet, wie Chef natürlich eine Rolle, um diese Dinge zu beschleunigen.

Das andere ist das Thema Monitoring. Also ich möchte natürlich, wenn ich Codeänderungen schnell in Produktion bringe, auch möglichst eine schnelle Rückmeldung darüber haben, ob diese Codeänderung irgendetwas bewirkt hat. Also ob ich möglicherweise dadurch vielleicht die Systemperformance gesteigert habe, ob ich vielleicht irgendwelche Business-KPIs verbessert habe. Ich habe vielleicht eine bessere Durchlaufzeit von Registrierungen, also ich kriege mehr Benutzerregistrierungen in einer bestimmten Zeit. Oder ich habe irgendwelche Verbesserungen an meinem System, die messbar sind. Und das erfordert natürlich, dass ich ein umfangreiches Monitoring zur Verfügung habe, sodass ich überhaupt sehen kann, dass diese Verbesserungen eingetreten sind. Also es geht letztendlich immer bei allem darum, dem Entwickler eine schnelle Rückmeldung darüber zu geben, ob die Änderung, die er durchgeführt hat, den gewünschten Effekt hatte.

Stefan Tilkov: Ok. Damit sind wir eigentlich schon ein bisschen bei dem Punkt, glaube ich: organisatorische Dinge. Was siehst du denn als organisatorische Konzequenzen? Ich überlege, in welcher Reihenfolge ich frage: also was siehst du als Konsequenzen daraus und was siehst du für Herausforderungen dabei? Kannst du jetzt dir selber sortieren, wie du das gerne beantworten möchtest.

Oliver Wolf: Also als Konsequenzen sehe ich in erster Linie natürlich genau das, was ich eingangs gesagt habe, dass Entwicklung und Betrieb eines Systems nicht mehr getrennt sein können. Weil einfach die Komplexität von solchen Hand-offs, wie wir sie heute haben, die dann meist damit einher gehen, dass die Entwicklung umfangreiche Betriebsdokumentation erzeugen muss, dass der Betrieb Systeme abnehmen muss, bevor sie in Produktion gehen können, damit er überhaupt die Verantwortung dafür übernehmen kann, dass er das ganze dann auch betreiben kann. Das sind Dinge, die einfach zu aufwendig sind, wenn man das haben möchte. Das heißt, es muss letztendlich – und das ist dann vielleicht auch schon wieder ein Stück weit eine Herausforderung – ein gewisses Vertrauensverhältnis zwischen Entwicklung und Betrieb bestehen. Wenn wir uns heute anschauen, wie Entwicklung und Betrieb oft organisiert sind, dann – ich denke, das haben wir alle auch schon mal erlebt – dann sind das oft wirklich so zwei Fronten, die sich gegenüber stehen. Weil es einfach auch sehr unterschiedliche Ziele gibt, die im Konflikt stehen. Klar, die Entwicklung hat einfach das Ziel, möglichst viele Features in möglichst kurzer Zeit zum möglichst günstigen Preis zu liefern. Während der Betrieb das Ziel hat, die Systeme am Laufen zu halten. Und natürlich wird jeder Betriebler wird bestätigen, dass sein größter Feind natürlich der Entwickler ist, der durch irgendeine Codeänderung das System in seiner Stabilität gefährdet, was ihm wiederum seinen Job schwerer macht. Und letztendlich muss man natürlich auch sagen, die Betriebler sind im Zweifelsfall diejenigen, die um drei Uhr nachts aus dem Bett geklingelt werden, wenn irgendwas nicht läuft. Und das sind nicht die Entwickler. Und dadurch ist so eine natürliche Feindschaft zwischen diesen beiden Gruppen oft da. Und genau das aufzubrechen, das ist natürlich eine wahnsinnige Herausforderung, weil es eben ja bedeutet, man muss plötzlich mit Menschen zusammenarbeiten, die man bisher immer ein bisschen als Feindbild hatte. Das sind die Leute, die mir das Leben schwer machen, die mir die Arbeit erschweren. Und plötzlich soll ich mit denen an einem Strang ziehen. Eigentlich wäre es naheliegend, das zu tun, weil beide haben das gleiche Ziel, letztendlich. Beide wollen oder sollten zumindest das Unternehmen erfolgreich machen wollen, sollten dafür sorgen wollen, dass das System funktioniert, läuft, im Zweifelsfall Geld verdient, wenn es z. B. ein Internetanwendung ist. Aber genau diese Hürden, diese kulturellen Hürden aufzubrechen, das ist die große Herausforderung. Und da, denke ich, gibt es auch nicht das Pauschalrezept.

Stefan Tilkov: Was sind so Dinge, die Entwickler vom Betrieb denken, die nicht gerechtfertig sind?

Oliver Wolf: Was denken Entwickler vom Betrieb? Also ich kann dir aus der eigenen Erfahrung sagen, ich bin kein Betriebler, ich habe wenn dann eher Entwicklung gemacht und da sind mir Betriebler natürlich immer als die Paragraphenreiter aufgefallen, die immer ganz genau wollten, dass alle Anweisungen befolgt sind, dass auch wirklich im Betriebshandbuch alles drin steht, was da so drin stehen muss, die da auch wenig flexibel und wenig verhandlungsbereit waren. Man kann es verstehen letztendlich, weil sie natürlich irgendwo die Hand dafür ins Feuer legen müssen, dass sie das System betreiben können innerhalb der von der Geschäftführung vorgegebenen Parameter – also Verfügbarkeit, Ausfallzeiten usw. Und natürlich müssen die sich auch absichern, klar. Aber das wirkt natürlich auf den Entwickler sehr betonköpfig.

Stefan Tilkov: Hast du auch die umgekehrte Sicht? Was denkt der Betriebler über den Entwickler und was sind da so richtige oder falsche Einschätzungen?

Oliver Wolf: Also aus meinen Gesprächen mit Betrieblern, ja ist mir schon soweit bewusst, dass natürlich die Entwicklung erstmal als „Das sind die Chaoten”, das sind die Chaoten, die die Dinge einfach so machen, wie sie wollen, die sich an keine Vorschriften halten, die einfach, wenn es irgendwann eng wird mit dem Termin, anfangen zu schludern. Und dann werden irgendwelche, dann wird vielleicht irgendwelches Logging einfach vergessen oder es werden irgendwelche Dinge gebaut, die für den Betrieb einfach schwer handhabbar und schwer verständlich sind. Klar, das liegt einfach daran, dass natürlich der Entwickler nicht in der Situation ist, es tatsächlich betreiben zu müssen. Und sich da rein zu versetzen, wie das vielleicht für einen Betriebler ist, der, sagen wir mal, von Java keine Ahnung hat und plötzlich irgendwie um drei Uhr nachts ein System oder ein Systemausfall nachvollziehen muss und schaut in ein Logfile voller Java-Stacktraces und kann da überhaupt nichts mit anfangen, das fällt dem Entwickler möglicherweise auch sehr schwer.

Stefan Tilkov: Das ist auch so meine Erfahrung, dass der Betrieb häufig halt das Gefühl hat – zu recht oder zu unrecht, das kann ja beides sein – Software geliefert zu bekommen, die einfach nicht betreibbar ist. Die einfach nicht …

Oliver Wolf: Genau, das ist so ein Standardwort: „Das ist nicht betreibbar!”

Stefan Tilkov: Genau, da ist einfach nicht an die rudimentären Dinge gedacht. Ich glaube, Entwickler unterschätzen auf der anderen Seite häufig auch die Komplexität der gesamten Umgebung, um ihre Software drum herum.

Oliver Wolf: Absolut, denn der Entwickler kennt das System, an dem er gerade arbeitet. Das kennt er in- und auswendig. Natürlich, das muss er ja auch. Aber er übersieht vielleicht, dass der Betriebler eben nicht nur dieses eine System betreiben muss, sondern vielleicht eine ganze Fülle von Systemen, die alle unterschiedlich sind, die vielleicht alle unterschiedliche Arten von Logging haben, die alle unterschiedliche Skripte haben, um sie zu starten und zu stoppen. Und das ist natürlich eine Komplexität, klar die lässt sich natürlich auch nur beherrschen, wenn man relativ gut darauf achtet, dass die Entwickler zumindest gewisse Grundanforderungen erfüllen an das, was da geliefert wird, klar.

Stefan Tilkov: Ok. Was ist denn jetzt die Lösung? Also brauchen wir einfach eine dritte Rolle, haben wir jetzt DevOps-Leute, die zwischen Entwicklern auf der einen Seite und Ops-Leuten auf der anderen Seite vermitteln? Oder machen wir die Entwickler zu DevOps-Leuten oder Betriebler zu DevOps-Leuten? Was ist denn jetzt der …

Oliver Wolf: Also in der Tat ist das etwas, was man teilweise sieht. Also gerade so in den letzten zwei Jahren habe ich das öfter gesehen, dass es wirklich sowas wie explizite DevOps-Teams gibt. Insbesondere dann, wenn das Unternehmen vielleicht immer noch diese klassische Trennung hat, weil vielleicht der Betrieb outgesourced ist an irgendeinen Dienstleister. Trotzdem möchte man aber jetzt stärker in diese Richtung gehen, dann gibt es eben möglicherweise ein zusätzliches DevOps-Team, was so eine Art Vor-Betrieb ist, der im eigenen Unternehmen angesiedelt ist und der dann alles, also den Entwicklern gegenüber so tut, als wäre er super agil und super flexibel und im Prinzip die Entwickler von der eigentlichen Operations-Truppe, die irgendwo beim Dienstleister sitzt, abschottet.

Stefan Tilkov: Das ist aber eigentlich ja das genaue Gegenteil von DevOps, oder? Das ist noch viel schlimmer, sowas.

Oliver Wolf: Das ist eigentlich viel schlimmer. Aber es ist vielleicht ein guter Zwischenschritt auf dem Weg dahin. Das könnte ich mir vorstellen, dass man einfach sagt, ab einem bestimmten Punkt kann man vielleicht die Abhängigkeit von dem externen Dienstleister reduzieren, kann den Betrieb wieder vielleicht ins eigene Haus holen oder kann vielleicht auf Cloud-Ressourcen gehen oder sowas und hat zumindest schon mal die grundlegenden Praktiken und Prozesse, die man dafür braucht, das ganze zu beschleunigen, im eigenen Haus. Also ich denke als Zwischenlösung ist das denkbar, als Lösung auf lange Sicht, gebe ich dir völlig recht, ist das erstmal schlimmer als alles andere.

Stefan Tilkov: Ist denn, das ganze im eigenen Haus zu machen, eine zwingende Voraussetzung für DevOps?

Oliver Wolf: Nicht unbedingt, würde ich so nicht sagen. Ich glaube, das Problem ist heute, dass die meisten Hosting-Dienstleister oder Betriebs-Dienstleister einfach da noch nicht angekommen sind. Und dadurch, dass es natürlich die extrem enge Verzahnung mit der Entwicklung mit sich bringt, die natürlich dann auch wieder sehr spezifisch für das jeweilige Entwicklungsvorgehen, das jeweilige Team, das jeweilige Produkt ist, bin ich mir nicht so sicher, ob Dienstleister, wie viel Dienstleister da wirklich übernehmen können. Andererseits ist natürlich der Trend, den wir ja im Moment auch beobachten, dass generell das Ganze etwas weg geht von dedizierten Hosting-Dienstleistern hin zu eher Plattform-as-a-Service (PaaS) oder Infrastructure-as-a-Service (IaaS) Anbietern und dann ist es natürlich naheliegend, dass praktisch diese Fähigkeiten im eigenen Haus aufgebaut werden.

Stefan Tilkov: Ok. Dann lass uns doch vielleicht darüber reden, was denn das Idealbild wäre. Was ist denn die perfekte Organisation, die DevOps schon aktzeptiert hat? Wie sieht die denn aus?

Oliver Wolf: Da gibt es natürlich auch ein ganzes Spektrum von Möglichkeiten. Also es geht so vom einen Extrem – das wäre so diese No-Ops Bewegung, die sagt „Wir brauchen überhaupt keine Operations mehr, das machen alles die Entwickler”. Das heißt auch in erster Linie, die Entwickler sind verantwortlich für den Betrieb, also werden dann nachts um drei aus dem Bett geklingelt, wenn es nicht läuft. Das ist so ein Modell, was z. B. Firmen wie Amazon oder sowas betreiben. Die sagen einfach, wir haben ein Team, das entwickelt eine bestimmte Komponente, und das Team ist kollektiv für den Betrieb dieser Komponente mitverantwortlich. Hat sicherlich den positiven Effekt, dass man als Entwickler ein sehr vitales Interesse daran hat, dass man vernünftige Software baut, klar.

Stefan Tilkov: Weil man sonst nachts um drei geweckt wird.

Oliver Wolf: Weil man sonst nachts um drei geweckt wird, genau. Also ist durchaus ein vernünftiger Ansatz vielleicht, aber sicherlich auch nicht für jede Organisation geeignet, weil es gerade, wenn man sich mal die Situation Deutschland anguckt: wir haben hier Betriebsräte, wir haben hier so Dinge wie Rufbereitschaft. Das ist natürlich alles nicht so einfach durchzusetzen.

Ansonsten, was ich ja auch teilweise sehe, ist, dass die Leute, die bisher für den Betrieb verantwortlich waren, zunehmend ja sich von dem reinen Systembetrieb entfernen und eher in Richtung Automatisierung gehen, dass also praktisch die beiden Seiten so ein bisschen aufeinander zuarbeiten. Das heißt, die Entwicklung tut mehr, um Dinge schon so vorzubereiten, dass sie betreibbar sind. Also Beispiel, aus dem Build-System fallen nicht mehr Jar-Files raus, sondern vielleicht schon fertig verpackte Container, in denen die Applikation drin steckt, die dann im Betrieb nur noch instanziiert werden müssen. Das ist z. B. ein Weg. Gleichzeitig ist es einfach so, dass sich das Aufgabenbild der Operations-Leute insofern ändert, dass sie eben nicht mehr den reinen Betrieb machen, sondern auch zunehmend Automatisierungsaufgaben übernehmen. Einfach Skripting, Einrichtung von Virtualisierungsumgebungen und solchen Dingen.

Stefan Tilkov: Was wir auch schon häufiger gesehen haben, dass man einfach gemischte Teams dann hat.

Oliver Wolf: Genau.

Stefan Tilkov: Dass so ein Team dann einfach ein paar Leute aus der ehemaligen Betriebs- oder der immernoch befindlichen Betriebstruppe zurück bekommt. Oder reinbekommt, damit eben so ein Team einfach aus beiden zusammen gesetzt wird.

Oliver Wolf: Genau, genau.

Stefan Tilkov: Das sich aufeinander zubewegen ist dann glaube ich der entscheidene Punkt.

Oliver Wolf: Das ist der entscheidene Punkt. Genau, das darf natürlich dann nicht irgendwo aufhören, dass man sagt, „Ok, jetzt haben wir immer noch eine Grenze, die ist jetzt einfach nur ein bisschen verschoben.”, sondern natürlich sollte das Fernziel irgendwie sein, dass es im Grunde genommen keinen echten Unterschied mehr zwischen Entwicklern und Operations gibt. Weil letztendlich ist die Aufgabe heutzutage eigentlich die gleiche. Also ich meine, der Operations-Mensch ist ja heute auch nicht mehr derjenige, der irgendwie an der Shell irgendwelche Kommandos eingibt, sondern das ist ja derjenige, der Automatisierung baut und Automatisierung heißt halt effektiv: entwickeln, Software entwickeln. Er entwickelt halt keine Anwendungssoftware, er entwickelt halt letztendlich Skripte, um Systeme zu konfigurieren, aber auch das ist Code, auch das sind Dinge, die entwickelt und getestet werden müssen, wo die gleichen Werkzeuge benutzt werden müssen, wo man Versionsverwaltung hat usw. Also eigentlich ist das technisch nichts anderes mehr.

Stefan Tilkov: Wie denkst du, dass man umgehen sollte, mit solchen Querschnittsaufgaben wie – was weiß ich – den Betrieb der übergreifenden Systemmanagementsoftware oder einer Datenbank, die man übergreifend einsetzt oder Vernetzen oder von anderen Dingen, wenn das jetzt eben teamübergreifend geregelt wird?

Oliver Wolf: Nagut, das ist wieder ein bisschen, da kommen wir ein bisschen wieder zurück in Richtung Softwarearchitektur. Da ist die Frage, wie groß diese Anteile eigentlich in Zukunft noch sein werden. Wenn wir jetzt in Richtung modernerer Architekturen denken, Microservice-Architekturen, da ist es natürlich eigentlich so, dass wir ja versuchen, den Anteil an solchen zentralen, gemeinsam genutzen Komponenten auch zu reduzieren. Wir wollen ja nicht mehr die große Datenbank haben, die alle nutzen, sondern wir wollen ja für die einzelnen Teile, aus denen das Gesamtsytem besteht – ob wir sie jetzt Microservices nennen oder ob wir sie Self-contained systems nennen oder wie auch immer, da gibt es ja verschiedene Begriffe dafür – da sagen wir ja, diese Systeme sollen ihre eigene Datenhaltung haben. Und damit ist das Ganze natürlich auch in der Verantwortung des jeweiligen Teams, das diese Komponente, dieses Teilsystem baut. Und damit wird dann die Notwendigkeit, solche zentralen Systeme zu betreiben, immer geringer. Es wird immer sowas wie ein zentrales Monitoring wahrscheinlich geben, klar. Und es wird auch immer Leute geben, die sich um den Betrieb von Netzwerkinfrastrukturkomponenten kümmern. Aber das ist eine andere Disziplin aus meiner Sicht.

Stefan Tilkov: Ok. Also mit der Datenbank gebe ich dir ja recht. Allerdings ist es ja auch eine – wie soll ich sagen – nicht zwingend nur eine Frage, wie viele Instanzen ich habe, sondern auch eine Skill-Frage.

Oliver Wolf: Na klar.

Stefan Tilkov: Also wie viele Leute möchte ich im Unternehmen haben, die wissen, wie man Oracle table spaces vergrößert? Wahrscheinlich wird das nicht jeder Entwickler jetzt absorbieren dieses Wissen, sondern es wird irgendwie welche wenigen Leute geben, die das übergreifend wissen.

Oliver Wolf: Genau. Aber das hat für mich die gleiche Qualität wie der Betrieb von Netzwerkinfrastrukturkomponenten. Das sind einfach Spezialskills, die ich brauche, um die Infrastruktur am Laufen zu halten, aber das sind dann eben DBAs, die sich z. B. mit der Optimierung von Datenbanken auskennen, die aber nicht unbedingt z. B. auch die fachliche Modellierung machen. Das ist ja oft was, was wir auch in Unternehmen sehen. Da gibt es dann den DB-Admin, denn ich dann als Entwickler irgendwie fragen muss. Im Zweifelsfall muss ich ihm irgendwie ein Ticket einstellen, damit er mir in irgendeiner Tabelle eine Spalte hinzufügt. Das ist natürlich etwas, was völlig diesem Gedanken zuwider läuft.

Stefan Tilkov: Ok. Also man will die Dinge da halten, wo sie am sinnvollsten erledigt werden, um die Wege kurz zu halten.

Oliver Wolf: Genau. Und wo sie fachlich auch einfach hingehören. Denn mit jeder fachlichen Änderung gehen ja möglicherweise auch solche Datenbankänderungen einher, also gehören die in das Entwicklungsteam und nicht in irgendeine separate Datenbankadministrationsgruppe, die im Betrieb angesiedelt ist. Ganz klar.

Stefan Tilkov: Ok. Jetzt nehmen wir mal an, ich bin in einem „normalen” Unternehmen, also ich bin nicht auf der grünen Wiese oder in einem Unternehmen, was vor zwei Jahren oder drei Jahren gestartet hat – wobei das nicht heißt, dass man nicht in drei Jahren auch schon gewaltig Legacy schaffen kann, aber nehmen wir mal an …

Oliver Wolf: Können wir auch ein paar Beispiele nennen.

Stefan Tilkov: Ja, lieber nicht. Nehmen wir an, wir sind in einem klassischen Unternehmen, das hat eher diese typischen Enterprisey-Releasezyklen. So vier im Jahr oder zwei im Jahr von einer großen, wichtigen betriebswirtschaftlichen Software, ein Bestandsführungssystem in einer Versicherung oder so. Wie komme ich denn in einem so klassischen, sehr traditionell organisierten Unternehmen weiter? Was tue ich denn da, wenn ich in diese Richtung möchte?

Oliver Wolf: Also erstmal wahrscheinlich die Hoffnung darauf, dass das Ganze sich schnell ändern wird, fallen lassen. Sondern sich damit abfinden, dass es ein relativ langer Weg sein wird. Aber ich glaube, man kann auch da als Entwicklungsteam, als Entwicklungsabteilung, als was auch immer. Als irgendeine Einheit innerhalb dieser großen Organisation, die sich auf die Fahne geschrieben hat, in Zukunft einfach agiler und schneller zu werden, eine ganze Menge tun. Selbst wenn vielleicht übergreifend ein Releasezyklus von zwei Releases pro Jahr oder sowas vorgegeben ist, spricht ja nichts dagegen, dass man nicht als Team von den Dingen, für die man die Verantwortung hat, durchaus häufiger interne Releases sich vorstellen kann. Und dafür dann auch diese komplette Pipeline aufbauen, um vielleicht auch zu sowas wie einem Continuous Delivery – oder Continuous Deployment, je nachdem wie man es jetzt sehen möchte – zu kommen. Und dann praktisch die Ergebnisse aus dieser Verarbeitungskette zu definierten Terminen rauszunehmen, um dann in diese großen Releases einfließen zu lassen. Damit kann man aus meiner Sicht schon innerhalb einer Organisation ein gewisses Vertrauen darin schaffen, dass diese Dinge funktionieren. Und hat dann aber auch wirklich den argumentativen Zündstoff in der Hand „Guck mal hier. In dem Team funktioniert das. Lass uns doch im nächsten Schritt mal probieren, das vielleicht mal Teamübergreifend über mehrere Entwicklungsteams zu versuchen.” Und ich glaube durch Überzeugen, dadurch, dass man demonstrieren kann, dass es funktioniert, kann man immer mehr bewegen, als durch irgendwelche strategischen Planungen, die am Ende doch nicht eingehalten werden.

Stefan Tilkov: Das setzt natürlich voraus, dass man Dinge hat, die man individuell entwickeln kann. Also wenn das ganze ein riesengroßer Klotz ist, wo alles mit allem verzahnt ist, dann wird es wahrscheinlich relativ schwierig, diesen Weg zu verfolgen.

Oliver Wolf: Ist dann natürlich auch wieder ein Thema der Softwarearchitektur, klar. Ich meine, wenn wir eine monolithische Architektur haben, wo einzelne Teams immer nur Komponenten beitragen, die für sich allein nicht lauffähig sind, die zwangsläufig die Integration mit dem Gesamten brauchen, dann ist es relativ schwierig. Aber in den allermeisten Fällen ist es doch schon so, dass die Dinge, die da raus kommen, irgendwie für sich betrachtet irgendeinen Mehrwert bringen, irgendwie lauffähig sind. Und ich glaube, dann ist das ein guter Weg, einfach zu versuchen, diese Praktiken, diese technologischen Möglichkeiten zu nutzen, damit als Team schneller und besser zu werden und andere zu überzeugen, dass das funktioniert.

Stefan Tilkov: Ok. Jetzt ist es gerade in großen Unternehmen natürlich häufig so, dass es eine sehr stark gewachsene und damit auch leider sehr stark etablierte und starre Produktionsinfrastruktur gibt. Bedeutet das, dass man den Ansatz nicht benutzen kann? Oder kommt man dann trotzdem irgendwie da weiter?

Oliver Wolf: Kommt wahrscheinlich so ein bisschen auf den Anspruch an. Natürlich wird man in einer solchen Organisation auf dem Weg nur sehr, sehr schwer es schaffen, tatsächlich dahin zu kommen, dass Änderungen, die ein Entwickler durchführt, zeitnah in Produktion gehen. Das ist da wahrscheinlich illusorisch. Manchmal ist es ja auch gar nicht möglich, weil es einfach Sicherheitsvorgaben gibt, die das verhindern, weil es vielleicht irgendwie Compliance-Richtlinien gibt, die das verhindern, weil das System irgendwie zertifiziert ist. Irgendwie gibt es da immer Dinge oder in vielen Fälle Dinge, die dem entgegen stehen. Aber auch dann glaube ich, dass das einen echten Nutzen bringt, denn das Ziel muss ja nicht zwangsläufig das Produktionssystem sein. Das ist es natürlich in Internetunternehmen, ist das in der Regel das Produktionssystem, klar, weil da wollen wir schnell das Feedback vom Kunden haben. In anderen Organisationen kann das Ziel auch einfach sein, kontinuierliches Deployment in ein QA-System zu machen. Dass ich einfach schnellere Rückmeldung aus den Systemtests bekomme. Auch das ist schon ein großer Nutzen, denn je kleiner ich die Menge an Änderungen halte, die ich in jedem Deploymentschritt durchführe, desto leichter kann ich Änderungen wieder zurück rollen, desto schneller kann ich feststellen, an welcher Änderung liegt es, wenn das System nicht mehr funktioniert. Das allein ist schon ein großer, großer Nutzen. Ich meine, das was wir mit Continuous Integration ja bezogen auf Unit-Tests und sowas haben, schnelle Rückmeldung darüber, ob ich was kaputt gemacht habe als Entwickler, das trage ich damit eine Stufe weiter und sage: „Ok, jetzt bekomme ich auch die Rückmeldung darüber, ob ich mit meiner Änderung im Gesamtsystemkontext irgendeine Funktionalität vielleicht beeinträchtigt habe durch meine Änderung.” Und das ist, finde ich, ein enormer Nutzen.

Stefan Tilkov: Siehst du auch einen Vorteil für die QA und Testsysteme selbst?

Oliver Wolf: Ja, ich denke schon, weil die – in vielen Organisationen sind die Systeme ja genau wie das Produktionssystem auch relativ starr. Da wird einfach, werden einfach bestimmte Ressourcen im Data-Center für genau diesen Zweck einfach in einer bestehenden Konfiguration mit bestimmter Kapazität fest gebucht und die müssen dann genutzt werden.

Stefan Tilkov: Sechs Monate nach Antrag.

Oliver Wolf: Genau, die müssen dann beantragt werden, das dauert dann alles fürchterlich lange. Da hat man natürlich auch, wenn man diese, wenn man die Automatisierung hier konsequent durchzieht, auch die Möglichkeit, da auch anders zu skalieren. Auch da kann ich z. B. sagen, wenn ich jetzt bestimmte Tests ausführen möchte, für die vielleicht gerade nicht genug Testressourcen zur Verfügung stehen, habe ich vielleicht auch die Chance künftig dafür eigene individuelle Teststrecken aufzubauen. Ich kann vielleicht Cloud-Ressourcen nutzen, um Tests auszuführen. Und damit – ja, ich sag' mal so ein bisschen ketzerisch – an den etablierten Strukturen im Unternehmen vorbei auch solche Dinge auszuführen.

Stefan Tilkov: Man kann es ja positiver formulieren. Also, was du sagst, ist im Prinzip, man könnte das, in diesem Teil könnte man die Dinge machen, weil da tut es keinem weh, da verstößt man nicht gegen Compliance oder gegen andere Sachen, und da ist vielleicht auch das Cloud-Sicherheitsthema nicht so relevant, weil man nur Testdaten hat.

Oliver Wolf: Weil man nur mit Testdaten zu tun hat, genau.

Stefan Tilkov: Ja. Finde ich einen guten Punkt. Ok. Was wären denn Dinge, die ich jetzt persönlich ganz konkret tun kann? Also nehmen wir mal an, unsere Zuhörer sind hochmotiviert, finden das total klasse, wir müssten die eigentlich gar nicht überzeugen. Die haben jetzt die letzte halbe Stunde nur Dinge gehört, die sie sowieso schon total super finden. Was sind denn konkrete Tipps, die wir mitgeben können, wie man sowas im Unternehmen einführen könnte? Bzw. wie man als Entwickler oder als Einzelperson dabei helfen kann, sowas zu machen?

Oliver Wolf: Also als Einzelperson ist es natürlich, hängt es natürlich sehr stark ab von dem, von dem Team, in dem man sich bewegt. Also wie stark da die Vorgaben sind, die letztendlich für die Entwicklung gelten. Ich mein, wenn ich natürlich als einer von hundert Entwicklern in einem großen Unternehmen im Entwicklungsteam bin, dann sind wahrscheinlich meiner Möglichkeiten etwas beschränkter, als wenn ich einer von zehn Entwicklern im Startup-Unternehmen bin. Ganz klar, keine Frage. Ich denke, der erste Ansatzpunkt – ich meine, in jedem Entwicklungsteam gibt es sowas wie interne Testsysteme, die nochmal Stufen vor den eigentlichen QA-Systemen sind, in denen dann irgendwelche Abnahmetests drüber stattfinden. Und ich glaube ein erster Test, wo man damit mal einfach Erfahrung sammeln und probieren kann, ist mal die Strecke einfach von der Änderung einer Codezeile bis in das Deployment, in diese internen Testsysteme zu automatisieren. Weil da kann man die Tools ausprobieren, da kann man Erfahrung sammeln, da kann man sehen, was es bedeutet, das zu tun. Ob man die Komplexität, die damit natürlich erstmal auf den ersten Blick steigt, ob man sich das antun möchte, also ob man den Nutzen darin sieht. Und ich glaube, das ist ein Experimentierfeld, wo man auch als Team in einer etwas konservativeren Umgebung die Freiheit in der Regel hat, das auch wirklich zu machen, ohne dass man sich dafür großartige Erlaubnisse holen muss.

Stefan Tilkov: Ok. Mir fällt im Moment grad nichts mehr ein. Fällt dir noch etwas ein?

Oliver Wolf: Ja, vielleicht ein Punkt noch, den haben wir vorhin so ein bisschen ausgespart. Nicht bewusst, aber das hat sich einfach nicht ergeben. Du hattest ja vorhin gefragt, wie denn eigentlich entwickelt wird. Also, ob man auf mehreren Branches entwickelt oder ob es alles im Prinzip auf dem Trunk, der Mainline des Codes passiert. Eine Konsequenz ist natürlich, wenn man auf der Mainline des Codes arbeitet und nicht auf Branches, wie geht man jetzt damit um, wenn Dinge einfach nicht fertig sind. Das ist ja auch immer so ein Thema. Ich meine, manche Features sind einfach so umfangreich, die kann man nicht jeden Tag oder jede Stunde oder im Zweifelsfall alle paar Minuten deployen, weil sie einfach mehr Zeit brauchen, um fertiggestellt zu werden. Jetzt könnte man sagen: „Ok, für diese Dinge geht man weiterhin auf Branches”, aber das birgt natürlich wieder das Risiko größerer Integrationen, größerer Merge-Konflikte, wenn dann irgendwann der Punkt kommt, das man sagt, Feature ist fertig.

Stefan Tilkov: Das heißt, du findest Feature-Branches, du siehst grundsätzlich ein Risiko in diesen Feature-Branches?

Oliver Wolf: Natürlich, die Erfahrung haben wir denke ich alle schon mal gemacht. Das es einfach, je länger man auf einem Feature-Branch isoliert vom Rest arbeitet, immer aufwendiger wird es, den Merge hinterher durchzuführen. Und immer schwerer absehbar, was dadurch möglicherweise an anderer Stelle für Auswirkungen entstehen. Deswegen ist ein Weg, den Internetfirmen da typischerweise gehen, wirklich Feature-Toggles, Feature-Flags in die Applikation zu integrieren. Also wirklich Flags, in denen im Code abgefragt wird, wenn das Flag gesetzt ist, dann diesen Codeteil ausführen, ansonsten nicht. Meistens eben zentral konfigurierbar. Und damit kann man eben sicherstellen, dass Features, auch wenn sie über einen langen Zeitraum entwickelt werden, auch wenn es auf der Mainline passiert, einfach im Betriebs-, im produktiven System nicht sichtbar werden bis zu einem bestimmten Stichtag, wo man sagt „Jetzt möchte ich das Feature einschalten.” Hat den zusätzlichen Vorteil, dass man diese Features auch selektiv ein- und ausschalten kann, um z. B. A-B-Testing zu machen mit verschiedenen Zielgruppen, verschiedene Implementierungen dieses Features auszuprobieren. Das ist eben auch in vielen Fällen eine sehr praktische Sache. Und mit anderen Arten einfach schwer zu realisieren.

Stefan Tilkov: Ok. Das heißt, mit dem A-B-Test meinst du, man würde im Prinzip für eine eingeschränkte Benutzergruppe das Ganze machen.

Oliver Wolf: Genau, genau.

Stefan Tilkov: Um einfach mal auszuprobieren, wie das Ganze funktioniert, was natürlich auch wieder Auswirkung auf die Art der Softwareentwicklung hat, weil ich dann damit umgehen können muss, dass das Feature gleichzeitig in einem Teil aktiv und in einem anderen Teil inaktiv ist.

Oliver Wolf: Absolut.

Stefan Tilkov: Ja. Was im Prinzip zeigt, dass das Ganze Auswirkungen eben nicht nur auf den Prozess an sich hat, also die Software bleibt nicht unverändert, weder von der Architektur noch von den Interna her.

Ich weiß nicht, ob man den Hund sehr laut hört oder nicht. Das werden wir nachher merken.

Hast du zum Abschluss noch ein paar Hinweise, womit man starten könnte, wenn man sich mit dem Thema näher beschäftigen möchte?

Oliver Wolf: Ja, also ein guter Tipp ist auf jeden Fall das Buch von Jez Humble zum Thema Continuous Integration, äh zum Thema Continuous Delivery. Das gibt es schon ein bisschen länger, ist aber immernoch so das Standardwerk eigentlich in dem Bereich, wo er wirklich sehr gut die komplette Delivery-Pipeline beschreibt, wie man das aufbauen könnte. Das ist auf jeden Fall ein guter Tipp. Es gibt mittlerweile auch ein deutsches Buch zum Thema von Eberhard Wolff. Wer das lieber auf deutsch lesen möchte. Ich habe es selber noch nicht gelesen, aber …

Stefan Tilkov: Ich habe es gelesen.

Oliver Wolf: … denke, es wird gut sein.

Stefan Tilkov: Ich finde es gut.

Oliver Wolf: Ansonsten gibt es natürlich zu dem Thema massenweise Blogs, was auf jeden Fall immer sehr interessant ist, das gilt ja generell auch für Architektur aber auch für das Thema DevOps, so die Erfahrungsberichte der verschiedenen Internetunternehmen. Und da gibt es von Flickr, von Etsy, von wem auch immer in deren Technology-Blogs Beschreibungen, wie sie das machen. Und da finde ich, kann man immer sehr viel raus lernen und auch für die eigene Situation ableiten.

Stefan Tilkov: Alles klar. Gut, Oli, vielen Dank!

Oliver Wolf: Gerne.