die devops-bewegung

DevOps

magazinJava • Architekturen • Web • Agile www.javamagazin.de

CD-INHALT

CDinkl

.JAVA

Mag

NIO2Erweiterungen der I/O-Funktionalität 27 Erste Sessions ab Seite 43

Open Source BPM: Tools und Strömungen 86

1.2012

Product Line Engineering mit OSGi Ein sinnvolles Paar? 105

Alle CD-Infos ab Seite 3

Entwicklung und Betrieb zusammen-bringen 32, 41

HIGHLIGHT

Cucumber-chef v1.0.4-0ChameRIA 1.5.0jBPM 5.1.0.Final

WEITERE INHALTE

• H-Ubu• Apache POI 3.8 beta 4• Activiti 5.8

DEVOPS-KEYNOTEvon Matthias Marschall

Video von der W-JAX 2011

GWT & HTML5Das große Web-Tutorial S. 60

Google DartDie neue Programmier-sprache S. 75

Spring ohne XMLJava-basierte Konfi guration S. 96

Infrastructure as Code mit Chef 53

OpsEntwicklung und Betrieb zusammen-Betrieb zusammen-bringen 32, 41

HIGHLIGHT

Cucumber-chef v1.0.4-0ChameRIA 1.5.0jBPM 5.1.0.Final

Sonderdruck fürwww.codecentric.de

von Patrick Peschlow

Als Patrick Debois vor gut zwei Jahren eine Konferenz in Belgien organisierte und nach einem Namen dafür suchte, konnte er nicht ahnen, dass sich dieser Name schon bald darauf wie ein Lauffeuer verbreiten wür-

de. Die Konferenz hieß DevOpsDays und wurde die erste in einer ganzen Reihe gleichartiger Konferen-zen. Seit diesen ersten DevOpsDays wird der Begriff „Dev Ops“ in immer größerem Maße verwendet und ist heute vielbeachtet. Bekannte Analysten wie Gartner [1] oder Forrester [2] haben DevOps auf ihrem Radar

Der Begriff „DevOps“ ist aktuell in aller Munde, es gibt aber noch keine gemeinsame Vorstellung davon, was genau das Ziel von DevOps ist und wie man es am besten erreichen kann. Dennoch kann es auch uns passieren, dass wir schon bald DevOps „machen“ müssen. So wächst nicht nur die Neugier, sondern auch die Sorge. Grund genug, die Dinge ein wenig zu ordnen.

Was ist das eigentlich und was bedeutet es für uns?

Die DevOps-Bewegung

2 www.JAXenter.dejavamagazin 1 | 2012

Sonderdruck

© Software & Support Media GmbH

und liefern kritische Einschätzungen. Verschiedene Unternehmen bieten integrierte „DevOps-Lösungen“ an, namhafte Hersteller geben ihren Produkten den DevOps-Stempel und man liest Schlagzeilen wie „VM-ware goes DevOps“. Interessanterweise existiert trotz des aktuellen Hypes keine gemeinsame Vorstellung da-von, worum es bei DevOps eigentlich geht. Das Ziel des vorliegenden Artikels ist es daher, ein klares Bild davon zu vermitteln, was DevOps ist und was es für unsere tägliche Arbeit bedeutet.

Aus Dev und Ops mach DevOpsDer Begriff setzt sich zusammen aus „Dev“, der die Soft-wareentwickler (Developers) repräsentiert, und „Ops“,

der für den IT-Betrieb (Operations) steht. Die Kombi-nation zum gemeinsamen „DevOps“ symbolisiert intui-tiv einen Schulterschluss zwischen Softwareentwicklern und IT-Betrieb. Und tatsächlich ist das der Grundge-danke von DevOps und der Auslöser der dazugehörigen Bewegung: ein Zusammenrücken der beiden in der tra-ditionellen Wahrnehmung grundverschiedenen Bereiche Softwareentwicklung und IT-Betrieb. Diese kurze Erklä-rung hat den Vorteil, dass wir uns spontan etwas unter DevOps vorstellen können. Andererseits lässt sie aber eine große Bandbreite an Interpretationen zu, was leicht zu Missverständnissen führen kann. Aktuell sieht die DevOps-Bewegung ihre Hauptaufgabe darin, die vielen Interpretationen zu kanalisieren und eine klare Defi niti-

Die DevOps-Bewegung

3www.JAXenter.de javamagazin 1 | 2012

Sonderdruck


on von DevOps zu formulieren. Wir werden in der Folge klären, wie der Begriff „DevOps“ heute aufzufassen ist. Zunächst betrachten wir aber den zugrunde liegenden Konflikt zwischen Dev und Ops.

Der traditionelle Konflikt zwischen Entwicklung und BetriebEtwas vereinfacht besteht die Aufgabe von Softwareent-wicklern darin, die vom Auftraggeber gewünschten Funktionen möglichst schnell umzusetzen. Wird eine neue Funktion verfügbar, ergibt sich ein potenzieller Mehrwert für die Endnutzer. Oft wird dieser Mehrwert schon bei der ersten Abnahme durch den Auftragge-ber anerkannt. Je häufiger neue Features komplettiert werden, desto positiver werden die Entwickler wahrge-nommen. Es ist für die Entwickler dabei weitestgehend irrelevant, ob die neuen Features tatsächlich auf dem Produktionssystem verfügbar sind.

Ebenfalls vereinfacht gesagt, besteht die Aufgabe des IT-Betriebs darin, die von der Entwicklung gelieferte Software auf der Produktivumgebung für die Endnut-zer verfügbar zu machen. Dazu zählen das Deploy-ment neuer Softwarereleases und die Sicherstellung des laufenden Betriebs unter bestimmten Qualitätsan-forderungen. Der Betrieb trägt also die unmittelbare Verantwortung für die Verfügbarkeit der Anwendung, und sein Erfolg wird daran gemessen, inwieweit die gegebenen Qualitätsanforderungen erreicht werden. Die Erwartungshaltung der Nutzer ist in der Regel die volle Verfügbarkeit und Sicherheit der Anwendung. Ist nun zum Beispiel die Verfügbarkeit einmal beein-trächtigt, fällt das direkt auf den Betrieb zurück. Die Folge ist eine stark negative Wahrnehmung durch die Auftraggeber, besonders wenn die Nutzer der Anwen-dung ein Problem melden, noch bevor die verwendeten Monitoring-Systeme Alarm schlagen. Um die Wahr-scheinlichkeit für unerwartete Ausfälle zu minimieren, setzt der Betrieb deshalb oft alles daran, den Zustand einer stabil laufenden Anwendung vor Änderungen zu schützen.

Dieser Vergleich der Aufgaben von Entwicklung und Betrieb zeigt, dass beide Abteilungen entgegengesetzte Anreize haben. Die Entwicklung ist an schnellen und häufigen Releases interessiert, der Betrieb hingegen wür-de Releases am liebsten vermeiden. Beide Seiten verfol-gen damit das gleiche Ziel, nämlich ihren eigenen Wert für das Unternehmen zu beweisen. Genau das führt aber regelmäßig zu Konflikten, Anfeindungen und schlechter Laune.

Blame GameIn der Regel treffen Devs und Ops unter Zeitdruck aufeinander, zum Beispiel beim Deployment eines neu-en Releases oder wenn es ein Problem (wie einen Sys-temausfall) gibt. Es beginnt dann das typische Blame Game, bei dem beide Lager sich gegenseitig die Schuld an der Situation geben. Ein paar Beispiele:

•Die Entwicklung gibt ein neues Release zum Deploy-ment an den Betrieb weiter, dem es aber einfach nicht gelingt, die Software auf der Produktiv umgebung lauffähig zu machen. Als der Betrieb die Entwickler kontaktiert und die auftretenden Fehler beschreibt, blocken diese jedoch ab: Die Software würde auf der Entwicklungsumgebung fehlerfrei laufen und des-halb wäre klar, dass der Fehler beim Betrieb läge. In der Folge beschuldigen sich beide Seiten gegenseitig, schuld an dem Problem zu sein. Es kommt zu Krisen-sitzungen und vielen bösen Telefonaten bzw. E-Mails zwischen den Abteilungen und an die Vorgesetzten. Eine Untersuchung ergibt schließlich, dass sich Ent-wicklungs- und Produktivumgebung in einem wichti-gen Detail unterscheiden (z. B. die Verwendung einer Komponente im Clustering-Modus), was aber keiner der beiden Seiten vorher bewusst war.

•Der Benutzeransturm auf die neue Webseite ist so groß, dass die Antwortzeiten schon bald immer grö-ßer werden und einige Stunden später die Seite kom-plett zusammenbricht. Aus Geschäftssicht ist das eine Katastrophe. Aber das erste, was die beteiligten Lager (Entwicklung, Betrieb und gegebenenfalls weitere Abteilungen für Datenbankadministration, Qualitätssicherung etc.) machen, ist heftig über die vermeintliche Ursache zu spekulieren: „Das muss ganz klar ein Datenbankproblem sein!“ oder „Das sind bestimmt die neuen Server schuld!“ Erst viel später wird eine objektive Analyse gestartet, zu diesem Zeitpunkt haben die Kunden aber bereits akzeptiert, dass die neue Webseite ein Desaster ist.

•Im Produktivsystem taucht ein ärgerliches Perfor-manceproblem auf. Unter großem Druck arbeiten die Entwickler mehrere Nächte durch und liefern schließlich einen Patch. Der Betrieb jedoch hat Be-denken, dass der Patch die Stabilität des Systems gefährdet, weil er Änderungen an einer kritischen Komponente umfasst. Deshalb wird zunächst eine genaue Qualitätskontrolle auf einer Testumgebung verlangt, um die Lösung in realistischen Testszenari-en zu überprüfen. Leider lässt sich die benötigte Last in der Testumgebung aber nicht adäquat darstellen. Viel Zeit vergeht, und einen Monat später ist der Patch immer noch nicht eingespielt. Die Entwickler sind enttäuscht, weil „es ja offenbar doch nicht so eilig war“.

Wer solche Situationen noch nicht erlebt hat, kann sich glücklich schätzen. Wer das Blame Game hingegen kennt, der weiß, dass man die dadurch verlorene Zeit besser zur Lösung des Problems hätte verwenden sollen. Schuldzuweisungen und das Sich-darüber-ärgern sind im Nachhinein immer noch möglich.

Der Betrieb als FlaschenhalsIm Laufe der Zeit haben wir uns an das Blame Game gewöhnt. Seit die Softwareentwicklung jedoch verstärkt


Sonderdruck


agile Methoden einsetzt, eskaliert die Situation. Metho-den wie Scrum setzen auf laufende Interaktion zwischen Auftraggebern und Entwicklern sowie kurze Release-zyklen, in der Regel setzt sich die damit einhergehende Philosophie aber nicht in den Betrieb fort. Im Endeffekt werden die Vorteile agiler Methoden also ausgebremst, wenn man dabei die letzte Meile, konkret Deployment und Betrieb, außer Acht lässt. Softwarereleases werden dann zwar in kurzen Iterationen erstellt, der geschaf-fene Mehrwert wird aber erst viel später auf der Pro-duktivumgebung sichtbar. Die immer kürzer werdenden Releasezyklen offenbaren den Betrieb zunehmend als Flaschenhals auf dem Weg der Software zum Endnut-zer. Auch erhöhen häufig stattfindende Releases das Potenzial für das direkte Aufeinandertreffen und damit auch das Blame Game zwischen Softwareentwicklung und Betrieb.

Eine Bewegung formiert sichIn den letzten Jahren entschied sich eine Reihe von Leuten unabhängig voneinander dafür, etwas gegen den Konflikt zwischen Entwicklung und Betrieb zu un-ternehmen. Sie sammelten Erfahrung, trafen sich und tauschten sich aus, und wurden schließlich zu dem, was man heute als DevOps-Bewegung bezeichnet. Es ver-wundert nicht, dass es sich dabei fast ausschließlich um Beschäftigte im IT-Betrieb (und nicht etwa um Entwick-ler) handelte. Die oft negative Wahrnehmung führte zu einem Wunsch nach Veränderung, vor allem zu dem Wunsch nach einem neuen Selbstbewusstsein, weg da-von als langsam zu gelten und weg von Parolen wie „Ein guter Tag ist, wenn heute keine Katastrophe passiert“. Die Parallelen zu den Anfängen der agilen Bewegung sind offensichtlich. Tatsächlich gab es schon vor der DevOps-Bewegung Bestrebungen wie Agile Operations oder Agile System Administration, um auch im IT-Be-trieb verstärkt agile Methoden einzusetzen. Der Schlüs-sel für den Erfolg der DevOps-Be we gung war nun, dass sie die Software entwicklung mit ins Boot geholt und da-durch die Anzahl der potenziell Interessierten stark ver-größert hat. DevOps hat die Ideen von Agile Operations und Co. aufgegriffen, diese aber um zwischenmensch-liche Komponenten ergänzt. In den letzten zwei Jahren wurden verschiedene Ziele von DevOps formuliert. Sie lassen sich in drei Bereiche einteilen: Zusammenarbeit, Automatisierung und Prozesse.

ZusammenarbeitVor allem in der frühen Phase der DevOps-Bewegung ist die zwischenmenschliche Komponente stark in

DevOps hat die Ideen der agilen Bewegung um zwischenmenschliche Komponenten ergänzt.

den Vordergrund gestellt worden. Bezeichnend ist ein Statement von Patrick Debois, veröffentlicht auf sei-nem Blog im Anschluss an die ersten DevOpsDays: „And remember it‘s all about putting the fun back into IT!“

Für viele Vertreter der Bewegung ist gegenseitiger Respekt die dringlichste Verbesserung im Umgang zwi-schen Entwicklung und Betrieb, denn er ist eine Vor-aussetzung für Vertrauen und gute Zusammenarbeit. Kulturelle Bausteine einer besseren Zusammenarbeit sind zum Beispiel Selbstverpflichtung der Beteiligten auf Ziele, aufmerksames Zuhören, gegenseitige Weiter-bildung und die Etablierung gemeinsamer Werte. Mit einer respektvollen und vertrauensvollen Zusammen-arbeit, so die Überlegung, lässt sich das Blame Game vermeiden. Das erklärte Ziel der DevOps-Bewegung in zwischenmenschlicher Hinsicht ist also gewisserma-ßen, die aus den agilen Methoden gezogenen Lehren eine Ebene nach oben zu ziehen und abteilungsüber-greifend zu etablieren.

AutomatisierungEin zentraler Gedanke von DevOps ist die Automatisie-rung von Vorgängen, die sonst manuell durchgeführt werden und daher wenig transparent sind beziehungs-weise sich nur schlecht für eine Qualitätskontrolle eig-nen. Ermöglicht wird eine Automatisierung durch die Nutzung geeigneter Tools. Viele DevOps-Anhänger bezeichnen Infrastructure as Code als wichtigsten Be-standteil der Automatisierung. Mit diesem Ansatz wer-den sämtliche benötigten Vorgänge zum Aufsetzen von Infrastruktur oder zum Durchführen von Deployments in Quellcode repräsentiert. Es können dann viele der in der Softwareentwicklung üblichen Lösungen zur Qua-litätskontrolle auch vom Betrieb eingesetzt werden. Mögliche Vorzüge des Infrastructure-as-Code-Ansat-zes sind folgende:

•Zentrale Verwaltung des Quellcodes unter Nutzung von Versionskontrolle.

•Hohe Transparenz und Vermeidung von Wissensin-seln.

•Automatisiertes Testen der Konfiguration von Ser-vern und virtuellen Maschinen.

•Automatisiertes Testen von Deployments und der an-schließenden Verfügbarkeit von beteiligten Systemen und geschäftskritischen Softwarefunktionen.

•Gemeinsame Nutzung von Konfigurations- und Deployment-Vorschriften durch Entwicklung und Betrieb.

www.JAXenter.de

Sonderdruck


Grundlegend für eine Realisierung von Infrastructure as Code sind Tools zum Konfigurationsmanagement, zum Beispiel Puppet [3], Chef [4] (siehe auch Artikel von Martin Eigenbrodt, im Java Magazin 1.2012, Sei-te 53) oder das ältere CFengine [5]. Diese Tools bie-ten domänenspezifische Sprachen (DSLs) an, um den gewünschten Endzustand des Systems auf einer abs-trakten, plattformübergreifenden Ebene zu beschrei-ben. Hinter den Kulissen werden diese Vorgaben dann mittels vordefinierter Abbildungen auf den jeweiligen Zielsystemen ausgeführt. Eine verwandte Gruppe von Tools konzentriert sich auf ein automatisiertes Deploy-ment und die koordinierte Ausführung von Aktionen auf laufenden, verteilten Servern. In der Regel bieten diese Tools ebenfalls DSLs an, um Abfolgen von Kom-mandos zu beschreiben. Vertreter dieser Kategorie sind Capistrano [6], ControlTier [7], Fabric [8], RunDeck [9] und Marionette Collective [10]. Zur Versionskon-trolle der formulierten Vorschriften (in der jeweils verwendeten DSL) sind die üblichen Verdächtigen wie Mercurial oder Git einsetzbar.

Zum automatisierten Testen der Quellcodes bietet sich ein BDD-Tool wie Cucumber [11] an, das gemein-sam mit Puppet oder Chef genutzt werden kann. Er-weiterungen wie Cucumber-Nagios [12] ermöglichen es außerdem, die Ausgaben direkt im Format bestimmter Monitoring-Tools zu erzeugen. Ein BDD-Ansatz ist be-sonders deshalb zu empfehlen, weil er eine Kultur des Testens mit sich bringt, bei der interessante Anwen-dungsfälle und nicht nur die bloße Verfügbarkeit von Servern getestet werden. Mit Continuous-Integration-Servern wie Hudson [13] oder Jenkins [14] können diese Tests zudem automatisiert ausgeführt werden. Besonders für Entwickler interessant dürften Tools zur vollautomatischen Installation von Betriebssystemen oder virtuellen Maschinen sein. Neuere Vertreter dieser Kategorie sind zum Beispiel Cobbler [15] oder Vagrant [16].

Es ist ein erklärtes Ziel der DevOps-Bewegung, die Automatisierung von Vorgängen im IT-Betrieb und die gemeinsame Nutzung von Tools zwischen Entwicklung und Betrieb zu fördern. Beispielsweise können die Ent-wickler ihre verwendete Konfiguration der Infrastruktur (z. B. als Puppet-Manifeste) an den Betrieb weitergeben und mit diesem abstimmen. Oder aber Entwicklung und Betrieb entwickeln den Infrastrukturcode direkt gemeinsam und schließen somit von vornherein Inkom-patibilitäten zwischen den Entwicklungs-, Test- und Produktivumgebungen aus.

ProzesseFür die Einführung von DevOps-Ideen in Unternehmen ist es essenziell, Prozesse zu haben. In diesem Bereich hat die DevOps-Bewegung noch einiges zu tun und muss erst noch konkrete Vorschläge erarbeiten. Ein zynischer Tweet von „DevOps Borat“ [17] zum Thema DevOps-Prozesse: „To make error is human. To propagate error to all server in automatic way is #devops.“ Natürlich ist der Kommentar nicht ganz ernst zu nehmen, er spie-gelt aber deutlich eine Sorge vor blindem Aktionismus wieder, bei dem die Funktionen von Entwicklung und Betrieb ohne die Beachtung möglicher Risiken zusam-mengeworfen werden.

Die meisten Befürworter von DevOps sind sich einig, dass es weder notwendig noch wünschenswert ist, Ent-wicklung und Betrieb zusammenzulegen. Interdiszipli-näre Experten, die an der Schnittstelle zwischen beiden Bereichen arbeiten, können natürlich trotzdem hilfreich sein. Definitiv ist „DevOps“ jedoch nicht als Stellen- oder Rollenbezeichnung zu sehen. Allgemein besteht bei der Definition von DevOps-Prozessen eine Schwierigkeit darin, dass in vielen kleineren Unternehmen die Grenze zwischen Entwicklung und Betrieb nicht so streng gezo-gen wird wie in großen Unternehmen. Es ist daher frag-lich, ob Prozesse und Vorgehensweisen, die für kleine Unternehmen gut funktionieren, auch in großen Unter-nehmen anwendbar sind. Dennoch oder gerade deshalb ist es ein erklärtes Ziel der DevOps-Bewegung, geeignete Prozesse für die Einführung und Nutzung von DevOps-Ideen zu definieren.

Missverständnisse und KritikDie genannten Ziele von DevOps sind alle nachvoll-ziehbar. Allerdings hat die fehlende Fokussierung der DevOps-Bewegung auf ein klares, übergeordnetes Ziel zu diversen Missverständnissen und Kritikpunkten ge-führt. Betrachten wir eine Auswahl davon:

•„DevOps ist nur ein Werbename, um altbekannte Dinge als neu anzupreisen.“ Fast ausnahmslos ge-hören die Gründer der DevOps-Bewegung selbst zu den Leuten, die schon vorher DevOps- Ansätze verfolgt haben. Sie wissen natürlich, dass viele der vorgeschlagenen Praktiken und Tools keine funda-mentale Neuheit darstellen. Dennoch haben sie eine ungeheure Aufmerksamkeit für ein Problem erreicht, über das vorher in der Öffentlichkeit nicht viel gere-det wurde. Allein das ist schon ein großer Erfolg. Die Initiatoren der Bewegung betonen übrigens regelmä-

Ein zentraler Gedanke von DevOps ist die Automatisierung von Vorgängen.


Sonderdruck


INFORMIEREN SIE SICH

jETZT ÜBER

UNSERE NÄCHSTEN

WORKSHOPS

UND

SCHULUNGEN

Mehr dazu unter: www.codecentric.de

cc_BusinessTech_AZ_210x297 RZ_2.indd 1 10.05.11 11:49

ßig, dass DevOps für sie keine Geldmaschine ist, und müssen sich sogar Vorwürfe gefallen lassen, warum sie nicht versuchen, aus DevOps mehr Kapital zu schlagen [18].

•„DevOps ist ein Freifahrtschein für Entwickler, beliebigen Schaden auf dem Produktivsystem anzu-richten.“ DevOps verlangt nicht, dass die Entwickler Schreibrechte auf den Servern des Produktivsystems oder gar deren Root-Passwort erhalten. Man kann einheitliche Deployment-Prozeduren und Infrastruc-ture as Code auch unter Wahrung gewisser sinnvoller Beschränkungen einsetzen.

•„DevOps möchte Entwicklung und Betrieb durch eine Elite von Alleskönnern ersetzen.“ Das Her-anzüchten einer solchen Elite wäre absurd. Nicht ohne Grund wurden vor vielen Jahren eine Spezi-alisierung und die daraus resultierende Trennung von Entwicklung und Betrieb eingeführt. DevOps versucht vielmehr, die Zusammenarbeit und den Wissensaustausch zwischen diesen Bereichen zu verbessern.

•„DevOps möchte den Betrieb abschaffen und die Entwickler alles machen lassen.“ Dieser Gedanke, oft auch als Ruf nach „NoOps“ formuliert, ist ebenfalls absurd. Die treibende Kraft hinter Dev Ops sind Be-schäftigte im IT-Betrieb, und es ist nicht deren Ziel, sich abzuschaffen.

•„Mit DevOps müssen wir neue Tools lernen.“ Das mag sein, aber warum so negativ? Es ist für DevOps-Neulinge eine naheliegende Entscheidung, den Einstieg über Tools zu finden. Man kann gerade durch Automatisierung einen schnellen Mehrwert erhalten und außerdem eine gemeinsame Basis für die Zusammenarbeit von Entwicklung und Betrieb schaffen. Interessant in diesem Zusam-menhang ist eine Umfrage, die Replay Solutions im Frühjahr 2011 durchgeführt hat und laut der Tools als sehr wichtig für den Erfolg von DevOps ange-sehen werden. Verbesserungen erhoffen sich die Befragten vor allem beim Defect Tracking und der Versionskontrolle [19]. Eine Umfrage von Puppet Labs vom Sommer 2011 bestätigt diesen Eindruck: Mit deutlichem Abstand wird die Automatisierung, z. B. mit Tools zum Konfigurationsmanagement, als größte erhoffte Verbesserung durch DevOps genannt [20]. Danach erst folgen abstraktere Ziele wie die Optimierung von Deployment-Prozessen oder die Verbesserung der Kommunikation zwi-schen den Abteilungen.

•„Manchen Leuten kann man einfach keinen Respekt entgegenbringen.“ Tatsächlich entstehen Respekt und Vertrauen nicht auf Knopfdruck, sondern müs-sen durch Leistung „erworben“ werden. Man wird immer wieder Leute finden, die keine ausreichende Leistung bringen und deshalb niemals das Vertrauen ihrer Teammitglieder erhalten. Dennoch gilt im Kon-text von DevOps: Entwicklung und Betrieb müssen

zunächst einmal verstehen, was die jeweils andere Seite eigentlich macht und wie die alltäglichen Her-ausforderungen aussehen, bevor sie deren Leistung auch nur entfernt beurteilen können. Letzten Endes sind Teammitglieder, die mangelhafte Leistung brin-gen, natürlich ein Problem, aber kein spezielles von Dev Ops.

•„DevOps wird durch PaaS-Angebote überflüssig.“ Das ist eine ernstzunehmende Kritik, denn die Nut-zung so mancher Cloud-Angebote kann die konkre-ten Aufgaben des Betriebs deutlich beeinflussen. Die Entgegnung der DevOps-Verfechter ist, dass durch PaaS lediglich eine weitere Abstraktionsschicht bzw. neue Schnittstelle für die klassischen Funktio-nen des Betriebs (wie Deployment, Monitoring und Sicherstellung der Qualitätsanforderungen) ent-steht. Man kann also trotzdem nicht ohne Betrieb auskommen.

Worum geht es bei DevOps wirklich?Insgesamt lässt sich sagen, dass DevOps ähnliche Herausforderungen wie die agilen Methoden zur Softwareentwicklung lösen möchte, nur abteilungs-übergreifend. Dadurch wird es natürlich schwieriger, geeignete Lösungen zu finden. Vor allem aber wird es schwieriger, DevOps-Ansätze in der Praxis zu etablie-ren. Wegweisend für DevOps sind hier die Antworten auf zwei grundlegende Fragestellungen:

1. Was für einen Anreiz haben Entwicklung und Betrieb, viel Zeit und Aufwand in gemeinsame Un-ternehmungen zu stecken, wenn der Tag ohnehin schon zu kurz ist, um die eigene Arbeit zu schaf-fen? Was für ein Anreiz besteht für den Betrieb darin, unbekannte Tools zur Automatisierung zu nutzen, wenn die selbstgeschriebenen Shell-Skripte schon seit Jahren im Einsatz sind? Grundlegend für eine Etablierung von DevOps ist deshalb die Schaffung von Anreizen für alle Beteiligten. Diese Anreize können aber letzten Endes nur über die Zielvorgaben der Geschäftsführung geschaffen werden.

2. Was für einen Anreiz hat die Geschäftsführung, DevOps-Ansätze in ihrem Unternehmen einzu-führen? Betrachten wir die Frage „Was bringt uns DevOps?“ aus der Sicht der Geschäftsführung, so wird schnell klar, dass DevOps nur dann inter-essant ist, wenn es einen (finanziellen) Mehrwert liefert.

In letzter Zeit kristallisiert sich daher immer mehr eine neue Wahrnehmung des von DevOps adressierten Pro-blems heraus. Die eingangs beschriebenen Ziele von DevOps beschäftigen sich mit Symptomen, ignorieren aber das Kernproblem. Die anfänglichen Rufe nach mehr Zusammenarbeit oder besseren Tools versuchen, den Alltag von Entwicklung und Betrieb angenehmer


Sonderdruck


zu machen. Dieser Ansatz hilft, die Massen zu mobili-sieren und Aufmerksamkeit zu erzeugen, er überzeugt aber nicht unbedingt die eigentlichen Entscheider, DevOps in einem Unternehmen einzuführen. Es ist deshalb nötig, das zugrunde liegende Problem als ein Geschäftsproblem zu sehen: Wie lässt sich maximaler Gewinn in kürzester Zeit generieren? Wie lässt sich die ursprüngliche Idee einer Software (die Vision) schnell und dennoch stabil zum Kunden beziehungsweise zum Endnutzer bringen, sodass sie einen Mehrwert bezie-hungsweise Einnahmen für das Unternehmen gene-riert? Ein wenig ironisch an dieser Entwicklung ist, dass der Name DevOps zwar ursprünglich sehr gut gepasst hat, aber aktuell die Sicht auf das eigentliche Geschäftsproblem verdeckt.

Betrachten wir die Dinge noch ein wenig nüchterner, so müssen wir feststellen, dass wir nicht dafür bezahlt werden, Spaß bei der Arbeit zu haben. Für das Unter-nehmen zählt in erster Linie das Ergebnis. Stimmt das Ergebnis, so gibt es aber kein Geschäftsproblem und es wird auch keine Lösung wie DevOps benötigt. Ideal ist natürlich, wenn der Unternehmenserfolg mit Metho-den gesteigert werden kann, die den Mitarbeitern auch Spaß machen. Allein das Argument, dass sich Entwick-lung und Betrieb freuen, wenn man ein bestimmtes Tool einführt oder gemeinsam Pizza isst, zieht aller-dings nicht. Die Einführung einer Maßnahme wie „Wir machen jetzt DevOps!“ muss erst nötig werden, zum Beispiel weil die aktuellen Zahlen das aussagen, und genauso muss auch der Erfolg der Maßnahme quanti-fizierbar sein. Das Stichwort ist hier die Messbarkeit. Wir benötigen hierzu kombinierte Metriken für die ge-meinsame Leistung von Betrieb und Entwicklung. Sie können die bis dato verwendeten Metriken ergänzen oder ersetzen.

Zum Vergleich: Es führt auch kein Unternehmen Agilität ein, wenn es sich davon nicht eine Steigerung des Gewinns verspricht. Daher liegt auch für DevOps der Weg zum Erfolg im Business Case. Und wie bei den agilen Methoden auch lässt sich der Business Case in erster Linie über Success-Stories nachweisen. Für die DevOps-Bewegung ist es daher essenziell, nicht nur über Techniken und Tools nachzudenken, sondern in erster Linie über die Erfolgserlebnisse durch DevOps zu berichten.

Was kommt mit DevOps auf uns zu?Unabhängig davon, ob nun die Geschäftsführung die Einführung von DevOps vorgibt oder wir uns autonom

an DevOps-Ansätzen versuchen, wird DevOps für uns eine stärkere Fokussierung auf bestimmte Elemente in unserem Arbeitsalltag bedeuten:

•In der Softwareentwicklung werden wir uns zuneh-mend mit Aspekten aus dem Betrieb auseinander-setzen, z. B. dem Aufsetzen von physikalischen oder virtuellen Maschinen, der Absicherung von Systemen oder der minutiösen Planung und Durchführung von Deployments. Dazu werden wir vermehrt Tools zur Automatisierung einsetzen, und zwar gemeinsam mit Beschäftigten aus dem Betrieb, von denen wir auch lernen werden. Wir werden mehr Verantwortung für unsere Software und auf der Produktivumgebung auftretende Probleme übernehmen. Wir werden schnelles Troubleshooting im Ernstfall unterstützen, durch mit dem Betrieb abgestimmtes Logging und Monitoring, und vielleicht sogar ins Alerting mit einbezogen werden. Wir werden unsere Software robuster machen, z. B. durch die Verwendung von Feature-Flags, mit denen neue Funktionen bei Bedarf (d. h. im Fehler- oder Problemfall) unkompliziert von außen wieder abgeschaltet werden können. Im Java-Umfeld können die Voraussetzungen für Feature-Flags bequem durch MBeans realisiert werden.

•Im IT-Betrieb werden wir verstärkt auf Automati-sierung setzen, mit Infrastructure as Code, Versions-kontrolle und automatisierten Tests. Wir werden in diesem Bereich von der Softwareentwicklung lernen. Außerdem werden wir agile Methoden wie Kanban anwenden, möglicherweise gemeinsam mit den Ent-wicklern. Wir werden uns auf häufige Releases ein-stellen müssen und den Prozess diesbezüglich mit den Entwicklern abstimmen. Wir werden gemeinsam mit den Entwicklern geeignete Metriken definieren, um problematische Situationen auf dem Produktivsystem schneller zu erkennen. Darüber hinaus werden wir frühzeitig in die Planung der Anforderungen an die Software mit einbezogen werden.

Zudem können wir davon ausgehen, dass eine Einfüh-rung von DevOps abteilungsübergreifende Metriken mit sich bringen wird, um den Erfolg zu messen. Auf solche gemeinsamen Metriken, und damit gemeinsame Anreize für Entwicklung und Betrieb, müssen wir uns einstellen.

Wo finde ich weitere Informationen zu DevOps?Die meisten relevanten Informationen zu DevOps fin-det man aktuell in Blogs. Pflichtlektüre für DevOps-

Wir werden nicht dafür bezahlt, Spaß bei der Arbeit zu haben. Für Unternehmen zählt das Ergebnis.


Sonderdruck


Interessierte ist der Blog von Patrick Debois, auf dem man aktuelle Ansichten zur DevOps-Bewegung und konkrete Beispiele für die Nutzung von DevOps-Tools findet [21]. Stephen Nelson-Smith führt einen Blog namens „Agile Sysadmin“, auf dem sich zum Beispiel ein wertvoller Beitrag zum Thema „Kanban für Ops“ findet [22]. Der Blog von Damon Edwards beziehungsweise DTO Solutions behandelt aktuell vor allem DevOps-Tools im Cloud-Umfeld, bietet aber auch einige wegweisende Beiträge aus der Anfangszeit [23]. Kief Morris führt einen Blog über Continuous Delivery, mit vielen DevOps-orientierten Beiträgen und Gedanken zur Umsetzung in der Praxis [24]. Der Blog „Agile Web Development & Operations“, von Matthias Marschall und anderen geschrieben, bietet ausgewogenen und durchdachten Inhalt. Für Einstei-ger dürfte insbesondere die Serie von Gastbeiträgen diverser DevOps-Größen lesenswert sein [25]. Weitere interessante Blogs sind „Agile Operations“ [26] von Scott Wilson und „The agile Admin“ [27] von Ernest Mueller. Die Webseite „Planet DevOps“ schließlich ist ein zentraler Einstiegspunkt, auf dem sich Beiträge von verschiedenen Autoren befinden [28]. Deutsch-sprachige Artikel zu DevOps sind zurzeit noch eine Rarität. Ein kürzlich erschienener Zeitschriftenartikel von Udo Pracht bietet aber einen guten Einstieg in das Thema [29].

Da DevOps noch in der Findungsphase ist, wurde noch kein ganzheitliches Buch zu diesem Thema veröf-fentlicht (da ist zwar „DevOps“ von Kevin Roebuck, es hat aber wenig mit der DevOps-Bewegung zu tun und ist nicht zu empfehlen). Es gibt jedoch hervorragende Bücher zu verwandten Themen mit klarem Bezug zu Dev Ops. Sehr empfehlenswert ist „Continuous Delive-ry“ von Jez Humble und David Farley, in dem es um Konfigurationsmanagement, automatisiertes Deploy-ment und die dafür benötigten Prozesse geht. Ebenso empfehlenswert ist „Web Operations“ von John All-spaw und Jesse Robbins, was sich unter anderem mit der Wichtigkeit geeigneter Metriken beschäftigt. Auch gibt es Bücher zu verschiedenen DevOps-Tools, zum Beispiel „Test-Driven Infrastructure with Chef“ von Stephen Nelson-Smith. Zu erwähnen ist außerdem „Release It!“ von Michael Nygard, das bereits heute ein Klassiker ist. Dieses Buch ist vor allem Entwicklern zu empfehlen, die ihre Sensibilität für mögliche unerwartete Produktions-probleme von Web- und Enterprise-Anwendungen stei-gern möchten.

Was Konferenzen betrifft, so sind die DevOpsDays [30] die vermutlich wichtigste Konferenz im DevOps-Umfeld. Zu nennen ist weiterhin das Camp DevOps [31], das kürzlich zum ersten Mal stattgefunden hat. Auf den bekannten Velocity-Konferenzen [32] wer-den ebenfalls regelmäßig Beiträge zu Themen aus dem DevOps-Umfeld gemacht. Darüber hinaus gibt es auch toolspezifische Konferenzen wie das Puppet Camp [33]. Unter dem Titel „DevOps Cafe“ bieten John Wil-

Links & Literatur

[1] http://www.gartner.com/technology

[2] http://www.forrester.com/rb/research

[3] http://puppetlabs.com

[4] http://www.opscode.com/chef

[5] http://cfengine.com

[6] http://github.com/capistrano

[7] http://controltier.org

[8] http://fabfile.org

[9] http://rundeck.org

[10] http://docs.puppetlabs.com/mcollective

[11] http://cukes.info

[12] http://auxesis.github.com/cucumber-nagios

[13] http://hudson-ci.org

[14] http://jenkins-ci.org

[15] http://fedorahosted.org/cobbler

[16] http://vagrantup.com

[17] http://twitter.com/#!/DEVOPS_BORAT

[18] http://teddziuba.com/2011/03/devops-scam.html

[19] http://replaysolutions.com/2011-DevOpsSurveyResults

[20] http://rww.to/qiAxu1

[21] http://www.jedi.be/blog

[22] http://agilesysadmin.net/

[23] http://dev2ops.org

[24] http://kief.com

[25] http://www.agileweboperations.com/devops-series

[26] http://agileoperations.net/index.php?frontpage

[27] http://theagileadmin.com

[28] http://www.planetdevops.net

[29] Udo Pracht: „Gemeinsam produktiv werden“, in WIRTSCHAFTSINFORMATIK & MANAGEMENT, Ausgabe 04/2011

[30] http://devopsdays.org

[31] http://campdevops.com

[32] http://velocityconf.com/velocity2011

[33] http://puppetlabs.com/community/puppet-camp

[34] http://devopscafe.org

[35] http://devopsweekly.com

lis und Damon Edwards einen Podcast zum Thema an [34]. Außerdem gibt es einen gut sortierten wöchentli-chen Newsletter, zusammengestellt von Gareth Rush-grove [35].

Dr. Patrick Peschlow ist Performance Engineer bei der codecen-tric AG. Er interessiert sich sehr für Performance und Effizienzstei-gerung in den verschiedensten Bereichen der IT, von JVM-Tuning über parallele Programmierung und Cloud-Architekturen bis hin zu Softwareentwicklungsprozessen.


Sonderdruck



Sonderdruck


Notizen

codecentric AG Kölner Landstraße 11 40591 Düsseldorf

Tel: +49 (0) 211.9941410 Fax: +49 (0) 211.9941444

E-Mail: [email protected] www.codecentric.de blog.codecentric.de

die devops-bewegung

Documents