Gute Monolithen. Einfache Architektur ist am besten / Sudo Null IT News

Kritik an Monolithen ist in der Branche alltäglich geworden. Viele halten es für selbstverständlich, dass verteilte (Micro-)Services immer besser sind als monolithische Anwendungen, die von Anfang bis Ende als ein einziges, unteilbares unabhängiges Stück geschrieben werden.

Wenn Sie sich erinnern, tauchte die Idee modularer Microservices vor etwa zehn Jahren mit dem Aufkommen von Agile- und DevOps-Ideologien auf. Diese leistungsstarken Konzepte haben die Branche stark beeinflusst.

Aber was sehen wir zehn Jahre später? In Wirklichkeit sind wir von einer großen Anzahl guter monolithischer Anwendungen umgeben, die großartig funktionieren, ohne auf Microservices umzusteigen. Wie?


Erstens, um die Konzepte nicht zu verwechseln:

Mono-Repository ist eine Entwicklungsstrategie, bei der der gesamte Code in einem Repository gespeichert wird. Das Standardpraxis für GoogleTwitter, Microsoft und viele andere Unternehmen.

Monolith (monolithische Anwendung) – eine einschichtige, in sich geschlossene und unabhängige Anwendung, die die Komponentenmodularität nicht in den Mittelpunkt der Entwicklung stellt.

Da monolithische Anwendungen immer in Monorepositories entwickelt werden, gibt es einige Begriffsverwirrung. Allgemein zur Vereinfachung:

  • Monolithen sind immer Monorepositories.
  • Monorepositories sind nicht immer Monolithen. Innerhalb des Monorepos können viele unabhängige Module leben und sich entwickeln, die aus irgendeinem Grund nicht in separate Repositories herausgenommen werden (zum Beispiel ist es für große Unternehmen bequemer), wie hier: ├── README.md ├── lerna.json ├── package.json ├── Pakete │ ├── cli │ ├── Komponenten-Schaltfläche │ ├── eslint-config │ ├── eslint-config │ ├── generische Box-Größe -zurücksetzen │ ├── Objekt-Seitenverhältnis │ ├── Objekt-Container │ ├── Objekt-Raster │ ├── … │ └── Utility-Breite └── Test ├── … └ ──test.sh

Vorteile von Monorepositories

:

  • Einzige Quelle der Wahrheit. Codeänderungen sind atomar, Schemas müssen nicht über mehrere Repositories hinweg synchronisiert werden.
  • Scheinbare Änderungskosten. Änderungen am Code erfordern Kompatibilität mit allem anderen Code.
  • Teilen und Wiederverwenden von Code. Es ist viel einfacher, den richtigen Code zu finden, um vorhandene Komponenten wiederzuverwenden. Dazu gehören auch Versionierung und Abhängigkeitsabgleich im gesamten Unternehmen.
  • Zusammenarbeit fördern. Die Bürokratie mit Genehmigungen und Genehmigungen mehrerer Repositories entfällt. Ändern Sie einfach den Code und erhalten Sie Feedback!

Natürlich gibt es auch negative Aspekte. Beispielsweise kann mein Code durch Änderungen beschädigt werden, die jemand anderes vorgenommen hat.

Im “richtigen” Monorepository empfehlen Ändern Sie das CI-Verfahren für abgedichtete Montage, die Qualität der Tests verbessern und auf Zusammenführungskonflikte achten, könnte sogar ein Entwicklungsteam bilden, um die Arbeit zu erledigen. Ein solches Monorepository wird nicht zu einem Monolithen.

▍ Ein einfacher Monolith ist gut

Befürworter von Monolithen betonen immer wieder, dass ihre Wahl der Einfachheit geschuldet ist. Das heißt, eine einfache Anwendungsarchitektur, einfache klassische Entwicklung ist eine ideale Option. Vor allem zu Beginn eines Startups. Monolith ist

einfache Architektur, die Probleme auf einfache Weise löst

. Über die Vorteile eines Monolithen

Er spricht

Dan Luu, CTO des Teams von 70 Ingenieuren, die die Wave-Zahlungs-App entwickelt haben:

Unter den großen, aber effektiven Monolithen werden genannt

Paketüberfluss

(in den Top 100 Internetseiten enthalten), Slack (

fast PHP-Monolith

), Booking, GitHub, Shopify, Stripe (in k8-Pods verteilter Monolith) und

viele andere

. Aus betriebswirtschaftlicher Sicht sind dies erfolgreiche Produkte mit einem Wert von mehr als einer Milliarde Dollar. Aus Sicht der Effizienz oder Produktivität mag es Fragen geben, aber das sind schon subjektive Dinge. Schließlich ist der Wert eines Unternehmens eine Art objektiver Zahlenwert, der mit dem Verständnis von erfolgreicher Softwareentwicklung korrelieren sollte.

Anscheinend wird für die meisten Anwendungen der 100 beliebtesten Websites im Internet ein Monolith mit einer einfachen Architektur diesen Datenverkehr recht gut bewältigen.

Das heißt, ein einfacher Monolith ist in den meisten Situationen ein völlig ausreichendes Produkt. Gleichzeitig wird diese einfache und langweilige These auf Konferenzen und in den Medien nur selten thematisiert. Führende Ingenieure und Spezialisten zerlegen gerne verteilte Architekturen von Microservices, Lastenausgleich über Cluster hinweg und andere komplexe Dinge. Je komplexer die Architektur, desto besser der Bericht. Banale einfache Dinge eignen sich nicht sehr gut für eine Präsentation, obwohl dies 99% der Aufgaben in der realen Welt sind.

Auf einer coolen Technologiekonferenz gibt es normalerweise keine Berichte über einfache Monolithen. Alle sprechen von verteilten Systemen und Microservices. Es scheint, dass in der realen Welt die meisten Systeme auf diese Weise konzipiert sind. Das ist nicht so.

Das Überraschendste ist nun, dass die Entwickler eines einfachen kleinen Systems, einer Anwendung ohne Hochlast, statt eines einfachen Monolithen zunächst eine verteilte Architektur von Microservices wählen, schreibt Dan Lu. Das heißt, man entscheidet sich zunächst für eine komplexere Architektur – und übernimmt zusätzliche Arbeit. All dies ist auf Hype und unter dem Druck der öffentlichen Meinung, sagen sie, so sollte es sein.

▍ Microservices im wirklichen Leben

Es gibt die Meinung, dass Microservices schlecht für die Produktion geeignet sind. Das heißt, sie funktionieren in der Praxis oft nicht so gut wie in der Theorie. Daher ist es nicht die beste Idee, ein neues Projekt mit Microservices-Design zu starten.

Stellen Sie sich vor, Netflix verwendet eine Microservice-Architektur. Wie würde diese imaginäre Infrastruktur in ihrer einfachsten Form aussehen? Ungefähr so:

Wenn beispielsweise ein Verschlüsselungsmodul ausfällt, können andere Dienste, einschließlich der Empfehlungsmaschine, vollständig aufhören zu funktionieren, aber dies wird bei einem Monolithen nicht passieren. Natürlich hat der Monolith seine eigenen Zuverlässigkeitsprobleme, aber er leidet nicht unter Kommunikationsfehlern zwischen Modulen.

▍ Komplexe Systeme fallen schneller

Und noch ein wichtiger Punkt. Nur wenige Menschen berücksichtigen das Wachstum der Entropie und

zunehmende Komplexität

, was häufig auftritt, wenn separate Dienste künstlich von einem guten Monolithen isoliert (und generiert) werden. Manchmal stellt sich heraus, dass der Monolith eine einfache Architektur ist und einzelne Dienste eine unnötige Verkomplizierung darstellen.

Ein verteiltes, vernetztes System arbeitet manchmal zuverlässiger. Es passiert aber auch umgekehrt, wenn die Gesamtleistung von einzelnen Netzwerkverbindungen abhängt. Zu viel Ungewissheit, Risiken, Abhängigkeiten.

In der Physik gilt: Je komplexer das System, desto höher die Dissipation (Streuung) von Energie, dh desto höher die Degradationsrate dieses Systems. Daraus lässt sich schließen Komplexe Systeme fallen schneller.

Diese sog Seneca-Klippewenn auf einen langen und langsamen Anstieg ein scharfer Einbruch folgt. Je komplexer und fortschrittlicher das System war, je länger das Wachstum andauerte, desto schneller erfolgte die Degradation.

Seneca Rock wird normalerweise im Zusammenhang mit dem Untergang von Zivilisationen oder erwähnt soziale Institution. Aber wir sehen es in vielen anderen Dingen – Geschäft, Investitionen, Ehe, Gesundheit, Ansehen, wirtschaftliche Entwicklung usw. Leider verläuft ein Absturz fast nie so reibungslos wie ein vorangegangener Aufstieg. Oft bricht alles zusammen wie ein Kartenhaus. Das gilt auch für komplexe Softwaresysteme.


„EKS hat Omega Star Ende des Monats gekündigt, aber Omega Star unterstützt immer noch keine ISO-Zeitstempel …“ Aus einem viralen Video “Mikrodienste”

Es gibt noch eine weitere Konsequenz. Je komplexer das System ist, desto mehr Energie wird benötigt, um seinen Zustand aufrechtzuerhalten. Im Zusammenhang mit Softwaresystemen bedeutet dies die Kosten für Support und Wartung. Einfachere Systeme sind einfacher zu warten. Idealerweise ein einfacher Monolith auf Knoten/Express ohne kritische Abhängigkeiten arbeitet es jahrelang geräuschlos – und erfordert keine besondere Wartung.

Dasselbe gilt für eine einfache Reihe von Microservices, die einen komplexen Monolithen ersetzen. Hier geht es vor allem darum, in welche Richtung wir uns bewegen, die Komplexität erhöhen oder das System vereinfachen?

Ein weiteres kontraintuitives Beispiel. Manchmal können Sie unnötige Komplexität vermeiden, indem Sie eine einfache eigene Lösung entwickeln, anstatt ausgefallene Programme von Drittanbietern zu verwenden. Denn Programme von Drittanbietern haben oft unnötige Funktionalität, was in Zukunft zu erhöhter Komplexität und Mehraufwand führen kann.

Ein zusätzliches, unnötiges Detail zu Beginn des Projekts zieht später Hunderte von Arbeitsstunden redundanter Arbeit nach sich. Es ist wie im Leben – jedes unnötige Ding erregt Ihre Aufmerksamkeit, während es in der Nähe ist. Aus Gründen der Zeitoptimierung ist es daher wünschenswert, zunächst keine Entitäten zu erzeugen.

Es gibt noch ein weiteres Prinzip Wählen Sie langweilige Technologieund nicht schön/interessant. Wenn es eine emotionale Reaktion hervorruft, ist dies ein gefährliches Zeichen. Jeder fühlt sich zu schönen, glänzenden Dingen hingezogen, aber langweilige Technologie ist gleichbedeutend mit Vorhersehbarkeit. Seine Mängel sind bekannt, Überraschungen sind nicht zu erwarten.

▍ Monolithen sind unser Freund

Ingenieure lieben Komplexität, das ist okay. Komplexe Dinge beflügeln unsere Vorstellungskraft. Schließlich ist das Lösen von Rätseln das Interessanteste, was es auf der Welt geben kann, oder? Aber theoretisch ist das alles schön. Aber in der Produktion oft

Monolithen sind unser Freund

. Die harte Wahrheit des Lebens.

Similar Posts

Leave a Reply

Your email address will not be published.