Wer Berge versetzen will, hat zwei Möglichkeiten: ihn Stein für Stein abtragen oder sich genug Muskeln antrainieren, um ihn auf einmal bewegen zu können. Angenommen, vom Versetzen des Berges ist das wirtschaftliche Überleben abhängig: wie wählt man?
Mit Bedacht. Und dazu gehört, dass man weiß, worum es geht. Nun sind wir bei CAMAO zwar gerne in den Alpen unterwegs, unsere versetzten Berge beziehen ihre Härte jedoch aus ihrer technischen Komplexität – zum Beispiel als Website für die Silberregion Karwendel.
In der Software-Architektur nennen sich die beiden vorgestellten Herangehensweisen Microservice- und Monolith-Architektur. Letzteres hat für Jahrzehnte die Branche dominiert. Microservices hingegen erfreuen sich erst seit ein paar Jahren immer größerer Beliebtheit.
Davids gegen Goliath: Microservices und Monolith im Vergleich
Die Monolith-Architektur sieht für ein Projekt eine einzige Code-Basis vor. Diese adressiert jeden einzelnen Aspekt des Produkts (bei einer Website z. B. Frontend, Backend, jeweils server- und client-seitig uvm.). Das erleichtert es, produktübergreifende Faktoren wie Sicherheit, Fehlerbehandlung oder Performance zu modifizieren. Kleinere Teams bewahren mit Monolith zudem einfacher den Überblick über ihr Projekt. Dies macht es für fachlich neue Projekte oder Prototyping attraktiv, da linear auf das Ziel hingearbeitet werden kann. Man verliert also weniger Zeit mit dem Aufsetzen einer komplexen Struktur.
Die Microservice-Architektur kommt am besten bei sehr komplexen Projekten zur Geltung. Sie teilt ein Projekt in mehrere, auch unabhängig voneinander funktionierende Services auf. Für jeden Service kann so die optimale Herangehensweise gewählt werden. Um z. B. für Big-Data-Projekte riesige Logdateien zu verarbeiten, ist C++ einfach geeigneter als Python. Auch die immer gefragteren Progressive Web Apps profitieren von der Microservice-Architektur, da sie von Haus aus oft viele verschiedene Funktionen beinhalten.
Die entkoppelte Struktur vereinfacht außerdem die Wiederverwendung einzelner Services im Unternehmen. Spezifische Skalierbarkeit ist ein weiterer Vorteil: Wenn nur ein bestimmter Service konstant unter Strom steht, kann diesem gezielt mehr Power gegeben werden. Natürlich lassen sich auch Monolith-Systeme gut in Module einteilen, oft werden die Grenzen zwischen den Modulen jedoch überschritten. Das kann direkte Fehler – und indirekte an ganz anderen Orten im Code – entstehen lassen. Die striktere Microservices-Architektur entschärft diese Fehlerquelle jedoch. Die Hürde leichtfertig Verbindungen herzustellen, ist hier zu groß.
Architektur-Matching: Was passt zum Unternehmen?
Die Entscheidung für oder gegen eine Architektur hängt zusätzlich noch vom Unternehmen ab. Microservices lohnen sich besonders mit einer guten Cloud-Infrastruktur: Neue Services lassen sich so kinderleicht ausrollen oder bestehende skalieren. Zudem begünstigt es schnelles Wachstum einer Organisation. Neue Mitarbeiter können einfach an einem isolierten Service arbeiten und müssen nicht direkt den ganzen Monolith verstehen. Zur Veranschaulichung hilft diese Infografik von Martin Fowler, der sich dem Thema bereits in einem eigenen Blogbeitrag gewidmet hat:
Bei CAMAO sind wir undogmatisch: Für eine Corporate Website zum Beispiel, wo „nur” redaktionell Content verarbeitet wird, generiert eine Microservice-Architektur wenig Mehrwert. Funktionsreiche Web-Applikationen hingegen, wie die von Classic Trader, können von dem Ansatz hingegen stark profitieren. Am besten, Ihr fragt uns einfach direkt unter: hello@camao.one
Der Autor
Markus Rothenbacher auf
