Polyglot architecture - Weniger Abhängigkeiten schaffen

Höhere Schnittstellen-Unabhängigkeit, flexibel agierende Teams und eine grössere Entscheidungsfreiheit bei der Auswahl von Programmiersprachen und Technologiestacks: Der Einsatz einer polyglot architecture in Verbindung mit Messaging/ Event Sourcing zur asynchronen Kommunikation zwischen mehreren Microservices (Bounded Contexts) oder auch externen Systemen /Applikationen, hat viele Vorteile zu bieten. Was sich hinter dem Pattern verbirgt, wann es Sinn ergibt es zu nutzen und welche Herausforderungen dabei auftreten können, erfahren Sie hier.‍

Wie funktioniert eine polyglot architecture?

Von einer polyglotten Architektur spricht man meist im Umfeld einer Microservice Architektur. Hierbei wird im Vorfeld eigenständig und abhängig von den Anforderungen festgelegt, welche Programmiersprache und welcher Technologiestack im Microservice verwendet wird. Innerhalb eines Ökosystems können somit verschiedene Sprachen und Stacks eingesetzt und parallel bedient werden. Statt zu limitieren wird bei einer polyglotten Architektur Entropie aktiv gefördert. Die Möglichkeit, die Rahmenbedingungen in weiten Teilen eigenständig zu bestimmen, ist einer der grossen Vorteile einer polyglot architecture.

Tight coupling Problem

Microservices können auf verschiedene Art und Weise gebaut werden. Bei einem polyglotten Ansatz wird verfolgt, dass jeder Service autonom agieren soll und auch die Datenbank spezifisch für den Service und den Anwendungsfall gewählt wird. Deshalb macht es in diesem Fall wenig Sinn, REST Schnittstellen als standardisierten Kommunikationsweg zu wählen. Wird eine Microservice Architektur zu stark auf REST Schnittstellen basierend aufgebaut, entstehen automatisch starke Abhängigkeiten (tight coupling).

Werden mehrere auf REST basierende Microservices hintereinander verknüpft und weist ein Teil der Kette einen Fehlerfall auf, hat das Auswirkungen auf alle konsumierenden Services. Die Fehlerquelle zu finden ist mühselig und die Kaskade führt dazu, dass jedes betreuende Team sich an das nächste Team wenden muss, von dem es den Service konsumiert. Dieser Mehraufwand bedeutet Zeitkosten, unter denen die Kunden leiden und teilweise Verluste entstehen, wenn Mitarbeiter gezwungen sind, ihre Tätigkeit zu unterbrechen und erst auf Rückmeldung warten müssen, um wieder produktiv zu sein.

Bei REST Schnittstellen werden die Daten aus dem integrierten Service bezogen. Das heisst, dass die Datenstruktur nicht für den Anwendungsfall des Microservices strukturiert ist, sondern für den generellen Anwendungsfall von mehreren Konsumenten. Im oben aufgeführten History Service kann dies schnell zu Skalierungsproblemen führen,  sobald der Service etwas mehr Daten durchsuchen und anzeigen muss.‍

Der bessere Weg: loose coupling

Werden solche Schein-Microservices, genauer gesagt monolithische Architekturen, dagegen durch Events aufgebrochen, kann dieses tight-coupling aufgelöst werden. Jeder Microservice erhält dadurch seine Autonomie und Abhängigkeiten können auf diese Weise nahezu umgangen werden. Um das zu erreichen, werden aus verschiedenen Event Streams diejenigen konsumiert, die für die Umsetzung des Services benötigt werden. Die genutzten REST- Services werden durch eine bewusste Replikation übernommen und in den eigenen Service integriert. Das heisst, dass statt auf REST-Services, vermehrt auf Libraries gesetzt wird, um gemeinsam genutzte Module in mehrere Microservices zu bringen. Auf diese Weise entsteht eine Architektur mit einer flachen Struktur an Microservices, die in der Lage sind, autonom zu agieren. Neben einer unabhängigen Struktur profitieren auch die Entwicklerteams von einer polyglotten Umgebung, da sie die Projektabwicklung flexibler und eigenständig gestalten können.

Die Vorteile von loosely coupled polyglot architectures

Von der Kombination unterschiedlicher Programmiersprachen, über die Beschleunigung von Entwicklungsphasen bis hin zur Förderung von IT-Talenten: loosely coupled polyglot architectures haben viele Vorteile zu bieten.

Releasezyklen unabhängig von anderen Teams

Fehlende Funktionalität für den Use Case kann von Teams in die von mehreren Microservices genutzten Libraries implementiert werden, anstatt diese von anderen Teams zu verlangen. Der Kommunkations- und Planungsoverhead innerhalb des ganzen Unternehmens minimiert sich und die Releasezyklen sind unabhängig von anderen Teams.

Sicherheit im Störungsfall: Fault tolerance

In einer polyglot architecture ist es möglich, verschiedene Services einzeln zu konsumieren. Fällt ein System störungsbedingt aus, bleiben die anderen Systeme davon unbeeinträchtigt und somit weiter handlungsfähig. Durch die Unabhängigkeit der einzelnen Datenbanken voneinander erhöht sich gleichzeitig die Sicherheit und die Systeme sind ohne allzu grosse Einbussen oder Verluste weiterhin einsatzbereit.

Abhängigkeiten reduzieren

Monolithische Anwendungen, oder vor allem auf REST aufgebaute Microservice-Architekturen, können schnell an Abhängigkeiten gewinnen, wenn bestehende Microservices durch weitere REST-Services ergänzt werden. Jeder zusätzliche REST-Service fördert eine starke Abhängigkeit auf den Stufen Fehlerbehandlung, Release-Planung und Schnittstellenpflege. Bei einer polyglotten Architektur dagegen bleiben die Abhängigkeiten im Team. Das ist insbesondere dann wichtig, wenn ein ganzes Ökosystem an REST-Services verwendet werden soll.

Skalierbarkeit und Flexibilität

Bei der Nutzung von REST-Services muss man darauf vertrauen, dass der REST-Service mit den Skalierungs-Anforderungen der eigenen Applikation mithalten kann. Meist werden diese Details jedoch nicht in API-Dokumentationen der genutzten REST-Services angegeben. Dies bedarf somit Abklärung und kostet die Teams jedes Mal Zeit. Falls die gebotenen Möglichkeiten nicht genügen, können diese innerhalb des Teams nicht ohne grossen Aufwand mitigieren. Deshalb muss der gesamte genutzte Service neu implementiert oder so lange gewartet werden, bis der konsumierte Service diese Skalierungsmassnahmen implementiert hat. Unter Umständen dauert dies aber zu lange und führt zum Stillstand der eigenen Applikation. Durch das Konsumieren von Events und die Nutzung von Libraries statt eines REST-Services, kann dies von den Teams selbst für den aktuellen Traffic skaliert werden.

Die richtige Programmiersprache und Datenbank

Die Entscheidung darüber, welche Programmiersprachen bei einer polyglot architecture eingesetzt werden, entscheidet das Team selbst, denn sie legen die technischen Bedingungen fest. Durch das Konsumieren und Verarbeiten von Events kann jeder Microservice unabhängig voneinander gebaut werden, dadurch können die Vorteile von verschiedenen Datenbanken, Programmiersprachen, Frameworks und Tools effizient genutzt werden.

Arbeitsgeschwindigkeit und Motivation

Durch die Möglichkeit, den Projektablauf aktiv mitbestimmen zu können, steigt auch die Geschwindigkeit und Motivation, mit der Lösungsansätze verfolgt und zum Ergebnis geführt werden können. Vorhandende Skills und Fähigkeiten werden auf diese Weise sinnvoll ausgeschöpft, statt limitiert. Vorhandene Ressourcen können direkt genutzt, statt zuerst geschult und dann genutzt werden. Ausserdem können mehrere Teams zur gleichen Zeit an verschiedenen Lösungen arbeiten und müssen keine Rücksicht auf den jeweiligen Entwicklungsstand nehmen oder auf Übergaben warten.

Sharing von Know-how

Durch das Einführen und Nutzen von Libraries, die in der Regel teamgetrieben sind, wird das interne Fachwissen innerhalb des Unternehmens besser verteilt.‍

Gibt es auch Nachteile bei polyglotten Architekturen?

Polyglot architecture hält viele Vorteile und Potenziale bereit. Dennoch gibt es auch einige Punkte, die berücksichtigt werden sollten, wenn es um die Frage geht, ob polyglotte Arbeitsweisen für ein Projekt in Frage kommen.

• Know-how-Sharing: Durch das Abschaffen der Abhängigkeiten von anderen Teams und das Einbinden von Libraries, deren Maintenance meist durch die Teamanforderungen getrieben wird, kann das Know-how-Sharing auch zu einem Nachteil ausfallen, falls die Libraries zu komplex werden. Das kann allerdings durch ein “library-team” mitigiert werden.
• Silos: Das Unternehmen muss bereit sein, sich von den Silos zu lösen. Da nun Weiterentwicklung der genutzten Libraries durch die Teams geschieht, verteilt sich die Verantwortlichkeit auf mehrere Teams. Das ist teils schwer zu vereinbaren mit stark hierarchischen Strukturen innerhalb der Unternehmen.
• Skalierung: Dadurch, dass die Teams die Skalierung selbst übernehmen müssen, bedarf es an Know-how, wie dies zu bewerkstelligen ist. Dies kann mitigiert werden, beispielsweise durch das Nutzen von standardisierten Plattformen wie Kafka, die den Teams Sharding-Problematiken und dessen Komplexität abnehmen. Das Team kann sich somit weiterhin um die effektiven Anforderungen des Unternehmens kümmern.
• Entropie: Wenn jeder Microservice in einer anderen Programmiersprache geschrieben wird, muss für jede genutzte Library eine Version in dieser Sprache existieren. Sobald zu viel Entropie herrscht, kann es schwierig werde dies zu handhaben. Dies kann zum Beispiel durch die weitverbreitete Intermediate Language WebAssembly mitigiert werden.

Werden die Vor- und Nachteile im Vorfeld gründlich abgewägt und in die Planung miteinbezogen, können jedoch frühzeitig notwendige Schritte eingeleitet und die Weichen für eine erfolgreiche Umsetzung gestellt werden.‍

Fazit: Effektive Lösungswege für komplexe Anforderungen

Die digitale Welt hat sich in den vergangenen Jahren enorm weiterentwickelt und stellt Unternehmen tagtäglich vor neue Aufgaben. Durch die digitale Transformation entsteht in den Unternehmen schnell ein Microservice-Ökosystem: viele Domänen-spezifische Services beginnen, einander zu integrieren. Werden beim Arbeiten mit REST basierten Microservices die Abhängigkeiten intransparent  oder zu viele Abhängigkeiten geschaffen, die zu Fehlerkaskaden führen können, ist eine polyglot architecture eine zu empfehlende Lösung. 

📝 Gefällt dir, was du liest?

Dann lass uns in Kontakt treten! Unser Engineering-Team wird sich so schnell wie möglich bei dir melden.