Micro Service oder Monolith: Welches ist die besser Software Architektur?
Klarte Antwort, it depends.
Mirco Services sind seit ca. zehn Jahren die vorherrschende Software-Architektur, wenn es um Server-Anwendungen geht. Die meisten stellen sich nur die Frage, wie gross darf oder kann ein Micro Service sein. Aber gibt es Alternativen zu Micro Services? Ja und zwar mindesten zwei:
- Serverless
- Monolith
Zum ersten Punkt der Serverless Architektur kommen wir später. Punkt 2 der Monolith gilt als überholt und wird mit der Softwarekrise in den 90er Jahren in Verbindung gebracht, nicht ganz zu unrecht, waren damals doch fast alle Softwareprodukte Monolithen.
Seit den 90er hat sich allerdings einiges getan, wie Software entwickelt wurde. Agile Softwareentwicklung hat mehr oder weniger zu den Micro Services geführt. Ein grosser Vorteil der Micro Services war und ist, das man durchaus in der Lage ist die Softwareentwicklung horizontal, also mit der Anzahl der Entwicklerteams, zu skalieren. Aber offen gesagt, ist dies auch mit Monolithen möglich. Mit der aktuellen Technik, ein paar alten bewährten Software Regeln ist auch möglich Monolithen mit multiplen Teams parallel mit der selben Geschwindigkeit zu entwickeln wie Micro Services. Dazu benötigt man nur zwei Regeln:
- Share Nothing
- Dinge, die zusammengehören sind im selben Package
Eine Anmerkung zu Punkt 2, das bedeutet nicht das ein Package mit Controller und eins mit Services und so weiter hat. Diese Packetierung ist falsch, das ist so als würde man die Pflanzen nach ihr Blütenfarbe klassifizieren. In einem Packet befindet sich Controller, Service, Model, Repository die zusammen einen Anwendungsfall implementieren. Pakete selbst sind unabhängig von einander und benutzen keine Klassen aus anderen Paketen. Und fertig ist der skalierbar programmierte Monolith.
PS: Fehlende Buchstaben im Text sind verursacht durch Apples grandiosen Versuchen Tastaturen für MacBooks neu zu erfinden.
PS 2: Die Paketierugsstrategie vieler Domain Driven Ansätze ist komplett falsch.
