eBook DevOps - New Relic · DevOps wurde geschaffen, um dieses Dilemma zu lösen, indem alle...

© 2015 New Relic, Inc. | +49 800 724-3111 | www.newrelic.de | www.twitter.com/newrelic | blog.newrelic.com

eBook

DevOpsWas es ist und warum es für Ihr Unternehmen von Bedeutung ist

http://www.newrelic.com

https://twitter.com/newrelic

http://blog.newrelic.com


InhaltEINLEITUNG 03

KAPITEL 1 Was ist DevOps? 04

KAPITEL 2 Wo kommt DevOps her? 06

KAPITEL 3 Welche Probleme führten zur Schaffung von DevOps? 08

KAPITEL 4 Wie funktioniert DevOps? 10

KAPITEL 5 Wer arbeitet mit DevOps? 13

KAPITEL 6 Warum finden Ihre Kollegen DevOps gut? 15

KAPITEL 7 Was nutzt DevOps mir? 19

SCHLUSSFOLGERUNG 21




eBook

03

DevOps: Was es ist und warum es für Ihr Unternehmen von Bedeutung ist


Einleitung Über DevOps gibt es ebenso viele Meinungen wie Kommentatoren, aber

eines ist klar: DevOps ist echt. Innerhalb einiger weniger Jahre änderten

sich die Schlagzeilen von „DevOps? Nie gehört!“1 oder „DevOps ist nichts

als ein schlechter Scherz“2 zu „DevOps: die neue Normalität“3 und „Drei

Gründe, warum Ihr Startup ohne DevOps erledigt ist“4. Von winzigen

Startups zu riesigen Fortune 500-Unternehmen – die IT-Branche sagt

zum DevOps-Konzept laut und deutlich „Ja“.

Aber trotzdem hat die breite Mehrheit von IT-Experten entweder

wenig Ahnung von DevOps oder ihr Verständnis beschränkt sich auf

Allgemeines. Wenn Sie zu dieser Kategorie gehören, dann sind Sie

hier richtig. Auf den folgenden Seiten beantworten wir eine Reihe

grundlegender Fragen, die Sie wahrscheinlich selbst auch stellen

würden:5

• Was ist DevOps?

• Woher kommt es?

• Welche Probleme führten zur Schaffung von DevOps?

• Wie funktioniert DevOps?

• Wie wird DevOps heute eingesetzt?

• Welche Gruppen arbeiten mit DevOps?

• Was sind die Vorteile?

1 James Turnbull, „What the F*** is DevOps?”, Blog-Post, https://coderwall.com/p/zhf8gq, Mai 2010.

2 Ted Dziuba, „DevOps is a Poorly Executed Scam“, Blog-Post, http://widgetsandshit.com/teddziuba/2011/03/devops-scam.html, März 2011.

3 „The New Normal of DevOps“, CA Technologies White Paper, http://www.ca.com/us/~/media/Files/whitepapers/the-new-normal-of-devops.pdf, Dezember 2013.

4 „Three Reasons Your Startup Will Suffer Without DevOps“, Readwrite, http://readwrite.com/2014/01/01/three-reasons-your-startup-needs-devops-or-else.

5 Damon Edwards, „The History of DevOps“, IT Revolution Press, http://itrevolution.com/the-history-of-devops.





KAPITEL 1

Was ist DevOps?




eBook

05



Der Begriff DevOps wurde 2009 von Patrick Debois geprägt, der dann

prompt zu einem seiner Gurus wurde. Er ist ein Zusammenschluss

der englischen Wörter für Entwicklung („Development“) und Betrieb

(„Operations“), und das sagt eigentlich schon alles. DevOps ist kein

Prozess, keine Technologie und kein Standard. Fans beschreiben DevOps

eher als „Kultur“, und das ist die Bezeichnung, die New Relic vorzieht.

Wir verwenden auch den Begriff „DevOps-Bewegung“, wenn es um

Themen geht wie Übernahmeraten und Trends für die Zukunft, und

„DevOps-Umgebung“, wenn wir uns auf eine IT-Organisation beziehen,

die die DevOps-Kultur bereits eingeführt hat.

Wir haben noch viel zu sagen zum Thema DevOps, aber hier ist erst

einmal eine nützliche Definition:

DevOps (ein Kunstwort aus Development und Operations) ist eine

Softwareentwicklungsmethode, die stark auf Kommunikation,

Kollaboration und Integration zwischen Softwareentwicklern und

IT-Experten beruht.6

6 „Big Data Drives Rapid Changes in Infrastructure and $232 Billion in IT Spending Through 2016“, Gartner Research, Oktober 2012.

7 Interview, 13. März 2014

Was ist DevOps?

„Erfolgreiches DevOps bedeutet gegenseitiger Respekt zwischen Entwicklung und Betrieb. Du lieferst hochwertigen Code und ich baue eine hochwertige Plattform, auf der der Code läuft. Wie wir das im einzelnen tun, darüber mögen wir unterschiedlicher Meinung sein, aber im Endeffekt liefern wir gemeinsam Software, die wie erwartet funktioniert und die Anforderungen unserer Kunden erfüllt.“7

—Mike Surma, DevOps Engineer, Rackspace





KAPITEL 2

Wo kommt DevOps her?




eBook

07



Um seinen Ursprung ranken sich diverse Legenden, aber trotzdem entstand

DevOps nicht einfach aus dem Nichts. Der Samen von DevOps wurde

vor langer Zeit gesät und von progressiven IT-Experten in zahlreichen

Disziplinen gepflegt. Ein Kommentator nennt DevOps einen „perfekten

Sturm“8, und hierfür gibt es jede Menge Belege. Zwei der wichtigsten

Vorläufer von DevOps waren die folgenden:

• Enterprise systems management (ESM). Viele der Personen, die

DevOps anfänglich definierten, waren Systemadministratoren. Diese

Durchführungsspezialisten brachten wichtige Best Practices von ESM

zu DevOps, darunter Konfigurationsmanagement, System-Monitoring,

automatisiertes Provisioning und den Toolchain-Ansatz.

• Agile Entwicklung. DevOps, in den Worten eines Beobachters, ist „agil

hoch zehn“9. DevOps stützt sich auf viele Prinzipien, Methoden und

Praktiken der Agilität wie kontinuierliche Bereitstellung, kontinuierliche

Integration und Zusammenarbeit.10 DevOps bringt die Prinzipien agiler

Entwicklung in die Systemadministration und damit letztendlich in das

komplette Spektrum des IT-Betriebs. In den Worten eines DevOps-

Pioniers mit 15 Jahren Erfahrung in der Systemadministration war es an

der Zeit, die Betriebsseite der Gleichung einmal ordentlich aufzumischen:

Systemadministratoren hinken, was den Stand der Technik betrifft, der

Entwicklung hinterher. Diese neuen Technologien zwingen uns endlich zu

einem Umdenken und einer grundlegenden Modernisierung. Ich begrüße

das und halte es für wichtig und richtig.11

Warum ist es wichtig? Es geht hier um die grundlegende Glaubwürdigkeit

der Bewegung. DevOps ist beileibe nicht das Geistesprodukt einiger

abgefahrener Computerfreaks, sondern nimmt seinen Ursprung im

Mainstream. Es vereint die etablierte IT-Operations-Disziplin mit einer

bewährten Entwicklungstechnologie, und die beiden Teile seines

Namens repräsentieren jeweils ihre Best Practices. Und damit integriert

DevOps Development und Operations in ein einheitliches Ganzes mit

gemeinsamen Zielen: hochwertige Software, schnellere Releases und

höhere Kundenzufriedenheit – die gleichen Anliegen, die ein Mainstream-

Unternehmen hat.

Wo kommt DevOps her?

8 Ernest Mueller, „What is DevOps?”, the agile admin, http://theagileadmin.com/what-is-devops (Dezember 2011).

9 Aniket Deshpande, „DevOps, an Extension of Agile Methodology – How It will Impact QA?”, Software Testing Help, http://www.softwaretestinghelp.com/devops-and-software-testing.

10 Jack Crews, „Agile Values, Principles and Practices”, Online-Präsentation, http://www.slideshare.net/jackcrews/agile-values-principles-and-practices.

11 Ernest Mueller, „Q&A: Ernest Mueller on Bringing Agile to Operations”, http://dev2ops.org/2010/04/qa-ernest-mueller-on-bringing-agile-to-operations, 2010.





KAPITEL 3

Welche Probleme führten zur Schaffung von DevOps?




eBook

09



Entwickler und Systemadministratoren sind in vielen Dingen nicht

gleicher Meinung, aber sie sind sich einig darin, dass ihre Kunden auf der

geschäftlichen Seite ihres Unternehmens unterschiedliche Anliegen haben.

Auf der einen Seite verlangen Business-Nutzer ständig etwas Neues – neue

Features, neue Services, neue Einkommensquellen, und zwar so schnell wie

möglich. Auf der anderen Seite wollen sie ein System, das stabil ist und ohne

Unterbrechungen läuft. Das führt zu einem Problem:

Das Problem beim herkömmlichen Prozess der Softwarebereitstellung

(wenn man es denn so nennen kann) ist, dass er diese beiden

Anforderungen schlecht gleichzeitig erfüllen kann. Unternehmen müssen

sich also entscheiden: Entweder bringen sie Änderungen schnell auf den

Markt und laufen Gefahr, dass ihre Produktionsumgebung wackelt, oder

sie lassen alles, wie es ist: stabil, aber überholt.12

Keine Option passt Führungskräften in den Kram. Und was noch wichtiger ist:

Keine erlaubt einem Unternehmen, seinen Kunden optimale Lösungen zu bieten.

Entwickler sind nur allzu bereit, Software immer schneller auf den Markt

zu bringen – das ist schließlich der Grund, aus dem sie eingestellt wurden.

Auf Operations-Seite weiß man aber, dass ständige schnelle Änderungen

ohne Sicherheitsnetz die Systemstabilität bedrohen und damit dem

Geschäftszweck zuwiderlaufen.

DevOps wurde geschaffen, um dieses Dilemma zu lösen, indem alle

Personen, die mit Softwareentwicklung und -bereitstellung zu tun haben –

Business-Nutzer, Entwickler, Tester, Systemadministratoren – in einen hoch

automatisierten Workflow integriert werden, der ein einziges, glasklares

Ziel verfolgt: schnelle Bereitstellung hochwertiger Software, die alle

Benutzeranforderungen erfüllt und gleichzeitig die Integrität und Stabilität

des gesamten Systems aufrechterhält.

Wie tun sich diese unterschiedlichen Interessengruppen zusammen? Indem

sie sich einem gemeinsamen Satz an Prinzipien verschreiben, der über die

herkömmlichen Grenzen und Rollen ihrer Disziplin hinausgeht, zum Beispiel:

• Sicherstellen, dass alle Teams am gleichen Ziel arbeiten und anhand der

gleichen Geschäftsmetriken gemessen werden.

• Aufrechterhalten kurzer Entwicklungszyklen, die es dem Unternehmen

gestattet, sich flexibel an neue Gegebenheiten anzupassen.

• Einsetzen von Feature-Flags und progressiven Deployment-Strategien,

die die Aktivierung bzw. Deaktivierung neuer Funktionen in der

Produktion ohne Redeployments erleichtert.

• Erstellen extrem schneller Feedback-Loops, die für eine sofortige

Problemidentifizierung und Lösung durch die entsprechenden Teams sorgen.

• Erarbeiten von Maßnahmen, die zu mehr Effektivität als Team führen, und

anschließendes Anpassen der eigenen Verhaltensweisen.13

Welche Probleme führten zur Schaffung von DevOps?

12 Niek Bartholomeus, „My experience with introducing DevOps in a traditional enterprise“, http://niek.bartholomeus.be/2013/01/28/introducing-a-devops-culture-in-a-traditional-enterprise, 28. Januar 2013.

13 Ernest Mueller, „A DevOps Manifesto”, the agile admin, http://theagileadmin.com/2010/10/15/a-devops-manifesto, 15. Oktober 2010.





KAPITEL 4

Wie funktioniert DevOps?




eBook

11



Wie jede Kultur, so ist auch DevOps ein Thema mit vielen Variationen. Die

meisten Beobachter sind jedoch der Meinung, dass praktisch alle DevOps-

Kulturen die folgenden Eigenschaften gemeinsam haben: Kooperation,

Automatisierung, kontinuierliche Integration, kontinuierliche Bereitstellung,

kontinuierliches Testen, kontinuierliches Monitoring und schnelle

Fehlerbehebung.

KooperationStatt sich gegenseitig die Schuld zuzuschieben, arbeiten die Bereiche

Entwicklung und IT-Operations zusammen. Obwohl diese Bereiche

früher voneinander abgeschottet waren und damit den Grundstein für

die Schaffung von DevOps gelegt hatten, geht DevOps weit über die

IT-Organisation hinaus. Zusammenarbeit ist nämlich für jeden wichtig,

der an der Softwarebereitstellung arbeitet, nicht nur für Entwicklung

und Operations, sondern auch alle anderen Teams wie Tester,

Produktmanagement und Führungsteam:

Erfolgreiches DevOps setzt die Koordination aller Bereiche eines

Unternehmens voraus (Entwicklung, QA, Operations usw.) und sieht

vor, dass jeder dieser Bereiche in unterschiedlichen Phasen des

Anwendungs-Lifecycle eine wichtige Rolle übernimmt. Es mag schwer,

wenn nicht gar unmöglich sein, Silos zu eliminieren, aber Kooperation ist

das A und O.14

AutomatisierungDevOps stützt sich stark auf Automatisierung. Dies bedeutet, dass Sie

Tools brauchen. Tools, die Sie selbst bauen. Tools, die Sie kaufen. Open-

Source-Tools. Proprietäre Tools. Und diese Tools sind nicht einfach so im

Entwicklungslabor verstreut: DevOps stützt sich auf Toolchains, um weite

Teile des durchgängigen Softwareentwicklungs- und Deployment-Prozesses

zu automatisieren.

Aber Vorsicht: Weil DevOps-Tools so leistungsstark sind, neigen manche

dazu, DevOps einfach als Kollektion von Tools zu betrachten. Das ist zwar

zum Teil richtig, aber DevOps ist viel mehr als nur das.

Kontinuierliche Integration Dies ist ein Aspekt, der häufig in DevOps-Kulturen anzutreffen ist, denn

DevOps ist aus einer agilen Kultur entstanden, und kontinuierliche

Integration ist ein Eckpfeiler des agilen Ansatzes:

Kontinuierliche Integration (CI) ist eine Praxis im Software-Engineering,

bei der isolierte Änderungen umgehend auf Herz und Nieren getestet

werden, ehe sie zu einer größeren Codebasis hinzugefügt werden. Das

Ziel der kontinuierlichen Integration ist, sofort Feedback zu liefern. Wenn

also ein Defekt in die Codebasis übernommen wird, kann er so schnell

wie möglich identifiziert und korrigiert werden. In der Regel liefert jedes

Teammitglied seine Resultate mindestens einmal am Tag, und bei jeder

signifikanten Änderung wird ein Build erstellt.15

Wie funktioniert DevOps?

14 Laurie Wurster et al, „Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology“, Gartner-Bericht, August 2013.

15 Margaret Rouse, „Continuous Integration (CI)“, SearchSoftwareQuality, http://searchsoftwarequality.techtarget.com/definition/continuous-integration, Juli 2008.




eBook

12



Das CI-Prinzip der agilen Entwicklung hat eine kulturelle Auswirkung auf das

Entwicklungsteam. Wenn man Entwickler quasi dazu zwingt, ihre Arbeit in

schneller Abfolge – sprich fast täglich – mit der anderer Entwickler zu integrieren,

kommen Integrationsprobleme und Konflikte deutlich häufiger zum Vorschein als

beim so genannten Wasserfallmodell der sequenziellen Entwicklung.

Um davon zu profitieren, müssen Entwickler allerdings weit häufiger

miteinander kommunizieren – und das steht im Widerspruch zum Image des

abgeschotteten Tüftlers, der Wochen oder Monate an einem Modul bastelt,

ehe er es der Welt vorstellen kann. Offene und häufige Kommunikation ist

für den DevOps-Ansatz ein absolutes Muss.

Kontinuierliches Testen Dass DevOps ebenso stark auf Tests beruht, lässt sich leicht übersehen – bis es

zu Problemen kommt. In den Worten eines Branchenexperten: „Qualitätskosten

sind gleich Fehlerkosten.“16 Kontinuierliche Integration und Bereitstellung sind

zwar die Stars von DevOps, aber kontinuierliches Testen kristalliert sich immer

mehr als ein ebenso wichtiges Puzzleteil von DevOps heraus.

Kontinuierliches Testen ist nicht nur eine Funktion der Qualitätssicherung,

sondern nimmt ihren Anfang in der Entwicklungsumgebung. Vorbei ist

die Zeit, in der Entwickler den Testern einfach ihren Code in den Schoß

kippen konnten und sagen: „Nun macht mal schön!“ In einer DevOps-

Umgebung testet jeder mit. Entwickler liefern nicht nur fehlerfreien Code,

sondern gleichzeitig Testdatensets. Außerdem helfen sie den Testern beim

Konfigurieren der Testumgebung, sodass sie die größtmögliche Ähnlichkeit

mit der Produktionsumgebung aufweist.17

In der Qualitätssicherung dreht sich alles um Geschwindigkeit. Der

QA-Zyklus darf sich nicht über Tage und Wochen hinziehen, sonst

steckt man gleich wieder im Wasserfallmodell. Tester können ihre

Aufgaben beschleunigen, indem sie einen großen Teil des Testprozesses

automatisieren und darüber hinaus ihre Testmethoden neu definieren:

Statt Tests als separate und langwierige Sequenz im Rahmen des

Deployment-Prozesses zu betrachten, rollen die Verfechter der

kontinuierlichen Bereitstellung kleinere Upgrades quasi nonstop aus,

messen ihre Leistung und rollen sie bei Bedarf schnell wieder ein.18

Es mag überraschen, aber auch die Operations-Funktion spielt beim Testen

und bei der Qualitätssicherung eine wichtige Rolle:

Operations hat Zugriff auf Produktionsnutzung und Lademuster. Diese

Muster sind wichtig, damit das QA-Team einen Belastungstest erstellen

kann, der korrekt auf die Anwendung zugeschnitten ist.19

Das Operations-Team kann außerdem dafür sorgen, dass Monitoring-

Tools vorliegen und Testumgebungen richtig konfiguriert sind. Es kann

an Funktions-, Belastungs-, Stress- und Lecktests beteiligt sein und auf

Grundlage seiner Erfahrung mit ähnlichen Anwendungen, die in der

Produktion laufen, Analysen durchführen.

Kontinuierliches Testen ist aufwendig, aber es lohnt sich. Die Testfunktion in einer

DevOps-Umgebung hilft Entwicklern dabei, das richtige Gleichgewicht zwischen

Qualität und Geschwindigkeit zu finden. Automatisierte Tools reduzieren die

Testkosten und sorgen dafür, dass die Tester ihre Zeit so effizient wie möglich

einsetzen. Und was noch wichtiger ist: Kontinuierliches Testen verkürzt die

Testzyklen, indem es früher im Prozess Integrationstests ermöglicht.

16 Wayne Ariola, SYS-CON.tv-Interview auf der 13. International Cloud Expo®, http://devopssummit.sys-con.com/node/2912573, 4. – 7. November 2013.

17 Sanjeev Sharma, „Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring“, Blog-Post, http://sdarchitect.wordpress.com/2012/10/30/understanding-devops-part-4-continuous-testing-and-continuous-monitoring, Oktober 2012.

18 http://www.pwc.com/us/en/technology-forecast/2013/issue2/features/devops-continuous-delivery.jhtml.

19 Jim Hirschauer, „DevOps Scares Me – Part 4: Dev and Ops Collaborate Across the Lifecycle“, DZone, http://java.dzone.com/articles/devops-scares-me-part-4-dev, August 2013.




eBook

13



Kontinuierliches Testen eliminiert außerdem Testengpässe durch

virtualisierte abhängige Services und vereinfacht die Schaffung virtualisierter

Testumgebungen, die leicht eingerichtet, geteilt und im Falle von

Systemänderungen aktualisiert werden können. So werden die Kosten der

Einrichtung und Wartung von Testumgebungen deutlich reduziert, und da Tests

schon früher im Prozess integriert werden, verkürzen sich auch die Testzyklen.20

Kontinuierliche Bereitstellung In den Worten eines Kommentators: „Kontinuierliche Bereitstellung ist

nichts weiter als die logische Fortsetzung des Konzepts der kontinuierlichen

Integration.“21 Statt den Prozess an der Türe zum Entwicklungslabor zu

beenden, dehnt sich die kontinuierliche Integration in DevOps auf die

gesamte Release-Kette aus, einschließlich QA und Operations. Das macht

einzelne Releases weit weniger komplex, und sie können viel häufiger auf

den Markt gebracht werden.

Wie häufig das passiert, hängt letztendlich von den Zielen des

Unternehmens ab. Ein Fortune 100-Unternehmen verbesserte zum Beispiel

seinen Release-Zyklus von einmal pro Jahr zu einmal pro Quartal – trotzdem

das reinste Schneckentempo, wenn man es mit den Hunderten von Releases

pro Stunde vergleicht, die Amazon erzielt.

Was konkret neu herausgebracht wird, ist auch von Fall zu Fall verschieden.

In manchen Organisation sind QA und Operations für die Triage von

Releases verantwortlich: Manche landen direkt bei den Benutzern, manche

werden an die Entwicklungsabteilung zurückgeschickt und manche fallen

unter den Tisch. Andere Unternehmen, zum Beispiel Flickr, schicken alles,

was von den Entwicklern kommt, an die Benutzer weiter und verlassen sich

auf Echtzeit-Monitoring und schnelle Fehlerbehebung, um die Auswirkung

von Fehlern, sollten sie denn auftreten, zu minimieren.

Kontinuierliches Monitoring Angesichts der hohen Anzahl von Releases ist es unmöglich, vorher

alles umfassend und auf Herz und Nieren zu testen, so wie es beim

Wasserfallmodell gang und gäbe ist. In einer DevOps-Umgebung müssen

Fehler daher in Echtzeit gefunden und behoben werden. Wie soll das

gehen? Eine wichtige Rolle hierbei spielt das kontinuierliche Monitoring.

Ein Experte beschreibt die Ziele des kontinuierlichen Monitoring wie folgt:

schnelles Feststellen, wenn ein Service ausfällt, Verstehen der Ursachen,

und vor allem Anwenden des Gelernten, um mögliche Probleme frühzeitig

zu erkennen.22 Einige Fachleute auf dem Gebiet des Monitoring sind sogar

der Überzeugung, dass die Definition eines Service eine Monitoring-

Komponente umfassen muss – für sie ist das ein integraler Bestandteil der

Servicebereitstellung.

Wie das Testen so startet auch das Monitoring bereits bei der Entwicklung.

Die gleichen Tools, die die Produktionsumgebung überwachen, können

während der Entwicklung eingesetzt werden, um Performance-Probleme zu

identifizieren, noch ehe sie in Produktion gehen.

DevOps erfordert zwei Arten des Monitoring: Server-Monitoring und

Anwendungsleistungs-Monitoring. Beim Thema Monitoring fällt als erstes der

Begriff „Tools“, denn ohne die richtigen Tools ist kein effektives Monitoring

möglich. Eine Liste der DevOps-Tools (und noch mehr Beiträge zum Thema

DevOps) finden Sie im DevOps Hub von New Relic.

20 „Enterprise testing capability for continuous software delivery“, http://www.ibm.com/ibm/devops/us/en/build/test/.

21 Sanjeev Sharma, „Understanding DevOps – Part 2: Continuous Testing and Continuous Monitoring“, Blog-Post, http://sdarchitect.wordpress.com/2012/09/25/understanding-devops-part-2-continuous-integration-and-continuous-delivery, September 2012.

22 Julien Pivotto, „The devops approach to monitoring“, Open World Forum-Präsentation, http://www.slideshare.net/roidelapluie/devops-andmonitoringowf13, Oktober 2013.





KAPITEL 5

Wer arbeitet mit DevOps?




eBook

15



Die DevOps-Akzeptanz beschleunigt sich. Eine im Dezember 2012 erhobene

Studie, bei der mehr als 4000 IT-Professionals befragt wurde, ergab, dass

mehr als 63 % der Befragten DevOps-Praktiken implementiert hatten – eine

erstaunliche Zunahme von 26 % im Vergleich zum Vorjahr.23 DevOps ist zwar

noch kein Mainstream-Trend, nimmt aber an Dynamik zu.24

Welche Unternehmen sagen Ja – oder sollten Ja sagen – zu DevOps?

Das kommt darauf an, wen man fragt. Eine Denkrichtung sieht DevOps

als richtige Antwort für alle Firmen, von kleinen Startups bis zu riesigen

Technologie-Giganten: „DevOps ist ein Way of Life, und wer das ignoriert,

der muss die Konsequenzen tragen.“25

Für andere ist Größe das einzige, was zählt. Laut dieser Denkrichtung

ist DevOps für kleinere Firmen leicht zu implementieren, aber die Kultur

eines Großunternehmens kann ein echtes Problem sein: „Wenn gute

Zusammenarbeit nicht in der DNA eines Unternehmens vorhanden ist, lässt

sich DevOps nur mit Mühe erfolgreich umsetzen.“26

In jedem Fall entwickelt sich DevOps ausgesprochen schnell weiter und

sein Verbreitungsgrad lässt sich nur schwer charakterisieren. Vieles deutet

jedoch darauf hin, dass die Firmengröße allein keine Rückschlüsse auf

DevOps-Erfolg zulässt.

Werfen wir zuerst einen Blick auf die Branchengiganten. Wenn man

ein Dutzend DevOps-Bekehrte um die Namen der größten DevOps-

Erfolgstorys bittet, hört man fast immer die gleichen vier oder fünf

Namen: Google, Twitter, Amazon, Netflix und Facebook. Ihre kombinierte

Marktkapitalisierung in Höhe von 717 Milliarden Dollar im Jahr 2014 ist

höher als das Bruttoinlandsprodukt aller Länder der Welt bis auf 19.

Viele Industriebeobachter sind der Meinung, dass DevOps in der einen

oder anderen Form bei ihrem meteorhaften Aufstieg eine wichtige Rolle

gespielt hat. „Dies sind Breakout-Erfolge, die sich nur durch eine neue

Betriebsphilosophie erklären lassen… In vielerlei Hinsicht ist ihr Erfolg ein

Strategieplan dafür, wie DevOps in Organisationen der unterschiedlichsten

Größe Erfolg haben kann.“27

Auf der anderen Seite des Spektrums sind die coolen, urbanen und

angesagten Startups und mittelgroßen Unternehmen – zum Beispiel Tumblr,

Evernote, Etsy und Github – , die vor allem deshalb mit den „Großen“

mithalten können, weil sie dank DevOps mit kleinen Teams riesige Erträge

erwirtschaften: „Es waren sicher nicht die herkömmlichen IT-Prozesse und

Produktentwicklungsmethoden, die diesen kleinen Unternehmen halfen, ihr

ganzes Gewicht in die Waagschale zu legen.“28

Wer arbeitet mit DevOps?

23 „2013 State of DevOps Report“, Puppet Labs, IT Revolution Press, https://puppetlabs.com/wp-content/uploads/2013/03/2013-state-of-devops-report.pdf.

24 Kyt Dotson, DevOps Interview: Raja Bhargava, CEO von JumpCloud http://devopsangle.com/2014/01/07/devops-interview-rajat-bhargava-ceo-of-jumpcloud/.

25 Adam Duro, „Three Reasons Your Startup Will Suffer Without DevOps“, readwrite, http://readwrite.com/2014/01/01/three-reasons-your-startup-needs-devops-or-else, 1. Januar 2014.

26 „The New Normal of DevOps“, CA Technologies White Paper, http://www.ca.com/us/~/media/Files/whitepapers/the-new-normal-of-devops.pdf, Dezember 2013.

27 James B. Brown, „5 Reasons Why DevOps is Hitting Its Stride“, Innovation Insights, http://insights.wired.com/profiles/blogs/5-reasons-why-devops-is-hitting-its-stride#ixzz2x6O8QnIA, March.

28 Ibid.





KAPITEL 6

Warum finden Ihre Kollegen DevOps gut?




eBook

17



DevOps hat für jeden in der Softwarekette etwas zu bieten: Entwickler,

Operations, Tester. DevOps wirkt sich sogar auf die Unternehmensseite

der Organisation aus: Manager, die die Software monetisieren, und

Führungskräfte, die immer die Erträge im Auge behalten müssen. Hier sind

einige der Vorteile, die von den einzelnen Gruppen angeführt werden:

EntwicklerAutomatisiertes Provisioning erweist sich für Programmierer als Segen,

denn damit können sie völlig bürokratielos eine Entwicklungsumgebung

bereitstellen – ohne langwierige Genehmigungszyklen und ohne auf

Zuweisung eines Servers durch IT warten zu müssen. Wenn Entwickler

innerhalb von 15 Minuten eine Arbeitsumgebung schaffen können, die alle

erforderlichen Ressourcen aufweist – Verarbeitungsleistung, Speicher,

Netzwerk, Anwendungen –, ändert sich damit ihre Arbeitsmethode

fundamental. Sie können weit kreativer und innovativer sein. Es ist viel

leichter, mehrere Optionen auszuprobieren, unterschiedliche Szenarien zu

testen und den Code umfassender zu prüfen.

Wenn Entwickler zum ersten Mal in einer DevOps-Umgebung arbeiten,

begreifen viele eigentlich erst, was in der Black-Box mit der Aufschrift

„Operations“ vor sich geht. Diese Erkenntnis hilft Entwicklern dann

dabei, effizient mit dem Operations-Team in einem gemeinsamen

Problemlösungsmodus zu arbeiten. Probleme werden schneller gelöst und

lenken weniger ab. Und die hektischen Telefonate zu nachtschlafender

Zeit gehören der Vergangenheit an. All dies führt unmittelbar zu mehr

Zufriedenheit und Erfüllung im Job und einer höheren Lebensqualität für die

Entwickler.

OperationsEiner weit verbreiteten Ansicht zufolge sind Systemadministratoren schier

besessen, wenn es um Systemstabilität geht. Und das stimmt auch. Ihr

Alptraumszenario sieht so aus, dass ein Softwarerelease innerhalb von

Sekunden nach Produktionsbereitstellung das komplette System zum

Erliegen bringt; Entwickler, die jede Verantwortung dafür ablehnen („Wir

haben nichts mehr mit dem Code zu tun!“); Benutzer in unterschiedlichen

Stadien der Empörung… und kein klarer Pfad zu einer raschen und

effektiven Lösung.

Die Early Adopter der DevOps-Methoden haben erkannt, dass die

verstärkte Einbeziehung der Entwickler die Systemstabilität erhöht.

Automatisierung reduziert darüber hinaus menschliche Fehler bei

manuellen Vorgängen und hat den zusätzlichen Vorteil, dass sich damit die

für Routinearbeiten benötigte Zeit verringert. Auch Systemadministratoren

erkennen Vorteile – sie lernen Neues dazu, es tun sich neue berufliche

Perspektiven auf und sie werden nicht mehr laufend nachts aus dem Schlaf

gerissen, um Brände zu löschen. In einer DevOps-Umgebung sind Tools

für Operations-Mitarbeiter deutlich wichtiger als in einer herkömmlichen

Umgebung, und sie bauen oft ihre eigenen Tools und schreiben Skripts, die

Teile des Deployment-Prozesses automatisieren.

Warum finden Ihre Kollegen DevOps gut?




eBook

18



TesterDie Wirkung von DevOps auf die Testseite lässt sich in zwei Worten

zusammenfassen: Chaos Monkey. Dieses bemerkenswerte und innovative-

Tool wurde von Netflix entwickelt, um seine eigene Software zu zerstören.29

Chaos Monkey beruht auf dem Prinzip, dass die beste Methode der

Fehlervermeidung ist, laufend Fehler herbeizuführen. Die Software

simuliert Fehler in Serviceinstanzen, indem sie einen oder mehrere

virtuelle Rechner herunterfährt. So kann man sich auf unerwartete Fehler

vorbereiten, statt nur herumzusitzen und darauf zu warten, bis eine

Katastrophe eintritt und dann versuchen, damit unzugehen.30

DevOps verlangt neue Methoden, Software zu testen, was wiederum

Tester zu kreativem Denken herausfordert. Und genau dieser Anstoß war

es, der zur Schaffung von Chaos Monkey führte. Bei automatisiertem

Provisioning können Tester eine Testumgebung bereitstellen, die mit

der Produktionsumgebung praktisch identisch ist. Dies führt zu höherer

Testgenauigkeit und der Fähigkeit, die Performance neuer Releases genauer

zu prognostizieren. Dank Automatisierung und Zusammenarbeit erhöht sich

die Produktivität der Tester ebenso wie die der anderen Gruppen.

ProduktmanagerRein technisch gesehen dreht es sich bei DevOps nur um die IT-Funktion

des Unternehmens. Wer jedoch den Übergang geschafft hat, ist davon

überzeugt, dass DevOps so ziemlich alles ändert:

Eine wirkungsvolle DevOps-Strategie erlaubt einer Organisation

das Analysieren – erstmalig und in Echtzeit – von Webanalysedaten,

Rechnerdaten und vorhandenen strukturierten Daten, um eine

Rundumsicht der kundenorientierten Systeme zu erhalten und zu sehen,

ob und wie sie Geschäftswert liefern. Mit DevOps können Organisationen

das Verhalten einzelner Kunden verstehen, welche Aktionen sie einleiten

und wie sich ihr Verhalten mit dem anderer Kunden vergleichen lässt.

Es erlaubt einer Organisation, What-If-Analysen von Änderungen an

ihrer Benutzeroberfläche oder ihren Produktangebot durchzuführen.

Basierend auf den Resultaten dieser prädiktiven Analysen und echten

praktischen Erfahrungen gestattet die agile Entwicklungsseite von

DevOps es Organisationen anschließend, schneller als zuvor auf

Marktanforderungen zu reagieren.31

Betrachten wir diese Aussage einmal etwas genauer. In einer DevOps-

Umgebung haben Akteure der Privatwirtschaft mehr Einfluss auf den

Entwicklungsprozess. DevOps ist geprägt vom Geist der Zusammenarbeit.

Entwickler nehmen daher Geschäftsanforderungen ernst und fördern gute

Beziehungen zu Produktmanagern. DevOps gibt Produktmanagern außerdem

sofortiges Feedback über die Wirkung neuer Preise, neuer Funktionen und

neuer Produktpaletten, was ihnen wiederum ermöglicht, alle möglichen

Variationen auszuprobieren, um zu sehen, welche am besten funktionieren.

Line-of-Business-Manager schätzen DevOps, denn damit landet Software

schneller auf dem Markt und sie erhalten den Wettbewerbsvorteil, der ihnen

so wichtig ist. DevOps verbessert die Systemstabilität und führt damit

zu weniger Systemausfällen, was Kunden freut. Und zufriedene Kunden

bedeutet treue Kunden.

29 http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html.

30 Margaret Rouse, „Chaos Monkey“, WhatIs.com, http://whatis.techtarget.com/definition/Chaos-Monkey, August 2013.

31 Kapil Apshankar, „How DevOps Drives Real-Time Business Growth“, Cognizant-Whitepaper, http://www.cognizant.com/InsightsWhitepapers/How-DevOps-Drives-Real-Time-Business-Growth.pdf, 2013.




eBook

19



FührungskräfteAls Patrick Debois und andere IT-Genies die DevOps-Bewegung ins

Leben rufen, kümmerten sie sich wenig darum, wie ihre Aktionen in der

Führungsetage ankommen würden. Nur fünf Jahre später werden sie und

ihre Aktionen in genau diesen Führungsetagen heftig diskutiert.

Was mögen Executives an DevOps? Zum einen hilft es der Organisation,

hochwertige Produkte bereitzustellen und sie schneller als die Konkurrenz

mit ihren herkömmlichen Methoden der Softwareentwicklung auf den

Markt zu bringen. All dies wirkt sich unmittelbar auf den Gewinn und die

Stärkung des Markenwerts aus. Ein weiterer Grund ist die Fähigkeit, die

besten Talente anzuziehen und bei der Stange zu halten: hochqualifizierte

Entwickler, Systemadministratoren und Tester wollen immer die Nase im

Wind haben. Und last but not least: Wenn Entwickler, Operations-Leute

und Tester zusammenarbeiten, müssen ihre Chefs selten eingreifen, um

Missverständnisse aus dem Weg zu räumen. Vielmehr können sie sich voll

auf das Formulieren ihrer Geschäftsziele konzentrieren, an deren Erfüllung

nun alle gemeinsam arbeiten.

32 Interview, 6. Februar 2014

„Ich wollte eigentlich den Release-Prozess immer verlangsamen. Je weniger neue Releases, desto sicherer konnte ich sein, dass das System stabil bleibt. Nach einigen Jahren der Arbeit in einer DevOps-Umgebung habe ich meine Meinung komplett geändert. Jetzt ist meine Philosophie: je mehr Deployments, desto besser.“32

—Aaron Bento, Site Reliability Engineer, New Relic





KAPITEL 7

Was nutzt DevOps mir?




eBook

21



Wenn man gewissen Quellen Glauben schenken möchte, können mithilfe

von DevOps einige bemerkenswerte Vorteile erzielt werden. Ein Wort der

Vorsicht ist trotzdem angebracht. Stellen Sie sich vor, jemand sagt Ihnen:

„Mein Auto braucht 7 Liter.“ Welches Auto? Wie ist der Fahrstil? Spricht

er von einem SUV mit Platz für acht? Dann wäre das eine viel zu niedrige

Zahl. Oder ist die Rede von einem Mini, der nur Langstrecken fährt? Dann

wären 7 Liter auf 100 Kilometer viel zu viel. Auf den Kontext kommt es an.

Wann immer Sie also Aussagen zu den sagenhaften mit DevOps erzielten

Verbesserungen hören, stellen Sie sicher, dass Sie den Kontext kennen.

Nichtsdestotrotz. Eine von Puppet Labs33 in Auftrag gegebene Umfrage

stellte fest, dass DevOps-Adopter Software 30 Mal schneller auf den Markt

bringen als ihre Konkurrenz. Auch die Qualität der Software ist höher:

DevOps-Anwendungen weisen im Durchschnitt nur halb so viele Fehler auf

wie die ihrer Mitbewerber. Und schließlich: Der Effekt auf die Systemstabilität

ist positiv: Wenn die Plattform zum Erliegen kommt, können DevOps-

Gruppen den Service 12 Mal schneller wiederherstellen als die Konkurrenz.

Eine Sache ist klar: IT-Profis, die sich für DevOps entschieden haben,

sind begeisterte Fans. Angesichts der Verbesserungen, die in der Studie

angeführt werden, ist das auch kein Wunder.

• Stabilität der Infrastruktur: 83 Prozent der Befragten melden entweder

„etwas Verbesserung“ oder „deutliche Verbesserung“.

• Geschwindigkeit des Anwendungs-Deployments: 83 Prozent der

Befragten melden entweder „etwas Verbesserung“ oder „deutliche

Verbesserung“.

• Sicherheit: 45 Prozent erwarten, dass DevOps die Sicherheit verbessert,

während nur 7 Prozent der Ansicht sind, durch DevOps würden die

Systeme weniger sicher.

Was nutzt DevOps mir?

33 PuppetLabs-Umfrage, op cit.




eBook

22



Fünf Jahre nach Beginn des DevOps-Experiments ist eine Sache klar:

DevOps wird nicht mehr von der Bildfläche verschwinden – und das

aus gutem Grund. Kaum zu glauben, aber DevOps hat es geschafft,

Geschäftsnutzer, Entwickler, Tester und Systemadministratoren in einen

einzigen Workflow zu integrieren, dessen Ziel es ist, Kundenanforderungen

zu erfüllen. Warum tun sie das freiwillig? Weil alle davon profitieren.

Entwickler und Systemverwalter sind plötzlich ein Herz und eine Seele

und unterstützen sich gegenseitig. Business-Manager freuen sich, denn sie

bekommen die Software, mit der sie ihre Produkte und Dienstleistungen

verkaufen können. Executives stellen fest, dass ihre Dashboard-Metriken –

Ertrag, Kundenzufriedenheit, Systemstabilität – einen Aufwärtstrend haben.

Und jeder einzelne ist in der Lage, Kunden die besten Ergebnisse und ein

optimales Erlebnis zu liefern.

Solche Gewinne lassen sich allerdings nicht von heute auf morgen

realisieren. Wenn Sie häufiger Code bereitstellen möchten, ohne dabei die

Stabilität Ihres Systems zu beeinträchtigen, müssen Sie alle Änderungen in

Ihrer Umgebung genau überwachen können. New Relic bietet die Daten, die

Sie brauchen, um die neuen Funktionen des Entwicklerteams zu messen und

zu überwachen, während gleichzeitig die Stabilität sichergestellt wird, die

das Operations-Team fordert. Wenn Sie mehr darüber erfahren möchten,

wie New Relic Ihrer Firma beim erfolgreichen Umstieg auf das DevOps-

Modell helfen kann, besuchen Sie uns: newrelic.com/devops.

Schlussfolgerung

34 Sascha Bates, „Shenanigans“, http://blog.brattyredhead.com/, 17. Mai 2013.

„Eine Kernbotschaft von DevOps ist: Wenn Ihnen die Methode nicht gefällt, mit der jemand etwas tut, sprechen Sie mit ihm und fragen ihn. Sie werden vermutlich feststellen, dass es für alles gute Gründe gibt, zum Beispiel: ,Ich wusste nicht, wie es geht.‘“34

—Sascha Bates, Consultant, Chef




http://newrelic.com/devops

eBook

23



About New RelicNew Relic ist ein Softwareanalyse-Unternehmen, das Milliarden von Datenpunkten über Millionen von Anwendungen in Echtzeit interpretiert.Die

umfassende SaaS-basierte Lösung von New Relic bietet eine leistungsstarke Schnittstelle zu Web- und Mobilanwendungen und konsolidiert die

Leistungsüberwachungsdaten für jede beliebige Technologie in Ihrer Umgebung. Hunderttausende von Benutzern und Zehntausende kostenpflichtige

Business-Accounts verlassen sich auf New Relic, wenn es darum geht, Milliarden von Echtzeitmetriken aus Produktionssoftware auszuwerten und

Antworten auf wichtige Geschäftsfragen zu erhalten. Wenn Ihre Marke und Ihr Kundenerlebnis von der Performance moderner Software abhängen, kann

New Relic Einsichten in Ihre Gesamtumgebung liefern. Weitere Informationen finden Sie unter www.newrelic.de.

New Relic, San Francisco HQ188 Spear Street, Suite 1200

San Francisco, CA 94105

New Relic, Portland111 SW 5th Avenue, Suite 2800

Portland, OR 97204

New Relic, Seattle2101 4th Avenue, 19th Floor

Seattle, WA 98121

Tel: +49 800 724-3111

[email protected]

www.newrelic.com

New Relic, Dublin34-39 Nassau Street, 3rd Floor

Dublin 2, Ireland




eBook DevOps - New Relic · DevOps wurde geschaffen, um dieses Dilemma zu lösen, indem alle...

Documents

Transcript of eBook DevOps - New Relic · DevOps wurde geschaffen, um dieses Dilemma zu lösen, indem alle...