Agile, DevOps und Continuous Delivery – eine Bestandsaufnahme

Meyen: Für Webentwickler ist das nichts Neues, sie haben sich schon immer um HTML, um die Datenbanken usw. kümmern müssen. DevOps bedeutet für sie eher ein bisschen mehr über Methoden und Automatisierung zu lernen, die Grundidee ist aber schon längst umgesetzt. Also interessiert DevOps doch vor allem Java-Leute, oder?

Schlegel: Ich glaube, das betrifft keine bestimmten Technologien, sondern die Art und Weise, wie Devs und Ops zusammenarbeiten. Unser typischer Kunde sieht DevOps und Continuous Delivery aus der Sicht des Betreibers, achtet also besonders auf den Betrieb. Man wird von ihm Behauptungen hören wie: „Diese Entwickler benutzen all diese verrückten Technologien, ohne jemals mit uns zu reden, und halten uns damit von unserem Ziel ab, das da heißt Stabilität.“ Die Entwickler hingegen sagen: „Diese Ops nehmen uns den Spaß am Entwickeln und halten uns von dem ab, was wirklich interessant ist und von unserem Ziel: Innovation.“ Es gibt also zwei einander widersprechende Ziele: Features versus Stabilität. Aber die Crux ist: Devs und Ops gehören zur selben Organisation. Und damit diese erfolgreich ist, müssen sie sich zusammenraufen. Das ist der springende Punkt. Wenn es nämlich den Entwicklern auf eine bestimmte Technologie ankommt, müsste man ihnen folgendes klarmachen: Wenn sie in einem bestimmten Projekt eine neue Technologie einsetzen wollen, ist der Stakeholder, mit dem sie sich absprechen müssen, die Operationsabteilung. Die hat ein nachvollziehbares Interesse daran zu verstehen, wie diese Technologie wirkt und sich auf die Stabilität auswirkt.

Dörnenburg: Aber Sebastian hat recht. Es gibt definitiv eine Korrelation, wenn nicht sogar eine Kausalität zwischen den bisher verwendeten Technologien und dem Ausmaß, in dem ein Umdenken erforderlich ist. Als traditioneller PHP-Entwickler ist man es gewohnt, das, was man geschrieben hat, über FTP auf einen Server zu kopieren, und dort läuft es einfach. Da gab es keine Ops-Abteilung, da hat man keine WAR Files erstellt und man hatte nicht überall zig Konfigurationen. Und die Ruby-Leute waren auch immer sehr innovativ: So etwas wie Heroku, das neulich von Salesforce übernommen wurde, ist ein ideales Vorbild. Man committet in ein zentrales Sourcecode Repository und das Deployment geht wie von selbst. Das ist in vielerlei Hinsicht das Endziel von Continuous Delivery. Es war einfach eine ganz natürliche Erweiterung des Toolsets und der Umgebung, die es schon gab. Wohingegen man zum Beispiel in der Java-Welt den Eindruck gewinnen konnte, es wäre alles mit der Absicht designt, Deployments zu erschweren. Deswegen ist es heutzutage viel schwieriger, Arbeitspraktiken zu ändern.

Fowler: Es kommt auch auf das unternehmerische Umfeld an, in dem man sich bewegt. In einer Startup-Umgebung ist es viel einfacher, in flachen Hierarchien zu arbeiten, während in einem größeren Unternehmen die Abteilungen schon Festungen gleichen.

Meyen: Erik hat gerade Heroku erwähnt. Ich habe den Eindruck, dass all diese Diskussionen um DevOps teilweise die Cloud betreffen, da die Cloud eine Art dynamische Infrastuktur ist. Seht ihr einen Zusammenhang zwischen PaaS oder IaaS und der DevOps-Bewegung?

Schlegel: Ich beobachte, dass Entwickler, die anfangen, in einer Art Cloud-Umgebung zu experimentieren, weil sie beispielsweise mit dem Ops-Team frustriert sind, für frischen Wind in Unternehmen sorgen. Vom kommerziellen Standpunkt aus wird es sich lohnen, Clouds für Spikes oder fürs erste Setup einzusetzen. Aber ich habe auch Kalkulationen gesehen, nach denen sich Clouds langfristig nicht rechneten.

Dörnenburg: Wir vergessen hier einen wesentlichen Schritt. Unser Ausgangspunkt war der, dass wir spezielle Server in Auftrag gaben, jeder manuell konfiguriert, jeder anders, sodass man nie so genau wusste, woran man war. Und dann kommt auf einmal ein riesiger Sprung zu Dingen wie Elastic Computing wie bei Amazon. Aber dazwischen gibt es einen großen Schritt, der für unsere Kunden die wichtigste Rolle spielt: Sie gehen nicht sofort in die Cloud, sie trauen dem Ganzen nicht, sie wissen noch nicht, was es damit auf sich hat. Sie denken, dass es vielleicht eine tolle Sache sein könnte, aber meiden sie noch. Sie setzen derzeit auf VMWare oder Xen, Technologien, mit denen sie ihre Umgebung virtualisieren können. Hier kommt wiederum Continuous Delivery ins Spiel, denn wenn man plötzlich 400 VMs hat, wird selbst der konservativste Op den Gedanken haben, dass er deren Setup nicht unbedingt komplett manuell ausführen möchte. Viele Unternehmen werden zunächst solche internen Clouds einsetzen. Aber die Idee, alles zu virtualisieren, es einfach rekonfigurierbar und verschiebbar zu machen, das scheint aktuell der Mainstream zu sein.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.