Es besteht das Gefühl, dass Microservices häufig als „Silberkugel“ vermarktet werden, um einen Monolithen zu ersetzen. Aber nicht jeder mag diesen Ansatz. In der Tat wird es manchmal falsch oder unangemessen verwendet. Im Folgenden finden Sie Beispiele für Probleme, auf die ich bei der Verwendung von Microservices in verschiedenen Unternehmen „Glück“ hatte und die ich in Zukunft nicht wiederholen möchte.
Phantomskalierbarkeit
Ein großes Plus des Microservice-Ansatzes ist die Skalierbarkeit. Ein unendlich großer Benutzerfluss und eine hohe Last werden als unvermeidlich angesehen. Aus diesem Grund wird viel Zeit für die vorläufige Optimierung und nicht für nützliche Geschäftsfunktionen aufgewendet. In der Realität sind nicht immer hohe Lasten vorhanden.
Das erste Opfer der Voroptimierung ist ein linearer Geschäftsprozess. Es zerfällt in viele Mikrodienste. Eine Art Reserve für die Zukunft aus Gründen der Aufgabentrennung oder der gespenstischen Skalierung. Infolgedessen wird es für Unternehmen schwieriger, in der IT-Landschaft zu navigieren und dieselbe Sprache wie die IT zu sprechen, ganz zu schweigen von den Problemen beim Navigieren durch den Quellcode für die Entwickler selbst.
Probleme mit der Service-Interaktion
Die empfangenen Dienste werden vom Monorep in separate Repositories verteilt. Die Dienste selbst werden immer schwieriger miteinander zu verknüpfen. In diesem Fall weicht die Version der Microservice-API möglicherweise von der Version derselben API in den Microservice-Clients ab. Dann wird der gute alte JSON durch Protobuf und HTTP durch gRPC ersetzt, um Leistung, Typisierung und bequeme API-Versionierung zu erhalten.
Leider sind Lösungen wie gRPC + Protobuf nicht fehlerfrei. Dienste können aufgrund der Ausbreitung eines Fehlers und einer bekannten Nichtübereinstimmung zwischen Dienst-Eingabe und Ausgabe konsistent abstürzen. Die Codebasis wird immer größer, das Debuggen von Diensten ist viel komplizierter als bei Klartextdaten, was eine Reihe neuer Probleme mit sich bringt.
Dieses Problem sollte durch einen normalen Testprozess behoben werden. Insbesondere Integrationstests. Es müssen jedoch Integrationstests für jeden Microservice und seine Gruppe innerhalb des Geschäftsprozesses geschrieben und ausgeführt werden. Dies ist eine ziemlich komplizierte Aufgabe, für die sie normalerweise keine zusätzliche Zeit aufwenden möchten. In diesem Fall kann der Microservice-Integrationstest auf die Form eines Komponententests für einen Monolithen reduziert werden.
Alte Einschränkungen und Gewohnheiten
Mit all dem wandern die üblichen Einschränkungen für den Monolithen in Mikrodienste. Markante Beispiele: eine Programmiersprache und eine Datenbank für alle Microservices. Im ersten Fall ist dies die erstere Einschränkung des Monolithen, im zweiten Fall handelt es sich um ein Vermächtnis, das versucht, der „Engpass“ des gesamten Systems zu werden. Aufgrund der Ablehnung der Möglichkeit der Existenz eines heterogenen Systems in verschiedenen Programmiersprachen durch die Entwickler und das Management geht die Möglichkeit der Auswahl geeigneter Tools zur Lösung dringender Probleme verloren.
Darüber hinaus sind für einzelne Microservices möglicherweise keine Entwickler verantwortlich. Jeder beginnt alles zu unterstützen, niemand ist für irgendetwas verantwortlich. In diesem Fall hat niemand Kenntnisse über die Funktionsweise einzelner Dienste, außer der letzten Person, die ihren Code geändert hat. Es kommt zu einer Desynchronisation der Entwickler, zu einem Verlust des Verständnisses für das Wesentliche der Arbeit von Microservices in Bezug auf die im Themenbereich gelösten Aufgaben.
Infrastrukturbürokratie
Microservices sind schwerer zu warten als ein Monolith. Die Infrastruktur, ein ehemaliges Serverpaar, wird zu einer kleinen privaten Cloud. Entwickler benötigen viel Zeit, um solche Lösungen zu unterstützen, und schaffen in Zukunft Probleme für das Management. Es besteht ein weit hergeholter Bedarf an zusätzlicher Bürokratie. Einzelne Mitarbeiter werden eingestellt, separate Prozesse erstellt.
In solchen Fällen können Regelsätze für die Arbeit mit Microservices verfügbar gemacht werden, um die Integrität der Microservices-Schleife aufrechtzuerhalten. Im schlimmsten Fall wird sogar die Möglichkeit verweigert, ein einmaliges Skript oder eine Migration auszuführen, wodurch der direkte Zugriff auf den Pfad verhindert wird. Das Fazit ist, dass das Skript als vollwertiger Dienst gestaltet ist und der langen Liste der Mikrodienste eine weitere Zeile hinzufügt.
Zukunft
Es stellt sich heraus, dass ein System ein viel größeres Rauschen aufweist als ein Nutzsignal. Überall - von der Infrastruktur bis zum Code eines bestimmten Dienstes. Vom Verständnis des Entwicklers für das Service-Interaktionsschema bis zum Management des Unternehmens. Programmierer werden unabsichtlich Meister im Lösen von Rätseln.
Natürlich ist der klassische Monolith nicht besser. Es ist langsam, zustandsbehaftet, schwer zu recyceln und wird nicht durch Unit- oder Integrationstests usw. abgedeckt. Aber wir können es besser machen! Dank des Mods für Microservices haben wir neben vielen anderen Vorteilen den Aufstieg von CI / CD gesehen und an Tests gearbeitet. Wir können sie jetzt auch auf andere Ansätze anwenden, nicht nur auf Microservices.
Wenn Sie das nächste Mal ein neues System entwickeln oder ein altes recyceln, überlegen Sie es sich zweimal. Benötigt ein Unternehmen Skalierbarkeit? Ist es notwendig, mit einer hohen Last fertig zu werden? Sind Sie selbst wirklich bereit für Microservices? Oder ist es besser, mit konservativeren Architekturen zu beginnen?
Vielleicht keine Rakete bauen, sondern einen einfachen Roller bauen, weil Sie nur bis zum Ende der Straße müssen?