Find English version below

Im März konnte man einen interessanten Beitrag auf primevideotech.com lesen, dessen Titel einem IT Manager den Mund wässrig machen könnte: „Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%“.  Eine Anwendung skalieren, und dabei noch Kosten einsparen?  Die Zauberei, die man hier vermuten könnte, liegt in der Anpassung der Anwendungsarchitektur an die Aufgabe, die diese Anwendung zu erfüllen hat.

In seinem Beitrag beschreibt Autor Marcin Kolny, wie eine in Microservice Architektur (MSA) implementierte Anwendung den gestiegenen Anforderungen an Skalierbarkeit deutlich nicht mehr gewachsen war, und dabei noch viel überflüssige Ressourcen verbrauchte, hauptsächlich für die Orchestrierung der einzelnen Services und den Transport der Daten zwischen ihnen über Cloud Object Storage.  Die Lösung bestand im Wechsel zu einer monolithischen Anwendungsarchitektur, die den Bedarf für Orchestrierung und den Overhead für den Datenfluss deutlich minimiert hat.  Dieser Fall demonstriert einmal wieder klar den Vorteil für einzelne Anwendungen, den modularer Aufbau und intermodulare Methodenaufrufe gegenüber separaten Services haben, die nur über Netzwerkaufrufe miteinander kommunizieren können. 

Doch möchte ich an dieser Stelle noch auf etwas anderes hinaus, für das dieser Fall als Beispiel dienen könnte.

Was genau das ursprüngliche Projektteam bewogen hat, die Architekturentscheidung für Microservices zu treffen, weiß ich nicht.  Ein knappes Vierteljahrhundert in der IT lassen mich aber zwei mögliche Gründe vermuten.  Der erste Grund wäre: MSA war als quasi-Standard gesetzt, weil man sich einfach nicht vorstellen kann, dass etwas anderes besser sein könnte.  In einem anderen Kontext kann MSA ja auch die bessere Lösung sein.  Der zweite Grund: „Hier haben wir all die schönen Funktionen, Services und Tools in unserer Cloud zur Verfügung.  Lasst uns die nutzen, um unsere Anwendung zu bauen.“  Und – Überraschung:  nutze ich Komponenten, die zur Unterstützung einer MSA entwickelt wurden, lande ich höchstwahrscheinlich bei einer MSA.

Was dabei in beiden Fällen passiert, ist, dass etwas, das Teil der eigentlichen Architekturentscheidung seien sollte (hier: „Wir benutzen MSA“) oder aus der Architekturentscheidung folgen sollte („wir setzen die Tools xyz ein“),  zur Randbedingung gemacht wird.  In diesem Fall ist die zwangsläufige Folge, dass durch diese Randbedingung  MSA zur Grundlage der Architektur der spezifischen Anwendung wird.

Während funktionale Anforderungen bei einem solchen Vorgehen noch weit genug im Rampenlicht stehen, um nicht unter die Räder zu kommen, werden nicht-funktionale Anforderungen (NFA) ins Dunkel gedrängt.  Sie bilden dort Hindernisse, über die ein Projekt dann erst spät in seinem Verlauf stolpert. 

Die meisten von uns kennen Beispiele aus der Vergangenheit und der Gegenwart, in denen die Nutzung einer bestimmten zur entsprechenden Zeit aktuellen Technologie als Randbedingung in eine Architekturentscheidung einging, anstatt eine mögliche Folge einer solchen Architekturentscheidung zu sein.  Ersetzen wir doch z.B. einfach MSA durch J2EE, SOA, Cloud, KI,…, und schon kommen uns Fälle aus unserer eigenen Erfahrung in den Sinn.

Dem Team aus dem eingangs erwähnten Artikel darf man gratulieren, dass sie sich offensichtlich erfolgreich der Anforderung gestellt haben, frühere Architekturentscheidungen in Frage zu stellen, um nicht nur die funktionalen Anforderungen, sondern auch die die nichtfunktionalen erfüllen zu können.  Uns allen möchte ich wünschen, möglichst häufig Zeugen solcher Erfolge zu werden, oder besser noch, Projekte zu erleben, in denen von vorneherein die geschäftlichen Anforderungen an eine Anwendung die Basis ihrer IT Architekturen werden, und nicht eine gerade bevorzugte Technologie.

English version

In March, you could read an interesting article on primevideotech.com, the title of which could make an IT manager's mouth water: "Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%".  Scaling up an application, and cutting costs in the process?  The magic that one might suspect here lies in adapting the application architecture to the task that this application has to perform.

In his paper, author Marcin Kolny describes how an application implemented in microservice architecture (MSA) was clearly unable to cope with increased scalability requirements, while still consuming a lot of unnecessary resources, mainly for orchestrating individual services and transporting data between them via cloud object storage.  The solution was to move to a monolithic application architecture that significantly minimized the need for orchestration and the overhead for data flow.  This clearly demonstrates the advantage for individual applications of modular design and intermodular method calls over separate services that can only communicate with each other via network calls.

But there is something else I would like to point out here, for which this case could serve as an example.

What exactly prompted the original project team to make the architectural decision for microservices, I don't know.  However, nearly a quarter of a century in IT leads me to suspect two possible reasons.  The first reason would be: MSA was set as a quasi-standard because it was simply impossible to imagine that anything else could be better.  In a different context, MSA could even be the better solution.  The second reason: "Here we have all these nice features, services and tools available in our cloud.  Let's use those to build our application."  And - surprise: if I use components developed to support an MSA, I'll most likely end up with an MSA.

What happens in both cases is that something that should be part of the actual architectural decision (here: "we use MSA") or should follow from the architectural decision ("we use the tools xyz") is made a boundary condition.  In this case, the inevitable consequence is that this boundary condition makes MSA the basis of the architecture of the specific application.

While functional requirements are still far enough in the limelight in such an approach to avoid being pushed under the wheels, non-functional requirements (NFA) are pushed into the dark.  There, they form obstacles that a project then stumbles over late in its course.

Most of us know examples from the past and the present where the use of a certain technology that was the latest and greatest at the given time entered into an architectural decision as a constraint instead of being a possible consequence of such an architecture decision.  For example, let's just replace MSA with J2EE, SOA, Cloud, AI,.... and cases from our experience will come readily into our mind.

The team from the article mentioned at the beginning may be congratulated for obviously successfully facing the requirement to question previous architectural decisions in order to be able to meet not only the functional requirements, but also the non-functional ones.  I would like to wish all of us to witness such successes as often as possible, or even better, to experience projects in which the business requirements for an application become the basis of their IT architectures from the outset, and not a preferred technology at the time.