Vertikalisierung der Softwareentwicklung und Micro Services

Die Vertikalisierung der Softwareentwicklung ist ein erfolgreiche Modell für die Skalierung der Softwareentwicklung. Dabei betreut ein Entwicklerteam eine Kunden-Domäne und entwickelt die Software für diese Domäne autonom. Dies wird gerne durch das Share Nothing Prinzip umgesetzt. Das Entwicklerteam kann ohne Rücksicht auf andere Teams, also ohne Abstimmungsaufwand und Meeting-Marathons die Software für die Kunden-Domäne entwickeln. Dies spart Zeit und bring schnell gute Erfolge, es ist sehr effizient.

Vertikalisierung führt oft dazu, das das Team die Kunden-Domäne als einen Micro Service umsetzt. In der Praxis stösst dieses Vorgehen: eine Domäne, ein Team, ein Micro Service, recht schnell an seine Grenzen. Der Grund ist die Komplexität dieses fetten Micro Services, der verscheiden Aufgaben erfüllt. Oft kommt es zu komplexen Deployments, weil der fette Micro Service in verscheiden Funktionen deployed wird, z.B. zur Datenversorgung und Kunden-App. Aus meiner Erfahrung ist das Deployment und der Betrieb sehr komplex und führt zu zusätzlichen Fehlern. Ein Codebasis führt zu funktional unterschiedlichen Micro Services, die durch Konfiguration unterschieden werden. Diese funktional unterschiedlichen Micro Services sind nicht unabhängig von einander. Es kann zu fehlerhaften Konstellationen kommen, oft hilft nur eine gezieltes Überwachen des Betriebes diese Klasse von neuen Fehlern zu erkennen. D.h. wir haben eine neue Klasse von Runtime Fehlern, die schwerer zu erkennen sind und dazu noch sehr spä erkannt werden. Diese Fehler sind erst nach dem Deployment erkennbar. Dann ist der Service für den Kunden aber schon gestört. Oder aus einer anderen Perspektive, wenn wir die 12 Factors App Kriterien heranziehen, wäre dies ein Bruch mit dem Faktor 1!

Eine erfolgreiche Alternative ist es aus diesen fetten Micro Service in einzelne kleine, in sich geschlossene, Micro Services zu zerlegen. Zum Beispiel kann man die Datenversorgung von der Bearbeitung von Kundenrequest trennen. Oft wird als Gegenargument angeführt, das es gemeinsamen Code gäbe. In der Praxis hat sich gezeigt, das die Menge des gemeinsamen Codes sehr gering ist. Das Problem des gemeinsame Codes kann bei Bedarf über Bibliothek gelöst werden.

Zusammengefasst die Vorteile der Zerlegung von fetten Micro Services einer Vertikalen in schlanke Micros Services:

• Vereinfachung des Deployments
• Vereinfachte Konfigurationen
• Keine Fehler durch Fehlkonfigurationen, die Instanzen der Applikation sind unabhängig voneinander
• Höhere Robustheit, Fehler in einem Micro Service stört nicht die gesamte Applikation, so führt der Ausfall der Datenversorgung nicht dazu das der Kunde nicht mehr bedient wird
• Ein negativen Performance-Einflüsse durch Daten-Imports oder Wartungsjobs.
• Bessere Wartbarkeit, Codebasis beleibt schlank und übersichtlich

Clean Code 2

Ich hatte schonen einen Post zu Thema Clean Code geschrieben, da wurde ich auf das Buch Clean Code von Robert C. Martin hingewiesen. Er beschreibt dort keine Techniken sondern eher Prinzipien, also mehr wie man Code schreibt. Immer wenn ich mit Programmierern über das Thema sprach, ergaben sich lebhafte Diskussionen über einzelne Prinzipien. In meiner Arbeit sind mir viele der Dinge im Buch begegnet. Klassen mit generischen Namen wie Statistik. Jeder mit dem ich sprach kennt eigene Episoden, die man auch in dieses Buches wiederfindet. An der ein oder anderen  Stelle an wird sich jeder Softwareentwickler wieder erkennen. So ist es hervorragend für Diskussionen unter Kollegen oder im Team geeignet. Schön an dem Buch ist, das man es auch quer lesen kann und wenn man genug Zeit hat auch sich die umfangreichen Codebeispiele ansehen. Es ist eines der wenigen Bücher bei denen ich dies wirklich getan habe. Dafür wird man dann aber auch meist mit einer neuen Einsicht belohnt.


Es ist aus meiner Sicht ein wichtiges Buch für alle Programmierer und unbedingt jedem zu empfehlen. Ich kann neben der englischen auch die deutsche Version empfehlen. Beide Versionen sind gelungen.