© Liashko/Shutterstock.com
Entwickler Magazin
Erfahrungen, Vor- und Nachteile von Microservices

Schein und Sein

Kaum ein Thema ist im Moment so ein Hype wie Microservices [1]. Welche Gründe gibt es dafür? Und wie kann man Microservices gewinnbringend einsetzen? Welche Herausforderungen gibt es? Dieser Artikel gibt einen Überblick über den Architekturtrend und beantwortet die wichtigsten Fragen.

Eberhard Wolff


Microservices dienen eigentlich nur zur Modularisierung von Software. Für Modularisierung gibt es aber unzählige Ansätze: Klassen, Packages oder JARs dienen in der Java-Welt beispielsweise diesem Ziel. Nur so können auch große Projekte in kleine Einheiten aufgeteilt werden und bleiben dadurch erweiterbar und wartbar. Aber Microservices sind anders: Die wesentliche Eigenschaft von Microservices ist das unabhängige Deployment. Ein Microservice kann in Produktion gebracht werden, ohne dass die anderen Microservices ebenfalls neu deployt werden müssen. Während also bei den klassischen Deployment-Monolithen die Module wie Klassen, Packages oder JARs alle gleichzeitig in Produktion gebracht werden müssen, ist das bei Microservices nicht so. Übrigens können Deployment-Monolithen durchaus intern sauber modularisiert sein – nur müssen eben alle Module gemeinsam in Produktion gebracht werden.

Konkret können Microservices beispielsweise als einzelne Docker-Container umgesetzt sein. Mehrere solcher Container bilden dann zusammen eine Anwendung. Jeder einzelne Microservice kann eine REST-Schnittstelle haben oder für bestimmte URLs die Weboberfläche als HTML-Seiten erzeugen.

Durch die Aufteilung in mehrere Deployment-Einheiten wie Docker-Container ergeben sich neben dem unabhängigen Deployment noch verschiedene andere Konsequenzen: Jeder Microservice kann in einer anderen Programmiersprache auf einer anderen Plattform implementiert sein. In einem Docker-Container kann schließlich fast jede Infrastruktur laufen. Ebenso kann jeder Microservice einzeln skaliert werden. Dazu sind nur ein Load Balancer und mehrere Instanzen des Docker-Containers notwendig. Auch bezüglich der Robustheit ist ein Microservice eine Einheit: Wenn beispielsweise ein Microservice zu viel Speicher allokiert oder die CPU stark belastet, beeinflusst das nur diesen einen Microservice. Wenn die anderen Microservices sogar den Ausfall dieses Microservice tolerieren können, entsteht so ein sehr robustes System.

Es gibt auch ganz andere Infrastrukturen für Microservices. Beispielsweise erlaubt Amazon Lambda [2] das Deployment einzelner in Java, JavaScript oder Python geschriebener Funktionen. Diese werden auch automatisch in ein Monitoring integriert. Die Abrechnung erfolgt pro Aufruf, wobei die erste Million Aufrufe kostenlos ist.

Eine solche Technologie verringert den Aufwand für einen Microservice erheblich: Er muss nur mit einem Kommandozeilenwerkzeug deployt werden, den Rest erledigt die Infrastruktur....

Entwickler Magazin
Erfahrungen, Vor- und Nachteile von Microservices

Schein und Sein

Kaum ein Thema ist im Moment so ein Hype wie Microservices [1]. Welche Gründe gibt es dafür? Und wie kann man Microservices gewinnbringend einsetzen? Welche Herausforderungen gibt es? Dieser Artikel gibt einen Überblick über den Architekturtrend und beantwortet die wichtigsten Fragen.

Eberhard Wolff


Microservices dienen eigentlich nur zur Modularisierung von Software. Für Modularisierung gibt es aber unzählige Ansätze: Klassen, Packages oder JARs dienen in der Java-Welt beispielsweise diesem Ziel. Nur so können auch große Projekte in kleine Einheiten aufgeteilt werden und bleiben dadurch erweiterbar und wartbar. Aber Microservices sind anders: Die wesentliche Eigenschaft von Microservices ist das unabhängige Deployment. Ein Microservice kann in Produktion gebracht werden, ohne dass die anderen Microservices ebenfalls neu deployt werden müssen. Während also bei den klassischen Deployment-Monolithen die Module wie Klassen, Packages oder JARs alle gleichzeitig in Produktion gebracht werden müssen, ist das bei Microservices nicht so. Übrigens können Deployment-Monolithen durchaus intern sauber modularisiert sein – nur müssen eben alle Module gemeinsam in Produktion gebracht werden.

Konkret können Microservices beispielsweise als einzelne Docker-Container umgesetzt sein. Mehrere solcher Container bilden dann zusammen eine Anwendung. Jeder einzelne Microservice kann eine REST-Schnittstelle haben oder für bestimmte URLs die Weboberfläche als HTML-Seiten erzeugen.

Durch die Aufteilung in mehrere Deployment-Einheiten wie Docker-Container ergeben sich neben dem unabhängigen Deployment noch verschiedene andere Konsequenzen: Jeder Microservice kann in einer anderen Programmiersprache auf einer anderen Plattform implementiert sein. In einem Docker-Container kann schließlich fast jede Infrastruktur laufen. Ebenso kann jeder Microservice einzeln skaliert werden. Dazu sind nur ein Load Balancer und mehrere Instanzen des Docker-Containers notwendig. Auch bezüglich der Robustheit ist ein Microservice eine Einheit: Wenn beispielsweise ein Microservice zu viel Speicher allokiert oder die CPU stark belastet, beeinflusst das nur diesen einen Microservice. Wenn die anderen Microservices sogar den Ausfall dieses Microservice tolerieren können, entsteht so ein sehr robustes System.

Es gibt auch ganz andere Infrastrukturen für Microservices. Beispielsweise erlaubt Amazon Lambda [2] das Deployment einzelner in Java, JavaScript oder Python geschriebener Funktionen. Diese werden auch automatisch in ein Monitoring integriert. Die Abrechnung erfolgt pro Aufruf, wobei die erste Million Aufrufe kostenlos ist.

Eine solche Technologie verringert den Aufwand für einen Microservice erheblich: Er muss nur mit einem Kommandozeilenwerkzeug deployt werden, den Rest erledigt die Infrastruktur....

Neugierig geworden?


   
Loading...

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