Suchen

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

| Autor / Redakteur: Benjamin Steinert und Christian Kroemer * / Stephan Augsten

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.

Firma zum Thema

Cloud Computing mit Platform as a Service.
Cloud Computing mit Platform as a Service.
(Bild: comSysto)

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.

Cloud-Technologien können Agilität entscheidend verstärken.
Cloud-Technologien können Agilität entscheidend verstärken.
(Bild: comSysto)

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.

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.

Typisches Hybrid-Cloud Setup: In der Public Cloud werden keine Daten gespeichert.
Typisches Hybrid-Cloud Setup: In der Public Cloud werden keine Daten gespeichert.
(Bild: comSysto)

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.

Ergänzendes zum Thema
Ausblick – Verantwortungsbewusstsein schaffen

Auch wenn sich der hier geschilderte Zustand mehr nach einer Art Verantwortungsabgrenzung voneinander anhört, so bedeutet das nicht, dass nicht mehr alle an einem gemeinsamen Ziel arbeiten. Das verdeutlicht die neueste Strömung im Bereich DevOps und Betrieb von komplexen Systemen.

Unter dem Begriff Site-Reliability-Engineering oder kurz SRE, ins Leben gerufen von Googles VP of Engineering Ben Treynor, entstehen neue Ideen, wie die Verantwortung und die Zusammenarbeit der Teams ausformuliert und festgehalten werden können. Ein Baustein davon: Treynors Idee nach definieren Entwicklung und Betrieb, in unserem Fall das Plattform-Team, eine Art Vertrag. Darin festgeschrieben sind Fehlerbudgets, die sich jedes Team „leisten“ kann.

Üblicherweise liegen dem klassische SLOs (Service-Level Objectives) zugrunde, wie zum Beispiel eine Erreichbarkeit des Systems für den Endkunden von 99 Prozent. Alle Teams müssen zusammen an diesem Ziel arbeiten. Verletzungen bedeuten Sanktionen, das Erreichen im Gegenzug Vorteile. Somit kann das noch junge Werkzeug SRE gerade im Umfeld hochverfügbarer Anwendungen zwei Punkte leicht transparent machen.

  • 1. Fehler passieren und sollten nicht verteufelt werden.
  • 2. Manchmal sind Downtimes notwendig, sie müssen aber im Rahmen bleiben.

Die Entwicklungsteams entscheiden aufgrund ihrer Autonomie im beschreiben Szenario selbst, welche Risiken sie sich leisten können und welche nicht. SRE bildet eine formale Basis, um das Verantwortungsbewusstsein dafür zu schaffen.

Neue Verantwortlichkeiten im Zusammenspiel

Cloud Computing mit Platform as a Service.
Cloud Computing mit Platform as a Service.
(Bild: comSysto)

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.

Erst durch eine Reduktion der Transaktionskosten werden kleinere Releases wirtschaftlich.
Erst durch eine Reduktion der Transaktionskosten werden kleinere Releases wirtschaftlich.
( Bild: comSysto )

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
(Bild: comSysto)

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
(Bild: comSysto)

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)