Monolithisch vs. Microservices-Architektur: Microservices sind out, Monolithen sind zurück

Diejenigen unter Ihnen, die das Gefühl haben, an einem schweren technischen Déjà-vu zu leiden, liegen nicht falsch. In derselben Situation befand sich die serviceorientierte Architektur (SOA) etwa im Jahr 2009, als Anne Thomas Manes deren Tod erklärte . Der Link führt zu einem Kommentar von David Linthicum zu Manes‘ Beitrag, da das Original offenbar vom Internet verschluckt wurde.

Nun war Manes etwas übertrieben und etwas sarkastisch, denn wie wir alle wissen, ist die serviceorientierte Architektur nicht ausgestorben. Es erlebte relativ schnell eine Wiederbelebung in Form von Microservices, und trotz der Wehmutstropfen im Internet haben die Designer immer noch nicht gelernt, welch große Rolle „das Netzwerk“ bei der Leistung spielt.

SOA ist aus zwei Gründen ‚gestorben‘:

1. Konkurrierende, aufgeblähte XML-basierte Standards, die die Architekturen übermäßig komplex machten. Niemand erinnert sich gern an WSDL, SOAP und UDDI. Niemand.
2. Die Gesetze der Physik und Interoperabilitätsstandards beschränken den Austausch von Netzwerkpaketen auf Lichtgeschwindigkeit und 1500 Bytes.

Die erste Herausforderung haben wir vielleicht gemeistert, aber die zweite? Die einzige Antwort auf die zweite Frage war und ist ein empfindliches Gleichgewicht zwischen der Granularität des Servicedesigns und einem guten Verständnis der für die Datenübertragung zwischen Diensten benötigten Zeit.

Die Datenübertragung ist nicht kostenlos. Es braucht Zeit. Bei der Kommunikation zwischen Diensten gibt es keine „Nullkosten“. Es dauert eine gewisse Zeit, ein Paket auf die Leitung zu legen, es dann zu übertragen, es dann vom Paket zu nehmen und es schließlich zu verarbeiten. Und vergessen Sie nicht, dass auch die Transportkommunikation Zeit braucht. Das Öffnen von Sockets und Akzeptieren von Anfragen ist ebenfalls nicht kostenlos, ebenso wenig wie die Zeit, die zum Serialisieren und Deserialisieren von Nutzdaten in etwas benötigt wird, das der Dienst verarbeiten kann.

Multiplizieren Sie nun diese Gesamtkosten mit der Anzahl der Dienste, die Sie nutzen möchten.

Je granularer Sie Ihr System gestalten, desto länger dauert die Bearbeitung einer Anfrage. Mit anderen Worten: Die Gesamtzeit zur Bearbeitung einer Anfrage hängt von der Anzahl der Dienste ab, die die Anfrage durchlaufen muss.

Höhere Granularität? Längere Bearbeitungszeit. Mehr Leistungen? Größere Überlastung des Netzwerks, was letztendlich die Verarbeitungszeit erhöht, da Netzwerkkarten und Geräte versuchen, die Pakete zu ordnen und eine erneute Übertragung anzufordern.

Daher können und werden Microservices ebenso wie SOA unter Designmustern leiden, die auf zu viel Granularität beruhen.

Amazon hat sich für einen Monolithen als Ersatz für seine Microservices entschieden. Das bedeutet, für ihren Anwendungsfall war eine monolithische Architektur die beste Option. Bedeutet das, dass Microservices tot sind?

NEIN. Stattdessen sollten wir zwei wichtige Punkte mitnehmen:

• Erstens sollten wir uns ein Beispiel an Amazon nehmen und bei der Gestaltung von Systemen, die auf Diensten basieren, überlegter und durchdachter vorgehen. Außerdem sollten wir uns darüber im Klaren sein, welche Auswirkungen es auf die Leistung hat, wenn Aufgaben auf zu viele kleine Dienste verteilt werden.
• Zweitens sollten wir bedenken, dass Monolithen eine praktikable Wahl für die Anwendungsarchitektur sind. Es gibt einen Grund dafür, dass 60 % des App-Portfolios eines Unternehmens aus Anwendungen bestehen, die auf „traditioneller“ Architektur basieren , und 16 % der Unternehmen nicht beabsichtigen, diese abzuschaffen.

Anwendungsarchitekturen sind weder gut noch schlecht, noch sind sie für jeden Anwendungsfall geeignet. Organisationen müssen einen Schritt zurücktreten und sorgfältig darüber nachdenken, was sie erreichen wollen und welche Architektur diesem Bedarf am besten gerecht wird, statt sich für die „modernste“ Architektur zu entscheiden, nur weil sie gerade in Mode ist.

Wenn wir sagen, dass die Zukunft der Hybrid-IT gehört, meinen wir mehr als nur eine Mischung aus Multi-Cloud- und lokalen Bereitstellungen. Wir meinen damit auch, dass das Portfolio der Unternehmens-Apps auf absehbare Zeit hybrid bleiben wird – eine Mischung aus Tradition und Moderne. Deshalb unterstützt das F5-Portfolio weiterhin alle Anwendungen, ob vor Ort oder in der öffentlichen Cloud – oder beides.