Brauchen wir Microservices? / Sudo Null IT-Nachrichten

Heute erfreut sich die Microservice-Architektur von Webanwendungen besonderer Beliebtheit. Dieser Ansatz hat viele bekannte Befürworter. Dazu gehören Facebook, Uber, Groupon, Klarna, Amazon, Netflix, eBay, Comcast und mehr. Aber wie notwendig ist ein solches Vorgehen im konkreten Fall?

Wann werden Microservices benötigt?

Microservices haben eine Reihe von wahrgenommenen Vorteilen. Warum angeblich? Fakt ist, dass sie nicht nur mit Hilfe von Microservices bezogen werden können. Und die meisten, wenn nicht alle Vorteile können mit Hilfe eines Monolithen erzielt werden.

Das Microservice-Modell macht die Anwendung wirklich flexibler und ermöglicht es Ihnen, auf eine andere Ebene der Lösung bestehender Probleme zu wechseln.

Aber man muss für alles bezahlen, auch für Microservices. Sie sind dafür bekannt, dass sie sehr teuer zu bauen und zu warten sind.

Sollten Sie diese zusätzliche Flexibilität benötigen? Wunderbar. Dann sollten Sie auf Microservices achten. Vielleicht zahlt sich der Aufpreis irgendwann aus.

Und wenn nicht? Sie werden den Stack der verwendeten Technologien ernsthaft überlasten, was es dem Client erschweren kann, mit der Anwendung zu interagieren.

Betrachten Sie die Hauptvorteile von Microservices und überlegen Sie, wie Sie diese mit einem Monolith erreichen können.

Skalierbarkeit

Jede Funktion einer Microservice-Anwendung wird auf eigenen Ressourcen ausgeführt, die unabhängig skaliert werden können. Auf diese Weise können Sie natürlich die für Funktionen bereitgestellten Ressourcen effektiv steuern.

Aber wie notwendig ist dieses Maß an Kontrolle? Wie ausgelastet sind die verschiedenen Funktionen der Anwendung? Haben sie eine individuelle Skalierung? Was sind die CPU-, Arbeitsspeicher-, Speicher- und GPU-Anforderungen für die einzelnen Funktionen?

Hinzufügen von Ressourcen, Beheben von Monolith-Problemen

Das Problem fehlender Ressourcen in vielen Situationen ist für viele Teams durch eine Skalierung der Hardware einfacher zu lösen. Das heißt, eine detaillierte Optimierung einer laufenden Software-Infrastruktur ist in den meisten Fällen wirtschaftlich nicht machbar.

Leistung und Leistungsprobleme in einem Monolithen sind wahrscheinlich einfacher zu beheben als der Wechsel zu einem neuen Architekturmuster. Die spezifische Lösung hängt vom Stack der verwendeten Technologien ab, erfordert jedoch keinen großen Aufwand.

Verteilen Sie den Datenverkehr auf unabhängig skalierbare Cluster

Wenn Sie mehrere Server haben, platzieren Sie eine Art Load Balancer davor. Sie können diesen Load Balancer so konfigurieren, dass er Datenverkehr an unabhängig skalierbare Cluster Ihrer Anwendungsinstanz weiterleitet.

Sie können auch asynchrone Aufgaben mithilfe von unabhängig skalierbaren Warteschlangen in Hintergrundjobs verschieben. Stellen Sie sicher, dass genügend Warteschlangen vorhanden sind, um die Infrastrukturkosten zu senken.

Fehleranalyse

Ein großer Vorteil einer gut konzipierten Microservices-Architektur besteht darin, dass der Ausfall einer der Funktionen die anderen nicht beeinträchtigt.

Datenverkehr an isolierte Cluster weiterleiten

Die Idee, verschiedene Arten von Datenverkehr in skalierte Cluster zu leiten, kann auch einen gewissen Failover-Schutz bieten.

Analysieren Sie die Ursachen vergangener Fehler. Dies ermöglicht die beste Verteilung des Datenverkehrs. Wenn Sie über ein instabiles Nebenfeature verfügen, das häufig allgemeine Fehler verursacht, kann es sich lohnen, seinen Endpunkt auf seinen eigenen Anwendungsinstanzcluster zu verweisen. Wenn es problematische Hintergrundjobs gibt, stellen Sie sie in eine eigene Warteschlange, die andere Jobs nicht beeinträchtigt.

Automatisiertes Testen

Vorbeugung ist besser als Heilung. Wenn Fehler und Ausfälle verhindert oder zumindest reduziert werden können, muss man sich viel weniger um deren Eingrenzung kümmern.

Die Entwicklung von Testfähigkeiten ist ein Schlüssel zum Vertrauen in die Qualität eines Softwareprodukts, in seine Fähigkeit, die erforderliche Funktionalität auch unter Arbeitsbelastung zuverlässig bereitzustellen.

Programmiersprache und technologischer Agnostizismus

Sie sollten keine zusätzlichen Sprachen und Technologien außerhalb des Umfangs einzelner Dienste verwenden. In der Regel kann eine zu große Freiheit bei der Wahl von Sprachen und Technologien zu einer Fragmentierung und einem zu komplexen Technologie-Stack führen.

Bewerten Sie die Klarheit und Ordnung des Monolithen.

Wenn bestimmte Domänenanforderungen spezielle Sprachen für bestimmte Funktionen erfordern, können Sie die Verwendung separater Dienste in Betracht ziehen. Die Vorteile jeder zusätzlichen Technologie sollten gegen die damit verbundenen Wartungskosten abgewogen werden.

Datensicherheit

Es gibt die Meinung, dass es schwierig ist, einen Monolithen zu schützen, aber Microservices erschweren diese Aufgabe nur. Indem Sie die Schwierigkeit des Stapels erhöhen, erweitern Sie den Angriffsbereich.

Es ist klar, dass die Trennung von Funktionen in verschiedene Dienste es Ihnen ermöglicht, unterschiedliche Sicherheits- und Aktivitätsebenen auf jeden von ihnen anzuwenden. Bedenken Sie jedoch, wie notwendig dieses Maß an Kontrolle ist.

Wäre es nicht einfacher, den gesamten Monolithen auf der höchsten erforderlichen Ebene zu sichern? Haben Sie überhaupt andere Anforderungen an die Datensicherheit?

Teamautonomie

Ich bin ein Unterstützer autonomer Gruppen von Entwicklern mit unterschiedlichen Profilen. Aber ich verstehe nicht ganz, woher die Idee kam, dafür eine Netzwerkdifferenzierung einzuführen.

Jedem Team die ausschließliche Nutzung bestimmter autonomer (isolierter) Systeme zu geben, mag wie eine Möglichkeit erscheinen, die Autonomie zu erhöhen, aber tatsächlich kann es auch dagegen wirken.

Stellen Sie sich vor, dass ein Team die Funktionalität eines anderen Teams teilweise ändern muss. In einer Microservices-Architektur müssen Sie wahrscheinlich ihr Wissen und ihre Erfahrung mit diesem Service nutzen, um dort Änderungen vorzunehmen. Möglicherweise müssen Sie sogar darauf warten, dass sie dies tun. Wenn sich die Funktion in einem Monolithen befindet, besteht eine gute Chance, dass ich bereits mit dem Code oder zumindest mit seinen Konventionen vertraut bin.

Der Grad der Befehlsautonomie hängt von der Modularität und Konsistenz des Systems ab. Weder der Monolith noch die Microservices garantieren oder beschränken diesbezüglich irgendetwas. Die Konsequenz von Microservices wird Modularität sein, und der Monolith wird eine größere Durchgängigkeit fördern.

Monolithische Modularität

Microservices führen naturgemäß dazu, das System in Module zu zerlegen. Tatsächlich helfen Monolithen dabei nicht viel, aber sie hindern Sie natürlich nicht daran.

Lose gekoppelter, modulbasierter Code mit eingeschränkter Funktionalität ist eine gute Lösung, unabhängig von der zusätzlichen Komplexität aufgrund von Netzwerkgrenzen zwischen diesen Aufgaben.

Microservices garantieren keine gute Modularität

Während Microservices Modularität bieten, gibt es keine Garantie für die Qualität dieser Modularität. Microservices können leicht zu einem eng gekoppelten „verteilten Monolithen“ werden, wenn das Design nicht vollständig durchdacht ist.

Wenn Sie den Monolithen nicht in effiziente Module zerlegen können, wird es schwierig, auch eine erfolgreiche Microservice-Architektur zu strukturieren. Microservices fördern die Modularität, erhöhen jedoch die Komplexität.

Unabhängige Bereitstellung

Einer der Vorteile von Microservices ist die unabhängige Bereitstellung. Aber die Notwendigkeit, mehrere Bereitstellungen über verschiedene Dienste hinweg zu organisieren, erschwert die Veröffentlichung neuer Funktionen.

Aufschlüsselung komplexer Änderungen

Mit einem Monolith ist es durchaus möglich, komplexe und riskante Änderungen in separaten Bereitstellungen zu isolieren. Ein gängiges Beispiel ist die Sicherstellung, dass Migrationen vorwärts- und rückwärtskompatibel mit Leistungs- und Bereitstellungsanforderungen sind.

Offensichtlich erschwert dies die Update-Funktionalität auf die gleiche Weise wie bei Microservices.

Abhängigkeitsverwaltung

In einer Microservice-Architektur sind alle Services unabhängig voneinander, aber spielt das für Sie wirklich eine Rolle?

In einem großen Monolithen ist es ziemlich schwierig, Abhängigkeiten zu verwalten. Die Aufteilung in mehrere kleinere Listen erleichtert die Verwaltung jeder einzelnen, kann es jedoch für das System als Ganzes schwieriger machen.

In einem Monolithen werden Sie früher oder später auf einen „Haufen von Abhängigkeiten“ und einen Konflikt zwischen zwei davon stoßen. Microservices garantieren nicht die Abwesenheit von Problemen, aber sie sollten die Wahrscheinlichkeit verringern, dass sie auftreten.

Bleiben Sie dran für Abhängigkeitsaktualisierungen

Offensichtlich ist es wünschenswert, Ihre Abhängigkeiten auf dem neuesten Stand zu halten. Aber in der Praxis wird in der Regel etwas übersehen.

Tatsächlich kann die Verwendung der neuesten Versionen dieses Problem verschlimmern, da eine Abhängigkeit schneller voranschreitet als andere damit verbundene. Auf dem neuesten Stand zu bleiben bedeutet nicht, so schnell wie möglich auf die neueste Version zu aktualisieren.

Einfacher und verständlicher Code

Dieser Vorteil von Microservices ist bestenfalls Schwindel und schlimmstenfalls ein Schwindel.

Natürlich ist jeder Service einfacher und übersichtlicher. Aber das System als Ganzes ist viel komplexer und schwerer zu verstehen. Sie entfernen Komplexität nicht, Sie erhöhen sie nur und verschieben sie an eine andere Stelle.

Monolithische Modularität

Bei einem Monolith müssen Sie keine Netzwerkgrenzen und isolierten Prozesse einführen, um den Code für Ingenieure verständlicher zu machen. Ein Monolith, der in Module mit klar definierten und begrenzten Aufgaben unterteilt ist, ist genauso einfach, wenn nicht sogar leichter zu verstehen, als ein System, das in separate Dienste unterteilt ist.

Probleme mit Ihrem Monolithen

Wenn Sie immer noch Probleme mit einem Monolithen haben, ist es wahrscheinlich, dass es kein ganzer Monolith ist.

Es ist durchaus möglich, dass der Monolith ein leuchtendes Leuchtfeuer für Codequalität, Tools und Modularität bleibt. In dieser Situation könnte es an der Zeit sein, auch über Microservices nachzudenken. Aber das ist nicht immer der Fall. Oft müssen Sie nur an Ihrem Code arbeiten.

Software zu bauen ist nicht einfach. Es ist sehr schwierig, große Systeme mit vielen dynamischen Komponenten zu organisieren, die sich im Laufe der Zeit ändern.

Ich gebe zu. Und ich baute chaotische Monolithen. Ich möchte nicht über die Vorlieben von irgendjemandem diskutieren. Doch wer hofft, die Probleme des Monolithen mit Hilfe von Microservices auf magische Weise lösen zu können, wird enttäuscht.

Wann sollten Sie sich für Microservices entscheiden?

Die Wahl zwischen Monolith und Microservices wird oft als zwei sich gegenseitig ausschließende Denkweisen dargestellt. Alte und neue Schulen. Richtig oder falsch. Einer von zweien.

Die Wahrheit ist, dass beide Ansätze mit unterschiedlichen Kompromissen akzeptabel sind. Die richtige Wahl hängt stark vom Kontext ab und es gibt eine Vielzahl von Überlegungen.

Meiner Meinung

Für neue, kleine und mittlere Entwicklerteams ist der Monolith die Standardwahl. Microservices bleiben eine praktikable Option, aber Sie müssen einen guten Grund haben, sie zu verwenden.

Mittlere bis große Teams sollten die Verwendung von Microservices in Betracht ziehen, aber mit großer Sorgfalt und Verständnis für Kompromisse.

Ein UFO ist eingeflogen und hat hier einen Aktionscode für unsere Blog-Leser hinterlassen:

15 % für alle VDS-Tarife (außer Heiztarif) – HABRFIRSTVDS.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *