Seite 3: Fazit

Inhaltsverzeichnis

Ausblick

Neben den hier näher erläuterten Technologien gibt es einige andere Ansätze:

• Vert.x setzt auf eine asynchrone Verarbeitung auf der JVM und unterstützt Sprachen wie Java, JavaScript, Ruby und Groovy. Es bietet also ein gewisses Maß an technischer Freiheit. Vert.x unterstützt ähnlich wie OSGi eine Aufteilung in Module, die sich einzeln deployen lassen und sowohl per lokalen Methodenaufruf kommunizieren oder im Netzwerk verteilt sein können. Sie kommunizieren mit JSON, sodass es keine Code-Abhängigkeiten zwischen den Modulen gibt.
• Erlang nutzt ebenfalls asynchrone Kommunikation zwischen Prozessen. Außerdem bietet die Programmiersprache eine Überwachung der Prozesse, um so beim Ausfall eines Service zu reagieren. Die Services sind auch weitgehend isoliert. Anders als Vert.x unterstützt Erlang zudem Prozesse in anderen Programmiersprachen, die sich ebenfalls überwachen lassen.

Fazit

Möglichst kleine Microservices sind wünschenswert, weil sie so leichter zu verstehen und zu ersetzen sind. Aber in der Praxis begrenzt die Infrastruktur die Größe der Microservices. Die vorgestellten Technologien erlauben zwar kleinere Services, gehen aber bei der Isolation Kompromisse ein: OSGi und Java EE verringern den Ressourcenverbrauch und die Komplexität, wenn mehrere Services in einer JVM laufen. Dann sind sie aber nicht mehr gegeneinander isoliert: Wenn ein Service viel Speicher benötigt oder die CPU stark belastet, werden die anderen entsprechend beeinflusst. OSGi erlaubt die Kommunikation der Services in der JVM, während bei Java EE die Kommunikation durch den Netzwerk-Stack gehen muss. Ebenso erlauben beide nicht mehr ohne weiteres eine einfache Lastverteilung zwischen den Services.

Amazon Lambda ist sehr interessant: Einzelne Methoden lassen sich ohne großen Aufwand deployen. Jeder Aufruf wird abgerechnet, das Monitoring ist ebenfalls problemlos, und die Services sind strikt gegeneinander isoliert – schließlich muss die Plattform sicherstellen, dass Dienste verschiedener Kunden sich nicht aus Versehen beeinflussen. So erlaubt Amazon Lambda ganz andere Ansätze bei der Softwareentwicklung.

Aber es müssen nicht gleich Nanoservices sein: Eine Vereinheitlichung und Vereinfachung der Infrastrukturen kann schon dabei helfen, den Aufwand für Services zu reduzieren und so auch kleinere Services realistisch nutzbar zu machen. Beispielsweise können Templates für neue Services und analog Ansätze für Monitoring und Deployment hilfreich sein.

Eberhard Wolff
arbeitet als Fellow bei der innoQ. Er ist seit mehr als 15 Jahren als Architekt und Berater tätig – oft an der Schnittstelle zwischen Business und Technologie. Sein technologischer Schwerpunkt liegt auf modernen Architektur-Ansätzen – Cloud, Continuous Delivery, DevOps, Microservices oder NoSQL spielen oft eine Rolle. (ane)