Wie man mit Shared-Dev-Cluster arbeitet (und warum) - Teil II: Warum Abwärtskompatibilität überbewertet wird

Im ersten Teil dieser Artikelserie habe ich über die Herausforderungen geschrieben, wenn Entwickler_innen, die an Kubernetes-basierten Anwendungen arbeiten, versuchen, alle Dienste lokal auszuführen.

Die Herausforderungen sind: Lokale Dienste mit Remote-Diensten zu verbinden, Cluster-Sharing, Multi-Tenant-Fähigkeiten von Remote-Diensten und die Versionierung sowie Verwaltung der Kompatibilität von Diensten.

Sie haben auch etwas über die faktorielle Komplexität erfahren und über die Details, warum die Verwaltung der Versionskompatibilität mühsam ist, wenn bei mehreren Dienste ganz grundlegende Änderungen durchgeführt werden oder Sie in der Lage sein müssen, verschiedene Versionen Ihrer Software zu unterstützen. Mit jeder Dimension der Variabilität wächst die Zahl der möglichen Konstellationen, in denen Ihre Software verfügbar sein muss, sehr schnell.

Jeder Faktor, der dazu führt, dass ein Dienst mit einem anderen nicht kompatibel ist, würde bedeuten, dass dieser spezifische Dienst in zwei (oder mehreren) verschiedenen Konfigurationen verfügbar sein muss. Jeder Faktor, der dazu führt, dass ein Dienst nicht von mehreren anderen Diensten genutzt werden kann, bedeutet, dass er für jede mögliche Konstellation von anderen Diensten einmal existieren muss.

In diesem zweiten Teil erkläre ich, was das genau bedeutet. Dazu sehen wir uns zunächst ein Beispiel an. Dann stelle ich dar, warum Sie diese Art von Komplexität sehr wahrscheinlich bereits in Ihrem Unternehmen vorfinden und welche Kosten entstehen, wenn Sie alle Dienste lokal betreiben.

Beispiel

Betrachten wir ein Beispiel, um zu zeigen, wie schnell Faktoren wachsen können. Der Einfachheit halber werde ich hier nur darstellen, ob die Dienste gemeinsam genutzt werden können und wie viele Versionen unterstützt werden müssen. Ich gehe davon aus, dass “unterstützte Versionen” bedeutet, dass keiner der Dienste abwärtskompatibel ist. Denn selbst wenn eine oder zwei Versionen abwärtskompatibel wären, würde das für das Ergebnis keinen großen Unterschied machen.

Anzahl an Services	Shareable	Nicht shareable	Unterstützte Versionen	Anzahl an Entwickler_innen (oder Kunden / Kundinnen)	Minimum an Remote-Services*
6	6	0	1	100	6
6	6	0	2	100	12
6	6	0	5	100	30
6	6	0	10	100	60
6	5	1	1	100	105
6	3	3	1	100	303
6	0	6	1 (Irrelevant)	100	600
6	3	3	2	100	306
6	3	3	5	100	315
6	3	3	10	100	330
6	0	6	10 (Irrelevant)	100	600

* Abhängig von der Leistung jedes Dienstes müssen unter Umständen mehrere Instanzen davon vorhanden sein, um 100 Entwickler_innen zu unterstützen. Sie können aber bei geringer Last auf die Mindestanzahl reduziert werden.

Haben Sie keine Angst vor Änderungen

Dieses Beispiel zeigt sehr schön, dass die Versionskompatibilität das kleinere der beiden Übel ist. Jede zusätzliche Version, die Sie unterstützen müssen, erhöht die Anzahl der Dienste nur um ein Vielfaches (6 in unserem Beispiel). In diesem Beispiel würde die Unterstützung von fünf verschiedenen Versionen eine immer noch überschaubare Anzahl von mindestens 30 Diensten zur Unterstützung jeder Version erfordern. Selbst wenn die Hälfte der Dienste abwärtskompatibel wäre und von verschiedenen Versionen gemeinsam genutzt werden könnte, würde sich die endgültige Anzahl nur auf 21 (statt 30) reduzieren, was zeigt, dass der Nutzen der Abwärtskompatibilität wirklich nicht so groß ist.

Dasselbe Prinzip gilt für andere Faktoren als die Versionen, die die Kompatibilität der Dienste beeinflussen.

Andererseits erhöht jeder nicht gemeinsam nutzbare Dienst die Anzahl der Entwickler_innen (oder Kundinnen / Kunden) um ein Vielfaches. Und dieses ist in der Regel viel höher als die Anzahl der Dienste. Mit nur einem nicht gemeinsam nutzbaren Dienst erhöht sich die Anzahl der mindestens erforderlichen Dienste in unserem Beispiel um 100!

In Anbetracht der enormen Kosten, die eine Abwärtskompatibilität mit sich bringt, wäre es viel sinnvoller, diese aufzugeben und sich auf die Einführung einer Mandantenfähigkeit für eine größere Anzahl von Diensten zu konzentrieren.

Nebenbei: Hier werden nur die Komplexitäten in der Entwicklung betrachtet. Die Einführung von grundlegenden Änderungen kann in Production andere Folgen haben, z. B. dass Kunden ihre Prozesse und Integrationen ändern müssen, wenn eine Änderung an der API eingeführt wird. Wichtig: Ich spreche hier von Änderungen an der Kommunikation zwischen den Diensten und nicht an externen APIs (die gleich oder unterschiedlich sein können).

Sie erhöhen nicht die Komplexität, Sie verschieben sie nur

Es ist verständlich, dass Sie diese Art von Komplexität in Ihrem Unternehmen nicht haben wollen. Das Problem ist nur: Sie haben sie höchstwahrscheinlich schon. Nur, dass diese im Moment von einzelnen Entwicklerinnen und Entwicklern verwaltet wird. Diese müssen herausfinden, wie die Anwendung lokal ausgeführt werden kann und dabei die Versionskompatibilität und die begrenzten Ressourcen des Laptops berücksichtigen.

Wenn von Entwickler_innen erwartet wird, dass sie alles lokal ausführen, führt dies standardmäßig zu einer vollständigen lokalen Einrichtung der Entwicklungsumgebung pro Entwickler_in. Keine Dienste können dann gemeinsam genutzt werden. Im Beispiel von oben müsste die maximale Anzahl von 600 Diensten zur Verfügung gestellt werden. Entwickler_innen müssten alle 6 Dienste auf dem Laptop ausführen.

Auf der Ebene der einzelnen Entwickler_innen ist diese Art von Aufwand oft weniger spürbar, weil es sich nicht um eine separate Kostenstelle handelt. Es handelt sich aber um reale Kosten, für die viele Unternehmen täglich zahlen – in Form von verlorener Zeit und Frustration bei Entwickler_innen. Und oft auch in Form von Qualitätseinbußen bei der Software und Produktionsausfällen, als Folge, dass die Entwickler_innen nicht mit den Tools ausgestattet sind, die sie für ihre Arbeit benötigen.

Die tatsächlichen Kosten, wenn alles lokal läuft

In Gesprächen mit vielen Entwicklerinnen und Entwicklern habe ich von drei Szenarien gehört, wie das in der Realität aussehen kann:

Szenario 1: Alles funktioniert gut
Entwickler_innen wissen, wie alle Dienste lokal betrieben werden können. Das ist bei einer winzigen Minderheit von Entwicklerteams der Fall. Ich habe das nur von Teams gehört, die:

aus maximal 5 Entwicklerinnen und Entwicklern besteht.
hochqualifiziert sind (Senior-Level).
nicht mehr als drei Dienste in der Software haben.
die viel Zeit in die Dokumentation und Automatisierung der lokalen Einrichtung und des Build-Prozesses investiert haben.

Szenario 2: Es funktioniert, ist aber anstrengend
Dieses Szenario ist sehr häufig. Vor allem bei kleinen Softwareunternehmen beobachte ich das. Sie haben typischerweise:

weniger als 100 Entwickler_innen (normalerweise 10-30)
eine Handvoll hochqualifizierter Senior-Entwickler_innen, die einen Großteil ihrer Zeit damit verbringen
- Tools (d.h. das Schreiben von Skripten) für das lokale Deployment und den lokalen Build zu entwickeln und
- jüngerer Entwickler_innen beim lokalen Deployment und dem lokalen Build unterstützen
nur wenige Dienste laufen (3-6)

Szenario 3: Es funktioniert nicht
Dies ist der Fall bei der überwiegenden Mehrheit der mittleren bis großen Softwareunternehmen, mit denen ich gesprochen habe. Sie haben in der Regel:

mehr als 100 Entwickler_innen
mehr als 5 Dienste laufen (oft mehrere Dutzend oder Hunderte)
das Problem, dass Sie nicht in der Lage sind die Software lokal auszuführen, weil ihre Laptops einfach nicht genug Rechenleistung bringen.

Das bedeutet, dass die Entwickler_innen blind arbeiten. Sie schreiben Code und pushen ihn direkt auf Staging. Sie sind nicht in der Lage, ihre Arbeit lokal zu validieren und zu testen (abgesehen von Unit-Tests).

Dies führt häufig zu

vielen Fehlern in der Software, was zu
hohe Investitionen in Tests,
hohe Investitionen in „Fehlerbehebungsmöglichkeiten“ wie automatische Rollbacks,
Produktionsausfälle, unzufriedene Kunden, Vertragsstrafen führt…

Was bedeutet das?

Ich kann mit meiner Stichprobe nur extrapolieren: Dabei schätze ich, dass nicht mehr als 1 % der Unternehmen wirklich erfolgreich mit einer Konfiguration sind, bei der von Entwickler_innen erwartet wird, dass alle Dienste lokal ausgeführt werden, d. h. Szenario 1.

Es scheint so zu sein, dass mit dem Wachstum und der zeitlichen Weiterentwicklung von Unternehmen auch die Software immer komplexer wird. Das führt zu einer raschen Zunahme der Faktoren, die beim lokalen Deployment variieren können – Stichwort faktorielle Komplexität.

Das führt zu Szenario 2, bei dem das lokale Deployment sehr viel Zeit der Entwickler_innen frisst. In allen Teams, mit denen ich gesprochen habe, gab es mehrere Personen, die einfach nicht in der Lage waren, mit dem lokalen Deployment umzugehen. Über alle Senior-Levels hinweg schwankte der Zeitaufwand für die Verwaltung der eigenen lokalen Deployments oder die Unterstützung von Kollegen bei lokalen Deployments zwischen 10 und 25 % der Zeit der Entwickler_innen. Der größte Zeitaufwand wurde von den jüngsten und den ältesten Entwicklern betrieben – die jüngeren brauchten viel Hilfe und die älteren leisteten viel Hilfe. Ein Senior zu werden bedeutete, ein Experte für das Deployment zu werden, wie z. B. das Schreiben von Helm-Charts oder die Fehlersuche in Minikube-Clustern.

Das eigentliche Bottleneck sind aber die lokal verfügbaren Rechenressourcen. In Szenario 3 war dies das am häufigsten genannte Problem. Selbst wenn Entwickler_innen viel Zeit investierten, waren sie einfach nicht in der Lage, die gesamte Anwendung lokal auszuführen. In diesem (besorgniserregend häufigen) Fall sind Entwickler_innen darauf angewiesen, blind zu arbeiten. Wie bereits erwähnt, führt dies zu Qualitätsproblemen, deren Behebung unglaublich schwierig und teuer ist.

Was ist die Lösung für dieses Problem? Das ist das Thema von Teil 3 dieser Serie. Ich werde erklären, was für viele Entwickler_innen funktioniert und wie man dorthin kommt.