Interview mit Kurt Bittner

„DevOps verändert die Bedeutung des Wortes Release“

Coman Hamilton

© Shutterstock.com/VoodooDot

Im Gespräch mit Kurt Bittner vom Marktforschungsunternehmen Forrester Research konnten wir einige faszinierende Einblicke in aktuelle Veränderungsprozesse innerhalb der DevOps-Welt gewinnen.

JAXenter: Kann DevOps die Sicherheit tatsächlich verbessern?

Kurt Bittner: Hier spielen gleich mehrere Punkte eine Rolle. Zunächst einmal ist es hilfreich, wenn man DevOps als „Dev plus Ops“, also als ein Zusammengehen von Dev und Ops, das die Performance und die Zusammenarbeit beider verbessert, versteht. Beim Thema Sicherheit hatten wir mit einer ähnlichen Problemlage zu kämpfen: Dieser Bereich lebte sozusagen abgekapselt in seiner eigenen Welt: Zunächst ist er weder mit der Entwicklung noch mit dem Betrieb besonders gut verzahnt. Zudem nutzen Sicherheitsleute meist andere Tools als die, die in den Bereichen Entwicklung und Betrieb zum Einsatz kommen, ja in einigen Fällen verraten sie noch nicht einmal, welche Tools sie überhaupt nutzen. Fakt ist jedoch, dass die Sicherheit von einem schnelleren Feedback genauso profitiert, wie dies beispielsweise im Bereich Kundenerfahrung der Fall ist. Das konstante Testen des Codes gegenüber bekannten Sicherheitsbedrohungen ist für eine Risikoeinschätzung essentiell. Je besser man das in die automatisierte Pipeline integriert, desto einfacher sind potentielle Sicherheitslücken sichtbar.

Wird das Scannen des Codes nach Fehlern in die Pipeline eingebaut, sucht man unentwegt nach Programmierfehlern. Es gibt aber noch mehr zu beachten, so ergeben sich etwa viele Sicherheitsbedrohungen aus ungepatchten Schwachstellen: Die Patches sind zwar vorhanden, da alles von Hand erledigt wird, kommt der Betrieb mit der Aktualisierung des Systems jedoch nicht hinterher. Mit den Möglichkeiten, die eine automatisierte Verwaltung eröffnet, können die Systeme hingegen jederzeit auf dem neuesten Stand gehalten werden; in diesem Fall ist es einfach Teil der normalen Lieferprozesse.

Es ist also eine Kombination verschiedener Techniken. Der erste Schritt besteht jedoch darin, dass sowohl Dev und Ops als auch die Sicherheit miteinander reden und realisieren, dass sie ein gemeinsames Ziel haben: Eine gute Kundenerfahrung.

JAXenter: Und das ist natürlich eines der Dinge, die DevOps so gut kann: Neue Kommunikationskanäle eröffnen …

Kurt Bittner: Ja. Aber Reden alleine reicht nicht, vielmehr spielen ganz spezifische Praktiken eine wichtige Rolle.

JAXenter: DevOps hat sich in der IT langsam aber sicher zu einem Mainstream-Konzept entwickelt. Was tut sich in dem Bereich den aktuell?

Kurt Bittner: Wir können in Organisationen ein gestiegenes Interesse an DevOps und dessen Durchdringung beobachten. Besonders in den Cloud- und Mobile-Bereichen vieler Organisationen sind seine Praktiken weit verbreitet. Die CIOs sehen diese schneller liefernden Teams und wünschen sich, dass auch andere Bereiche derart arbeiten. Außerdem sehen sie sich einer gestiegenen Gefahr durch Mitbewerber gegenüber, und die Kunden stehen vor einer deutlich größeren Auswahl an Service- und Produktanbietern. Etwas überspitzt formuliert: Viele CIOs werden von der Angst getrieben, dass ihre Firma zu langsam liefert und die Qualität zu schlecht ist. Soviel zur negativen Sichtweise.

Andere sehen die Sache deutlich positiver. Entwickler wollten eigentlich schon immer auf Augenhöhe im Geschäftsablauf mitmischen, wirklich etwas beitragen. Mit 12-monatigen Lieferzyklen ist das sehr schwer, jetzt wo sie jedoch nur noch einen Monat (oder noch weniger) umfassen, beginnt sich dieser Umstand zu ändern.

JAXenter: Und das ist noch etwas, das sich zur Zeit ändert: Die Bedeutung des Wortes „Release“.

Kurt Bittner: Ganz genau. Hier spielen mehrere Aspekte eine Rolle. Wenn man sich die wirklich fortschrittlichen Unternehmen ansieht, so stellt man fest, dass diese ständig etwas veröffentlichen. Allerdings veröffentlichen sie API-Änderungen oder neue APIs. Mit der Zeit addieren sich diese Änderungen und machen beispielsweise ein neues Feature möglich. Traditionellerweise beinhaltete die Idee eines Release immer, dass die Software dem User neue Funktionen zur Verfügung stellt.

Die schnelleren Releasezyklen, die modularere Architektur und Dinge wie Microservices erlauben es jedoch, diese Verbindung aufzuheben. Anstatt an ein technisches Software-Release-Event gebunden zu sein, kann das Zu- und Abschalten von Features nun vermehrt auf den Nachfragezyklus des Unternehmens abgestimmt werde.

JAXenter: Häufig werden die Begriffe DevOps und Continuous Delivery synonym verwendet. Wo liegt Ihrer Ansicht nach der Unterschied zwischen DevOps und CD?

Kurt Bittner: Ich betrachte DevOps als ein philosophisches Konzept, das besagt, dass Dev und Ops zusammenarbeiten sollten. Allerdings ist es eher unspezifisch und vage wenn es darum geht, wie das tatsächlich erreicht werden soll. Es ist also eher ein Oberbegriff für viele verschiedene Praktiken und Aktivitäten. Der Begriff Continuous Delivery hingegen umfasst eine sehr spezifische Sammlung von Praktiken, die sich hauptsächlich darum drehen, eine automatisierte Delivery Pipeline zu erhalten, sowie Prozesse und Tools, die die Lieferung von Software unterstützen.

Einige Aspekte von DevOps bewegen sich allerdings – vielleicht – außerhalb von CD, wie etwa der Wert von Pizza-und-Bier-Treffen, bei denen die Leute miteinander reden. Auch wenn das wichtig ist, spricht man bei CD über sehr spezifische Dinge. Gewöhnlicherweise mündet ein von CI angestoßener Prozess mindestens in einer Stage-Test-Umgebung, wenn nicht gar in der Produktion.

JAXenter: Manch einer hier auf der Jenkins User Conference ging sogar so weit, einen „NoOps“-Ansatz zu propagieren. Können Sie damit etwas anfangen?

Kurt Bittner: Ganz allgemein gesprochen: Ja, in dem Sinne, dass Ops aufhört als separate Organisation zu existieren. Betrachten wir doch einmal, was dem Betrieb in der Vergangenheit alles zugewiesen wurde: die Verantwortung dafür, dass Maschinen, Netzwerke und Anwendungen laufen, manchmal auch für die Infrastruktursicherheit (auch wenn das mittlerweile ein eigenständiger Bereich ist). Manche Organisationen haben gar keine Leute, die sich um die Maschinen kümmern, weil sie auf Cloudlösungen von Drittanbietern zurückgreifen. Man muss diese Umgebungen allerdings immer noch bereitstellen, man muss sie immer noch verwalten und man muss immer noch Software in ihnen deployen

NoOps suggeriert, dass diese Verantwortlichkeiten auf das Lieferungsteam übergehen. Und ich nutze statt „Entwicklungsteam“ explizit diesen Begriff, weil ein „Lieferungsteam“ für die Lieferung neuer oder die Änderung bestehender Funktionen verantwortlich ist. Und sie haben einige Ops-Verantwortlichkeiten über Umgebungen, deren Verwaltung und Konfiguration. Nehmen wir einmal an, Sie nutzen eine interne Cloud, haben irgendwo eine Art von Rechenzentrum und einen ganzen Haufen Infrastruktur – wenn Sie sich virtuellen Maschinen und später Containern zuwenden, sehen diese Ops-Leute eigentlich nie, was sich in der Anwendung befindet.

Sie sind lediglich dafür verantwortlich, dass die Infrastruktur läuft, genauso wie es in einer Stadt Leute gibt, die zwar für die Brücken und Straßen, nicht jedoch für die darauf fahrenden Autos und Lastwagen zuständig sind. Ich denke, diese Art der Aufteilung wird sich bezahlt machen. Und ich glaube, Leute, die die Serverfarmen am Laufen halten, werden definitiv gebraucht. Aber diese können sich auch außerhalb der Organisation befinden und müssen nicht wirklich verstehen, was innerhalb der Anwendungen vor sich geht. Genau wie bei Transportwegen in einer Stadt sehen sie ich lediglich den Workload und den Traffic an.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

JAXenter: Wie werden Unternehmen durch CD wettbewerbsfähiger?

Kurt Bittner: Wie das Marc Andreessen zugeschriebene Zitat besagt: „Software is eating the world“. Mehr und mehr Produkte und Dienstleistungen stützen sich auf die ein oder andere Art auf Software: Sei es über ein Customer Interface, mobile Anwendungen, Cloud-Anwendungen oder durch Einbettung in das Produkt selbst.

Ich würde sagen ein Extrembeispiel hierfür sind die Autos von Tesla Motors, da hier tausend Dinge, wie etwa Energieverteilung und -verwaltung, Beschleunigung, Bremsen und Customer Experience über Software gesteuert werden können. Wenn diese durch Software ermöglichten und durch Software definierten Produkte in der Industrie mehr und mehr um sich greifen (mittlerweile gibt es ja bereits recht banale Dinge wie die Thermostate von Nest und Honeywell, die Software einsetzen, um eine bessere Leistung zu erbringen), so wird Lieferung von Software immer wichtiger. Etwas genauer gesagt: Die Produkte, die direkt mit dem Kunden interagieren verleihen einem die Fähigkeit zu verstehen, was dieser tut.

Kontext, Leistung, Zufriedenheit: Misst man diese Werte, kann man seine Produkte besser auf die Bedürfnisse des Kunden abstimmen, was wiederum für eine höhere Kundebindung sorgt. Je schneller man dieses Feedback nutzt, desto höher ist der Wettbewerbsvorteil, den man gegenüber seinen Mitbewerbern hat.

Kurt Bittner is a leading expert on Agile and iterative software development approaches, including application life-cycle management (ALM). He focuses on the organizational and cultural shifts necessary to extract broader business value from software development processes.

Aufmacherbild: Gear icon von Shutterstock / Urheberrecht: VoodooDot

Verwandte Themen:

Geschrieben von
Coman Hamilton
Coman Hamilton
Coman was editor of JAXenter.com at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous websites and magazines, as well as several ad agencies.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: