Monolithische vs. Microservices-Softwarearchitektur

Zusammenfassung

Diese Woche bin ich nach Göteborg geflogen, um Leute einer großen internationalen Reederei zu treffen und über die Entwicklung von Unternehmenssoftware zu sprechen. Im Raum saßen mehrere Experten, und einer fragte mich, wie man die richtige Softwarearchitektur wählt (für große, komplexe Apps im Unternehmensumfeld). Eine sehr gute Frage, die einen Blogbeitrag wert ist.

Volltext

Softwarearchitektur

Wenn du Apps entwirfst, geht es nicht nur um Aussehen und Bedienung. Gutes Design umfasst auch, wie alles zusammenarbeitet. Softwarearchitektur beschreibt die grundlegenden Strukturen eines Softwaresystems. Jede Struktur besteht aus Elementen, Beziehungen zwischen ihnen und Eigenschaften der Elemente wie auch der Beziehungen.

Das ist vergleichbar mit der Architektur eines Gebäudes. Ist eine Architektur erst festgelegt und umgesetzt, wird es teuer, sie nachträglich zu ändern. Deshalb solltest du die richtige Softwarearchitektur wählen, bevor du anfängst zu bauen.

Bei einfachen Apps liegt die Architektur vielleicht auf der Hand. Wächst deine Anwendung aber an Umfang und Funktionen, kann die Zahl der Strukturen im System schnell steigen. Das passiert mit der Zeit, wenn die Wünsche deiner Kunden wachsen. Je mehr Strukturen, desto mehr Beziehungen zwischen ihnen, und desto komplexer wird es.

Mit komplexem Softwaredesign umgehen

Wenn deine Software viele verschiedene Dinge erledigen soll, bekommst du es wahrscheinlich mit Komplexität zu tun. Aus Sicht der Architektur gibt es verschiedene Ansätze, damit umzugehen.

Monolithische Architektur

Die monolithische Architektur beschreibt man am besten als "einen großen Block". Alles, was deine App tut, gehört zur selben Codebasis.

In einer "monolithischen Architektur" ist die Software oft in Schichten aufgebaut, und jede Schicht besteht aus anderen Arten von Komponenten:

• Präsentationsschicht: zuständig für die Schnittstelle zu Benutzern und/oder Anwendungen (UI / API).
• Geschäftslogik: Hier stehen die eigentlichen Geschäftsregeln. Sie ist der Kern der Anwendung und passt sehr eng zu den tatsächlichen Geschäftsprozessen.
• Datenzugriffsschicht: bietet eine gemeinsame Schnittstelle zwischen der laufenden Anwendung und den dauerhaften Backend-Speichern.
• Datenbank und Dateisystem: Hier liegen alle Daten und statischen Ressourcen (Dateien, Bilder usw.).

Je größer die Anwendung wird, desto größer wird jede Schicht. Das macht es schwieriger, eine monolithische Architektur zu skalieren: Irgendwann wird einfach alles zu groß und zu komplex.

Bei jeder Änderung an der Anwendung ist die gesamte Codebasis betroffen. Bei (sehr) großen Anwendungen erschwert das die Wartung, denn du musst die ganze Anwendung verstehen.

Weil die gesamte Anwendung voneinander abhängt, wirken sich Probleme in einem Teil oft stark auf das ganze System aus. Die Teile kommunizieren intern auf Codeebene miteinander. Das heißt, sie müssen in derselben (oder einer kompatiblen) Programmiersprache geschrieben sein. Das ist eine Hürde für neue Technologien (in Zukunft), denn die Programmiersprache eines einzelnen Teils lässt sich nicht einfach ändern.

Microservices-Architektur

Statt eine große monolithische Anwendung zu bauen, kannst du deine Anwendung in kleinere, miteinander verbundene Dienste aufteilen. Jeder Microservice ist eine kleine eigene Anwendung, mit eigener (aber kleinerer und einfacherer) Architektur, eigener Geschäftslogik und eigenen Datenschichten.

Die Dienste sprechen über APIs miteinander, die unabhängig von der eingesetzten Technologie definiert sind, oft in einer gemeinsamen "API-Struktur" wie REST, JSON, Redis und XML. So funktionieren die Microservices zusammen als "ein System".

Wenn du die "Big-Block"-Anwendung in kleinere Dienste zerlegst, werden die einzelnen Teile des Systems leichter verständlich. Auch die Wartung wird einfacher, weil sich jeder Microservice unabhängig entwickeln lässt. Außerdem sinkt die Hürde für neue Technologien: Du kannst für jeden Dienst die Technologie wählen, die am besten passt. Ein Teil des Systems darf in einer anderen Sprache programmiert sein als die übrigen. So können Teams mit ganz unterschiedlichem Know-how zusammenarbeiten.

Die Kunst bei der Microservices-Architektur besteht darin, einen Microservice richtig abzugrenzen. Zu breit oder zu kleinteilig kann die Architektur zerstören. Zum Abgrenzen kannst du Geschäftsprozesse nehmen, eine hierarchische Trennung oder eine Trennung nach Fachdomänen.

Die Herausforderung: Microservices machen das Gesamtsystem komplexer, weil sie einen verteilten Kommunikationsmechanismus brauchen. Die vielen APIs, die ineinandergreifen, können knifflig zu testen und zu debuggen sein. Und Änderungen, die mehrere Dienste betreffen, sind schwerer umzusetzen.

Die APIs zwischen den Diensten zu definieren, zu entwerfen und umzusetzen erfordert eine Einigung über die ausgetauschten Daten. Das kann schwierig werden, wenn du umfangreiche und nicht universelle Datenstrukturen teilen willst.

Auch Überwachung und Bereitstellung einer Microservices-Architektur können komplex werden, wenn die Zahl der Dienste wächst. Es gibt schlicht mehr zu verwalten, und das erfordert für jeden Dienst mehr Planung und Abstimmung.

Die richtige Architektur wählen

Mein verstorbener Vater hat mir einmal gesagt, dass man "am meisten mit den Dingen verdient, die man nicht tut". Komplexe Anwendungen zu bauen ist von Natur aus schwer. Das Beste, was du tun kannst, ist, die Dinge einfacher zu machen, indem du nicht alles tust. Konzentrier dich auf das, was wirklich zählt, und mach es richtig.

Ist deine Anwendung einfach und schlank, ist eine monolithische Architektur der richtige Weg. Entwicklung, Bereitstellung, Wartung: Alles ist leichter, wenn die Dinge klein sind.

Kommst du an der Komplexität nicht vorbei, solltest du unbedingt die Microservices-Architektur in Betracht ziehen. Stell dir diese Fragen:

• Kannst du eine "gemeinsame Sprache" zwischen deinen Microservices festlegen?
• Gibt es klar getrennte Geschäftsprozesse?
• Wie stark hängen diese Geschäftsprozesse voneinander ab?
• Wie wird sich deine Anwendung im Lauf der Zeit entwickeln: Wird sie wachsen oder schrumpfen?
• Wie viele verschiedene Programmiertechnologien willst du einsetzen? Wird sich das künftig ändern?
• Wer baut und wartet die Software, und hat er Erfahrung mit einer solchen Architektur?

Fazit

Eine "Patentlösung" auf die Frage, welche Softwarearchitektur die richtige ist, gibt es nicht. Beide Ansätze haben Vor- und Nachteile.

Am besten triffst du eine bewusste, gut durchdachte Entscheidung und setzt voll darauf!