Mit DevOps und Cloud zu mehr Agilität, Teil 2 Next Stop „Cloud“

Das Umdenken in Richtung DevOps kann neue Probleme schaffen, die meist auf die vorhandene IT-Infrastruktur im Unternehmen zurückzuführen sind. Doch mit dem Cloud Computing etabliert sich zunehmend eine wichtige Stütze der DevOps-Transformation.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Confluent Germany GmbH

Mit der Etablierung von Data Warehouses, dem WWW und der Digitalisierung unserer Geschäftsprozesse im Allgemeinen haben die Data Center Einzug in die Keller der Unternehmen gehalten. Server wurden seit jeher gehegt und gepflegt sowie verantwortungsvoll und aufopfernd in Change-Management-Prozessen betreut.

DevOps hat hier bereits eine Transformation angestoßen, damit sich Prozesse, die Menschen und auch die Zusammenarbeit verändern, der nächste Schritt betrifft das „bare metal“ selbst. Ob sporadisch neue Datenbanken, mehr Speicher oder komplett neue Server für eine vielleicht nur temporäre Kampagne oder Testumgebung: Die wachsenden und wechselnden Anforderungen aus der neuen agilen DevOps-Welt stellen die alte Data-Center-Welt sehr häufig vor große Herausforderungen, die in der Regel nicht in der notwendigen Zeit zu meistern sind.

Die mittlerweile in der breiten Masse angekommenen Server-Virtualisierungskonzepte erlauben heute völlig neue und flexible Ansätze, die nach dem „Pets vs. Cattle“-Sinnbild von Randy Bias das Thema Cloud Computing zu dem machen, was es heute ist: Das noch fehlende Bindeglied zwischen Agile und DevOps.

Server und Netzwerke müssen somit nämlich heute genau nicht mehr vom Betrieb gehegt und gepflegt werden wie Haustiere – Kosenamen für Server waren ebenfalls keine Seltenheit –, sondern diese Dinge existieren in modernen Rechenzentren heute nur noch virtuell. Fällt eine Server VM aus irgendeinem Grund aus, so kann eine frische Kopie innerhalb von Minuten wiederhergestellt werden.

Ist ein Hardwaredefekt daran schuld, so wird der betroffene Knoten gar nicht mehr für die weitere Ausführung in Betracht gezogen, sondern ein völlig anderer, weil es keine Rolle spielt, auf welchem „Blech“ mit welcher Netzwerkkarte das Abbild gestartet wird.

In modernen „as a Service“-Umgebungen sind heute alle scheinbar hardwarenahen Themengebiete so stark abstrahiert und virtualisiert, dass sich eigentlich alles in Software und Konfiguration derselben abbilden lässt. Infrastructure-as-a-Service-, also IaaS-Angebote von Amazon oder Google zum Beispiel erlauben bereits seit Jahren die Erzeugung von virtuellen Servern und Netzen mit wenigen Klicks beziehungsweise Operationen.

Orchestrierungs- und Provisionierungstools wie „Hashicorp Terraform“ können dabei die automatisierte Erzeugung, Vernetzung und Installation der notwendigen Netzwerke, Server und Applikationen übernehmen. Denn alles, was in Software abgebildet wurde, lässt sich auch durch Software ansprechen. Das verdanken wir denselben Ideengebern bei Amazon, denen wir auch die ganze DevOps Bewegung verdanken. Sie haben postuliert, dass sich Services immer durch eine sauber strukturierte APIs ansprechen lassen sollen, die unter Zuhilfenahme anerkannter Standards wie zum Beispiel HTTP, JSON oder HATEOAS realisiert werden.

Das erleichtert die Integration und schärft das Verständnis für die Abstraktion weg von Team-Insellösungen oder proprietären Sackgassen. Das ist einer der Eckpfeiler, weshalb Amazon mit seinem Web Services Angebot so erfolgreich war. Eine Public Web API, die es erlaubt, Server-Instanzen zu starten, konnte der breiten Masse als Dienst angeboten werden.

Mit DevOps und Cloud zu mehr Agilität, Teil 1

Agile Transformation und DevOps-Kultur

Platform as a Service (PaaS) ist nun ein Konzept, das darauf beruht, den Entwicklungsteams alle Werkzeuge direkt in die Hand zu geben, die sie für ihre Arbeit brauchen. Cloud Foundry ist ein prominenter Vertreter dieses Ansatzes. Solche Plattformen können aufbauend auf Infrastructure-as-a-service-Setups betrieben werden und liefern den großen Mehrwert, dass dadurch sehr viele Best Practices und Konventionen von Haus aus bereitgestellt sind, ohne den technologischen Horizont einzuschränken.

Einem Entwicklungsteam Infrastructure-as-a-service-Werkzeuge an die Hand zu geben, führt schnell zu sehr heterogenen Insellösungen, da sie per Definition keine Plattform-Konzepte vorgeben. Bei PaaS sollen Entwickler in der Lage sein, sich ihren eigenen favorisierten Technologiemix aufzubauen, ohne sich mit Themen wie Netzwerken oder virtuellen Maschinen beschäftigen zu müssen.

Der Grundgedanke ist dabei, eigenverantwortlich Software in diese Plattform automatisiert zu deployen sowie Datenbanken und andere Services über den plattformeigenen „Shop“ ohne Verwaltungsaufwand zu bestellen – und das alles mit dem „Self-Service“-Gedanken im Vordergrund. Entwickler liefern also nicht nur die Software, sondern ein Gesamtpaket aus zum Beispiel einer oder mehreren Anwendungen, definierter Laufzeitumgebung, Datenbank, URLs basierend auf definierten Routen zu Applikationen und Monitoring.

Bei alldem soll noch betont werden, dass das Thema Cloud nicht bedeutet, dass nun das firmeneigene Rechenzentrum ausgedient hat. Ansätze wie Hybrid Cloud (vgl. Abbildung links) erlauben die Zusammenführung von Public-und Private-Cloud-Konzepten, ohne neue Nachteile in Kauf nehmen zu müssen. Damit ist der gleichzeitige Betrieb von unterschiedlichen Bestandteilen eines Software Systems in unterschiedlichen Rechenzentren gemeint. Einerseits sollen zum Beispiel die anonymen Katalogseiten eines Online Shops mit möglichst niedriger Latenz weltweit verfügbar sein, andererseits die sensiblen Kundendaten aber nie mit diesen Systemen in Berührung kommen.

Grundlage für die Hybrid Cloud liefern wiederum Virtualisierungstechnologien wie OpenNebula oder RackSpace, durch die sich das eigene Data Center zu einem privaten IaaS Dienst verwandeln lassen. Darauf lässt sich dann ebenfalls wieder eine PaaS ausrollen, um dem Entwicklungsteam eine konsistente „Developer Experience“ über beide Welten hinweg zu bieten.

„Developer Experience“ dank PaaS

Da sich mit dieser sehr großen Freiheit an Realisierungsmöglichkeiten aus unterschiedlichen DevOps-Teams dennoch schnell sehr heterogene Landschaften entwickeln, kann die Freiheit hinter „You build it, you run it“ schnell zu einem unbeherrschbaren Zoo mutieren. Denn nicht nur Technologien und Tools kommen und gehen, sondern auch die Teams, die damit in einer Organisation arbeiten und die Kollegen die mit unterschiedlichem Erfahrungsschatz zu unterschiedlichen Lösungen greifen.

An dieser Stelle kommt Platform-as-a-Service (PaaS) ins Spiel. Das Konzept setzt an einer ganz anderen Zielgruppe an, nämlich beim Entwickler selbst. Es gibt den Verantwortlichen für den Betrieb sehr viele erprobte Konzepte und Technologien an die Hand, die bei einem Aufbau auf blanker virtueller Infrastruktur immer relevant oder sogar zwingend erforderlich sind. Dabei wird das Operations-Team durch die Plattform zum Dienstleister für die Entwicklung.

Einer der prominenten Vertreter hier ist die „Cloud Foundry“-Plattform, welche in ihrer Grundform durch die „Cloud Foundry Foundation“ als Open-Source-Projekt getragen wird. Ohne hinsichtlich der vielen Bestandteile von Cloud Foundry weiter ins Detail zu gehen: Plattform-as-a-Service macht sich zum Ziel, den Softwareentwickler ins Zentrum zu stellen und alles dafür zu tun, die „Developer Experience“ so angenehm wie möglich zu gestalten.

Das beginnt beim Deployment von Applikationen und geht über die Bereitstellung von Services wie Datenbanken oder Message Queues bis hin zum Netzwerk/Routen-Management und Self-Healing-Konzepten – all das dem Self-Service-Ansatz folgend. Kein Entwickler soll mehr Tage oder Wochen auf eine Datenbank oder eine VM warten müssen.

Eine echte Self-Service-Plattform für Entwickler

Auf solch einer Basis können neue Teams und neue Projekte sofort fachlich durchstarten, weil infrastrukturell alles zur Verfügung steht, was für einen fliegenden Start notwendig ist. Das einzige, mit dem sich ganz neue Teams in einer solchen PaaS-Welt befassen müssen, ist die API zur Plattform hin und aus der Plattform heraus.

Wissen über Server, IP-Adressen und installierte Runtimes spielen keine Rolle. Feinheiten und Tunings am eigenen Environment können getrost vertagt werden, weil viele Standard-Konventionen bereits von der Plattform definiert wurden. Continuous Delivery gehört zum guten Ton und ist direkt anwendbar, die Entwickler entscheiden weitestgehend, wann, wo und wie geliefert wird.

Cloud-Native Ansätze wie 12-Factor erleichtern dabei die Anwendung von effizienten und robusten Rollout-Techniken entscheidend. Ein Gesamtsystem oder auch nur Teile davon können elastisch skalieren und sich den aktuellen Lastbedürfnissen anpassen, ohne dass architektonische Änderungen gemacht werden müssen, idealerweise ist noch nicht einmal manuelles Eingreifen notwendig. Das gleiche gilt für Konzepte wie „Self-Healing“, das Services automatisch neu startet, falls Metriken aus dem Tritt geraten.

Ausfallsichere Deployments mit kleinen Inkrementen können zum Beispiel nach dem Blue-Green-Verfahren aufgrund der gebotenen Freiheit unter Beachtung der Cloud-Native-Prinzipien leicht realisiert werden. Dabei wird eine neue Softwareversion (blaue Version) ohne Wartungsfenster parallel zur aktuellen Produktionsversion (grüne Version) installiert und steht somit technisch für Verifikationen zur Verfügung.

ie anschließende Umschaltung passiert dann schrittweise, sodass für einen Zeitraum die blaue und die grüne Version verfügbar sind und kurz darauf nur noch die blaue. Notwendig dafür ist die Möglichkeit, dynamisch einen Hostnamen auf eine Applikation zu mappen, jederzeit einen Softwarestand zu installieren und diesen in einem virtuellen Netzwerk verfügbar zu machen. Alles das ist quasi undenkbar in einem klassischen Data Center, vor allem bei einer klassischen Rollenverteilung. Auf einer PaaS sind das die grundlegenden Werkzeuge.

Durch diesen Paradigmenwechsel wird allerdings auch eine Menge Komplexität in die Plattform und deren Pflege verlagert, die nun von einem Team geleistet werden muss, das sich um den reibungslosen Betrieb der Plattform an sich kümmert. Ein fokussiertes Plattform-Team, das idealerweise wiederum cross-funktional aufgestellt ist – allein schon deshalb, weil ein solches System aus sehr vielen Software-Einzelkomponenten besteht, die nur im Verbund ihre wahre Kraft entfalten können – bildet sich heraus (siehe Abbildung unten).

Kollegen, die sich mit der on-premise Hardware und dem Management auskennen . also Netzwerk- und Systemadmins, Cloud-Architekten und DevOps-Spezialisten – arbeiten nun Hand in Hand, um den Entwicklungsteams die beste PaaS-Erfahrung zu bieten. Im Gegenzug steht das Entwicklungsteam nun in der Verantwortung, mit den bereitgestellten Werkzeugen die beste Erfahrung für den Endkunden zu bieten.

Neue Verantwortlichkeiten im Zusammenspiel

Auch wenn diese Entwicklung auf den ersten Blick den Anschein erweckt, dass die Verantwortungsbereiche verschwimmen, so werden sie in der Tat klarer voneinander abgegrenzt (vgl. Abildung links). Natürlich erhält das Entwicklungsteam insgesamt mehr

Verantwortung, allerdings in genau den Bereichen, die für selbstverantwortliches und agiles Arbeiten eigentlich dringend erforderlich sind. Dazu zählt beispielsweise, den 3rd-Level-Support für das Produkt beziehungsweise die eigene Domäne zu leisten.

Auf der anderen Seite hat das Plattform Team nun wesentlich weniger Aufwand mit Anfragen von jedem einzelnen Entwicklungsteam, weil die Plattform dazwischen klassische Aufgaben wie die Bereitstellung von Datenbanken oder Ausführungsumgebungen automatisiert. Dabei behält das Plattform-Team zu jeder Zeit die Kontrolle und Verantwortung darüber, welche Technologien und Services in welchem Umfang angeboten werden.

Beide Teams verstehen sich dabei ganz klar als DevOps-Teams, was deutlich macht, dass DevOps keine Technologie oder dedizierte Aufgabe ist, sondern genauso wie Agilität ein Mindset, das alle kooperierenden Teams „leben“ müssen, damit alle von den Vorteilen profitieren. Hinzu kommen die Kommunikation auf Augenhöhe und der laufende Austausch über Erfahrungen, Probleme und Ideen.

Das Ergebnis sind Releases, die aufgrund der neuen Freiheiten in Umfang und Frequenz jeweils vom Entwicklungsteam an die Gegebenheiten angepasst werden können. Ganz nach dem DevOps Motto „You build it, you run it“, was entgegen der Ansicht einiger keine Drohung ist, sondern ein Privileg. Wenn ein Entwicklungsteam oder ein Operations/Platform Team bei dieser Meinung angekommen ist, dann haben sie die Bedeutung von DevOps verinnerlicht.

Eine wichtige Vorbedingung soll an dieser Stelle nicht unerwähnt bleiben, auch wenn sie nicht im Fokus dieses Artikels steht: Kleine und schlagkräftige Teams, die eigenverantwortlich Komponenten eines größeren verteilten Systems bis in Produktion verantworten, sind nur möglich, wenn ihre Verantwortungsbereiche auch technisch klar voneinander entkoppelt sind.

Ohne eine dafür geeignete Architektur sind auch die effizientesten Deployment-Prozesse wertlos, da die Koordination der gegenseitigen Abhängigkeiten schnell unbeherrschbar wird. Im besten Fall ist ein PaaS-gestütztes Entwicklungsteam aber dazu in der Lage, ein Gesamtprodukt oder Feature auszuliefern, das zum einen aus Bausteinen der Plattform und zum anderen aus implementierten Services besteht, die einen Business Case abbilden.

Fazit

Um wirklich agil sein zu können, ist schnelles Feedback unverzichtbar. Schnelles Feedback gibt es nur mit häufigen und feingranularen Releases. Und damit diese sich wirtschaftlich lohnen, müssen die Kosten, um Software in Produktion auszurollen, drastisch reduziert werden.

Genau dabei helfen DevOps und Cloud – die entscheidenden Enabler aus der IT –, um das komplette Business agiler und damit wettbewerbsfähig zu machen. Plattform-as-a-Service Konzepte potenzieren dabei die Leistungsfähigkeit noch weiter, da durch konsistente und sichere Abbildung von DevOps-Vorgehensmodellen den Entwicklungsteams eine bestmögliche „Developer Experience“ geboten werden kann.

Ergänzendes zum Thema

Ein ökonomischer Exkurs

Die gesamte, hier beschriebene Transformation ist getrieben von dem Wunsch, immer häufiger Software in Produktion zu deployen um schnelles Feedback zu erhalten. Zum Schluss wollen wir diese Entwicklung aus einer qualitativen ökonomischen Perspektive betrachten.

Die hier gezeigte Abbildung visualisiert die Kosten pro Feature in Abhängigkeit von der Release-Größe, der „Batch Size“. In diesem Modell (angelehnt an Don Reinertsen ) sind zwei Kostenarten relevant:

• 1. Die „Holding Costs“ beschreiben im Wesentlichen entgangene Erlöse durch das verzögerte Ausrollen von fertigen Features. Diese steigen linear mit der Zeit, die zwischen zwei Releases vergeht.

• 2. Die Transaktionskosten beschreiben die Kosten des Rollouts selbst. Das beinhaltet das Deployment auf mehrere Staging-Umgebungen, die komplette Verifikation inklusive Regression und schließlich die Installation in Produktion ohne negativen Impact auf den laufenden Betrieb.

Der Kurvenverlauf basiert auf der Annahme, dass die Kosten für ein Release unabhängig von dessen Größe konstant sind. Daraus ergeben sich mit steigender „Batch Size“, also mit mehr Anpassungen innerhalb desselben Releases, selbstverständlich geringere Transaktionskosten pro Feature.

Will man die Gesamtkosten minimieren, liefert dieses Modell eine theoretisch optimale Release-Häufigkeit, die in der Regel deutlich niedriger ist, als von der Fachabteilung gewünscht. Da der Kurvenverlauf der „Holding Costs“ praktisch nicht beeinflusst werden kann, lässt sich das nur durch die Reduktion der Kosten für ein Release ändern.

Besonders hoch sind diese erfahrungsgemäß, wenn viele manuelle Schritte vonnöten sind. Daher ist DevOps, also die Automatisierung von wiederholbaren Prozessen, hier ein gewaltiger Hebel. Mithilfe der Cloud lässt sich dieser Ansatz auch auf andernfalls nicht automatisierbare Schritte wie das Aufsetzen von neuen Servern übertragen. Beides führt also zu reduzierten Transaktionskosten und damit letztendlich zu einer wesentlich kleineren, optimalen Release-Größe.

* Über die Autoren

Benjamin Steinert

Benjamin Steinert beschäftigt sich als Developer Advocate bei comSysto mit Themen Cloud Native, DevOps und Platform-as-a-Service. Seine achtjährige Erfahrung in der agilen Softwareentwicklung mit Java in unterschiedlichen Domänen und Rollen legen die Basis dafür.

Christian Kroemer

Christian Kroemer ist Agile Advocate bei comSysto, um die richtigen Rahmenbedingungen für moderne Softwareentwicklung zu schaffen. In verschiedenen Rollen unterstützt er Teams und Organisationen dabei, sich kontinuierlich zu verbessern und dabei agiler zu werden. Gerne stürzt er sich auch selbst tief in Java-Code und die Infrastruktur für komplexe Systeme.

(ID:45042543)