Erfolgversprechendes Trio Microservices, Docker und DevOps
Prognose Wachstum: Immer mehr Unternehmen setzen in der Software-Entwicklung auf den hohen Nutzen von DevOps. Einerseits zur Beschleunigung von Software-Delivery-Prozessen, andererseits zur Verbesserung der Qualität, Zuverlässigkeit und Sicherheit des Produkts.
Anbieter zum Thema

Die Kluft zwischen Organisationen, die DevOps bereits nutzen und denen, die noch nicht aktiv geworden sind, vertieft sich stetig. Diese Unterschiede und die Vorteile von DevOps werden in dem erst kürzlich erschienenen „State of DevOps Report“ beleuchtet.
Für viele Organisationen begann der Weg hin zu DevOps mit der Verknüpfung von Upstream Development und Downstream Delivery über drei Ebenen hinweg:
- Menschen und Kulturen
- Prozesse und Methoden
- Tools und Technik
Diese drei Ebenen sind voneinander abhängig, sodass zur Etablierung einer effektiven DevOps-Kultur alle adressiert werden müssen.
Auf der dritten Ebene – Tools und Technik – haben leistungsstarke Unternehmen seit Langem den Wert von Werkzeugen zur Automatisierung des Lieferprozesses, wie bei Continuous Integration und Continuous Delivery, erkannt. Allerdings bemerken Unternehmen oftmals, dass sie mit der Automatisierung von Legacy-Architekturen und dem Einsatz traditioneller Technologien nicht weit kommen.
Viele Unternehmen haben dementsprechend ein zunehmendes Interesse daran, ihre Software-Stacks mit Microservice-Architekturen und Container-Technologie zu verbessern. In vielerlei Hinsicht eigenen sich Microservices und Container sehr gut für DevOps, da sie die meisten Kernkonzepte unterstützen, die das Herz von DevOps ausmachen: darunter häufige Builds, schnelle Bereitstellung und kleinere, agilere Teams.
Im Folgenden soll erläutert werden, wie Microservices und expandierende Docker-Container-Ökosysteme so mit einer DevOps-Kultur vereint werden können, so dass mehr Funktionen schneller geliefert werden können, ohne dabei Qualität, Zuverlässigkeit oder Sicherheit einbüßen zu müssen.
Microservices sind nicht nur ein Mash-up von SOA
Aus einer Perspektive scheinen Microservices eine neue Version des SOA-Trends (Service Oriented Architecture) der vergangenen Jahre zu sein. Weil das Konzept der Microservices seine Wurzeln in SOA hat, haben die beiden Konzepte in der Tat viele gemeinsame Eigenschaften. Dennoch gibt es wichtige Unterscheidungen, die sie voneinander differenzieren.
Wie SOA entkoppeln Microservices einzelne Komponenten eines komplexen Systems und definieren Schnittstellen oder Vereinbarungen zwischen diesen Komponenten. Mit Microservices jedoch, die oftmals durch RESTful APIs implementiert werden, wird die Kommunikation zwischen den Komponenten erleichtert und Schnittstellen und Vereinbarungen sind weniger starr. Außerdem wird Microservices nachgesagt, sie seien eher auf die benutzerdefinierte Funktionalität als auf Back-End-Dienste fokussiert, jedoch ist das keine verbindliche Regel.
Microservice-Komponenten können auch unabhängig bereitgestellt werden, sodass es für relativ kleine Teams – unter anderem solche mit Expertise in einem bestimmten Bereich – einfacher ist, iterative Prozesse anzuwenden, um einen Microservice als Einzelkomponente zu erstellen, zu testen und zu liefern. Obwohl Microservices in der Branche relativ neu sind, gewinnen sie doch schnell an Popularität und Akzeptanz, weil sie Organisationen als Wegbereiter dienen, um Software schneller zu liefern.
Mehrere Faktoren tragen zu dieser Beschleunigung bei. Kleine Komponenten können unabhängig von Teams mit acht bis zwölf Entwicklern aufgebaut werden, die eine durchgängige Kontrolle über Entwicklung und Lieferung haben. Des Weiteren ermöglicht das Entkoppeln von Systemfunktionalitäten in kleinere Komponenten eine zuverlässige und häufige Aktualisierung einzelner Komponenten mit geringem oder keinem Einfluss auf das Gesamtsystem. (Tatsächlich können Systeme, die auf Elastizität ausgelegt sind und auf Microservices basieren, trotz der Nichtverfügbarkeit eines bestimmten Dienstes weiter ausgeführt werden.)
Das Zerlegen monolithischer Applikationen in Microservices erleichtert auch Rollbacks, wenn Probleme in der Produktion erkannt werden, sowie Rolling Deployments und Blue-Green Deployments. Kurz gesagt, ein funktionsübergreifendes Scrum-Team mit Entwicklungs-, Qualitätssicherungs- und Operations-Know-how kann schnell eine komplette Microservice-Komponente entwickeln, testen und bereitstellen und dann, sobald diese implementiert ist, schneller auf unerwartete Probleme reagieren.
Wie passen Container in dieses Konzept?
So wie Microservices einigen der Kernkonzepte von SOA neues Leben eingehaucht haben, so hat Docker eine jahrzehntealte Container-Technologie neu belebt. Die ersten Linux-Container waren vor 15 Jahren verfügbar und die Wurzeln dieser Technologie reichen noch weiter zurück. Im Zentrum der Aufmerksamkeit steht heute jedoch die Docker Container-Implementierung.
Docker ist die derzeit bei weitem beliebteste und am meisten verbreitete Container-Technologie. Durch die Definition eines Standard-Image-Formats und die Einrichtung eines Ökosystems aus Tools und Providern hat Docker die Container-Technologie zugänglich gemacht und dazu beigetragen, Container in den Mainstream der IT zu bringen. Mittlerweile gibt es kaum noch einen Mainstream-Anbieter von Entwicklungs- und Bereitstellungs-Tools, der ohne eine gewisse Docker-Unterstützung auskommt.
Worin liegt der Vorteil eines Einsatzes von Docker-Containern gegenüber separaten Servern oder gar virtuellen Maschinen, die in ähnlicher Weise verwendet werden können? Mit Containern vermeidet man den Aufbau und die Konfiguration eines völlig neuen physischen Servers oder einer neuen virtuellen Umgebung mit Prozessor-Emulation, einem Betriebssystem und installierter Software. Stattdessen kann mit dem Docker-Container eine ganze Umgebung in ein einziges leichtes Image eingekapselt werden. So bieten Docker-Container schnellen Zugriff auf Infrastruktur – eine Grundvoraussetzung für DevOps und Continuous Delivery.
Unveränderlichkeit ist ein wichtiges Merkmal der von Containern bereitgestellten Umgebungen. Laut John Willis, Director Ecosystem Development bei Docker, ist „Unveränderlichkeit eine Methodik, mit der in der Regel nichts Neues auf einer laufenden Infrastruktur geschaffen wird – prinzipiell sind die Produktion (das Basis-Betriebssystem), Middleware und Anwendung Bit für Bit identisch.“
Da ein Docker-Image die Anwendung, alle seine Abhängigkeiten und seine Umgebung verwaltet, wird die gesamte Bereitstellung eingebrannt und kann sich intakt durch die Software-Delivery-Pipeline bewegen. Die Anwendung hat eine konsistente Umgebung von der Entwicklung über Qualitätssicherung, Staging und Produktion. Diese Konsistenz eliminiert das Risiko, dass Entwickler einem sich ständig wandelndem Ziel nachlaufen.
Da die Branche weiterhin das Ideal verfolgt, Software nach jeder Veränderung zu testen, werden on-Demand-Umgebungen notwendig, um die gesteigerte Anzahl und Frequenz von Builds zu bewerkstelligen. Docker-Container bieten diese Fähigkeit und eliminieren einen bis dato massiven Engpass: das Warten auf die Bereitstellung ebensolcher Umgebungen.
Zusammenfassung
Mehr als die Hälfte der Teilnehmer der Jenkins-Community-Umfrage im Jahr 2016 gab an, dass ihr Unternehmen bereits Container-Technologie einsetzt – und mehr als 90 Prozent davon verwendeten Docker. Die Studie zeigte auch einen Aufwärtstrend bezüglich der Häufigkeit sowie der Automatisierung von Bereitstellungen. Von den Teilnehmern, die Continuous Delivery praktizierten, stellten mehr als 40 Prozent ein- oder mehrmals pro Woche Code bereit und etwa 30 Prozent führten vollautomatische Produktionsbereitstellungen durch.
Diese Ergebnisse korrelieren mit der wachsenden Beliebtheit von Microservices und Docker in Unternehmen, die DevOps-Methoden anwenden. Durch das Aufbrechen einer Applikation in separate Funktionskomponenten können kleine, funktionsübergreifende Teams diese als Microservices in Containern aufbauen, testen und bereitstellen.
Container eignen sich hervorragend für kleine, agile Teams, weil sie schnellen Zugriff auf eine unveränderliche Infrastruktur ermöglichen, ohne andere Entwicklungsströme zu stören. Darüber hinaus passen Container perfekt zu Microservices, weil sie gut dafür geeignet sind, kleinere, in sich geschlossene Komponenten zu hosten. Durch die Kombination von Microservices und Containern können agile Teams eigenständiger arbeiten, ihre eigene Infrastruktur beschaffen und letztendlich Software schneller liefern – vor allem, wenn die gesamte Software-Delivery-Pipeline mit Jenkins und anderen Automatisierungswerkzeugen, die Docker unterstützen, orchestriert wird.
Es gibt natürlich einige Vorbehalte zu bedenken, bevor man sich Hals über Kopf in das Thema Microservices und Container stürzt. Zum einen entwickelt sich die Container-Technologie rasant und die Frequenz neuer Docker-Releases ist hoch. Doch auch wenn man der Übernahme der Container-Technology offen gegenübersteht, sollte man die eigenen spezifischen Anwendungsfälle betrachten. Denn anstatt Zeit und Ressourcen zu opfern, ein älteres monolithisches System (das adäquat funktioniert) in Microservices aufzubrechen, könnten diese Software belassen und eine Microservice-Architektur nur bei der Implementierung neuer Fähigkeiten verwendet werden, um so die ältere Architektur allmählich zu ersetzen.
DevOps benötigt ein Zusammenspiel von Kultur und Prozessen sowie Tools und Techniken. Die Fähigkeit eines Unternehmens, Tools (einschließlich Docker) und Technologie (einschließlich Container und Microservices) zur Unterstützung einer kollaborativen Kultur und bewährter Methoden einzusetzen, ist ein führender Indikator zur Differenzierung im Wettbewerb. So kann Software schneller entwickelt und mit gesteigerter Qualität, Zuverlässigkeit und Sicherheit geliefert werden – von der Konzeption bis zum Kunden.
* Brian Dawson ist DevOps-Evangelist bei CloudBees.
(ID:44882880)