Die Rolle von DevOps in der Skalierung - Interview mit Andreas de Pretis

Andreas de Pretis ist Gründer und Geschäftsführer der 25th-floor GmbH, einem agilen IT-Dienstleister in Wien. 25th-floor ist seit einiger Zeit in der österreichischen IT-Szene als Spezialist für DevOps bekannt. Andreas betreut seit Jahren die Infrastruktur von borisgloger consulting und er hat für "Scrum Think b!g" einen Gastbeitrag beigesteuert.Boris: Andreas, wie lange gibt es 25th-floor schon und was bietet ihr an?Andreas: Ich bezeichne mich selbst gerne als spezialisierten IT-Allrounder mit einer Leidenschaft für alles rund um Operations, Infrastruktur und Software-Entwicklung. Nach nunmehr fast 19 Jahren in der Branche kann ich auf ein breites Spektrum an Erfahrungen in diversen Positionen und Rollen zurückblicken - vor allem natürlich in meinem eigenen Unternehmen. Die 25th-floor GmbH haben wir Anfang 2004 nebenberuflich gegründet, seit Ende 2005 bin ich “all in”. Seitdem entwickeln wir Individualsoftware und Produkte für unsere Kunden und betreiben diese großteils auf eigener Infrastruktur in Wiener Rechenzentren. Die Wartung und Weiterentwicklung unserer Infrastruktur ist, neben meiner Tätigkeit als Geschäftsführer, nach wie vor mein Job - was sich dank eines hohen Grades an Automatisierung recht gut vereinbaren lässt. Vor allem DevOps - noch bevor das Kind um 2009 herum einen Namen bekam - leben wir eigentlich schon immer, da es für uns die logische Konsequenz der agilen Entwicklung war. Beides ist deshalb bei uns ganz tief in der Firmen-DNA programmiert.Boris: Was hat sich in der IT in den letzten Jahren verändert?Andreas: Das ist gar nicht so leicht zu beantworten, da unsere Branche bekanntermaßen so schnelllebig ist wie keine andere. Das alles zu beleuchten würde wohl den Rahmen dieses Interviews sprengen. Fakt ist, dass große Unternehmen heute nicht mehr um Themen wie Cloud-Computing (egal ob Public, Private oder Hybrid), Automatisierung auf allen Ebenen, mobile Arbeitsplätze, verteilte Teams, agilen Mindsets und Methoden, neuen Arbeitswelten und schlankeren Prozessen herumkommen.Ein Beispiel möchte ich aber doch konkret herausziehen: Open Source in der IT. Obwohl Open Source und auch der Einsatz in Konzernen nichts neues mehr ist, merke ich doch, dass es in letzter Zeit massive Bewegungen in diese Richtung gibt. Kein Unternehmen kommt heutzutage mehr ohne Open Source Software, Bibliotheken, Utilities & Tools aus und immer mehr erkennen den Mehrwert angestammter Free and Open Source Software (FOSS) Projekte gegenüber schwerfälligen “Enterprise”-Systemen. Dazu kommt, dass schon seit geraumer Zeit viele sehr große Unternehmen in die Weiterentwicklung von FOSS investieren, ihr eigenes Know-how einbringen, die Entwicklung vorantreiben oder eigene Frameworks und Technologie unter Open Source Lizenzen stellen.Neben Software betrifft das auch Hardware (Open Hardware, Open Compute Project uvm.). Selbst Microsoft hat sich unter der Führung von Satya Nadella hier massiv gewandelt und gilt mittlerweile als der größte Contributor auf GitHub. Facebook, Google, Spotify, Netflix & Co zählen ebenfalls zu den Top-Mitspielern bei der Entwicklung und Veröffentlichung von Frameworks, Libraries und Tools unterschiedlichster Art.Als EntwicklerIn kann man sich nur freuen, aus dem Vollen schöpfen, sich idealerweise selbst einbringen und auf die Schultern von Giganten stellen. GitHub hat mit seiner Plattform definitiv einen Bärenanteil an der Entwicklung der letzten Jahre.Boris: Ich bin der Meinung, dass die Infrastruktur für den Erfolg eines skalierten Projektes wesentlich ist. Siehst du das auch so?Andreas: Da kann ich dir nur voll und ganz zustimmen - und zwar die Infrastruktur auf allen Ebenen: angefangen bei Räumlichkeiten, Ausstattung des Arbeitsplatz, Kommunikation und Zusammenarbeit, Prozessen, Bürokratie bis hin zur Technik und natürlich im IT-Umfeld. Die Infrastruktur muss die Menschen im Unternehmen unterstützen, ihnen helfen, sich auf ihre Aufgaben zu fokussieren, Informationen schnell auszutauschen und Prozesse effizient abzuwickeln. Leider stehen die internen Richtlinien vieler Unternehmen dem oft noch im Weg. Meiner Meinung nach muss Infrastruktur v.a. in großen Projektorganisationen zu einem Gutteil wieder “demokratisiert” werden: Man sollte weniger Wert auf den leider oft schwerfälligen Enterprise-Charakter legen und stattdessen die MitarbeiterInnen einbeziehen und den jeweiligen Kontext berücksichtigen.Wichtig ist dabei, nicht zu vergessen, dass sich die Infrastruktur ebenso flexibel und rasch weiterentwickeln kann. Eine Blaupause, die vor Jahren einmal abgesegnet wurde, kann nicht für immer gelten. Hier sorgen vor allem veraltete Software-Versionen, Plattformen und Stacks für hohe Workaround-Kosten und einschränkende Arbeitsbedingungen.Boris: Wie wichtig ist aus Deiner Sicht kontinuierliches Liefern?Andreas: Aus meiner Sicht ist kontinuierliches Liefern nicht nur wichtig, sondern heutzutage unerlässlich. Wer am Markt bestehen will, kommt gar nicht umhin, ständig zu liefern und dementsprechend rasch und flexibel auf Veränderungen reagieren zu können. Abgesehen davon ist User-Feedback das Um und Auf, um in weiterer Folge die richtigen Entscheidungen treffen zu können. Schnelles und kontinuierliches Liefern ist ja dank agiler Software-Entwicklung eigentlich nichts Neues und auch in großen Strukturen keine Wissenschaft mehr. Aktuell gewinnt das Thema durch den Digitalisierungs-Hype, extrem agile disruptive Startups und die Geschwindigkeit der Großen in der Branche endlich an Fahrt, auch in massiven Softwareprojekten und Konzernstrukturen. Liefer- und Releasezyklen von mehreren Monaten bis zu einem Jahr oder darüber hinaus können von keinem CEO mehr hingenommen werden.Boris: Du hast mir mal von einem neuen Paradigma erzählt: Das neue Paradigma: “Infrastructure as a Service. Kannst du kurz erläutern, was sich darunter verbirgt?Andreas: Das muss schon eine Weile zurückliegen, dass ich dir davon erzählt habe. Neu in dem Sinne ist das nämlich nicht. Wenn man so will, ist “Infrastructure as a Service” (IaaS) das Fundament der Cloud und hat schon einige Jahre am Buckel. Den Anfang hat 2007 Amazon mit seinem EC2 Service gemacht. Mit deiner Frage beziehst du dich aber vermutlich auf “Infrastructure as Code”, die Automatisierung von Server-Konfigurationen bzw. der gesamten Server-Infrastruktur inkl. Umfeldsystemen den gesamten Lifecycle betreffend - ein wichtiger Aspekt v.a. hinsichtlich DevOps.Sämtliche Systemparameter, Abhängigkeiten, Konfigurations-, Installations- und Deployment-Schritte werden dabei nur noch als Code abgebildet und gescriptet. Es gibt dafür bereits einige sehr gute und erprobte Systeme, die auch mit Enterprise-Support ausgestattet sind. Ein Vorteil daran ist, dass das Setup ganzer Server und Laufzeitumgebungen sehr einfach versioniert, testgetrieben entwickelt und in einer Deployment-Pipeline mit einem CI-System abgebildet werden kann. Ein unerlässliches Werkzeug, wenn die Bereitstellung neuer Systeme nicht mehr Monate, sondern Tage oder Stunden dauern soll oder Teams auch für die eigene Infrastruktur verantwortlich sind.Das Thema hat in den letzten zwei Jahren durch Docker und die Renaissance von Container-Virtualisierung noch eine ganz neue Dimension bekommen und an Dynamik gewonnen. Laufzeitumgebungen für Applikationen werden nicht mehr klassisch eingerichtet und konfiguriert, sondern als Ganzes an mehr oder weniger “dumme” Server-Umgebungen ausgeliefert. Die Applikation oder das (Micro)Service bringt in sich alles mit, was sie braucht, um korrekt zu funktionieren. Dabei kann gleichzeitig eine Dev-Prod-Parity, die Gleichheit zwischen der Entwicklungs- und Produktionsumgebung (mit allen Schichten dazwischen), hergestellt werden. Ein sehr spannendes Thema, mit dem ich mich seit geraumer Zeit intensiv auseinandersetze.Zusammenfassen lässt sich das wohl am besten mit: Make deployments boring again!Boris: Was würdest du Kunden empfehlen, die beginnen wollen eine Continuous Delivery Pipeline aufzubauen. Womit starten sie am besten?Andreas: Der erste und wichtigste Tipp ist, Continuous Delivery nicht als rein technischen Aspekt zu sehen und nicht mit Continuous Integration oder v.a. Continuous Deployment zu verwechseln. Letztere sind lediglich ein Teil von Continuous Delivery. Was die ersten Schritte betrifft, gilt wie so oft: Man muss einfach mal damit beginnen und die entsprechenden (Pilot-)Teams mit den nötigen Ressourcen, Kompetenzen und Freiheiten ausstatten. Wenn die organisatorischen Rahmenbedingungen geschaffen wurden, die Teams und die Menschen in den Teams wieder ermächtigt wurden, eigene Entscheidungen zu treffen und für die Lieferungen auch die Verantwortung zu tragen, dann sind Technik, Automatisierung und die dafür nötigen Skills keine Raketenwissenschaft mehr. Wie so oft gilt: zuerst die Menschen, dann die Prozesse, dann die Tools.Boris: Vielen Dank für das interessante Gespräch.Andreas: Gerne, vielen Dank für die Einladung.Wer mehr über die notwendigen Tools und die Infrastruktur zur Skalierung von Scrum und agilen Projekten lesen will, findet Andreas’ Beitrag hier und in meinem neuesten Buch "Scrum Think b!g - Scrum für wirklich große Projekte, viele Teams und viele Kulturen":