Problem Nr. 1: zu kleinteilige Dienste

Die Möglichkeit, jeden Tag neue Dienste zu erstellen, führte zu einem Kreativitätsschub bei den Entwicklern. Ein neues Feature? Bäm, ein neuer Dienst! Mit einem Mal betreuten Teams mit 20 Entwicklern 50 Dienste. Das ist mehr als ein Dienst pro Person!

Nun ist ja das Problem mit Code im Allgemeinen, dass er erodiert. So war die Wartung jedes Dienstes plötzlich mit Kosten verbunden.

Stellen Sie sich vor, Sie verbreiten ein Bibliotheks-Upgrade über die gesamte Reihe Ihrer Dienste. Stellen Sie sich nun vor, dass diese Dienste zu unterschiedlichen Zeitpunkten gestartet wurden, mit unterschiedlichen Architekturen und einer bestimmten Verknüpfung zwischen der Geschäftslogik und den verwendeten Frameworks.

Das ist völlig verrückt! Natürlich gibt es Lösungen für diese Art von Problemen. Allerdings waren die meisten davon zu Anfang noch nicht verfügbar, andere verbrauchen auch heute noch große Mengen an Arbeitszeit.

Es gibt noch andere Negativbeispiele: Etwa, als mir jemand sagte, dass das Deployment einer neuen Funktion in Dienst A zur gleichen Zeit auch ein Deployment in Dienst B erforderte. Oder als man begann, Dienste zu schreiben, um CSVs zu erzeugen. Warum sollte jemand Netzwerk-Hops einführen, um ein weltweit bekanntes Dateiformat zu erzeugen? Wer würde so etwas pflegen?

Einige Teams litten an regelrechter Servicitis. Noch schlimmer waren aber die Reibungsverluste, die das alles erzeugte: Man konnte nicht einfach in ein Projekt in seiner IDE schauen, sondern musste mehrere Projekte gleichzeitig öffnen, um in dem ganzen Durcheinander einen Sinn zu erkennen.

Problem Nr. 2: Entwicklungsumgebungen

Ich habe aufgehört zu zählen, wie oft jemand zu mir gesagt hat:

Hey, João. Hast du mal eine Minute? Wir müssen unsere Entwicklungsumgebungen verbessern! Die Leute beschweren sich die ganze Zeit über sie.

Dabei hatte das Problem verschiedene Dimensionen: Mobile-Entwickler, die eine Funktion nicht entwickelten, bevor sie in einer Entwicklungsumgebung war, oder Backend-Entwickler, die ihren Dienst ausprobieren wollten, ohne den Business Flow zu unterbrechen. Auch war es problematisch, wenn jemand den gesamten Ablauf in einer mobilen App vor der Produktion testen wollte.

Insbesondere hinsichtlich der Skalierung in verteilten Systemen sollten vorher unbedingt folgende wichtige Fragen geklärt werden:

1. Wie aufwendig ist es, 200 Dienste bei einem Cloud-Anbieter zu betreiben? Ist es möglich? Ist es zudem möglich, die für den Betrieb benötigte Infrastruktur bereitzustellen?

2. Wie lange dauert es, das alles einzurichten? Was, wenn ein Mobile-Entwickler anfängt, eine Funktion zu programmieren, und es eine ganze Reihe von Diensten in einer bestimmten Version gibt, aber die Dienste, wenn die Entwicklung fertig ist, alle schon in neuen Versionen produktiv eingesetzt werden?

3. Wie sieht es mit Testdaten aus? Gibt es Testdaten für alle Dienste? Sind sie im gesamten Verbund kohärent, so dass Benutzer und andere Entitäten übereinstimmen?

4. Bei Anwendung in mehreren Regionen und mit mehreren Mandanten: Wie sieht es mit der Konfiguration und mit Feature Flags aus? Wie bleiben sie synchron mit der Produktion? Was ist, wenn sich die Voreinstellungen zwischenzeitlich ändern?

Und das ist nur die Spitze des Eisbergs. Man könnte darüber nachdenken, sämtliche Entwicklerkraft in diese Probleme zu stecken, vielleicht funktioniert das sogar. Allerdings bezweifle ich, dass die meisten Organisationen dafür groß genug sind. Es richtig zu machen, ist erstaunlich schwierig und teuer.