Microservices und ihre Alternativen

Spricht man heute über Microservices, rollt manch ein Entwickler schon entnervt mit den Augen. Zum einen, weil man in den letzten Jahren überraschend oft damit konfrontiert wurde. Zum anderen, weil das Architekturmuster lange Zeit als alternativlos konnotiert wurde und mittlerweile sogar in den Etagen der IT-Entscheider als das Nonplusultra der Softwarearchitekturen gilt.

Zugegeben, diese Stellung kommt nicht von ungefähr, weisen Microservices doch eine Vielzahl unbestreitbarer Vorteile auf. Diese kommen aber auch zu einem Preis, und ob man bereit ist, den zu zahlen, kann man eben nur einschätzen, wenn man ihn auch kennt. Ziel dieses Artikels ist es daher, einen genaueren Blick auf das Architekturmuster und seine Nachteile zu werfen. Darüber hinaus sollen aber auch Alternativen aufgezeigt und einander gegenübergestellt werden, um eine Grundlage für zukünftige Architekturentscheidungen zu bieten.

Bevor wir uns aber den Microservices im Detail zuwenden, betrachten wir zunächst ein anderes Muster, das in den vergangenen Jahren zunehmend wie ein Anti-Pattern behandelt wurde und mit seinen Nachteilen viele Argumentationshilfen pro Microservices geliefert hat. Die Rede ist vom Monolithen. Hierbei ist Monolith aber nicht gleich Monolith, und die Unterscheidung in Architekturmuster und Anti-Pattern ist durchaus angebracht, auch wenn der Übergang fliessend ist.

Grundsätzlich beschreibt ein Monolith eine Softwarearchitektur, bei der das gesamte System nur als Einheit funktioniert und somit nicht aufgetrennt wird beziehungsweise aufgetrennt werden kann. Dabei ist es unerheblich, ob der Monolith intern zum Beispiel einer Schichtenarchitektur wie in Bild 1 folgt. Das Mono im Namen besagt, dass es nur «eines» gibt, und dieses «eine» kann nicht weiter zerlegt werden.

Je nachdem, was mit dem «einen» gemeint ist, können diverse Arten von Monolithen unterschieden werden. Deployment-Monolithen sind beispielsweise Softwaresysteme, bei denen alle Softwarebestandteile gemeinsam veröffentlicht werden müssen. Laufzeit-Monolithen hingegen sind Systeme, deren Bestandteile getrennt voneinander bereitgestellt werden und damit auch unterschiedlichen Releasezyklen folgen können. Für deren reibungslosen Betrieb müssen aber alle Bestandteile zur Laufzeit auch verfügbar und zueinander kompatibel sein. Dies bedeutet, dass die Bestandteile durchaus verteilt vorliegen, es aber eine so grosse Abhängigkeit zwischen ihnen gibt, dass sie immer nur als Ganzes betrieben werden können. Löst man also einen Teil heraus, funktioniert auch der Rest nicht mehr zuverlässig.

Je nachdem, ob es sich um einen Laufzeit- oder Deployment-Monolithen handelt, schränkt dies die Verwendung des Softwaresystems ein. Am deutlichsten wird dies bei der Skalierung. Wird die Software zur Laufzeit als ein einzelner Prozess auf einem einzelnen Rechner zur Verfügung gestellt, dann kann nur skaliert werden, indem entweder die Leistungs­fähigkeit der Hardware erhöht wird (vertikale Skalierung) oder es muss eine exakte Kopie des Systems parallel aufgestellt werden. In letzterem Fall stellt sich dann aber die ­Frage, wie die beiden Instanzen miteinander synchronisiert werden können. In der Praxis geschieht dies nicht selten, indem eine gemeinsame Datenbank genutzt wird, auf die beide Monolith-Instanzen schreibend und lesend zugreifen. Hierbei ergibt sich dann aber mit der Datenbank selbst eine Art Monolith, der auf Dauer durchaus zum Flaschenhals werden kann.

In dem Bestreben, die Skalierung zu verbessern, wurde ein Deployment-Monolith mit nur einer Laufzeitinstanz in einen Laufzeit-Monolithen gewandelt (Bild 2). Dessen Nachteile zeigen sich dann auch im Problemfeld der Ausfallsicherheit. Gibt es nur eine Instanz und fällt diese aus, so ist auch kein weiteres Arbeiten möglich. Besitzt man mehrere Bestandteile, die aber stark voneinander abhängen, so ist es teils unerheblich, ob diese gemeinsam oder getrennt zur Verfügung gestellt werden können. Funktioniert einer der Bestandteile nicht, so funktionieren auch alle anderen nicht mehr.

Besonders interessant ist an dieser Stelle, dass sich die tatsächliche Ausfallsicherheit hierbei am schwächsten Glied der Kette orientiert. Ist der Datenbankserver instabil, so ist auch das Gesamtsystem instabil und die Aufteilung in mehrere Bestandteile hat möglicherweise das System sogar geschwächt. Denn die Fehlersuche zur Laufzeit ist in drei Bestandteilen, so wie in Bild 2 dargestellt, viel schwieriger, als sie es in einer einzelnen Instanz wie in Bild 1 war.