© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: EnterpriseTales

Kolumne: EnterpriseTales


Das waren noch Zeiten, als unsere heißgeliebten monolithischen Enterprise-Anwendungen robust und sicher vor sich hinliefen. Heute dagegen baut man stark verteilte Systeme auf Basis von niedlichen, kleinen Services, die scheinbar permanent wegzubrechen drohen. Wie soll man das bitte noch im Griff behalten?

Beschäftigt man sich mit dem Thema Microservices und den zugehörigen Architekturansätzen, stößt man schnell auf das Thema Resilience. Reichte es früher aus, ein Softwaresystem stabil (reliable) zu gestalten, muss es heute belastbar und flexibel (resilient) sein. Warum ist das eigentlich so und was genau ist der Unterschied? Enterprise Tales auf Ursachenforschung ...

Für eine monolithische Anwendung ist es essenziell, dass sie das macht, was man von ihr erwartet: Nämlich ohne Fehler und ohne Ausfälle zu funktionieren. Denn fällt ein solches System aus, fällt per Definition alles aus. Entsprechend viel Energie wird darauf verwandt, ein solches System fehlerfrei (Development) und hoch verfügbar (Deployment) aufzubauen. Während der Entwicklung sorgen ausgefeilte QA-Szenarien dafür, die Software möglichst bugfrei zu bekommen. Ausfallsicherheit der Server erkauft man sich über Load Balancing und komplexe Cluster, oder man schiebt die Anwendung gleich mit entsprechenden SLAs in die Cloud.

Bei einem Microservice-basierten System ist die Ausgangslage ein wenig anders. Fällt einer der Services aus, können die anderen Services theoretisch weiterarbeiten, vorausgesetzt, das System ist auf die Ausfälle bzw. das Fehlverhalten einzelner Services vorbereitet [1]. Die Idee von Resilience ist es also, mit temporären Problemen sinnvoll umgehen zu können. Was genau in diesem Kontext sinnvoll ist, klären wir später. Zusätzlich sollte ein resilientes System in der Lage sein, sich schnell – und wenn möglich, automatisch – von einem aufgetretenen Problem zu erholen. Dabei sollte es wieder zur normalen Ausgangsposition zurückkehren, nachdem es in einen Ausnahmezustand gelaufen ist. Die Verwendung von Microservices löst dabei nicht automatisch das Problem. Ganz im Gegenteil: Es ist viel Energie notwendig, ein stark verteiltes System so aufzubauen, dass temporäre Ausfälle oder fehlerhafte Responses einzelner Services sauber abgefangen werden können, ohne dass dabei die Ergonomie der Anwendung leidet. Gleiches gilt für die automatische Wiederherstellung des Systems [2].

Die sieben, äh, acht Irrtümer verteilter Systeme

Dass verteilte Systeme, und dazu gehören nun einmal auch unse...

Java Magazin
Kolumne: EnterpriseTales

Kolumne: EnterpriseTales

Das waren noch Zeiten, als unsere heißgeliebten monolithischen Enterprise-Anwendungen robust und sicher vor sich hinliefen. Heute dagegen baut man stark verteilte Systeme auf Basis von niedlichen, kleinen Services, die scheinbar permanent wegzubrechen drohen. Wie soll man das bitte noch im Griff behalten?

Lars Röwekamp


Das waren noch Zeiten, als unsere heißgeliebten monolithischen Enterprise-Anwendungen robust und sicher vor sich hinliefen. Heute dagegen baut man stark verteilte Systeme auf Basis von niedlichen, kleinen Services, die scheinbar permanent wegzubrechen drohen. Wie soll man das bitte noch im Griff behalten?

Beschäftigt man sich mit dem Thema Microservices und den zugehörigen Architekturansätzen, stößt man schnell auf das Thema Resilience. Reichte es früher aus, ein Softwaresystem stabil (reliable) zu gestalten, muss es heute belastbar und flexibel (resilient) sein. Warum ist das eigentlich so und was genau ist der Unterschied? Enterprise Tales auf Ursachenforschung ...

Für eine monolithische Anwendung ist es essenziell, dass sie das macht, was man von ihr erwartet: Nämlich ohne Fehler und ohne Ausfälle zu funktionieren. Denn fällt ein solches System aus, fällt per Definition alles aus. Entsprechend viel Energie wird darauf verwandt, ein solches System fehlerfrei (Development) und hoch verfügbar (Deployment) aufzubauen. Während der Entwicklung sorgen ausgefeilte QA-Szenarien dafür, die Software möglichst bugfrei zu bekommen. Ausfallsicherheit der Server erkauft man sich über Load Balancing und komplexe Cluster, oder man schiebt die Anwendung gleich mit entsprechenden SLAs in die Cloud.

Bei einem Microservice-basierten System ist die Ausgangslage ein wenig anders. Fällt einer der Services aus, können die anderen Services theoretisch weiterarbeiten, vorausgesetzt, das System ist auf die Ausfälle bzw. das Fehlverhalten einzelner Services vorbereitet [1]. Die Idee von Resilience ist es also, mit temporären Problemen sinnvoll umgehen zu können. Was genau in diesem Kontext sinnvoll ist, klären wir später. Zusätzlich sollte ein resilientes System in der Lage sein, sich schnell – und wenn möglich, automatisch – von einem aufgetretenen Problem zu erholen. Dabei sollte es wieder zur normalen Ausgangsposition zurückkehren, nachdem es in einen Ausnahmezustand gelaufen ist. Die Verwendung von Microservices löst dabei nicht automatisch das Problem. Ganz im Gegenteil: Es ist viel Energie notwendig, ein stark verteiltes System so aufzubauen, dass temporäre Ausfälle oder fehlerhafte Responses einzelner Services sauber abgefangen werden können, ohne dass dabei die Ergonomie der Anwendung leidet. Gleiches gilt für die automatische Wiederherstellung des Systems [2].

Die sieben, äh, acht Irrtümer verteilter Systeme

Dass verteilte Systeme, und dazu gehören nun einmal auch unse...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang