Microservices entzerren nicht nur die Softwareentwicklung, sondern bilden auch die Grundlage für den DevOps-Ansatz. Wir sagen Ihnen, was Sie wissen müssen. [...]
Anwendungen bestehen aus einer Vielzahl von Tasks, deren Ausführung das Computersystem auf die zur Verfügung stehenden Ressourcen aufteilt. Eine der wesentlichen Fragen der Softwareentwicklung: Wie sollten die einzelnen Code-Stücke miteinander verknüpft sein, damit die Anwendung möglichst performant und effizient läuft? Eine zunehmend populäre Antwort auf diese Frage sind Microservices – kleine, separate und funktionale Code-Teile, die mit anderen Microservices interagieren und so ein größeres Anwendungssystem ausbilden.
Auch wenn die Grundidee einzelner, separater Funktionskomponenten nichts Neues ist, die Art und Weise wie Microservices implementiert werden, macht sie zum Fundament für moderne Cloud-Applikationen. Darüber hinaus sind Microservices auch eng mit dem DevOps-Ansatz verwoben, der darauf abzielt, neue Funktionen schnell und kontinuierlich auszuliefern.
Was sind Microservices?
Das „Micro“ in Microservices impliziert, dass es sich ausschließlich um kleine Applikationen handelt. Das ist in manchen Fällen korrekt – in anderen hingegen nicht: Microservices sollten genau so groß sein, wie sie sein müssen, um einen spezifischen Sachverhalt oder ein Problem lösen zu können – sagen die Befürworter dieses Architektursystems. Das zugrundeliegende Problem sollte allerdings ein konzeptionelles und kein technisches sein.
Oder wie Microsoft es ausdrückt: „Microservices sollten nicht um horizontale Layer wie Data Access oder Messaging, sondern um Geschäftspotenziale herum aufgebaut werden“. Microservices interagieren mit anderen Microservices und externen Nutzern über Schnittstellen (APIs), um eine größere Applikation auszubilden.
Deswegen können die individuellen Funktionalitäten eines Microservice vergleichsweise leicht angepasst oder überarbeitet werden, ohne dabei den Rest des Systems in Mitleidenschaft zu ziehen. Das zahlt wiederum auf den DevOps-Ansatz ein: Wenn die spezifischen Funktionen einer größeren Anwendung in separate, unabhängig funktionierende Code-Teile aufgespalten werden, ist es wesentlich einfacher, das DevOps-Mantra (fortlaufende Integration und Auslieferung) in der Praxis umzusetzen. Standardisierte APIs tragen dazu bei, dass sich Microservices einfach automatisiert testen lassen.
Microservice-Architektur oder Monolithen?
Wenn Sie von Microservices hören, dann meist im Zusammenhang mit Software-Architekturen. Microservices-Architekturen beinhalten nicht nur die Microservices selbst, sondern auch Management- und Service-Discovery-Komponenten sowie ein API Gateway, das für die Kommunikation zwischen den Microservices und der Außenwelt zuständig ist.
Eine monolithische Applikation stellt quasi den Gegenentwurf zu Microservices dar. Er beschreibt eine Applikation beschreibt, deren Programmcode aus einer einzelnen, riesigen Binärdatei besteht. Eine monolithische Applikation ist folglich wesentlich schwerer zu skalieren und zu optimieren. Weil die Funktionen fest verdrahtet und integriert sind, verursacht so ein Anwendungsmonolith in der Regel allerdings auch weniger Management-Aufwand als eine Microservices-Architektur.
Wie definiert man Microservice?
Microservices sollten eine spezifische Funktion abbilden – zumindest in der Theorie sagt sich das leicht. In der Praxis ist das Beziehungsgeflecht zwischen den einzelnen Funktionalitäten einer Applikation in den meisten Fällen derart komplex, dass eine klare Abgrenzung schwerer fällt, als man denkt. Eine Domänenanalyse und Domain Driven Design sind die theoretischen Ansätze, die Ihnen dabei helfen, Ihren Task mit Blick auf das große Ganze in individuelle Probleme zu zerlegen, die eine Microservices-Architektur lösen kann.
Eine Reihe von Microsoft-Blogposts gibt tiefergehenden Aufschluss über diesen Prozess, bei dem ein abstraktes Modell Ihrer Geschäftsbereiche entsteht. Dieses Modell verdeutlicht die Bounded Contexts, deren Verständnis für die User-Funktionalitäten von essenzieller Bedeutung ist. Jeder Microservice sollte in einem einzelnen Bounded Context existieren, wobei manche Bounded Contexts auch mehr als einen Microservice umfassen können.
Was unterscheidet Microservices von SOA und Web Services?
Wenn Sie zu den erfahreneren IT-Profis gehören, könnte Ihnen das bisher Beschriebene bekannt vorkommen. Die Idee, kleine individuelle Programme zusammenarbeiten zu lassen, erinnert sowohl an SOA (Service-orientierte Architektur) als auch an Web Services – beides Buzzwords aus der ehrwürdigen Web-2.0-Ära zu Beginn der 2000er Jahre. Auch wenn Microservices das Rad nicht neu erfinden, gibt es einige grundlegende Unterschiede zu SOA und Web Services. Hier finden Sie eine detaillierte Erklärung zu den einzelnen Architektur-Modellen – im Folgenden die Kurzversion:
- Innerhalb einer SOA sind die individuellen Komponenten relativ eng miteinander verknüpft und greifen parallel auf bestimmte Assets wie Storage zu. Die Kommunikation zwischen den Komponenten läuft über eine spezielle Middleware Software, einen sogenannten Enterprise Storage Bus. Microservices sind im Vergleich dazu unabhängiger, weniger ressourcenintensiv und kommunizieren über schlankere Protokolle. Erwähnenswert ist, dass Microservices im Dunstkreis von SOA entstanden sind und teilweise als Nachfolge-Konzept der Service-orientierten Architektur gesehen werden.
- Ein Web Service bildet ein öffentlich zugängliches Set von Funktionen ab, auf die andere Applikationen über das Web zugreifen können. Das gängigste Beispiel dafür ist Google Maps: Will ein Restaurantbesitzer seinen Kunden den Weg weisen, bindet er Maps auf seiner Webseite ein. Diese Verbindung ist im Vergleich zu Microservices weit weniger starr.
Wie kommunizieren Microservices?
Ein schlauer Rat, den man immer wieder hört, wenn es um Microservices geht, ist auf „Smart Endpoints and dumb pipes“ zu setzen. Mit anderen Worten: Das Ziel bei Microservices sollte sein, auf möglichst grundlegende und etablierte Kommunikationsmethoden zurückzugreifen, statt auf komplexe mit einer umfassenden Integration.
Ganz generell sollte die Kommunikation zwischen Microservices asynchron stattfinden. Dabei können allerdings immer noch synchrone Protokolle wie http zum Einsatz kommen, auch wenn asynchrone Protokolle wie AMQP (Advanced Message Queueing Protocol) sich inzwischen im Microservices-Umfeld steigender Beliebtheit erfreuen. Diese Art der losen Anbindung macht eine Microservices-Architektur wesentlich flexibler – beispielsweise wenn es zu einem Ausfall individueller Komponenten oder Teilen des Netzwerks kommt.
Was haben Microservices mit Java zu tun?
Einige der ersten Microservices-Errungenschaften stammen aus der Java Community. Insbesondere Martin Fowler ist hier als Pionier hervorzuheben. Auf einer Java-Konferenz im Jahr 2012 gab es eine der wichtigsten frühen Präsentationen zum Thema zu sehen mit dem Titel „Micro services – Java, the Unix Way„.
In der Folge dieser Entwicklungen entstand eine Vielzahl von Java Frameworks, auf deren Grundlage sich Microservices umsetzen lassen. Eines der populärsten ist Spring Boot, das speziell für Microservices konzipiert wurde. Ergänzt wird es durch Spring Cloud, das – wie der Name verspricht – solche Lösungen auch in die Cloud bringt. Ein Tutorial um mit Microservices auf Grundlage dieser Frameworks durchzustarten, finden Sie beim Hersteller Pivotal Software.
Microservices und Container – wie hängt das zusammen?
Von allen Technologien, die die Grundlage für Microservices bilden, haben es Container am weitesten in den Business IT Mainstream geschafft. Ein Container ähnelt im Grunde einer virtuellen Maschine (VM), stellt aber im Grunde nur einen isolierten User Space dar, der den Kernel des Betriebssystems nutzt, während seine internen Rechenoperationen unabhängig ablaufen. Container sind wesentlich kleiner als VM-Instanzen und lassen sich leichter ausrollen – sowohl lokal als auch in der Cloud.
Warum Container und Microservices gut harmonieren ist offensichtlich: Jeder einzelne Microservice kann in seinem eigenen Container laufen, was den Overhead in Sachen Servicemanagement drastisch reduziert. Die meisten Container-Implementierungen bringen diverse Tools mit, mit denen sich Deployment, Management, Skalierung, Networking und Verfügbarkeit Container-basierter Applikationen automatisiert steuern lassen. Die Kombination aus kleinen, leicht zu entwickelnden Microservices und einfach auszurollenden Containern macht den DevOps-Ansatz erst möglich. Es gibt verschiedene Implementierungen des Container-Konzepts, von denen Docker die mit Abstand populärste darstellt.
Spring hingegen ist mit der Java-Plattform verbunden. Container-basierte Systeme sind außerdem vielseitig kompatibel: Innerhalb eines Containers kann jede Programmiersprache laufen, die vom Betriebssystem unterstützt wird. Das gibt Softwareentwicklern wesentlich mehr Flexibilität. Ganz generell ist es ein wesentlicher Vorteil von Microservices, dass jeder einzelne Service in seiner eigenen Programmiersprache geschrieben sein kann – je nachdem, welche für den Entwickler am meisten Sinn macht.
Es wäre sogar möglich, einen einzelnen Service komplett in einer neuen Programmiersprache zu entwickeln, ohne dass das System in seiner Gänze beeinträchtigt würde – solange die APIs stabil bleiben. An dieser Stelle finden Sie einen interessanten Artikel, der detailliert die Vor- und Nachteile von Spring Cloud im Vergleich zu Kubernetes unter die Lupe nimmt.
Wie lassen sich Microservices designen?
Egal in welcher Sprache Sie Ihre Microservices entwickeln, dabei werden sich Problemfelder auftun, die andere Entwickler bereits bearbeitet haben. Auch auf dem Gebiet der Microservices gibt es deshalb verschiedene Entwurfsmuster (Design Patterns), mit denen sich bekannte, wiederkehrende Probleme bei der Softwareentwicklung lösen lassen.
Eine vollständige Auflistung der Entwurfsmuster für Microservices-Architekturen finden Sie bei Devopedia – hier einige ausgewählte Highlights:
- Service Registry: verbindet Clients mit verfügbaren Microservices-Instanzen;
- Cicruit Breaker: sorgt dafür, dass nicht verfügbare Services nicht mehr aufgerufen werden können;
- Fallback: stellt eine Alternative für einen ausgefallenen Service zur Verfügung;
- Sidecar: stellt ergänzende Services für den Haupt-Container zur Verfügung, etwa Logging, Synchronisierung oder Monitoring;
- Adapter: standardisiert oder normalisiert das Interface zwischen Haupt-Container und der Außenwelt;
- Ambassador: verbindet den Haupt-Container mit der Außenwelt – beispielsweise, um localhost-Verbindung mit einem Proxy auszustatten
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.com.
Be the first to comment