Für eine einfache Architektur plädieren (2022)

• Wave ist ein Unternehmen im Wert von 1,7 Mrd. US-Dollar (2,3 Billionen KRW) mit 70 Ingenieurinnen und Ingenieuren und bietet Mobile-Banking-Dienste für Afrika an
• Verwendet wird eine Standard-CRUD-App-Architektur als Python-Monolith auf Basis von Postgres
• Ausgehend von einer einfachen Architektur und durch das Lösen von Problemen bei minimaler Komplexität konnten sich die Ingenieurinnen und Ingenieure auf Arbeit konzentrieren, die den Nutzerinnen und Nutzern Mehrwert bietet
• Stack Overflow wuchs erfolgreich, indem es einen Monolithen skalierte, und war so erfolgreich, dass es für 1,8 Milliarden US-Dollar übernommen wurde

Trotz der Effizienz einfacher Architekturen bevorzugen die meisten Medien komplexe Architekturen

• Auf Technologiekonferenzen gibt es viele Vorträge über komplexe, Microservices-basierte Architekturen, aber keine über einfache Monolithen
• Viele Unternehmen ahmen komplexe Technologien nach, obwohl ihre Anwendungen klein sind, und gewinnen damit auf Konferenzen und bei HN an Aufmerksamkeit
• Unsere Architektur ist so einfach, dass wir nicht einmal ein Architekturdiagramm zeichnen müssen

Wie man Einfachheit bewahrt

• Wave verwendet synchrones Python, was bedeutet, dass Serverprozesse blockieren, während sie auf I/O warten
• Asynchrone Frameworks wie Eventlet wurden ausprobiert, aber es gab zu viele Bugs, sodass die Kosten den operativen Schmerz nicht wert waren
• Anstatt die Komplexität zu erhöhen, werden Aufgaben mit langer Laufzeit ausgelagert und über Queues verarbeitet
• Um Vorschriften zur Datenresidenz einzuhalten, müssen in einigen Ländern On-Premises-Rechenzentren betrieben werden
  • Senegal und Côte d’Ivoire liefen in der Cloud, aber Uganda und andere Länder benötigten wegen regulatorischer Vorgaben On-Premises-Betrieb
  • In solchen Fällen ist eine einfache Architektur deutlich unkomplizierter als eine komplexe

Bauen statt kaufen

• Als kleines Team bevorzugte man anfangs den Kauf von Software, entwickelte aber eigene Tools, wenn kritische Bugs nicht behoben werden konnten
• Eigene Tools zu bauen ist eine Komplexität, die man eigentlich vermeiden möchte, aber in einigen Produktkategorien fand man selbst nach sehr umfassender Recherche keinen Anbieter mit einem passenden Produkt
• Auch außerhalb der Kernkompetenzen ist es manchmal notwendig, eigene Tools zu entwickeln und internes Fachwissen aufrechtzuerhalten

Entscheidungen, die man überdenkt

• Technologiewahlen wie RabbitMQ, Celery, SQLAlchemy und Python werden überdacht, da sie die Komplexität erhöhen oder die Wartungslast steigern
• Würde man heute eine neue Codebasis starten, würde man diese Entscheidungen sehr sorgfältig abwägen

Entscheidungen, mit denen man zufrieden ist

• Mit Entscheidungen wie GraphQL, einem benutzerdefinierten Transportprotokoll und Kubernetes ist man zufrieden
• GraphQL bietet Vorteile wie Selbstdokumentation, Codegenerierung und den interaktiven Explorer GraphiQL
• Man ist der Ansicht, dass bei GraphQL die Vorteile die Nachteile überwiegen
  • Vorteile
    • Selbstdokumentation für exakte Rückgabetypen
    • Sicherere Clients durch Codegenerierung auf Basis exakter Rückgabetypen
    • Höhere Produktivität durch den interaktiven GraphiQL-Explorer
    • Verschiedene Apps (Nutzer-App, Support-App, Wave-Agent-App usw.) können größtenteils eine gemeinsame API nutzen, was die Komplexität reduziert
    • Mit einer konfigurierbaren Abfragesprache können Clients in einem einzigen Packet-Roundtrip genau die benötigten Daten abrufen, ohne viele spezialisierte Endpunkte bauen zu müssen
    • Beseitigt Bikeshedding darüber, was als RESTful API gelten sollte
  • Nachteile
    • Die GraphQL-Bibliotheken waren zum Zeitpunkt der Einführung von GraphQL nicht besonders gut
    • Die Standard-GQL-Codierung ist redundant, und da viele Kundinnen und Kunden nur geringe Bandbreite haben, achtet man stark auf Größenbeschränkungen
• Kubernetes wird eingesetzt, um die Anforderungen an den Betrieb von Rechenzentren in verschiedenen Ländern zu erfüllen

Fazit

• Indem die Anwendungsarchitektur so einfach wie möglich gehalten wird, kann das Budget für Komplexität (und Personal) dort eingesetzt werden, wo Komplexität dem Geschäft tatsächlich hilft
• Mit dem Grundsatz, Dinge so einfach wie möglich zu halten, solange es keinen zwingenden Grund für mehr Komplexität gibt, konnte ein recht großes Unternehmen mit vergleichsweise wenigen Ingenieurinnen und Ingenieuren aufgebaut werden, obwohl das Afrika-Finanzgeschäft gemeinhin als schwierig gilt

[secret3056]

"Buy statt Build" scheint eher "Build statt Buy" zu sein.

Another area is with software we’ve had to build (instead of buy).

[xguru]

Ach, ich wollte etwas betonen, aber der Titel ist seltsam geworden. Ich habe ihn korrigiert. Danke.

[savvykang]

Ändern sich die Trends je nach Wirtschaftszyklus? Unabhängig von Trends ist es vorteilhaft, mit einem Monolithen zu beginnen, um die Fixkosten zu senken und die Wartung zu erleichtern.

[aer0700]

Eine leicht verständliche Architektur ist auch leichter zu warten.

[mhj5730]

Meiner Ansicht nach ist es besser, jeden Service zunächst monolithisch zu starten. Wenn man von Anfang an auf MSA setzt, ist das Geldverschwendung.

[dhlee0305]

"Wenn die Komplexität steigt, steigen auch die Kosten (Geld, Personal, Zeit ...)."
"Versuche nicht, ein Problem, das sich mit einer einfachen Architektur lösen lässt, mit einer komplexen Architektur zu lösen."

[xguru]

Hacker-News-Kommentare

• Ratschläge eines Ingenieurs zu Microservices

  • Microservices sind keine Strategie zur Leistungssteigerung, sondern eine Strategie zur potenziellen Kostensenkung und zur Abstimmung im Engineering.
  • Zwischen einer horizontal skalierbaren monolithischen Anwendung und Microservices gibt es keinen großen Unterschied, außer wenn man eine bestimmte Funktion gezielt herunterskalieren möchte.
  • In einer monolithischen App ist es nicht möglich, nur einen Teil der App zu verkleinern.
  • Kosteneinsparungen beginnen erst im großen Maßstab und erfordern mindestens drei Replikate.
  • Für die meisten Unternehmen liegt der eigentliche Vorteil in der Abstimmung im Engineering.
  • Ein Monolith mit einem einzelnen Repository kann von einem Team besessen und verwaltet werden, aber ein geteilter Monolith gehört niemandem und ist daher schwer zu pflegen.

• Vortrag über Microservices

  • Auf allgemeinen Technologiekonferenzen gab es mehrere Vorträge über die Komplexität und die Nebenwirkungen von Microservice-Architekturen, aber keine darüber, wie man einen einfachen Monolithen baut.
  • Ein Vortrag von David Schmitz über Tipps, wie man mit Microservices scheitert, war besonders eindrucksvoll, und sein humorvoller Vortragsstil ist sehr ansprechend.

• Kognitive Verzerrung und Einfachheit

  • Menschen konzentrieren sich oft darauf, etwas hinzuzufügen, und übersehen dabei einfache Lösungen.
  • Studien zeigen, dass es eine bessere Lösung sein kann, Probleme durch das Entfernen von Lego-Steinen statt durch das Hinzufügen zu lösen.

• Overengineering und mangelnde Erfahrung

  • Architektur sollte „so einfach wie möglich und so komplex wie nötig“ sein, aber das zu erreichen erfordert Erfahrung.
  • In der IT-Branche fehlt es oft an Erfahrung, und Erfahrung braucht Zeit.
  • Ingenieure und Manager mit wenig Erfahrung setzen häufig unnötige Technologien oder Metriken ein.

• Unternehmen, die Work-Life-Balance wichtig nehmen

  • Gesucht wird ein Unternehmen, das sich auf die Verbesserung des Produkts konzentriert und die restliche Zeit dem Privatleben überlässt.

• Persönliche Erfahrung mit Dan Luu

  • Dan Luu ist im Umgang mit Fans seines Blogs sehr großzügig und verfügt über Fachwissen an der Schnittstelle zwischen Software und Hardware.
  • Er teilt seine Einsichten und seine Expertise freigiebig, und von ihm zu lernen ist eine sehr angenehme Erfahrung.

• Die Bedeutung einer einfachen Architektur

  • In den meisten Fällen besteht die benötigte Architektur aus grundlegenden Bausteinen wie einem SSL-fähigen Load Balancer, mehreren App-Servern, einer geshardeten Datenbank und einer Message Queue.

• Architektur und die soziale Struktur von Engineering-Teams

  • Die Architektur sollte die soziale Struktur der Engineering-Teams widerspiegeln; wenn das nicht berücksichtigt wird, können Chaos und Ineffizienz entstehen.
  • Große monolithische Repositories und einfache Architekturen können schwer zu verwalten sein, und auch Unternehmen wie Google und Meta entwickeln intern viele Tools.
  • Architektur kann die Zusammenarbeit zwischen Teams unterstützen oder behindern, daher sollte die technische Führung das berücksichtigen.

• Präferenz für einfache Architektur

  • Einfache Architekturen und Monolithen sind in den meisten Fällen geeignet, allerdings sollte man darauf achten, dass keine Probleme durch synchrones I/O entstehen.
  • Bugs bei der Datenintegrität sind in Finanzsystemen ein wichtiges Problem, das vermieden werden muss.

[dangyup]

Könnten Sie bitte den Link zu dem Vortrag teilen, der „David Schmitz’ Tipps zum Scheitern von Microservices“ behandelt?

[xguru]

Es ist https://www.youtube.com/watch?v=r8mtXJh3hzM