Prä- versus Post-DevOps-Welt

Michael Thomas

© Shutterstock.com/alphaspirit

Nati Shalom, Blogger sowie Gründer und CTO von GigaSpaces, stößt nach eigenen Aussagen immer wieder auf das Problem, dass sich in Diskussionen die Erläuterung der fundamentalen Unterschiede in der Anwendungsverwaltung, die sich mit der Etablierung von DevOps ergeben haben, äußerst schwierig gestaltet.

Einer der Gründe hierfür ist Shalom zufolge, dass immer noch dieselbe Terminologie wie in früheren Zeiten genutzt wird, diese heute jedoch andere Bedeutungen in sich trägt. Des Weiteren ist es, wie Shalom häufig feststellen musste, gängige Praxis, traditionelle Rechenzentrum-Management-Tools nach und nach um beispielsweise Automatisierungstools zu erweitern, DevOps sozusagen wie ein Feature aufzupfropfen. Es wird also versucht, eine alte Struktur für neue Anforderungen fit zu machen.

Doch schon der generelle Aufbau von Rechenzentren ist Shalom zufolge in der Prä- und der Post-DevOps-Welt jeweils ein anderer. In der Prä-DevOps-Welt ging man demnach von der Prämisse aus, dass jede Organisation individuell zu befriedigende Bedürfnisse hat und das Rechenzentrum auf diese zugeschnitten werden muss; jedes Rechenzentrum also „besonders“ ist. In der Post-DevOps-Welt hingegen stellen Rechenzentren agile Infrastrukturen dar, die auf die Geschwindigkeit, in der Produkte und Features veröffentlicht werden können, optimiert sind – „besonders“ zu sein, bremst hier eher.

Um die fundamentalen Unterschiede der Anwendungsverwaltung in der Prä- und Post-DevOps-Welt, den „kulturellen Wandel“, zu verdeutlichen, stellt Shalom sechs Begriffspaare auf:

1. Monolith versus Werkzeugkette

In den Zeiten vor DevOps war man laut Shalom mangels Alternativen geradezu gezwungen, monolithische Management-Lösungen zu entwickeln. In der Post-DevOps-Welt hingegen bietet sich die Auswahl von (größtenteils quelloffenen) Werkzeugketten an, die sich jederzeit ändern können bzw. den Bedürfnissen angepasst werden. Closed Source-Dienste von nur einem Anbieter limitiert per definitionem den Spielraum der DevOps-Teams, neue Tools in ihre Prozesse zu integrieren.

2. Closed Source versus Open Source

Wie von Shalom angedeutet, wurden traditionelle Management-Lösungen in der Regel als Closed Source-Lösungen entworfen, während in der Post-DevOps-Welt Open Source eine Schlüsselstellung einnimmt: U. a. durch die Möglichkeit, ein Framework im Hinblick auf die eigenen Bedürfnisse anzupassen, kann eine höhere Produktivität und eine höhere Innovationsgeschwindigkeit erreicht werden.

3. Limitierte Skalierung versus Webskalierung

Während traditionelle Management-Lösungen auf die Handhabung von maximal mehreren Hundert Services und Anwendungen ausgerichtet waren, muss in heute gängigen Umgebungen auf Tausende oder gar Hunderttausend Knoten skaliert werden. Dies kann beispielsweise durch ein Architektur-Design erreicht werden, bei dem Services separiert werden und unabhängig voneinander skalieren.

4. Verwaltung von Hosts und Geräten versus Verwaltung von Infrastruktursystemen und Clustern

Das Tooling der Prä-DevOps-Welt war auf die Verwaltung von Hosts und Geräten ausgerichtet, modernes Tooling sollte Shalom zufolge hingegen in der Lage sein, komplexere Systeme zu verwalten. Die Verwaltung von Infrastruktursystemen und Clustern ist herausfordernd. Die Orchestrierung endet heutzutage meist nicht mit der Installation und Bereitstellung, sondern erstreckt sich auch auf die Phase danach: Das Monitoring muss ebenso bedacht werden wie z. B. Workflows, Policies, die Autoskalierung oder die Wartung. Die Orchestrierung bedarf nicht nur der Einrichtung der Infrastruktur, sondern auch eines Prozesses, der beispielsweise mit einem MongoDB- oder Hadoop-Cluster interagieren kann.

Die meisten traditionellen Werkzeuge sind für derart komplexe Prozesse nicht geeignet. In der Post-DevOps-Welt ist die Verwaltung von Infrastruktursystemen und Clustern gang und gäbe; viele kommen gleich mit eigener Orchestrierung und eigenem Management daher. Anstatt über eine einzelne Kontrollinstanz zu verfügen, muss dabei mehr Verantwortung auf verschiedene Ebenen des Managements übertragen werden.

5. Infrastrukturzentrierung versus Anwendungszentrierung

Während Shalom zufolge in der Prä-DevOps-Welt die meisten Management-Tools für die Verwaltung von Rechen-, Speicher- und Netzwerkdiensten gedacht waren und das Anwendungsmanagement sozusagen nachträglich übergestülpt wurde, neigt die Post-DevOps-Welt dazu, Anwendungszentrierter zu sein, wobei die Management-Aufgaben einen integrierten Bestandteil des Entwicklungsprozesses darstellen.

6. Limtierte Plug-ins versus Zukunftssicherheit

Althergebrachte Management-Lösungen bieten zwar Plug-ins, diese sind jedoch häufig begrenzt und/oder schwer zu implementieren, weshalb Support durch den Anbieter der jeweiligen Lösung erforderlich ist.

Um Zukunftssicherheit zu gewährleisten, müssen laut Shalom alle Layer des Stacks integriert werden könen, und zwar ohne dass dazu Management-Lösung geändert werden muss. Außerdem, so Shalom weiter, wird eine Laufzeit-Integration benötigt, in der Anwendungen, die andere Cloud-Ressourcen und -Infrastrukturen nutzen, leicht bereitgestellt werden können. All dies sollte vollständig isoliert möglich sein, damit nicht bei jeder Einführung eines neuen Plug-ins der Management-Layer angetastet werden muss.

Aufmacherbild: Businessman jumping from old computer to new laptop von Shutterstock.com / Urheberrecht: alphaspirit

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: