Microservices-Prinzipien #5: Beste Technologie für die Aufgabe statt eine Technologie für alles

Dieser Beitrag ist Teil einer sechsteiligen Serie über Microservices-Prinzipien. Die anderen Teile sind: Geschäftsfähigkeit, Autonomie, Kleiner begrenzter Kontext, Asynchrone Kommunikation und Ein Team.

Microservices sind ein heißes Thema. Deshalb sagen viele Leute eine Menge Dinge. Um Unternehmen dabei zu helfen, das Beste aus diesem neuen Architekturstil zu machen, hat Xebia eine Reihe von Prinzipien definiert, die unserer Meinung nach bei der Implementierung einer Microservice-Architektur angewendet werden sollten. In diesem Blog behandeln wir: "Beste Technologie für die Aufgabe statt eine Technologie für alles"

Ein allgemeiner Vorteil von dienstbasierten (und lose gekoppelten) Architekturen ist die Möglichkeit, für jeden Dienst eine andere Technologie zu wählen. Obwohl dieses Konzept nicht neu ist, wird es nur selten angewandt. Der Grund dafür scheint oft darin zu liegen, dass die Dienste zwar unabhängig voneinander arbeiten sollten, aber dennoch (Teile) desselben Stacks nutzen. Dies wird noch verstärkt durch den Drang, die gesamte Entwicklung unter einer einzigen Technologie zu konsolidieren. Der Grund dafür ist in der Regel, dass die Entwickler austauschbarer und damit wertvoller werden, wenn alles auf der gleichen Technologie läuft, was ja eigentlich eine gute Sache sein sollte.

Wenn dies also kein Neuland ist, warum sollten Sie es wieder aufgreifen? Warum sollte eine Microservices-Architektur einen bestehenden Ansatz ändern? Die kurze Antwort lautet: Autonomie. Die lange(re) Antwort ist, dass eine Microservices-Architektur nicht versucht, gemeinsame (technologische) Funktionen in singleton-ähnlichen Diensten zu zentralisieren. Nein, der Schwerpunkt einer Microsservices-Architektur liegt auf der Service-Autonomie, die sich an der Geschäftsfähigkeit orientiert, und ein Microservice kann daher seinen eigenen Stack implementieren. Dadurch kann ein Microservice leichter alleine eingesetzt werden und ist so wenig wie möglich von anderen Diensten abhängig.

Aber der autonome Einsatz ist nicht der wichtigste Grund, um die Technologie auf der Basis von einzelnen Diensten zu betrachten. Der wichtigste Grund ist der einfache Grundsatz "das beste Werkzeug für die Aufgabe". Nicht jede Technologie ist gleich gut. Das beschränkt sich nicht nur auf die Wahl der Programmiersprache oder des Frameworks. Es gilt für den gesamten Stack, einschließlich der Datenschicht.

Anstatt eine beträchtliche Summe für den Kauf großer, aufgeblähter Mehrzweck-Middleware auszugeben, sollten Sie leichtgewichtige Einzweck-Container in Betracht ziehen. Wählen Sie Container, in denen die von Ihnen benötigte Technologie läuft. Sie brauchen nicht für alles Java-Anwendungen mit einer relationalen Datenbank. Es gibt andere Sprachen, Frameworks und sogar Datenspeicher, die auf spezifische Bedürfnisse zugeschnitten sind. Denken Sie an andere Sprachen wie Scala oder Go, an Frameworks wie Akka oder Play und an Datenbankalternativen, die sich auf spezielle Anforderungen wie das Speichern (und Abrufen) geografischer Daten konzentrieren.

Die Wahl des Stacks hat auch mit den Möglichkeiten zu tun, die Sie für Ihre Anwendungslandschaft haben. Wenn Sie bereits über Komponenten verfügen, die für Sie funktionieren, oder wenn Sie Komponenten aus dem Regal kaufen möchten, ist es ein echter Vorteil, nicht durch einen vorhandenen Stack eingeschränkt zu sein. Wenn Sie sich zum Beispiel für eine reine Windows-Umgebung entschieden haben, schränken Sie Ihre Möglichkeiten ein.

Wenn Sie Bedenken haben, eine so vielfältige Landschaft zu pflegen, sollten Sie bedenken, dass ein Großteil der Komplexität dadurch entsteht, dass Sie versuchen, einen einzigen Stack für alles zu pflegen. Kleinere und einfachere Stacks sollten leichter zu pflegen sein. Und ein einziges Betriebsteam für all diese verschiedenen Technologien zu haben, klingt nicht nach einer guten Idee? Da haben Sie Recht! Wenn Sie immer noch getrennte Entwicklungs- und Betriebsteams haben, ist es vielleicht auch an der Zeit, diese Strategie zu überdenken. Der Devops-Ansatz macht den Betrieb der Dienste zu einer gemeinsamen Aufgabe. Das geht nicht von heute auf morgen, aber es ist auch ein Grund, warum Microservices so gut zu Unternehmen passen, die eine agile Arbeitsweise eingeführt haben und/oder Continuous Delivery anwenden.

Wenn Sie Ihren Entwicklern ein breiteres Spektrum an Tools zur Verfügung stellen, sollten sie sich auch weiterhin engagieren. Die Möglichkeit, mit mehr als einer Technologie zu arbeiten, kann ein Faktor sein, um Talente zu halten und anzuziehen.

[bearbeitet: 3 aug 2015 - Präambel hinzugefügt und Zeile"In den nächsten Tagen werden wir jedes dieser Prinzipien in einer Reihe von Blogbeiträgen ausführlicher behandeln." entfernt]