DevOps. magazin. JAVA Mag. Sonderdruck für CD-INHALT. Entwicklung und Betrieb zusammenbringen. Infrastructure as Code mit Chef 53

Transkript

1 inkl. JAVA Mag CD Open Source BPM: Tools und Strömungen magazin Java Architekturen Web Agile CD-INHALT DEVOPS-KEYNOTE von Matthias Marschall Video von der W-JAX 2011 NIO2 Erweiterungen der Product Line Engineering mit OSGi Ein sinnvolles Paar? 105 I/O-Funktionalität 27 Erste Sessions ab Seite 43 DevOps HIGHLIGHT Sonderdruck für Cucumber-chef v ChameRIA jbpm Final Entwicklung und Betrieb zusammenbringen 32, 41 WEITERE INHALTE H-Ubu Apache POI 3.8 beta 4 Activiti 5.8 Infrastructure as Code mit Chef 53 Alle CD-Infos ab Seite 3 GWT & HTML5 Das große Web-Tutorial S. 60 Google Dart Die neue Programmiersprache S. 75 Spring ohne XML Java-basierte Konfiguration S. 96

2 Was ist das eigentlich und was bedeutet es für uns? Die DevOps-Bewegung 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. 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ürde. Die Konferenz hieß DevOpsDays und wurde die erste in einer ganzen Reihe gleichartiger Konferenzen. 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 2 javamagazin Software & Support Media GmbH

3 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 VMware goes DevOps. Interessanterweise existiert trotz des aktuellen Hypes keine gemeinsame Vorstellung davon, 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 DevOps Der Begriff setzt sich zusammen aus Dev, der die Softwareentwickler (Developers) repräsentiert, und Ops, der für den IT-Betrieb (Operations) steht. Die Kombination zum gemeinsamen DevOps symbolisiert intuitiv einen Schulterschluss zwischen Softwareentwicklern und IT-Betrieb. Und tatsächlich ist das der Grundgedanke von DevOps und der Auslöser der dazugehörigen Bewegung: ein Zusammenrücken der beiden in der traditionellen 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 Definiti- Software & Support Media GmbH javamagazin

4 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 Betrieb Etwas vereinfacht besteht die Aufgabe von Softwareentwicklern 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 Auftraggeber anerkannt. Je häufiger neue Features komplettiert werden, desto positiver werden die Entwickler wahrgenommen. 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 Endnutzer verfügbar zu machen. Dazu zählen das Deployment neuer Softwarereleases und die Sicherstellung des laufenden Betriebs unter bestimmten Qualitätsanforderungen. 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 beeinträ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 Anwendung ein Problem melden, noch bevor die verwendeten Monitoring-Systeme Alarm schlagen. Um die Wahrscheinlichkeit 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ürde Releases am liebsten vermeiden. Beide Seiten verfolgen 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 Game In der Regel treffen Devs und Ops unter Zeitdruck aufeinander, zum Beispiel beim Deployment eines neuen Releases oder wenn es ein Problem (wie einen Systemausfall) 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 Deployment 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 deshalb 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 Krisensitzungen und vielen bösen Telefonaten bzw. s zwischen den Abteilungen und an die Vorgesetzten. Eine Untersuchung ergibt schließlich, dass sich Entwicklungs- und Produktivumgebung in einem wichtigen 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 komplett 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 Performanceproblem auf. Unter großem Druck arbeiten die Entwickler mehrere Nächte durch und liefern schließlich einen Patch. Der Betrieb jedoch hat Bedenken, 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 Testszenarien 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 Flaschenhals Im Laufe der Zeit haben wir uns an das Blame Game gewöhnt. Seit die Softwareentwicklung jedoch verstärkt 4 javamagazin Software & Support Media GmbH

5 DevOps hat die Ideen der agilen Bewegung um zwischenmenschliche Komponenten ergänzt. agile Methoden einsetzt, eskaliert die Situation. Methoden wie Scrum setzen auf laufende Interaktion zwischen Auftraggebern und Entwicklern sowie kurze Releasezyklen, 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 geschaffene Mehrwert wird aber erst viel später auf der Produktivumgebung sichtbar. Die immer kürzer werdenden Releasezyklen offenbaren den Betrieb zunehmend als Flaschenhals auf dem Weg der Software zum Endnutzer. 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 sich In den letzten Jahren entschied sich eine Reihe von Leuten unabhängig voneinander dafür, etwas gegen den Konflikt zwischen Entwicklung und Betrieb zu unternehmen. Sie sammelten Erfahrung, trafen sich und tauschten sich aus, und wurden schließlich zu dem, was man heute als DevOps-Bewegung bezeichnet. Es verwundert nicht, dass es sich dabei fast ausschließlich um Beschäftigte im IT-Betrieb (und nicht etwa um Entwickler) handelte. Die oft negative Wahrnehmung führte zu einem Wunsch nach Veränderung, vor allem zu dem Wunsch nach einem neuen Selbstbewusstsein, weg davon 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-Betrieb verstärkt agile Methoden einzusetzen. Der Schlüssel für den Erfolg der DevOps-Be we gung war nun, dass sie die Software entwicklung mit ins Boot geholt und dadurch die Anzahl der potenziell Interessierten stark vergrößert hat. DevOps hat die Ideen von Agile Operations und Co. aufgegriffen, diese aber um zwischenmenschliche 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. Zusammenarbeit Vor allem in der frühen Phase der DevOps-Bewegung ist die zwischenmenschliche Komponente stark in den Vordergrund gestellt worden. Bezeichnend ist ein Statement von Patrick Debois, veröffentlicht auf seinem 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 zwischen Entwicklung und Betrieb, denn er ist eine Voraussetzung für Vertrauen und gute Zusammenarbeit. Kulturelle Bausteine einer besseren Zusammenarbeit sind zum Beispiel Selbstverpflichtung der Beteiligten auf Ziele, aufmerksames Zuhören, gegenseitige Weiterbildung und die Etablierung gemeinsamer Werte. Mit einer respektvollen und vertrauensvollen Zusammenarbeit, 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übergreifend zu etablieren. Automatisierung Ein zentraler Gedanke von DevOps ist die Automatisierung von Vorgängen, die sonst manuell durchgeführt werden und daher wenig transparent sind beziehungsweise sich nur schlecht für eine Qualitätskontrolle eignen. Ermöglicht wird eine Automatisierung durch die Nutzung geeigneter Tools. Viele DevOps-Anhänger bezeichnen Infrastructure as Code als wichtigsten Bestandteil der Automatisierung. Mit diesem Ansatz werden 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 Qualitätskontrolle auch vom Betrieb eingesetzt werden. Mögliche Vorzüge des Infrastructure-as-Code-Ansatzes sind folgende: Zentrale Verwaltung des Quellcodes unter Nutzung von Versionskontrolle. Hohe Transparenz und Vermeidung von Wissensinseln. Automatisiertes Testen der Konfiguration von Servern und virtuellen Maschinen. Automatisiertes Testen von Deployments und der anschließenden Verfügbarkeit von beteiligten Systemen und geschäftskritischen Softwarefunktionen. Gemeinsame Nutzung von Konfigurations- und Deployment-Vorschriften durch Entwicklung und Betrieb. Software & Support Media GmbH

6 Ein zentraler Gedanke von DevOps ist die Automatisierung von Vorgängen. 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 , Seite 53) oder das ältere CFengine [5]. Diese Tools bieten domänenspezifische Sprachen (DSLs) an, um den gewünschten Endzustand des Systems auf einer abstrakten, plattformübergreifenden Ebene zu beschreiben. 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 Deployment und die koordinierte Ausführung von Aktionen auf laufenden, verteilten Servern. In der Regel bieten diese Tools ebenfalls DSLs an, um Abfolgen von Kommandos zu beschreiben. Vertreter dieser Kategorie sind Capistrano [6], ControlTier [7], Fabric [8], RunDeck [9] und Marionette Collective [10]. Zur Versionskontrolle 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 gemeinsam mit Puppet oder Chef genutzt werden kann. Erweiterungen wie Cucumber-Nagios [12] ermöglichen es außerdem, die Ausgaben direkt im Format bestimmter Monitoring-Tools zu erzeugen. Ein BDD-Ansatz ist besonders deshalb zu empfehlen, weil er eine Kultur des Testens mit sich bringt, bei der interessante Anwendungsfä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 Entwickler 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 Inkompatibilitäten zwischen den Entwicklungs-, Test- und Produktivumgebungen aus. Prozesse Fü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 spiegelt aber deutlich eine Sorge vor blindem Aktionismus wieder, bei dem die Funktionen von Entwicklung und Betrieb ohne die Beachtung möglicher Risiken zusammengeworfen werden. Die meisten Befürworter von DevOps sind sich einig, dass es weder notwendig noch wünschenswert ist, Entwicklung und Betrieb zusammenzulegen. Interdisziplinäre Experten, die an der Schnittstelle zwischen beiden Bereichen arbeiten, können natürlich trotzdem hilfreich sein. Definitiv ist DevOps jedoch nicht als Stellenoder 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 gezogen wird wie in großen Unternehmen. Es ist daher fraglich, ob Prozesse und Vorgehensweisen, die für kleine Unternehmen gut funktionieren, auch in großen Unternehmen 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 Kritik Die genannten Ziele von DevOps sind alle nachvollziehbar. Allerdings hat die fehlende Fokussierung der DevOps-Bewegung auf ein klares, übergeordnetes Ziel zu diversen Missverständnissen und Kritikpunkten geführt. Betrachten wir eine Auswahl davon: DevOps ist nur ein Werbename, um altbekannte Dinge als neu anzupreisen. Fast ausnahmslos gehö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 fundamentale Neuheit darstellen. Dennoch haben sie eine ungeheure Aufmerksamkeit für ein Problem erreicht, über das vorher in der Öffentlichkeit nicht viel geredet wurde. Allein das ist schon ein großer Erfolg. Die Initiatoren der Bewegung betonen übrigens regelmä- 6 javamagazin Software & Support Media GmbH

7 INFORMIEREN SIE SICH jetzt ÜBER UNSERE NÄCHSTEN WORKSHOPS UND SCHULUNGEN Mehr dazu unter:

8 ß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 anzurichten. DevOps verlangt nicht, dass die Entwickler Schreibrechte auf den Servern des Produktivsystems oder gar deren Root-Passwort erhalten. Man kann einheitliche Deployment-Prozeduren und Infrastructure as Code auch unter Wahrung gewisser sinnvoller Beschränkungen einsetzen. DevOps möchte Entwicklung und Betrieb durch eine Elite von Alleskönnern ersetzen. Das Heranzüchten einer solchen Elite wäre absurd. Nicht ohne Grund wurden vor vielen Jahren eine Spezialisierung 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 Beschä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 Zusammenhang 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 angesehen 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 zwischen den Abteilungen. Manchen Leuten kann man einfach keinen Respekt entgegenbringen. Tatsächlich entstehen Respekt und Vertrauen nicht auf Knopfdruck, sondern müssen 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 Kontext von DevOps: Entwicklung und Betrieb müssen zunächst einmal verstehen, was die jeweils andere Seite eigentlich macht und wie die alltäglichen Herausforderungen aussehen, bevor sie deren Leistung auch nur entfernt beurteilen können. Letzten Endes sind Teammitglieder, die mangelhafte Leistung bringen, natürlich ein Problem, aber kein spezielles von Dev Ops. DevOps wird durch PaaS-Angebote überflüssig. Das ist eine ernstzunehmende Kritik, denn die Nutzung so mancher Cloud-Angebote kann die konkreten 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 Funktionen des Betriebs (wie Deployment, Monitoring und Sicherstellung der Qualitätsanforderungen) entsteht. 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 etablieren. 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 Unternehmungen zu stecken, wenn der Tag ohnehin schon zu kurz ist, um die eigene Arbeit zu schaffen? 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 einzuführen? Betrachten wir die Frage Was bringt uns DevOps? aus der Sicht der Geschäftsführung, so wird schnell klar, dass DevOps nur dann interessant ist, wenn es einen (finanziellen) Mehrwert liefert. In letzter Zeit kristallisiert sich daher immer mehr eine neue Wahrnehmung des von DevOps adressierten Problems 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 8 javamagazin Software & Support Media GmbH

9 Wir werden nicht dafür bezahlt, Spaß bei der Arbeit zu haben. Für Unternehmen zählt das Ergebnis. zu machen. Dieser Ansatz hilft, die Massen zu mobilisieren 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 beziehungsweise Einnahmen für das Unternehmen generiert? 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 Unternehmen 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 Methoden gesteigert werden kann, die den Mitarbeitern auch Spaß machen. Allein das Argument, dass sich Entwicklung und Betrieb freuen, wenn man ein bestimmtes Tool einführt oder gemeinsam Pizza isst, zieht allerdings 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 quantifizierbar sein. Das Stichwort ist hier die Messbarkeit. Wir benötigen hierzu kombinierte Metriken für die gemeinsame 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 zunehmend mit Aspekten aus dem Betrieb auseinandersetzen, 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 Automatisierung setzen, mit Infrastructure as Code, Versionskontrolle 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 Entwicklern. Wir werden uns auf häufige Releases einstellen 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ührung 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 findet man aktuell in Blogs. Pflichtlektüre für DevOps- Software & Support Media GmbH javamagazin

10 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 Einsteiger 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]. Deutschsprachige 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öffentlicht (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 Delivery von Jez Humble und David Farley, in dem es um Konfigurationsmanagement, automatisiertes Deployment und die dafür benötigten Prozesse geht. Ebenso empfehlenswert ist Web Operations von John Allspaw 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 Produktionsprobleme von Web- und Enterprise-Anwendungen steigern 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] werden 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- lis und Damon Edwards einen Podcast zum Thema an [34]. Außerdem gibt es einen gut sortierten wöchentlichen Newsletter, zusammengestellt von Gareth Rushgrove [35]. Dr. Patrick Peschlow ist Performance Engineer bei der codecentric AG. Er interessiert sich sehr für Performance und Effizienzsteigerung in den verschiedensten Bereichen der IT, von JVM-Tuning über parallele Programmierung und Cloud-Architekturen bis hin zu Softwareentwicklungsprozessen. Links & Literatur [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] Udo Pracht: Gemeinsam produktiv werden, in WIRTSCHAFTSINFORMATIK & MANAGEMENT, Ausgabe 04/2011 [30] [31] [32] [33] [34] [35] 10 javamagazin Software & Support Media GmbH

11 Notizen Software & Support Media GmbH javamagazin

12 codecentric AG Kölner Landstraße Düsseldorf Tel: +49 (0) Fax: +49 (0) blog.codecentric.de