Interview mit Jeff Sussna

„Bei Continuous Delivery geht es nicht darum, immer schneller Schrott abzuliefern“

Lucy Carey
Jeff Sussna

Im Zentrum der DevOps-Kultur steht die verbesserte Zusammenarbeit zwischen Entwicklern und Betrieb einer Software. Soweit diese theoretische Stoßrichtung auf allgemeine Zustimmung treffen dürfte, gibt es in der Praxis doch Unklarheiten darüber, wie DevOps konkret in ein Unternehmen eingeführt werden kann. Jeff Sussna, DevOps-Experte und Gründer von Ingineering.IT, verrät uns, welche Fehler man bei der Einführung von DevOps vermeiden sollte und wie PaaS, Continous Delivery und Lean-Methoden helfen können.

Was sind Ihrer Ansicht nach die größten Herausforderungen in der „DevOps“-Kultur?

Jeff Sussna: Ich glaube, die Herausforderungen von DevOps ähneln denen des sogenannten Design Thinking. Beides sind allgemeine Ansätze oder Weltanschauungen und keine strikten Methodologien. Beide stehen für einen Wandel – weg von Unternehmen, die auf industrieller Arbeitsweise basieren. Leider neigen immer noch viele dazu, diese Ansätze wie Vorschriften zu behandeln, die man einfach wie am Fließband befolgen kann. In Wirklichkeit sind es aber Herausforderungen für unsere Art zu denken.

Ich glaube auch, dass die Herausforderungen bei DevOps sich verändert haben. Inzwischen ist es nicht mehr so sehr die Frage, worum es dabei geht, sondern wie man einen DevOps-Ansatz konkret umsetzen kann. Je populärer der Begriff wird, desto stärker wird aber der Druck von Seiten der Hersteller, der Händler und der Kommentatoren, dass man ihn wieder an die alten Denkmuster anpasst.

Jeff Sussna ist Gründer von Ingineering.IT, einem Consulting-Unternehmen mit Fokus auf Continuous Delivery, Cloud Computing und Design Thinking. Jeff Sussna verfügt über mehr als 20 Jahre Erfahrung in der IT-Branche und war Leiter verschiedener High-Performance Teams aus dem Dev/QA/Ops-Spektrum. Er ist gefragter Sprecher auf internationalen Konferenzen und wurde vom BizTech-Magazin als einer der Top 50 Must-Read IT-Blogger ausgezeichnet. Seine Interessen liegen bei der Integration von Entwicklung, Betrieb, Desing und Business.

Gibt es in der Praxis irgendjemanden, der auf exemplarische Art und Weise eine gute Arbeitskultur für DevOps etabliert hat?

Jeff Sussna: Als ich das Wort DevOps das erste Mal hörte, arbeitete ich gerade für ein SaaS-Startup. Meine erste Reaktion war: „Naja, wie soll man’s auch sonst machen?“ In Startups kümmert sich jeder um den Kunden, ganz einfach, weil man es tun muss. Jeder interessiert sich dafür, ob der Code stimmt oder ob die Infrastruktur funktioniert, weil sie gar keine andere Wahl haben.

Dev und Ops arbeiten Seite an Seite, was manchmal so weit geht, dass sie nebeneinander im Büro übernachten. Alles fängt mit dem Gefühl an, dass man sich auf einer gemeinsamen Mission befindet und entsprechend Verantwortung übernimmt.  In unternehmensweiten Mikro-Service-Architekturen kann DevOps hilfreich sein, da große monolithische Silos in kleinere und kohärentere Service-Teams aufgegliedert werden können,  die ein gemeinsames Gefühl für den Kundenservice haben – oder für andere Teile des Unternehmens.

Wenn wir die andere Seite der Medaille betrachten, was sind die größten Fehlerquellen, die IT- Unternehmen bei der Einführung einer DevOps-Kultur machen können?

Jeff Sussna: Leider ist diese Frage sehr leicht zu beantworten. Der größte Fehler, den ein IT-Unternehmen machen kann, ist zu versuchen, das Problem mittels einer restriktiven Methodologie oder einem großen, teuren All-in-One-Tool zu lösen. Mit dieser Vorgehensweise übersieht man leicht den kritischen Teil, nämlich das Gefühl des Einzelnen, Teil einer gemeinsamen Sache mit entsprechenden Verantwortungen zu  sein.

Dennoch gibt es ja auch DevOps-Tools – sind diese empfehlenswert?

Jeff Sussna: Ich empfehle jeder Organisation bei der Einführung von DevOps mit Vagrant anzufangen. Entwickler, Tester, Administratoren – alle sollten es verwenden. Es ist ein extrem einfach zu verwendendes Tool  mit einer Art Verstärkungseffekt, der dazu führt, dass Entwickler und Admins auf die gleiche Art und Weise über die gleichen Probleme denken. Außerdem hilft es bei der Automatisierung und dabei, dass die Continous-Delivery-Reise am richtigen Punkt beginnt: auf dem Desktop der Teammitglieder.

Was ist für Sie das Entscheidende beim Lean-Ansatz?

Jeff Sussna: Lean ist ein extrem weitreichendes Feld, und ich will gar nicht erst versuchen, hier irgendwelche allumfassenden Antworten zu geben. Für mich bedeutet Lean, kontinuierlich zu versuchen, den Kundennutzen zu maximieren und alle Hindernisse auf dem Weg dahin zu beseitigen. Hindernisse können in der Form von überflüssigen Prozessen auftreten, z.B. manuelle Sign-offs, die mehrere Tage bis zur Fertigstellung brauchen. Zeitverschwendung und überflüssiger Energieaufwand, ohne dem Kunden den Mehrwert zu verdeutlichen, kann dabei aber auch eine Rolle spielen.

Was waren für sie die lehrreichsten Erfahrungen, die ihnen geholfen haben, eine „Lean-Mentalität“ zu entwickeln?

Jeff Sussna: Meine lehrreichste Erfahrung hatte mit dem Integrieren von Sicherheits-Tests in einen Continous-Delivery-Prozess zu tun. Anstatt drei Monate zu coden und dann eine langwierige Sicherheitstestphase mit mehrstufigen Test-fail-fix-Zyklen zu durchlaufen, checkten wir die Sicherheit bei jedem Check-in des Codes. Bei der anschließenden von der Regierung vorgeschriebenen Sicherheitsüberprüfung war unsere Anwendung die erste, die auf Anhieb durchkam. Der vorherige Mehraufwand war minimal, und die späteren Vorteile waren gewaltig. Und was vielleicht noch wichtiger war: Unser Ansatz löste die ansonsten eher feindselige Beziehung zwischen Sicherheitsabteilung und den Entwicklern auf.

Auf Ihrem Blog haben Sie geschrieben, dass Sie es gerne hätten, wenn PaaS-Anbieter anders auftreten. Was meinen Sie damit?

Jeff Sussna: Rein prinzipiell bin ich schon seit langem ein Fan von PaaS. Ich glaube aber, dass die Diskussion ein wenig erwachsener werden muss. Im Moment geht die Tendenz in die Richtung, einen Gegensatz zwischen Devs und Ops heraufzubeschwören: „PaaS befreit die Entwickler von den Sysadmins.“ Was mich zuerst an PaaS reizte, war die auf meinen Erfahrungen beruhende Vorstellung, dass PaaS Vorteile für beide Seiten hat, weil es den Entwicklern einen Freiraum in einem sicheren, berechenbaren Umfeld  bietet. Ich würde gerne konkrete Diskussionen darüber sehen, wie PaaS Vorteile für alle, die mit IT-Dienstleistungen zu tun haben, schaffen kann.

Continuous Delivery wird mehr und mehr zu einer neuen Norm – wie können Unternehmen ihre Leistungsfähigkeit in diesem Bereich noch weiter ausbauen?

Jeff Sussna: Auf jeden Fall sollten sie sicherstellen, dass sie die Schlüsselmerkmale von Continuous Delivery verstehen: Kleinerer Lieferumfang, ausfallsichere und entkoppelte Releases. Bei Continuous Delivery geht es nicht darum, immer schneller und mit immer weniger Kontrollen Schrott abzuliefern. Es geht darum, die Qualität zu verbessern, indem man Komplexität reduziert. Es ist leichter, den Code einer einzigen Zeile zu überprüfen, die Integration zu testen und Produktionsprobleme zu diagnostizieren, als bei tausend Zeilen Code.

Ironischerweise verbessert Continuous Delivery die Geschwindigkeit, weil die Fehler zu einem früheren Zeitpunkt im Lebenszyklus eines Produkts auftreten. Je früher man die Probleme findet, desto schneller, leichter und billiger ist es, sie zu fixen. Continuous Delivery gibt einem Unternehmen mehr Kontrolle, nicht weniger, weil man Dinge wie Feature-Flags hat. So kann die IT technische Releases durchführen, während die Marketing-Leute entsprechend die Kunden-Releases machen, wenn sie den Zeitpunkt für richtig halten.

Vielen Dank für dieses Gespräch!

Interview zuerst erschienen auf JAXenter.com, Übersetzung: Selim Baykara

Geschrieben von
Lucy Carey
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: