Was ist DevOps?

DevOps ist ein Konzept, welches aus zwei Trends heraus entstanden ist: Zum einen gibt es den Trend namens Agile Systemadministration oder Agile Operations, welche das Ziel verfolgen, agile Konzepte auch den IT Betrieb zu bringen. Zum anderen steht dahinter die Idee, einen Nutzen daraus zu gewinnen, dass die Entwicklung und der Betrieb möglichst eng miteinander arbeiten, sei das entweder beim Erstellen oder beim betreiben einer Dienstleistung. Diese Zusammenarbeit soll über den gesamten Applikaitonslebenszyklus – oder moderner Servicelebenszyklus stattfinden, vom Design zur Entwicklung und Wartung einer Applikation.

Dev meint dabei nicht nur den bekannten Entwickler, sondern jede Person, die irgendwie an der Entwicklung einer Appliation beteiligt ist. Ops steht für alle möglichen Jobs im Betrieb: Systemadministrator, Datenbankadministratoren, Netzwerktechniker, Sicherheitsspezialisten etc.

Schlussendlich ist DevOps aber mehr als Entwicklung und Betrieb, mehr als die Tools und Prozesse, die dahinterstehen. Es steht für eine Philosophie, eine Einstellung, Dinge anders zu machen als in der Vergangenheit. Es ist das Schaffen einer Kultur, in der die Entwickler mit dem Betrieb zusammenarbeiten, immer mit dem Ziel, eine möglichst gute Software abzuliefern und am Laufen zu halten. Und alle Beteiligten arbeitet zusammen, um dieses Ziel zu erreichen.

Das Umdenken in der agilen Revolution

Bevor Agile unsere Welt kam schienen die Rollen klar verteilt: Die Devs waren die Macher, die Ersteller der Software, während die Ops die Personen waren, die sich um die Applikation in der Wartung gekümmert haben. Die Industrie hat aber festgestellt, dass diese zwei Rollen durchaus Synergieeffekte für sich nutzen können, wenn sie zusammenarbeiten.

Dieser Gedankenanstoss kam auch aus der agilen Ecke: Dort wird bis heute die Zusammenarbeit als eines der höchsten Werte gepriesen. Und das nicht nur zwischen diesen beiden, sondern zwischen allen Rollen. Gemeinsam soll in kurzen Iterationen das Produkt beziehungsweise das Inkrement stetig verbessert werden. Aus agiler Sicht macht es nur Sinn, wenn man die Interaktion eines Systems mit deren Umsystemen gemeinsam betrachtet und die Applikation als Ganzes betrachtet, statt nur den Code.

 Entwickler werden sich dabei vermehrt mit dem Thema der virtuellen Maschinen beschäftigen, während die Leute im Betrieb sich mit automatisierten Tests auseinandersetzen. Das ganze läuft dann bestenfalls unter einem Schirm von gemeinsamen Messzahlen (KPI = Key Performance Indicators).

Developer und Operations-Leute werden weiterhin bestehen

Genauso wie es unrealistisch isch, dass in einem Scrum Team jede Person ein Software Architekt ist, ist es nicht möglich, dass Leute im Betrieb plötzlich die gesamte Entwicklung übernehmen oder umgekehrt. Es ist aber sehr von Vorteil, wenn die Leute im Betrieb die Entwickler verstehen und auch die Entwickler ein gewisses Skill-Set haben, um betriebliche Herausforderungen zu meistern – Nicht zuletzt, wenn es einen Stellvertreter braucht, weil eine Person im Betrieb vier Wochen in die Ferien geht.

Microservices Einführung

Jeder moderne Software Architekt sollte wissen, um was es sich beim Thema Microservices handelt. Man findet im Internet alle möglichen technischen Erklärungen dafür, dabei ist es überhaupt nichts Übersinnliches.

Die simpelste Erklärung ist: Ein Microservice ist eine Einheit für sich, hat genau eine spezifische Aufgabe, und kann in nicht mehr als zwei Wochen gebaut werden.

Dies scheint wirklich zu einfach zu sein, nicht wahr?

Schauen wir uns drei wichtige Punkte dazu genauer an:

  1. Ein Microservice fokussiert sich auf genau eine Aufgabe, ähnlich der Kohäsion einer Methode oder einer Klasse. Wenn etwa Amazon als Microservice gebaut werden würde, dann gäbe es genau ein Modul für das Kaufen und Verkaufen eines Artikels, ein Modul für die Anzeige und das Hinzufügen der Benutzerkommentare etc. Im Gegenzug dazu sind die meisten Applikationen heutzutage grosse, schwere Kreuzer, die über Jahrzehnte gewachsen sind und innerlich sehr vernetzt sind.

  2. Microservices laufen für sich alleine, unabhängig von anderen Modulen. Wenn ein Microservice also abstürzt, wenn man andere Teile der Applikation ändert, ist es dieser nicht gut designt.

  3. Einer der wichtigsten Punkte ist allerdings: Ein Microservice ist in kurzer Zeit zu erstellen und in genauso kurzer Zeit nochmals zu erstellen. Wie oben geschrieben, spricht man von einer Zeitspanne von etwa zwei Wochen. Warum man einen Service nochmals schreiben sollte, fragen Sie? Nun, stellt man fest, dass der Microservice entweder das falsche macht oder ganz einfach nicht mehr aktuell ist, kann dieser in kurzer Zeit durch ein modernes Pendant ersetzt werden. Dies gilt natürlich auch für Performance: Läuft ein Microservice nicht schnell genug, kann dieser in kürzester Zeit durch eine neue Variante ersetzt werden.

Dazu kommt, dass jeder Microservice für sich ein API zur Verfügung stellt, welches unabhängig von der verwendeten Sprache oder Technologie ist. Dies bedeutet beispielsweise, dass man bei Amazon die ganze Applikation mit Java & Spring bauen könnte bis auf den wichtigsten Teil, das Anzeigen der Werbung. Weil dieser Teil für das Business unglaublich wichtig ist, wird dieser kurzerhand in C++ geschrieben, um sicherzustellen, dass dieser gut performt.

Dasselbe gilt natürlich auch für die dahinterliegende Datenbank. Für die Artikel könnte man eine MongoDB verwenden, während ein anderer Teil mit Oracle arbeitet.

Fokussierte Teams

Was nun bei Microservices dazukommt ist die kleiner granulierte Organisation. Statt ein grosses Team zu haben, welche die Herrschaft über alle Services hat, arbeiten viele kleine Teams an einer überschaubaren Anzahl von Microservices.

Fazit

Diese Einführung sollte reichen, um eine Idee zum Thema Microservices zu erhalten.