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

Logo_25th-floor

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":

Buchcover Scrum-Think big
Mehr Formate
Bücher
Skalierung
Boris Gloger
March 22, 2017

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4