Entwicklung und IT-Betrieb haben vor allem in größeren Unternehmen meist nicht viel miteinander zu tun. Die Entwickler programmieren, der IT-Betrieb sorgt für den Einsatz der Ergebnisse und stellt - oft für nur kurze Zeit - Testumgebungen zur Verfügung. Die Folge ist oftmals eine fehlende Abstimmung zwischen beiden Bereichen.
Foto: chalabala - Fotolia.com
Dadurch dauert die Inbetriebnahme neuer Software lang, oft trifft zudem die Anwendung trotz ausufernder Spezifikationen nicht die exakten Wünsche der Anwender. Die Anforderungen haben sich bis zur Freigabe wahrscheinlich schon wieder geändert, so dass das Produkt zur Auslieferung schon wieder veraltet ist ("dead on delivery"). Das gilt insbesondere für Web- und Mobile-Applikationen.
Zudem ist die Kommunikation zwischen Entwicklung und Betrieb bei Problemen oft ungenügend, wodurch sich Ausfälle in die Länge ziehen können. Weitere Folgen der unzureichenden Kooperation: Softwarewildwuchs, Sicherheitslücken und zu hohe Kosten.
Die Entwicklung reagierte zuerst
Auf den "Need for Speed" reagierten die Entwicklungsbereiche zunächst mit agiler Programmierung. In Scrums, einzelnen, oft nur ein oder zwei Wochen dauernden Programmierphasen, entstehen dabei Teilfunktionen, die anschließend vom Kunden abgenommen und später gegebenenfalls erweitert oder modifiziert werden. Doch im IT-Betrieb ging es bisher weiter wie gehabt.
Der Gedanke, dass die beiden Bereiche wesentlich enger verzahnt werden müssten, wird zwei Männern zugeschrieben: dem belgischen IT-Consultant Patrick Dubois und Andrew Shafer, Senior Director Technology bei der EMC-Tochterfirma Pivotal. So berichtet jedenfalls der auf DevOps spezialisierte Blog ITRevolution. Demnach gründeten Dubois und Shafer im Social Network Google+ 2009 eine Agile System Administrator Group. Im selben Jahr fanden in Gent internationale "DevOps Days" statt.
Inzwischen hat sich DevOps vor allem im angloamerikanischen Raum ziemlich weit verbreitet. In Europa gestaltet sich der Umgang mit dem Thema bisher eher zögerlich, wie eine von T-Systems Multimedia Solutions in Auftrag gegebene Spotlight-Analyse des Beratungsunternehmens PAC belegt.
Aber was ist DevOps nun eigentlich? - Jedenfalls ist es kein Produkt. Vielmehr handelt es sich eher um ein Bündel bisher kaum kodifizierter Best Practices, Methoden und Tools, die aber auch die Struktur der Software beeinflussen. Und was ist das Ziel? Programme und Versionen sollen in kurzen Zyklen und im Gleichtakt mit dem IT-Betrieb bereitgestellt werden. Statt monolithischer Programme entstehen kombinierbare Mikroservices. Daraus können beispielsweise Cloud-Provider schnell immer wieder neue Services zusammenstricken, zumindest in der Idealvorstellung.
Fehler im Entwicklungsprozess sollen dank DevOps früher aufgedeckt, Kompatibilitätsprobleme, etwa mit der Einsatzumgebung, von vornherein vermieden werden. Testequipment steht fast ohne Wartezeiten sowie ausreichend lang bereit, bei Fehlern wird die Ursache schnellstmöglich gefunden und behoben, denn hierfür ist ja gerade bei neuen Produkten die Hilfe der Entwickler meist unabdingbar.
Inzwischen gibt es auch eine Reihe von Open-Source-Tools für nahezu jede Phase im Produktlebenszyklus einer nach DevOps-Prinzipien entwickelten und genutzten Software (siehe "Produkte für DevOps" auf Seite 28). Die Softwareriesen haben ebenfalls erkannt, dass sie an der neuen Welle nicht vorbeikommen, und stellen ihre Toolboxen auf DevOps um. Ob dabei aus Anwendersicht mehr als Wortgeklingel herauskommt, muss abgewartet werden.
Produkte für DevOps
Für die Entwicklung:
Versionskontrolle, Versions-Management: Git, GitLab, Bazaar;
Build- und Test-Automatisierung: Ant, Maven, JMeter, PHPUnit;
Continuous Integration und Delivery: Jenkins, Tinderbox, Gump, Go.
Für das Deployment:
Container-Plattformen: Rocket, CoreOS, Ubuntu;
Konfigurations-Management: Chef, Puppet, Ansible;
Mikroservice-Plattform: Kubernetes, Mesosphere, OpenShift;
Provisioning: Chef Knive, Docker Swarm, OpenShift Heat.
Für die Wartung:
Logging: StatsD, Collectd;
Monitoring/Analytics: Ganglia, Kigana, Nagios, Zabbix.
Was die Anwender sagen
Ungeachtet all dieser Aktivitäten zögern die deutschen Anwender mit dem DevOps-Einstieg. Laut der bereits erwähnten PAC-Umfrage kennen 33 Prozent von ihnen den Begriff gar nicht, und weitere 30 Prozent interessieren sich nicht dafür. Nur 15 Prozent haben DevOps ganz oder teilweise umgesetzt. Grund genug, mit einigen dieser DevOps-Anwender über ihre Erfahrungen zu sprechen.
Einer von ihnen ist Leonteq, ein unabhängiger Technologie- und Servicepartner für Investment-Lösungen. Der Zürcher Finanzdienstleister wurde 2007 gegründet und beschäftigt heute rund 400 Mitarbeiter. Er betreibt Niederlassungen in Monaco, Guernsey, Frankfurt am Main, Paris, London, Singapur und Hongkong. Ein Spezialistenteam des Unternehmens hat eine eigene Plattform für die Herstellung von Investmentprodukten entwickelt.
Schnell und effizient maßschneidern
Derzeit erwirtschaftet Leonteq 40 Prozent des Umsatzes mit eigenen Produktemissionen. Die anderen 60 Prozent erzielt das Unternehmen im Kerngeschäft mit "White-Label"-Dienstleistungen. Dabei wird ein strukturiertes Anlageprodukt für einen Partner entworfen, der es dann unter seinem Namen emittiert.
Die von Leonteq angebotenen Dienstleistungen umfassen unter anderem die Strukturierung, die Dokumentation, das Hedging und die Verwaltung des Produkts über den gesamten Lebenszyklus. Zu den Kooperationspartnern gehören etwa die Schweizer Raiffeisen Gruppe oder DBS, eine führende Bank in Asien.
Im Geschäft mit strukturierten Anlageprodukten ist es besonders wichtig, möglichst schnell und effizient auf Veränderungen des wirtschaftlichen Umfelds mit neuen maßgeschneiderten Produkten reagieren zu können. Anfangs verfolgte Leonteq in der Applikationsentwicklung dieses Ziel mit eigenen Tools, die Aufgaben und Prozesse abbildeten.
Doch mit der Zeit stiegen dann die Anforderungen an diese Plattform, und mit ihnen erhöhte sich auch deren Komplexität. Früher oder später dauert in dieser Situation die Auslieferung neuer Applikationen einfach zu lang. Hinzu kam: Wegen der begrenzten Verfügbarkeit der Testumgebungen ließen sich die Anwendungen häufig nicht in der gewünschten Ausführlichkeit testen. Alles in allem umfasste der Release-Zyklus sechs bis sieben Wochen, und die Integration in die bestehende Umgebung war oft problematisch.
Um Abhilfe zu schaffen, entschied sich Leonteq 2012 - dem Jahr des Börsengangs - für eine neue, DevOps-basierende Entwicklungsumgebung. Eines der Ziele war, mehrere Produkte in unterschiedlichen Umgebungen gleichzeitig und synchronisiert testen zu können. Der Produktlebenszyklus jeder der momentan 65 Applikationen sollte Tool-gestützt verwaltet und beschleunigt werden. Vier Tools kamen in die engere Wahl. Zu den Entscheidungskriterien gehörten Skalierbarkeit der Umgebung, Wartungskosten und Verständlichkeit des Werkzeugs. Schließlich fiel die Wahl auf Release Automation von CA.
Auf eine dreimonatige Vorbereitungsphase folgte ein rund vier Wochen dauernder Proof of Concept, für den die besten Entwickler und Systemarchitekten verantwortlich waren. "Unsere Mitarbeiter wussten, wie wichtig das Projekt war, jeder hat den Nutzen gesehen", berichtet Manish Patnaik, Chief Operating Officer & Chief Information Officer bei Leonteq. Etwa drei Wochen nach der Implementierung wurden die ersten Services automatisch erstellt.
Inzwischen sind die Resultate im praktischen Betrieb sichtbar. Ein Release-Zyklus dauert nur noch zwei Wochen, was Flexibilität und Time-to-Market wesentlich verbessert. Die sechs Testumgebungen, die nötig sind, um ein Produkt fertigzustellen, arbeiten jetzt voll synchronisiert. Wartezeiten auf Testequipment oder schlechte Testergebnisse gehören der Vergangenheit an. Und der nächste Schritt in die DevOps-Welt läuft schon: Die Testabläufe sollen vollständig automatisiert werden. Aufgabe der mit Tests befassten fünf Mitarbeiter ist es nun vor allem, Testfälle zu definieren.
Jeder dritte Entscheidungsträger kennt DevOps nicht
Wie sich in einer aktuellen Umfrage unter mehr als 100 mittelständischen und großen IT-Anwenderunternehmen in Deutschland herausstellte, halten 88 Prozent der Entscheidungsträger hierzulande eine effektivere Zusammenarbeit zwischen Entwicklung und Betrieb für wichtig oder sehr wichtig. Das DevOps-Konzept ist allerdings erst in 15 Prozent der Unternehmen – zumindest teilweise – umgesetzt.
Agile Programmierung herausgelöst
Auch die Deutsche Bank ist im Bereich Digital Solutions für Privatkunden aktiv damit beschäftigt, DevOps-Konzepte umzusetzen. Für die Digitalisierungsstrategie ist IT-seitig Jana Brendel verantwortlich.
In diesem Bereich sieht die Deutsche Bank vielversprechende neue Geschäftsmöglichkeiten, sagt Brendel. Banken würden künftig auch datengetriebene Non-Banking-Services anbieten, vor allem für Sicherheit oder Bequemlichkeit: "Wir glauben, dass man in Zukunft die Rechnung des Strom-Providers in seine Banking-Applikation ziehen und per Fingerprint bezahlen kann, oder man koppelt eine Nachrichtenbox für die Sicherung von Rechnungen über die erforderlichen fünf bis zehn Jahre direkt ans Konto." Solche Lösungen ließen sich mit konventioneller Programmiertechnik kaum sinnvoll entwickeln.
Der Bereich "Agile Programmierung" wurde vor drei Monaten aus der Anwendungsentwicklung der Deutschen Bank herausgelöst. Daneben existiert der klassische Sektor, zu dem etwa das Kernbanksystem gehört. Hier wird mit zwei bis vier Releases pro Jahr und nach dem Wasserfall-Prinzip gearbeitet.
Der DevOps-orientierte Bereich arbeitet derzeit an sieben agilen Pilotprojekten. So werden zum Beispiel Anwendungen für die Apple Watch gebaut. Die Ergebnisse der Pilotphase sind vielversprechend. "Wir sind mit DevOps in der Lage, radikal schneller Software zu veröffentlichen", sagt Brendel. Die gemeinsame Entwicklung bis zur Betriebsbereitschaft habe nur vier Monate gedauert: "Das reicht sonst gerade einmal für die Anforderungsdefinition."
Nicht nur die Geschwindigkeit, auch die Qualität begeistert Brendel: "Normalerweise weiß der Auftraggeber bei Beauftragung noch nicht genau, was er will. Agile Programmierung und DevOps fokussieren die Anstrengungen und Ergebnisse von Anfang an auf den Bedarf des Kunden." Das helfe, attraktive Anwendungen zu entwickeln. Zum Beispiel eine Finanzplanungs-Applikation, die sich innerhalb kurzer Zeit 800.000 Deutsche-Bank-Kunden von der Website heruntergeladen hätten: "Das Digitalprodukt war von Anfang an darauf zugeschnitten, dass es den Anwendern Spaß machen soll, ihre Finanzen zu verwalten. Und das ist uns anscheinend gelungen." Daher werde das Unternehmen immer mehr von der Programmierlandschaft auf diese Methodik umstellen. Für den Transformationsprozess veranschlagt Brendel zwei Jahre.
"DevOps schafft völlige Transparenz", beschreibt Brendel die Auswirkung des Ansatzes. Nichts stelle sich mehr zwischen Angebot und Nachfrage. Auch die Führungskräfte müssten in einer DevOps-Welt umlernen: "Sie räumen vor allem Hindernisse weg, die den Projektverantwortlichen im Weg stehen." Der Schlüssel zum Erfolg sei allerdings das Coaching der Mitarbeiter. Sie müssten sich an mehr Kooperation und ergebnisorientiertes Denken gewöhnen.
Selbstbedienung für den Kunden
Auch einem Managed-Cloud-Provider kann der DevOps-Ansatz helfen, seinen Kunden agilere Dienstleistungen anzubieten. Dazu Michael Riexinger, Leiter Systems bei Claranet: "Wir verwenden DevOps kundenspezifisch in Projekten, um eine hohe Release-Frequenz zu ermöglichen. Die Mechanismen basieren auf generischen Toolsets, die Vorgehensweise ist dabei aber kundenindividuell."
Bevor Claranet Mitte 2014 den neuen Ansatz etablierte und Tools wie Ansible, Puppet, Saltstack oder Chef einsetzte, war das Deployment ein größtenteils manueller Prozess. Wenn ein Kunde neue Software testen wollte, erforderte dies viele umständliche und zeitaufwendige Schritte seitens des Providers. Da es sich teilweise um kostenpflichtige Changes handelte, konnte das teuer für den Kunden werden. Gesucht wurde also eine Lösung, die mehr Selbstbedienungsmöglichkeiten und höhere Agilität eröffnen würde.
Heute laden die Kunden ihren neuen Code mittels Tool-gestützter DevOps-Mechanismen auf ihren Rechner bei Claranet. Dann wird bei Bedarf ein Trigger in einer API ausgelöst; der sorgt dafür, dass die Software in der Cloud kompiliert sowie anschließend auf das Test- und das Produktionssystem überspielt wird. Und zwar ohne dass der Provider eingreifen muss. Über denselben Mechanismus ist auch ein Rollback möglich. Inzwischen wird das Framework dahin erweitert, dass auch das Testen selbst automatisch abläuft. Das steigert letztlich die Qualität der Software.
Durch die neue Methodik hat sich auch der Personaleinsatz bei Claranet verschoben. Die Mitarbeiter werden mehr für die Weiterentwicklung der DevOps-Umgebung und der Services statt für Routineaufgaben eingesetzt.
Claranet verlässt sich im DevOps-Kontext auf Open-Source-Tools. Riexinger will so ein Vendor-Lockin vermeiden. Er schätzt auch die Entwickler-Community und den unkomplizierten Zugang zu Open-Source-Lösungen. Die Arbeit mit den Werkzeugen sei relativ einfach, und auch die Klientel ziehe mit: "Unsere Kunden reagieren auf unsere DevOps-Angebote sehr positiv." (qua)