DevOps in der Praxis
In der Theorie ist DevOps ein strategischer Ansatz, der Entwickler und Admins näher zusammenbringen und damit agile Entwicklungsmethoden ermöglichen soll. Funktioniert das in der Realität?
- Uwe Geier
In der Theorie ist DevOps ein strategischer Ansatz, der Entwickler und Admins näher zusammenbringen und damit agile Entwicklungsmethoden ermöglichen soll. Funktioniert das in der Realität?
Kein Unternehmen wirft von einem Tag auf den anderen seine Softwareentwicklungsprozesse ĂĽber den Haufen und arbeitet nach agilen Methoden. Vielmehr schleichen sich Herangehensweisen wie DevOps ein. Da sind zum einen die Anforderungen des Markts, Produkte und Service schneller und effizienter zur VerfĂĽgung zu stellen. Zum anderen hat der Erfolg von DevOps auch etwas mit einem Kulturwandel zu tun.
Agile Methoden – im Kleinen längst bewährt
Meist ist es ein kleines Problem, für das eine schnelle Lösung benötigt wird: Eine Test-Routine muss mal eben programmiert, eine Schnittstelle zwischen zwei Anwendungen ein wenig angepasst werden oder Ähnliches. Es ist weder Zeit noch besteht die Notwendigkeit, hierfür einen klassischen Entwicklungsprozess anzustoßen. Ein kleines Team findet sich zusammen, spricht die Anforderungen und Abhängigkeiten ab und legt los. Der Entwickler stellt dem Administrator das Programmierte vor, dieser regt weitere Verbesserungen an, damit die Integration und der Betrieb reibungslos funktionieren. Der Entwickler überarbeitet sein Werk und lässt den Admin erneut prüfen und testen. Fertig.
So oder so ähnlich verlaufen die ersten DevOps-Schritte – aus der täglichen Arbeit heraus und ohne darüber nachzudenken, ob diese Vorgehensweise nun einen Namen hat oder nicht. Die Vorteile: kurze Abstimmungswege und schnelle Erfolge. Diese Art und Weise der Softwareentwicklung eignet sich auch für größere Projekte, etwa der Entwicklung von Apps oder Modulen. Dabei werden die Teams nicht mehr nach ihrer Funktion zusammengestellt, sondern nach Use Cases.
Ein Beispiel: Eine größere Softwareapplikation benötigt ein neues Feature, etwa um einen neuen Partner in den Produktionsprozess einbinden oder sicher mobil auf die Anwendung zugreifen zu können. Der Use Case ist damit klar definiert und mit ihm das Ziel, das erreicht werden soll. Der Projektleiter holt nun die Entwickler und die für den Betrieb der Software verantwortlichen Admins an einen Tisch. Die Anforderungen aller Beteiligten werden diskutiert und dokumentiert. Regelmäßige Meetings dieser Art in kurzen Abständen haben sich bewährt. Beispielsweise kann sich das Team täglich zum Arbeitsbeginn kurz abstimmen. Da immer alle beteiligt sind, fließen Änderungen viel schneller und im laufenden Prozess ein. Das Risiko, dass im Nachhinein noch viele Bugfixes einzuspielen sind, sinkt deutlich.
Offene Enden und Mangel an Konzeption
Das klingt einfach umsetzbar – und das ist es tatsächlich. In der täglichen Praxis gibt es kaum echte Reibungspunkte, die nicht fachlich zu klären wären. Dass es Entwicklern egal wäre, ob ihre App später auf der Infrastruktur auch wirklich läuft, und dass Admins stets schlecht auf Entwickler zu sprechen seien, da diese unadministrierbare Software entwickelten, ist eine Mär. Fachliche Diskussionen in frühen Entwicklungsstadien sind hingegen ausdrücklich erwünscht und machen den Kern dessen aus, was DevOps sein soll. Denn ob beispielsweise wegen der besseren Versionierbarkeit ein ganzes Paket programmiert oder doch in einem Git-Repository eingespielt wird, lässt sich so frühzeitig ausdiskutieren und fällt nicht im Nachhinein auf die Entwickler zurück.
Dennoch: Ein Softwareentwicklungsprojekt besteht nicht nur aus kleinen Apps. Agile Methoden leben mit dem Risiko, zu wenig Aufwand in die Anfangskonzeption zu stecken und damit Spaghetti-Code zu produzieren, der sich schließlich nur noch mit hohem Aufwand pflegen lässt. Klassische Softwareentwicklung startet für gewöhnlich mit einem Pflichtenheft und einem sorgfältig durchdachten Konzept, das spätere Integrationen und Erweiterungen bedenkt. Das ist und bleibt auch sinnvoll, vor allem wenn es sich um generalistische Software wie ERP-Systeme handelt.
Doch die meisten anderen Anwendungen haben ihre Halbwertszeit deutlich verkürzt. Der Softwarelebenszyklus beträgt bestenfalls noch wenige Jahre; zu schnell und grundlegend entwickeln sich Techniken weiter. So passiert es zum einen, dass eine Software ganz neu aufzusetzen ist, weil neue Feature konzeptionell nicht bedacht wurden und sich nun nicht mehr integrieren lassen. Zum anderen haben sich viele Apps aber nach wenigen Jahren bereits überlebt und eine Erweiterung wäre aufwendiger als eine Neuprogrammierung mit modernen Werkzeugen.
Tools, Community, Prozesse
A Fool with a Tool Is Still a Fool
DevOps ist eine Strategie, die organisatorische und technische Unterstützung benötigt, um wirklich gelebt zu werden. Zahlreiche Werkzeuge für das Deployment, das Release-Management, die Planung, das Reporting, das gesamte Projektmanagement und die Arbeitsorganisation stehen im DevOps-Umfeld zur Verfügung. Dabei sind die Automatisierung und die Nutzung von Vorhandenem im Fokus.
Welches Werkzeug nun aber konkret unterstützen soll, ist nebensächlich. Meist spielen die Vorlieben derjenigen eine Rolle, die das Projekt vorantreiben. Wichtig erscheint, dass sich Teams zutrauen, nach neuen Paradigmen zu entwickeln, und dass die Unternehmensführung modern genug aufgestellt ist, das auch zuzulassen. Der schnell sichtbare Erfolg kleinerer Anfangsprojekte hilft dabei, die Vorgesetzten von der Effizienz agiler Softwareentwicklung zu überzeugen.
Wenn die Teams dann wachsen, werden unterstĂĽtzende Tools notwendig. Die Auswahl fĂĽr alle Teilbereiche der Softwareentwicklung und des Betriebs ist beeindruckend. Nicht alle lassen sich problemlos miteinander integrieren. Einige sind sehr auf einen Teilprozess spezialisiert, andere versuchen die Gesamtidee von DevOps abzubilden.
Scrum etwa gehört oft zu den ersten erkennbar genutzten "Tools". Scrum-Meetings finden teamübergreifend in kurzen, regelmäßigen Abständen – oft täglich zu Arbeitsbeginn – statt. Kleine Projektschritte mit Zwischenergebnissen, empirisches, inkrementelles und iteratives Vorgehen sowie klare Regeln zeichnen die Vorgehensweise nach Scrum aus und sind damit eine gute Voraussetzung für agile Entwicklung.
Scrum ist jedoch nur der Anfang, der einen organisatorischen Rahmen bildet. Viele Entwicklungsteams arbeiten schon länger beispielsweise mit Git, um die Versionen ihrer Software sinnvoll zu verwalten. Web-basierte Systeme wie Jenkins und Bamboo dürften vielen Entwicklern ebenfalls ein Begriff sein – sie unterstützen beim Continous Delivery und der Integration durch automatisiertes Generieren von Code und Tests. Daneben gibt es sowohl für den Build- als auch für den Test-Prozess spezialisierte Tools wie Maven oder Cucumber. Im Konfigurations-Management haben sich besonders Puppet und Chef etabliert. Beide automatisieren den Aufbau, das Deployment und das Management der Infrastruktur. Diese soll dadurch ähnlich versionierbar, testbar und wiederherstellbar sein wie Anwendungs-Code. Wer Container und Images erstellen, teilen oder vorhandene Container nutzen möchte, kommt derzeit kaum an Docker vorbei.
DevOps lebt von der Community
Docker ist derzeit so etwas wie der Inbegriff der DevOps-Bewegung. Die Open-Source-Software isoliert mit Hilfe der Virtualisierung von Betriebssystemen ganze Anwendungen in Container. Die Applikationen lassen sich als Paket deutlich einfacher zur Verfügung stellen und transportieren. Die Container und Images werden direkt eingespielt. Dabei hat man eine stark angepasste Betriebssystemumgebung für das jeweilige Produkt, muss sich jedoch nicht um die Installation kümmern. Diese lässt sich sehr schnell austauschen und bereitstellen. Das Ergebnis sind zügige und einfache Deployments.
Im Docker Hub kann sich jeder Nutzer einen privaten Bereich einrichten, auf den niemand sonst Zugriff hat, um seine Anwendungen in Container zu packen und sie dann beispielsweise dem Testteam zu übergeben. Docker Hub hat aber auch einen öffentlichen Bereich, in dem viele Entwickler ihre Container anderen zur Verfügung stellen. Nutzer können sich aus einem Pool zahlloser Container bedienen und sie ihren Bedürfnissen gemäß anpassen und weiterentwickeln.
Mehrere Anbieter setzen auf den Docker-Trend. Beispielsweise soll DevOps Central, die Community-Plattform des Berliner IaaS-Anbieters (Infrastructure as a Service) Profitbrick, den Einstieg in die agile
Softwareentwicklung erleichtern. Sie bringt die notwendige, flexibel skalierbare Infrastruktur mit. Detaillierte Kenntnisse der Systemarchitektur sind nicht notwendig. Mit wenig Aufwand können sich Entwickler ihre Umgebung schaffen, sie nutzen und ebenfalls unkompliziert wieder loswerden. Die gebotenen Frameworks bieten jeweils Basisfunktionen, die jeder weiterentwickeln und auf seine speziellen Use Cases anpassen kann.
Ist DevOps ITIL-tauglich?
Die Prozessänderungen und -beschleunigungen rufen die ITIL-Spezialisten (IT Infrastructure Library) auf den Plan, die sich fragen, ob so viel Agilität mit den mühselig durchgesetzten Normen überhaupt vereinbar ist. ITIL definiert, wie das IT-Service-Management im Unternehmen umgesetzt wird, um standardisiert ein gewisses Maß an Qualität erreichen zu können. Service-Management als solches denkt dabei durchaus globaler und bezieht sich auf die Gesamtheit der organisatorischen und spezialisierten Fähigkeiten, ein oder mehrere Services anzubieten und damit wertschöpfend für den Kunden zu arbeiten. In der Praxis heißt das: Man sollte sich Gedanken darüber machen, was eigentlich erreicht werden soll, wie man das überprüft und wie man auf Fehlentwicklungen reagieren kann. Denn die Softwareentwicklung ist nur ein kleiner Teil eines umfassenden, unternehmensübergreifenden Service-Managements.
Mit welcher Methode oder welchen Werkzeugen ein Team sein Ziel erreichen soll, schreibt ITIL nicht vor. Insofern passen ITIL und DevOps gut zueinander. Denn auch wenn die DevOps-Prinzipien für Außenstehende chaotisch wirken mögen, unterliegen sie doch sinnvollen Regeln: regelmäßige Abstimmungen, gewollt-iteratives Vorgehen, bewusste Teamzusammenstellungen nach Use Cases, klare Zeit- und Zielvorgaben und Ähnliches. Und nur weil ein Team agil entwickelt, heißt das nicht, dass die Arbeit oberflächlich erledigt wird. Die ausführliche Dokumentation ist hier ebenso notwendig wie bei der klassischen Softwareentwicklung.
Fazit
Die Zeit ist reif für DevOps. Viele Entwicklungsteams arbeiten längst vor allem bei kleineren Projekten oder bei ad hoc benötigten Problemlösungen nach agilen Prinzipien. Operations-Abteilungen werden dabei oft frühzeitig mit einbezogen, indem man mit Fragen einfach auf die Kollegen zugeht. Nicht immer muss die Zusammenarbeit einen Namen wie Scrum-Meeting erhalten. DevOps findet in der Praxis also längst statt. Für größere Projekte braucht es allerdings einen organisatorischen Rahmen und unterstützende Werkzeuge.
Manchmal fehlt gerade deutschen Unternehmen noch etwas Mut, konsequent agil zu arbeiten. DevOps ist keineswegs eine amerikanische Bewegung, sondern wird von Experten weltweit getrieben. Dennoch entspricht DevOps eher der amerikanischen Mentalität als der deutschen, Projekte einmal weniger zu planen, sondern einfach zu starten.
Die Praxis wird die Mentalität überholen. Längst sind Entwicklungsteams international, die Fach-Community, mit der man sich austauscht, ist es sowieso. Der Vorwurf, in Deutschland gäbe es eher Spezialisten als Generalisten und die Arbeit wäre deshalb strikt in Bereiche geteilt, hält sich hartnäckig. Das mag durchaus zutreffen, muss und wird sich aber in naher Zukunft ändern. Das verlangen nicht nur Entwicklungen wie DevOps, sondern eine extrem beweglich gewordene Softwarebranche.
Was hindert deutsche Unternehmen noch? Hört man sich unter DevOps-Nutzern um, bestätigen sich die Befürchtungen der Kritiker nicht, dass Admins etwa künftig um einen Teil ihres Jobs fürchten müssen. Denn DevOps kann kein Ersatz für jahrelange Erfahrung sein. So erhalten Entwickler mit Sicherheit einen tieferen Einblick in die Administration und werden angehalten, über ihr jeweiliges Spezialgebiet hinaus die Zwänge des anderen Bereiches in ihre Arbeit einzubeziehen. Dennoch ist ein entsprechend gebriefter Entwickler noch lange kein versierter Admin. Das gilt umgekehrt genauso. Aber Praktiker zeigen andere Risiken auf: So besteht die Gefahr, dass die entwickelte Software komplexer wird. Programmier- und Systemfehler sind dann deutlich schwerer zu diagnostizieren und zu beheben. Kein Grund aber, vor DevOps zurückzuschrecken.
Uwe Geier
ist Head of Systems Operations bei ProfitBricks.
(ane)
