• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Die devops-bewegung
 

Die devops-bewegung

on

  • 1,630 views

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 ...

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.

Statistics

Views

Total Views
1,630
Views on SlideShare
1,630
Embed Views
0

Actions

Likes
1
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Die devops-bewegung Die devops-bewegung Document Transcript

    • inkl.JAVA Mag CD Open Source BPM: Tools und Strömungen 86 1.2012 magazin Java • Architekturen • Web • Agile www.javamagazin.de NIO2 Product LineCD-INHALT Erweiterungen der Engineering mit OSGi I/O-Funktionalität 27 Ein sinnvolles Paar? 105 Erste Sessions ab Seite 43 DEVOPS-KEYNOTE von Matthias Marschall Video von der W-JAX 2011 HIGHLIGHT SonderdruckEntwicklung und ChameRIA 1.5.0 für Cucumber-chef v1.0.4-0 www.codecentric.de jBPM 5.1.0.Final DevOps Ops Betrieb zusammen- bringen 32, 41 WEITERE INHALTE Infrastructure • H-Ubu • Apache POI 3.8 beta 4 as Code • Activiti 5.8 mit Chef 53 Alle CD-Infos ab Seite 3 GWT & HTML5 Google Dart Spring ohne XML Das große Die neue Programmier- Java-basierte Web-Tutorial S. 60 sprache S. 75 Konfiguration S. 96
    • Sonderdruck 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 de. Die Konferenz hieß DevOpsDays und wurde die erste in einer ganzen Reihe gleichartiger Konferen- Als Patrick Debois vor gut zwei Jahren eine Konferenz zen. Seit diesen ersten DevOpsDays wird der Begriff in Belgien organisierte und nach einem Namen dafür „DevOps“ in immer größerem Maße verwendet und suchte, konnte er nicht ahnen, dass sich dieser Name ist heute vielbeachtet. Bekannte Analysten wie Gartner schon bald darauf wie ein Lauffeuer verbreiten wür- [1] oder Forrester [2] haben DevOps auf ihrem Radar2 javamagazin 1 | 2012 © Software & Support Media GmbH www.JAXenter.de
    • Sonderdruckund liefern kritische Einschätzungen. Verschiedene der für den IT-Betrieb (Operations) steht. Die Kombi-Unternehmen bieten integrierte „DevOps-Lösungen“ nation zum gemeinsamen „DevOps“ symbolisiert intui-an, namhafte Hersteller geben ihren Produkten den tiv einen Schulterschluss zwischen SoftwareentwicklernDevOps-Stempel und man liest Schlagzeilen wie „VM- und IT-Betrieb. Und tatsächlich ist das der Grundge-ware goes DevOps“. Interessanterweise existiert trotz danke von DevOps und der Auslöser der dazugehörigendes aktuellen Hypes keine gemeinsame Vorstellung da- Bewegung: ein Zusammenrücken der beiden in der tra-von, worum es bei DevOps eigentlich geht. Das Ziel ditionellen Wahrnehmung grundverschiedenen Bereichedes vorliegenden Artikels ist es daher, ein klares Bild Softwareentwicklung und IT-Betrieb. Diese kurze Erklä-davon zu vermitteln, was DevOps ist und was es für rung hat den Vorteil, dass wir uns spontan etwas unterunsere tägliche Arbeit bedeutet. DevOps vorstellen können. Andererseits lässt sie aber eine große Bandbreite an Interpretationen zu, was leichtAus Dev und Ops mach DevOps zu Missverständnissen führen kann. Aktuell sieht dieDer Begriff setzt sich zusammen aus „Dev“, der die Soft- DevOps-Bewegung ihre Hauptaufgabe darin, die vielenwareentwickler (Developers) repräsentiert, und „Ops“, Interpretationen zu kanalisieren und eine klare Definiti-www.JAXenter.de © Software & Support Media GmbH javamagazin 1 | 2012 3
    • Sonderdruck on von DevOps zu formulieren. Wir werden in der Folge • Die Entwicklung gibt ein neues Release zum Deploy- klären, wie der Begriff „DevOps“ heute aufzufassen ist. ment an den Betrieb weiter, dem es aber einfach nicht Zunächst betrachten wir aber den zugrunde liegenden gelingt, die Software auf der Produktiv­ mgebung u Konflikt zwischen Dev und Ops. lauffähig zu machen. Als der Betrieb die Entwickler kontaktiert und die auftretenden Fehler beschreibt, Der traditionelle Konflikt zwischen Entwicklung blocken diese jedoch ab: Die Software würde auf der und Betrieb Entwicklungsumgebung fehlerfrei laufen und des- Etwas vereinfacht besteht die Aufgabe von Softwareent- halb wäre klar, dass der Fehler beim Betrieb läge. In wicklern darin, die vom Auftraggeber gewünschten der Folge beschuldigen sich beide Seiten gegenseitig, Funktionen möglichst schnell umzusetzen. Wird eine schuld an dem Problem zu sein. Es kommt zu Krisen- neue Funktion verfügbar, ergibt sich ein potenzieller sitzungen und vielen bösen Telefonaten bzw. E-Mails Mehrwert für die Endnutzer. Oft wird dieser Mehrwert zwischen den Abteilungen und an die Vorgesetzten. schon bei der ersten Abnahme durch den Auftragge- Eine Untersuchung ergibt schließlich, dass sich Ent- ber anerkannt. Je häufiger neue Features komplettiert wicklungs- und Produktivumgebung in einem wichti- werden, desto positiver werden die Entwickler wahrge- gen Detail unterscheiden (z. B. die Verwendung einer nommen. Es ist für die Entwickler dabei weitestgehend Komponente im Clustering-Modus), was aber keiner irrelevant, ob die neuen Features tatsächlich auf dem der beiden Seiten vorher bewusst war. Produktionssystem verfügbar sind. • Der Benutzeransturm auf die neue Webseite ist so Ebenfalls vereinfacht gesagt, besteht die Aufgabe des groß, dass die Antwortzeiten schon bald immer grö- IT-Betriebs darin, die von der Entwicklung gelieferte ßer werden und einige Stunden später die Seite kom- Software auf der Produktivumgebung für die Endnut- plett zusammenbricht. Aus Geschäftssicht ist das zer verfügbar zu machen. Dazu zählen das Deploy- eine Katastrophe. Aber das erste, was die beteiligten ment neuer Softwarereleases und die Sicherstellung Lager (Entwicklung, Betrieb und gegebenenfalls des laufenden Betriebs unter bestimmten Qualitätsan- weitere Abteilungen für Datenbankadministration, forderungen. Der Betrieb trägt also die unmittelbare Qualitätssicherung etc.) machen, ist heftig über die Verantwortung für die Verfügbarkeit der Anwendung, vermeintliche Ursache zu spekulieren: „Das muss und sein Erfolg wird daran gemessen, inwieweit die ganz klar ein Datenbankproblem sein!“ oder „Das gegebenen Qualitätsanforderungen erreicht werden. sind bestimmt die neuen Server schuld!“ Erst viel Die Erwartungshaltung der Nutzer ist in der Regel die später wird eine objektive Analyse gestartet, zu volle Verfügbarkeit und Sicherheit der Anwendung. diesem Zeitpunkt haben die Kunden aber bereits Ist nun zum Beispiel die Verfügbarkeit einmal beein- akzeptiert, dass die neue Webseite ein Desaster ist. trächtigt, fällt das direkt auf den Betrieb zurück. Die • Im Produktivsystem taucht ein ärgerliches Perfor- Folge ist eine stark negative Wahrnehmung durch die manceproblem auf. Unter großem Druck arbeiten Auftraggeber, besonders wenn die Nutzer der Anwen- die Entwickler mehrere Nächte durch und liefern dung ein Problem melden, noch bevor die verwendeten schließlich einen Patch. Der Betrieb jedoch hat Be- Monitoring-Systeme Alarm schlagen. Um die Wahr- denken, dass der Patch die Stabilität des Systems scheinlichkeit für unerwartete Ausfälle zu minimieren, gefährdet, weil er Änderungen an einer kritischen setzt der Betrieb deshalb oft alles daran, den Zustand Komponente umfasst. Deshalb wird zunächst eine einer stabil laufenden Anwendung vor Änderungen zu genaue Qualitätskontrolle auf einer Testumgebung schützen. verlangt, um die Lösung in realistischen Testszenari- Dieser Vergleich der Aufgaben von Entwicklung und en zu überprüfen. Leider lässt sich die benötigte Last Betrieb zeigt, dass beide Abteilungen entgegengesetzte in der Testumgebung aber nicht adäquat darstellen. Anreize haben. Die Entwicklung ist an schnellen und Viel Zeit vergeht, und einen Monat später ist der häufigen Releases interessiert, der Betrieb hingegen wür- Patch immer noch nicht eingespielt. Die Entwickler de Releases am liebsten vermeiden. Beide Seiten verfol- sind enttäuscht, weil „es ja offenbar doch nicht so gen damit das gleiche Ziel, nämlich ihren eigenen Wert eilig war“. für das Unternehmen zu beweisen. Genau das führt aber regelmäßig zu Konflikten, Anfeindungen und schlechter Wer solche Situationen noch nicht erlebt hat, kann Laune. sich glücklich schätzen. Wer das Blame Game hingegen kennt, der weiß, dass man die dadurch verlorene Zeit Blame Game besser zur Lösung des Problems hätte verwenden sollen. In der Regel treffen Devs und Ops unter Zeitdruck Schuldzuweisungen und das Sich-darüber-ärgern sind aufeinander, zum Beispiel beim Deployment eines neu- im Nachhinein immer noch möglich. en Releases oder wenn es ein Problem (wie einen Sys- temausfall) gibt. Es beginnt dann das typische Blame Der Betrieb als Flaschenhals Game, bei dem beide Lager sich gegenseitig die Schuld Im Laufe der Zeit haben wir uns an das Blame Game an der Situation geben. Ein paar Beispiele: gewöhnt. Seit die Softwareentwicklung jedoch verstärkt4 javamagazin 1 | 2012 © Software & Support Media GmbH www.JAXenter.de
    • Sonderdruck DevOps hat die Ideen der agilen ­Bewegung um ­zwischenmenschliche ­Komponenten ergänzt.agile Methoden einsetzt, eskaliert die Situation. Metho- den Vordergrund gestellt worden. Bezeichnend ist einden wie Scrum setzen auf laufende Interaktion zwischen Statement von Patrick Debois, veröffentlicht auf sei-Auftraggebern und Entwicklern sowie kurze Release- nem Blog im Anschluss an die ersten DevOpsDays:zyklen, in der Regel setzt sich die damit einhergehende „And remember it‘s all about putting the fun back intoPhilosophie aber nicht in den Betrieb fort. Im Endeffekt IT!“werden die Vorteile agiler Methoden also ausgebremst, Für viele Vertreter der Bewegung ist gegenseitigerwenn man dabei die letzte Meile, konkret Deployment Respekt die dringlichste Verbesserung im Umgang zwi-und Betrieb, außer Acht lässt. Softwarereleases werden schen Entwicklung und Betrieb, denn er ist eine Vor-dann zwar in kurzen Iterationen erstellt, der geschaf- aussetzung für Vertrauen und gute Zusammenarbeit.fene Mehrwert wird aber erst viel später auf der Pro- Kulturelle Bausteine einer besseren Zusammenarbeitduktivumgebung sichtbar. Die immer kürzer werdenden sind zum Beispiel Selbstverpflichtung der BeteiligtenReleasezyklen offenbaren den Betrieb zunehmend als auf Ziele, aufmerksames Zuhören, gegenseitige Weiter-Flaschenhals auf dem Weg der Software zum Endnut- bildung und die Etablierung gemeinsamer Werte. Mitzer. Auch erhöhen häufig stattfindende Releases das einer respektvollen und vertrauensvollen Zusammen-Potenzial für das direkte Aufeinandertreffen und damit arbeit, so die Überlegung, lässt sich das Blame Gameauch das Blame Game zwischen Softwareentwicklung vermeiden. Das erklärte Ziel der DevOps-Bewegungund Betrieb. in zwischenmenschlicher Hinsicht ist also gewisserma- ßen, die aus den agilen Methoden gezogenen LehrenEine Bewegung formiert sich eine Ebene nach oben zu ziehen und abteilungsüber-In den letzten Jahren entschied sich eine Reihe von greifend zu etablieren.Leuten unabhängig voneinander dafür, etwas gegenden Konflikt zwischen Entwicklung und Betrieb zu un- Automatisierungternehmen. Sie sammelten Erfahrung, trafen sich und Ein zentraler Gedanke von DevOps ist die Automatisie-tauschten sich aus, und wurden schließlich zu dem, was rung von Vorgängen, die sonst manuell durchgeführtman heute als DevOps-Bewegung bezeichnet. Es ver- werden und daher wenig transparent sind beziehungs-wundert nicht, dass es sich dabei fast ausschließlich um weise sich nur schlecht für eine Qualitätskontrolle eig-Beschäftigte im IT-Betrieb (und nicht etwa um Entwick- nen. Ermöglicht wird eine Automatisierung durch dieler) handelte. Die oft negative Wahrnehmung führte zu Nutzung geeigneter Tools. Viele DevOps-Anhängereinem Wunsch nach Veränderung, vor allem zu dem bezeichnen Infrastructure as Code als wichtigsten Be-Wunsch nach einem neuen Selbstbewusstsein, weg da- standteil der Automatisierung. Mit diesem Ansatz wer-von als langsam zu gelten und weg von Parolen wie „Ein den sämtliche benötigten Vorgänge zum Aufsetzen vonguter Tag ist, wenn heute keine Katastrophe passiert“. Infrastruktur oder zum Durchführen von DeploymentsDie Parallelen zu den Anfängen der agilen Bewegung in Quellcode repräsentiert. Es können dann viele der insind offensichtlich. Tatsächlich gab es schon vor der der Softwareentwicklung üblichen Lösungen zur Qua-DevOps-Bewegung Bestrebungen wie Agile Operations litätskontrolle auch vom Betrieb eingesetzt werden.oder Agile System Administration, um auch im IT-Be- Mögliche Vorzüge des Infrastructure-as-Code-Ansat-trieb verstärkt agile Methoden einzusetzen. Der Schlüs- zes sind folgende:sel für den Erfolg der DevOps-Be­ e­ ung war nun, dass w gsie die Software­ ntwicklung mit ins Boot geholt und da­ e • Zentrale Verwaltung des Quellcodes unter Nutzungdurch die Anzahl der potenziell Interessierten stark ver- von Versionskontrolle.größert hat. DevOps hat die Ideen von Agile Operations • Hohe Transparenz und Vermeidung von Wissensin-und Co. aufgegriffen, diese aber um zwischenmensch- seln.liche Komponenten ergänzt. In den letzten zwei Jahren • Automatisiertes Testen der Konfiguration von Ser-wurden verschiedene Ziele von DevOps formuliert. Sie vern und virtuellen Maschinen.lassen sich in drei Bereiche einteilen: Zusammenarbeit, • Automatisiertes Testen von Deployments und der an-Automatisierung und Prozesse. schließenden Verfügbarkeit von beteiligten Systemen und geschäftskritischen Softwarefunktionen.Zusammenarbeit • Gemeinsame Nutzung von Konfigurations- undVor allem in der frühen Phase der DevOps-Bewegung Deployment-Vorschriften durch Entwicklung undist die zwischenmenschliche Komponente stark in Betrieb.www.JAXenter.de © Software & Support Media GmbH
    • Sonderdruck Ein zentraler Gedanke von DevOps ist die Automatisierung von Vorgängen. Grundlegend für eine Realisierung von Infrastructure Prozesse as Code sind Tools zum Konfigurationsmanagement, Für die Einführung von DevOps-Ideen in Unternehmen zum Beispiel Puppet [3], Chef [4] (siehe auch Artikel ist es essenziell, Prozesse zu haben. In diesem Bereich von Martin Eigenbrodt, im Java Magazin 1.2012, Sei- hat die DevOps-Bewegung noch einiges zu tun und muss te 53) oder das ältere CFengine [5]. Diese Tools bie- erst noch konkrete Vorschläge erarbeiten. Ein zynischer ten domänenspezifische Sprachen (DSLs) an, um den Tweet von „DevOps Borat“ [17] zum Thema DevOps- gewünschten Endzustand des Systems auf einer abs- Prozesse: „To make error is human. To propagate error trakten, plattformübergreifenden Ebene zu beschrei- to all server in automatic way is #devops.“ Natürlich ben. Hinter den Kulissen werden diese Vorgaben dann ist der Kommentar nicht ganz ernst zu nehmen, er spie- mittels vordefinierter Abbildungen auf den jeweiligen gelt aber deutlich eine Sorge vor blindem Aktionismus Zielsystemen ausgeführt. Eine verwandte Gruppe von wieder, bei dem die Funktionen von Entwicklung und Tools konzentriert sich auf ein automatisiertes Deploy- Betrieb ohne die Beachtung möglicher Risiken zusam- ment und die koordinierte Ausführung von Aktionen mengeworfen werden. auf laufenden, verteilten Servern. In der Regel bieten Die meisten Befürworter von DevOps sind sich einig, diese Tools ebenfalls DSLs an, um Abfolgen von Kom- dass es weder notwendig noch wünschenswert ist, Ent- mandos zu beschreiben. Vertreter dieser Kategorie sind wicklung und Betrieb zusammenzulegen. Interdiszipli- Capistrano [6], ControlTier [7], Fabric [8], RunDeck näre Experten, die an der Schnittstelle zwischen beiden [9] und Marionette Collective [10]. Zur Versionskon- Bereichen arbeiten, können natürlich trotzdem hilfreich trolle der formulierten Vorschriften (in der jeweils sein. Definitiv ist „DevOps“ jedoch nicht als Stellen- verwendeten DSL) sind die üblichen Verdächtigen wie oder Rollenbezeichnung zu sehen. Allgemein besteht bei Mercurial oder Git einsetzbar. der Definition von DevOps-Prozessen eine Schwierigkeit Zum automatisierten Testen der Quellcodes bietet darin, dass in vielen kleineren Unternehmen die Grenze sich ein BDD-Tool wie Cucumber [11] an, das gemein- zwischen Entwicklung und Betrieb nicht so streng gezo- sam mit Puppet oder Chef genutzt werden kann. Er- gen wird wie in großen Unternehmen. Es ist daher frag- weiterungen wie Cucumber-Nagios [12] ermöglichen es lich, ob Prozesse und Vorgehensweisen, die für kleine außerdem, die Ausgaben direkt im Format bestimmter Unternehmen gut funktionieren, auch in großen Unter- Monitoring-Tools zu erzeugen. Ein BDD-Ansatz ist be- nehmen anwendbar sind. Dennoch oder gerade deshalb sonders deshalb zu empfehlen, weil er eine Kultur des ist es ein erklärtes Ziel der DevOps-Bewegung, geeignete Testens mit sich bringt, bei der interessante Anwen- Prozesse für die Einführung und Nutzung von DevOps- dungsfälle und nicht nur die bloße Verfügbarkeit von Ideen zu definieren. Servern getestet werden. Mit Continuous-Integration- Servern wie Hudson [13] oder Jenkins [14] können Missverständnisse und Kritik diese Tests zudem automatisiert ausgeführt werden. Die genannten Ziele von DevOps sind alle nachvoll- Besonders für Entwickler interessant dürften Tools zur ziehbar. Allerdings hat die fehlende Fokussierung der vollautomatischen Installation von Betriebssystemen DevOps-Bewegung auf ein klares, übergeordnetes Ziel oder virtuellen Maschinen sein. Neuere Vertreter dieser zu diversen Missverständnissen und Kritikpunkten ge- Kategorie sind zum Beispiel Cobbler [15] oder Vagrant führt. Betrachten wir eine Auswahl davon: [16]. Es ist ein erklärtes Ziel der DevOps-Bewegung, die • „DevOps ist nur ein Werbename, um altbekannte Automatisierung von Vorgängen im IT-Betrieb und die Dinge als neu anzupreisen.“ Fast ausnahmslos ge- gemeinsame Nutzung von Tools zwischen Entwicklung hören die Gründer der DevOps-Bewegung selbst und Betrieb zu fördern. Beispielsweise können die Ent- zu den Leuten, die schon vorher DevOps- Ansätze wickler ihre verwendete Konfiguration der Infrastruktur verfolgt haben. Sie wissen natürlich, dass viele der (z. B. als Puppet-Manifeste) an den Betrieb weitergeben vorgeschlagenen Praktiken und Tools keine funda- und mit diesem abstimmen. Oder aber Entwicklung mentale Neuheit darstellen. Dennoch haben sie eine und Betrieb entwickeln den Infrastrukturcode direkt ungeheure Aufmerksamkeit für ein Problem erreicht, gemeinsam und schließen somit von vornherein Inkom- über das vorher in der Öffentlichkeit nicht viel gere- patibilitäten zwischen den Entwicklungs-, Test- und det wurde. Allein das ist schon ein großer Erfolg. Die Produktivumgebungen aus. Initiatoren der Bewegung betonen übrigens regelmä-6 javamagazin 1 | 2012 © Software & Support Media GmbH www.JAXenter.de
    • ICH IE S NS RM IERE BER Ü NINFO jETZT CHSTE Ä RE N S UNS E S HOP W ORK ND U NGEN ULU SCH Mehr dazu unter: www.codecentric.de
    • Sonderdruck ßig, dass DevOps für sie keine Geldmaschine ist, und zunächst einmal verstehen, was die jeweils andere müssen sich sogar Vorwürfe gefallen lassen, warum Seite eigentlich macht und wie die alltäglichen Her- sie nicht versuchen, aus DevOps mehr Kapital zu ausforderungen aussehen, bevor sie deren Leistung schlagen [18]. auch nur entfernt beurteilen können. Letzten Endes • „DevOps ist ein Freifahrtschein für Entwickler, sind Teammitglieder, die mangelhafte Leistung brin- beliebigen Schaden auf dem Produktivsystem anzu- gen, natürlich ein Problem, aber kein spezielles von richten.“ DevOps verlangt nicht, dass die Entwickler Dev­Ops. Schreibrechte auf den Servern des Produktivsystems • „DevOps wird durch PaaS-Angebote überflüssig.“ oder gar deren Root-Passwort erhalten. Man kann Das ist eine ernstzunehmende Kritik, denn die Nut- einheitliche Deployment-Prozeduren und Infrastruc- zung so mancher Cloud-Angebote kann die konkre- ture as Code auch unter Wahrung gewisser sinnvoller ten Aufgaben des Betriebs deutlich beeinflussen. Die Beschränkungen einsetzen. Entgegnung der DevOps-Verfechter ist, dass durch • „DevOps möchte Entwicklung und Betrieb durch PaaS lediglich eine weitere Abstraktionsschicht eine Elite von Alleskönnern ersetzen.“ Das Her- bzw. neue Schnittstelle für die klassischen Funktio- anzüchten einer solchen Elite wäre absurd. Nicht nen des Betriebs (wie Deployment, Monitoring und ohne Grund wurden vor vielen Jahren eine Spezi- Sicherstellung der Qualitätsanforderungen) ent- alisierung und die daraus resultierende Trennung steht. Man kann also trotzdem nicht ohne Betrieb von Entwicklung und Betrieb eingeführt. DevOps auskommen. versucht vielmehr, die Zusammenarbeit und den Wissensaustausch zwischen diesen Bereichen zu Worum geht es bei DevOps wirklich? verbessern. Insgesamt lässt sich sagen, dass DevOps ähnliche • „DevOps möchte den Betrieb abschaffen und die Herausforderungen wie die agilen Methoden zur Entwickler alles machen lassen.“ Dieser Gedanke, oft Softwareentwicklung lösen möchte, nur abteilungs- auch als Ruf nach „NoOps“ formuliert, ist ebenfalls übergreifend. Dadurch wird es natürlich schwieriger, absurd. Die treibende Kraft hinter Dev­ ps sind Be- O geeignete Lösungen zu finden. Vor allem aber wird es schäftigte im IT-Betrieb, und es ist nicht deren Ziel, schwieriger, DevOps-Ansätze in der Praxis zu etablie- sich abzuschaffen. ren. Wegweisend für DevOps sind hier die Antworten • „Mit DevOps müssen wir neue Tools lernen.“ auf zwei grundlegende Fragestellungen: Das mag sein, aber warum so negativ? Es ist für DevOps-Neulinge eine naheliegende Entscheidung, 1. Was für einen Anreiz haben Entwicklung und den Einstieg über Tools zu finden. Man kann Betrieb, viel Zeit und Aufwand in gemeinsame Un- gerade durch Automatisierung einen schnellen ternehmungen zu stecken, wenn der Tag ohnehin Mehrwert erhalten und außerdem eine gemeinsame schon zu kurz ist, um die eigene Arbeit zu schaf- Basis für die Zusammenarbeit von Entwicklung fen? Was für ein Anreiz besteht für den Betrieb und Betrieb schaffen. Interessant in diesem Zusam- darin, unbekannte Tools zur Automatisierung zu menhang ist eine Umfrage, die Replay Solutions im nutzen, wenn die selbstgeschriebenen Shell-Skripte Frühjahr 2011 durchgeführt hat und laut der Tools schon seit Jahren im Einsatz sind? Grundlegend als sehr wichtig für den Erfolg von DevOps ange- für eine Etablierung von DevOps ist deshalb die sehen werden. Verbesserungen erhoffen sich die Schaffung von Anreizen für alle Beteiligten. Diese Befragten vor allem beim Defect Tracking und der Anreize können aber letzten Endes nur über die Versionskontrolle [19]. Eine Umfrage von Puppet Zielvorgaben der Geschäftsführung geschaffen Labs vom Sommer 2011 bestätigt diesen Eindruck: werden. Mit deutlichem Abstand wird die Automatisierung, 2. Was für einen Anreiz hat die Geschäftsführung, z. B. mit Tools zum Konfigurationsmanagement, DevOps-Ansätze in ihrem Unternehmen einzu- als größte erhoffte Verbesserung durch DevOps führen? Betrachten wir die Frage „Was bringt uns genannt [20]. Danach erst folgen abstraktere Ziele DevOps?“ aus der Sicht der Geschäftsführung, so wie die Optimierung von Deployment-Prozessen wird schnell klar, dass DevOps nur dann inter- oder die Verbesserung der Kommunikation zwi- essant ist, wenn es einen (finanziellen) Mehrwert schen den Abteilungen. liefert. • „Manchen Leuten kann man einfach keinen Respekt entgegenbringen.“ Tatsächlich entstehen Respekt In letzter Zeit kristallisiert sich daher immer mehr eine und Vertrauen nicht auf Knopfdruck, sondern müs- neue Wahrnehmung des von DevOps adressierten Pro- sen durch Leistung „erworben“ werden. Man wird blems heraus. Die eingangs beschriebenen Ziele von immer wieder Leute finden, die keine ausreichende DevOps beschäftigen sich mit Symptomen, ignorieren Leistung bringen und deshalb niemals das Vertrauen aber das Kernproblem. Die anfänglichen Rufe nach ihrer Teammitglieder erhalten. Dennoch gilt im Kon- mehr Zusammenarbeit oder besseren Tools versuchen, text von DevOps: Entwicklung und Betrieb müssen den Alltag von Entwicklung und Betrieb angenehmer8 javamagazin 1 | 2012 © Software & Support Media GmbH www.JAXenter.de
    • Sonderdruck 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 mobili- an DevOps-Ansätzen versuchen, wird DevOps für unssieren und Aufmerksamkeit zu erzeugen, er überzeugt eine stärkere Fokussierung auf bestimmte Elemente inaber nicht unbedingt die eigentlichen Entscheider, unserem Arbeitsalltag bedeuten:DevOps in einem Unternehmen einzuführen. Es istdeshalb nötig, das zugrunde liegende Problem als ein • In der Softwareentwicklung werden wir uns zuneh-Geschäftsproblem zu sehen: Wie lässt sich maximaler mend mit Aspekten aus dem Betrieb auseinander-Gewinn in kürzester Zeit generieren? Wie lässt sich die setzen, z. B. dem Aufsetzen von physikalischen oderursprüngliche Idee einer Software (die Vision) schnell virtuellen Maschinen, der Absicherung von Systemenund dennoch stabil zum Kunden beziehungsweise zum oder der minutiösen Planung und Durchführung vonEndnutzer bringen, sodass sie einen Mehrwert bezie- Deployments. Dazu werden wir vermehrt Tools zurhungsweise Einnahmen für das Unternehmen gene- Automatisierung einsetzen, und zwar gemeinsam mitriert? Ein wenig ironisch an dieser Entwicklung ist, Beschäftigten aus dem Betrieb, von denen wir auchdass der Name DevOps zwar ursprünglich sehr gut lernen werden. Wir werden mehr Verantwortung fürgepasst hat, aber aktuell die Sicht auf das eigentliche unsere Software und auf der ProduktivumgebungGeschäftsproblem verdeckt. auftretende Probleme übernehmen. Wir werden Betrachten wir die Dinge noch ein wenig nüchterner, schnelles Troubleshooting im Ernstfall unterstützen,so müssen wir feststellen, dass wir nicht dafür bezahlt durch mit dem Betrieb abgestimmtes Logging undwerden, Spaß bei der Arbeit zu haben. Für das Unter- Monitoring, und vielleicht sogar ins Alerting mitnehmen zählt in erster Linie das Ergebnis. Stimmt das einbezogen werden. Wir werden unsere SoftwareErgebnis, so gibt es aber kein Geschäftsproblem und es robuster machen, z. B. durch die Verwendung vonwird auch keine Lösung wie DevOps benötigt. Ideal ist Feature-Flags, mit denen neue Funktionen bei Bedarfnatürlich, wenn der Unternehmenserfolg mit Metho- (d. h. im Fehler- oder Problemfall) unkompliziert vonden gesteigert werden kann, die den Mitarbeitern auch außen wieder abgeschaltet werden können. Im Java-Spaß machen. Allein das Argument, dass sich Entwick- Umfeld können die Voraussetzungen für Feature-lung und Betrieb freuen, wenn man ein bestimmtes Flags bequem durch MBeans realisiert werden.Tool einführt oder gemeinsam Pizza isst, zieht aller- • Im IT-Betrieb werden wir verstärkt auf Automati-dings nicht. Die Einführung einer Maßnahme wie „Wir sierung setzen, mit Infrastructure as Code, Versions-machen jetzt DevOps!“ muss erst nötig werden, zum kontrolle und automatisierten Tests. Wir werden inBeispiel weil die aktuellen Zahlen das aussagen, und diesem Bereich von der Softwareentwicklung lernen.genauso muss auch der Erfolg der Maßnahme quanti- Außerdem werden wir agile Methoden wie Kanbanfizierbar sein. Das Stichwort ist hier die Messbarkeit. anwenden, möglicherweise gemeinsam mit den Ent-Wir benötigen hierzu kombinierte Metriken für die ge- wicklern. Wir werden uns auf häufige Releases ein-meinsame Leistung von Betrieb und Entwicklung. Sie stellen müssen und den Prozess diesbezüglich mit denkönnen die bis dato verwendeten Metriken ergänzen Entwicklern abstimmen. Wir werden gemeinsam mitoder ersetzen. den Entwicklern geeignete Metriken definieren, um Zum Vergleich: Es führt auch kein Unternehmen problematische Situationen auf dem ProduktivsystemAgilität ein, wenn es sich davon nicht eine Steigerung schneller zu erkennen. Darüber hinaus werden wirdes Gewinns verspricht. Daher liegt auch für DevOps frühzeitig in die Planung der Anforderungen an dieder Weg zum Erfolg im Business Case. Und wie bei den Software mit einbezogen werden.agilen Methoden auch lässt sich der Business Case inerster Linie über Success-Stories nachweisen. Für die Zudem können wir davon ausgehen, dass eine Einfüh-DevOps-Bewegung ist es daher essenziell, nicht nur rung von DevOps abteilungsübergreifende Metriken mitüber Techniken und Tools nachzudenken, sondern in sich bringen wird, um den Erfolg zu messen. Auf solcheerster Linie über die Erfolgserlebnisse durch DevOps gemeinsamen Metriken, und damit gemeinsame Anreizezu berichten. für Entwicklung und Betrieb, müssen wir uns einstellen.Was kommt mit DevOps auf uns zu? Wo finde ich weitere Informationen zu DevOps?Unabhängig davon, ob nun die Geschäftsführung die Die meisten relevanten Informationen zu DevOps fin-Einführung von DevOps vorgibt oder wir uns autonom det man aktuell in Blogs. Pflichtlektüre für DevOps-www.JAXenter.de © Software & Support Media GmbH javamagazin 1 | 2012 9
    • Sonderdruck Interessierte ist der Blog von Patrick Debois, auf dem lis und Damon Edwards einen Podcast zum Thema an man aktuelle Ansichten zur DevOps-Bewegung und [34]. Außerdem gibt es einen gut sortierten wöchentli- konkrete Beispiele für die Nutzung von DevOps- chen Newsletter, zusammengestellt von Gareth Rush­ Tools findet [21]. Stephen Nelson-Smith führt einen grove [35]. 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 Dr. Patrick Peschlow ist Performance Engineer bei der codecen- auch einige wegweisende Beiträge aus der Anfangszeit tric AG. Er interessiert sich sehr für Performance und Effizienzstei- gerung in den verschiedensten Bereichen der IT, von JVM-Tuning [23]. Kief Morris führt einen Blog über Continuous über parallele Programmierung und Cloud-Architekturen bis hin zu Delivery, mit vielen DevOps-orientierten Beiträgen Softwareentwicklungsprozessen. und Gedanken zur Umsetzung in der Praxis [24]. Der Blog „Agile Web Development & Operations“, von Matthias Marschall und anderen geschrieben, bietet Links & Literatur ausgewogenen und durchdachten Inhalt. Für Einstei- ger dürfte insbesondere die Serie von Gastbeiträgen [1] http://www.gartner.com/technology diverser DevOps-Größen lesenswert sein [25]. Weitere [2] http://www.forrester.com/rb/research interessante Blogs sind „Agile Operations“ [26] von [3] http://puppetlabs.com Scott Wilson und „The agile Admin“ [27] von Ernest [4] http://www.opscode.com/chef Mueller. Die Webseite „Planet DevOps“ schließlich [5] http://cfengine.com ist ein zentraler Einstiegspunkt, auf dem sich Beiträge [6] http://github.com/capistrano von verschiedenen Autoren befinden [28]. Deutsch- sprachige Artikel zu DevOps sind zurzeit noch eine [7] http://controltier.org Rarität. Ein kürzlich erschienener Zeitschriftenartikel [8] http://fabfile.org von Udo Pracht bietet aber einen guten Einstieg in das [9] http://rundeck.org Thema [29]. [10] http://docs.puppetlabs.com/mcollective Da DevOps noch in der Findungsphase ist, wurde [11] http://cukes.info noch kein ganzheitliches Buch zu diesem Thema veröf- [12] http://auxesis.github.com/cucumber-nagios fentlicht (da ist zwar „DevOps“ von Kevin Roebuck, es [13] http://hudson-ci.org hat aber wenig mit der DevOps-Bewegung zu tun und ist nicht zu empfehlen). Es gibt jedoch hervorragende [14] http://jenkins-ci.org Bücher zu verwandten Themen mit klarem Bezug zu [15] http://fedorahosted.org/cobbler Dev­ ps. Sehr empfehlenswert ist „Continuous Delive- O [16] http://vagrantup.com ry“ von Jez Humble und David Farley, in dem es um [17] http://twitter.com/#!/DEVOPS_BORAT Konfigurationsmanagement, automatisiertes Deploy- [18] http://teddziuba.com/2011/03/devops-scam.html ment und die dafür benötigten Prozesse geht. Ebenso [19] http://replaysolutions.com/2011-DevOpsSurveyResults empfehlenswert ist „Web Operations“ von John All- spaw und Jesse Robbins, was sich unter anderem mit der [20] http://rww.to/qiAxu1 Wichtigkeit geeigneter Metriken beschäftigt. Auch gibt [21] http://www.jedi.be/blog es Bücher zu verschiedenen DevOps-Tools, zum Beispiel [22] http://agilesysadmin.net/ „Test-Driven Infrastructure with Chef“ von Stephen [23] http://dev2ops.org Nelson-Smith. Zu erwähnen ist außerdem „Release It!“ [24] http://kief.com von Michael Nygard, das bereits heute ein Klassiker ist. [25] http://www.agileweboperations.com/devops-series Dieses Buch ist vor allem Entwicklern zu empfehlen, die [26] http://agileoperations.net/index.php?frontpage ihre Sensibilität für mögliche unerwartete Produktions- probleme von Web- und Enterprise-Anwendungen stei- [27] http://theagileadmin.com gern möchten. [28] http://www.planetdevops.net Was Konferenzen betrifft, so sind die DevOpsDays [29] do Pracht: „Gemeinsam produktiv werden“, in U [30] die vermutlich wichtigste Konferenz im DevOps- WIRTSCHAFTSINFORMATIK & MANAGEMENT, Ausgabe 04/2011 Umfeld. Zu nennen ist weiterhin das Camp DevOps [30] http://devopsdays.org [31], das kürzlich zum ersten Mal stattgefunden hat. [31] http://campdevops.com Auf den bekannten Velocity-Konferenzen [32] wer- [32] http://velocityconf.com/velocity2011 den ebenfalls regelmäßig Beiträge zu Themen aus dem [33] http://puppetlabs.com/community/puppet-camp DevOps-Umfeld gemacht. Darüber hinaus gibt es auch toolspezifische Konferenzen wie das Puppet Camp [34] http://devopscafe.org [33]. Unter dem Titel „DevOps Cafe“ bieten John Wil- [35] http://devopsweekly.com10 javamagazin 1 | 2012 © Software & Support Media GmbH www.JAXenter.de
    • SonderdruckNotizenwww.JAXenter.de © Software & Support Media GmbH javamagazin 1 | 2012 11
    • codecentric AGKölner Landstraße 1140591 DüsseldorfTel: +49 (0) 211.9941410Fax: +49 (0) 211.9941444E-Mail: info@codecentric.dewww.codecentric.deblog.codecentric.de