Konto Anmelden
Jump to section

Was sind Microservices?

URL kopieren

Microservices sind ein Architekturkonzept für die Anwendungsentwicklung. Als Architektur-Frameworks sind Microservices verteilt und lose gekoppelt, sodass die Änderungen eines Teams nicht dazu führen können, dass die gesamte Anwendung nicht mehr funktioniert. Der Vorteil bei der Verwendung von Microservices liegt darin, dass Entwicklungsteams schnell neue Anwendungskomponenten bauen können, um sich ändernden geschäftlichen Anforderungen gerecht zu werden.

Der Unterschied zwischen einer Microservice-Architektur und traditionellen, monolithischen Ansätzen besteht in der Art und Weise, wie Apps in ihre Kernfunktionen aufgeschlüsselt werden. Jede Funktion bzw. jeder Service kann unabhängig entwickelt und bereitgestellt werden. Das heißt, individuelle Services können ohne negative Auswirkungen auf andere Services ausgeführt werden (und ausfallen). Das hilft Ihnen dabei, die technologische Seite von DevOps anzunehmen, und CI/CD (Constant Iteration and Delivery) nahtloser und erreichbarer zu machen.

Bild

Erinnern Sie sich nur einmal an Ihren letzten Besuch in einem Online-Shop. Dabei haben Sie vielleicht die Funktion für die Produktsuche auf der jeweiligen Site verwendet. Diese Funktion ist ein Service. Vielleicht wurden Ihnen auch Empfehlungen für verwandte Produkte angezeigt, die aus der Datenbank der Käuferpräferenzen stammen. Auch das ist ein Service. Haben Sie Artikel zu Ihrem Warenkorb hinzugefügt? Genau, auch das ist ein Service.

Ein Microservice ist also eine Kernfunktion einer Anwendung und wird unabhängig von anderen Services ausgeführt. Bei der Microservice-Architektur aber geht es um mehr als nur die lose Kopplung solcher Kernfunktionen. Es geht um die Umstrukturierung der Entwicklungsteams und der serviceübergreifenden Kommunikation auf eine Art und Weise, die als Vorbereitung auf unvermeidbare Fehler, zukünftige Skalierbarkeit und die Integration neuer Features fungiert.

Wie wird das erreicht? Durch die Anpassung der Grundlagen einer SOA (serviceorientierten Architektur) zur Bereitstellung von Microservices.

Wenn es Ihnen bekannt vorkommt, dass Apps in ihre Kernfunktionen aufgegliedert werden, um Probleme monolithischer Konzepte zu vermeiden, dann liegt das daran, dass der Architekturstil von Microservices dem etablierten Softwaredesign der SOA ähnelt.

In den Anfängen der Anwendungsentwicklung erforderten selbst minimale Änderungen an einer vorhandenen App ein komplettes Versions-Update mit einem eigenen Qualitätssicherungszyklus. Das wiederum hat die Effizienz zahlreicher nachgelagerter Teams enorm eingeschränkt. Dieses Konzept wird deshalb oft als „monolithisch“ bezeichnet, weil sich der Quellcode für die gesamte App in einer untrennbaren Entwicklungseinheit (wie .war oder .ear) befand. Wenn also Updates für Teile einer App Fehler verursachten, musste das ganze System offline genommen, zurückskaliert und repariert werden. Zwar ist dieses Konzept für kleinere Anwendungen immer noch umsetzbar, die damit verbundenen Ausfallzeiten sind für wachsende Unternehmen allerdings nicht mehr tragbar.

Und genau hier kommt der SOA-Ansatz ins Spiel, bei dem Apps in diskrete, wiederverwendbare Services strukturiert werden, die über einen ESB (Enterprise Service Bus) kommunizieren. In dieser Architektur folgen die um einen bestimmten Geschäftsprozesses organisierten Einzelservices einem Kommunikationsprotokoll (wie SOAP, ActiveMQ oder Apache Thrift), sodass sie über den ESB gemeinsam verwendet werden können. Diese über einen ESB integrierten Services bilden eine Anwendung.

Auf der einen Seite können dadurch Services ganz ohne monolithische Entwicklungszyklen gleichzeitig entwickelt, geprüft und angepasst werden. Auf der anderen Seite stellt der ESB einen Single Point of Failure für das gesamte System dar. Das heißt, beim Versuch, einen monolithischen Ansatz zu eliminieren, hat man einen neuen ins Leben gerufen, nämlich den ESB, der ein Hindernis für die gesamte Organisation sein kann.

Worin besteht der Unterschied? Microservices können, üblicherweise zustandslos, miteinander kommunizieren. Daher sind auf Microservices basierende Apps fehlertoleranter und weniger abhängig von einem einzelnen ESB. Und weil Microservices über sprachunabhängige APIs kommunizieren, können Entwicklungsteams ihre eigenen Tools wählen.

Wenn man sich die Geschichte von SOA ansieht, sind Microservices eigentlich gar kein so neues Konzept. Allerdings ist ihre Realisierbarkeit dank den Fortschritten bei der Containerisierungstechnologie zwischenzeitlich enorm angestiegen. Mit Linux-Containern können Sie jetzt mehrere Teile einer App auf derselben Hardware unabhängig voneinander ausführen, während Sie gleichzeitig die einzelnen Bestandteile und Lifecycles viel besser steuern können. Zusammen mit APIs und DevOps-Teams bilden containerisierte Microservices die Basis für cloudnative Anwendungen.

Dank der verteilten Entwicklung von Microservices entstehen für Ihre Teams und Routinen ganz neue Möglichkeiten. Außerdem können Sie mehrere Microservices gleichzeitig entwickeln. Das heißt, dass mehrere Entwicklerinnen und Entwickler gleichzeitig an derselben App arbeiten und so die Entwicklungszeit deutlich reduziert werden kann.

Schnellere Markteinführung

Da die Entwicklungszyklen in einer Microservice-Architektur sehr viel kürzer sind, können auch Deployments und Updates viel agiler durchgeführt werden.

Hohe Skalierbarkeit

Wenn der Bedarf für bestimmte Services steigt, können diese über mehrere Server und Infrastrukturen hinweg flexibel implementiert werden.

Resilienz

Wenn diese unabhängigen Services ordnungsgemäß entwickelt sind, haben Sie keinerlei Auswirkungen aufeinander. Das heißt, wenn eine Komponente ausfällt, streikt im Gegensatz zum monolithischen Ansatz nicht gleich die gesamte App.

Einfaches Deployment

Da microservice-basierte Apps modular und dazu viel kleiner als herkömmliche monolithische Apps sind, können Sie die mit der alten Methodologie verbundenen Probleme getrost vergessen. Zwar erfordert die neue Variante eine intensivere Koordination, bei der eine Service-Mesh-Schicht behilflich sein kann, dieser Umstand kann jedoch durch die großen Vorteile mehr als wettgemacht werden.

Besserer Zugriff

Da eine größere App in kleinere Bestandteile aufgegliedert wird, können Entwicklerinnen und Entwickler die einzelnen Komponenten leichter verstehen, aktualisieren und verbessern, was wiederum zu kürzeren Entwicklungszyklen führt, speziell in Kombination mit agilen Methoden.

Mehr Offenheit

Dank sprachunabhängiger APIs können Entwicklungsteams ihre bevorzugte Sprache bzw. Technologie für die notwendige Funktion frei wählen.

Wenn Ihre Organisation über einen Wechsel zu einer Microservice-Architektur nachdenkt, dann seien Sie darauf gefasst, dass sich dadurch nicht nur die Funktionsweise der Apps, sondern auch die Arbeitsweise Ihrer Beschäftigten ändert. Organisatorische und kulturelle Änderungen gelten als Herausforderungen, weil jedes Team seine eigenen Entwicklungsabläufe hat und für individuelle Services mit einem eigenen Kundenstamm verantwortlich ist. Diese Gedanken mögen für Entwicklungsteams zwar nicht typisch sein, sind aber für den Erfolg einer Microservice-Architektur unerlässlich.

Neben den kulturellen und prozessualen Komponenten sind Komplexität und Effizienz zwei der größten Herausforderungen einer Microservice-Architektur. John Frizelle, Platform Architect bei Red Hat Mobile, hat bei seinem Vortrag anlässlich des Red Hat Summit 2017 die folgenden acht Herausforderungen dargelegt:

  1. Entwicklung: Sie benötigen Zeit, um die Abhängigkeiten zwischen Ihren Services zu identifizieren. Beachten Sie, dass der Abschluss eines Builds aufgrund solcher Abhängigkeiten mehrere weitere Builds auslösen kann. Dazu müssen Sie auch die Auswirkungen von Microservices auf Ihre Daten berücksichtigen.
  2. Tests: Integrations- wie auch End-to-End-Tests können komplexer und wichtiger werden als je zuvor. Beachten Sie, dass – je nachdem, wie Sie die gegenseitige Unterstützung Ihrer Services strukturiert haben – ein Fehler in einem Teil Ihrer Architektur Probleme in einem anderen verursachen kann.
  3. Versionierung: Vergessen Sie bei einem Update auf neue Versionen nicht, dass dadurch die Abwärtskompatibilität beeinträchtigt werden kann. Und auch wenn Sie eine bedingungsabhängige Logik integrieren, können Ihre Builds sehr schnell schwerfällig und ineffizient werden. Alternativ könnten Sie mehrere Live-Versionen für unterschiedliche Kunden hochfahren, das aber steigert wiederum den Wartungs- und Verwaltungsaufwand.
  4. Deployment: Ja, auch dieser Punkt gehört zu den Herausforderungen, zumindest bei der anfänglichen Einrichtung. Um das Deployment zu erleichtern, sollten Sie großzügig in die Automatisierung investieren, da die Komplexität von Microservices für ein Deployment durch den Menschen überwältigend sein kann. Überlegen Sie, auf welche Art und Weise bzw. in welcher Reihenfolge das Rollout Ihrer Services erfolgen soll.
  5. Protokollierung: Bei verteilten Systemen benötigen Sie zentrale Protokolle zur Erfassung aller Daten. Ansonsten wird eine effiziente Skalierung unmöglich.
  6. Überwachung: Sie benötigen unbedingt eine zentrale Ansicht Ihres Systems, um die Ursachen von Problemen identifizieren zu können.
  7. Debugging: Remote-Debugging mithilfe Ihrer lokalen IDE (Integrated Development Environment) ist hier keine Option und funktioniert nicht bei Dutzenden oder Hunderten von Services. Leider gibt es auf diese Frage zum jetzigen Zeitpunkt keine zufriedenstellende Antwort.
  8. Konnektivität: Ziehen Sie eine Service-Discovery-Lösung in Betracht, zentral oder integriert.

Berechnen Sie Ihre Einsparungen durch Migration

Manche virtuellen Infrastrukturen schränken die Wahl der Software ein, weil Sie mit ihnen an Unternehmenslizenzvereinbarungen gebunden sind. Mit einer Migration zu Open Source-Virtualisierung können Sie den Weg zu Containern freimachen.

Weiterlesen

ARTIKEL

Wie Microservices die IT-Integration im Gesundheitswesen unterstützen

Microservices unterstützen Entwickler im Gesundheitswesen und anderen Branchen bei der Erstellung von Anwendungen aus lose gekoppelten Services, wodurch Entwicklung, Test, Bereitstellung und Upgrade vereinfacht werden.

ARTIKEL

Was sind Microservices?

Microservices sind ein Architekturkonzept der Anwendungsentwicklung, bei dem Teile einer App unabhängig voneinander und gleichzeitig zusammen fungieren.

ARTIKEL

Was ist ein Service Mesh?

Ein Service Mesh ist eine in eine Anwendung integrierte Infrastrukturschicht, mit der Interaktionen zwischen Services dokumentiert werden, um die Kommunikation zu optimieren und Ausfallzeiten zu vermeiden.

Mehr über Microservices erfahren

Produkte

Red Hat OpenShift

Eine unternehmensfähige Kubernetes-Container-Plattform, auf der Operationen für den gesamten Stack automatisiert werden, um Hybrid Clouds, Multi-Clouds und Edge-Deployments noch einfacher verwalten zu können.

Ressourcen

Analystenreport

Red Hat Integration unterstützt Unternehmen bei der Optimierung von Anwendungsleistung und Geschäftsergebnissen

E-Book

Einem Elefanten das Tanzen beibringen – Zusammenfassung

Training

Kostenloser Trainingskurs

Developing Cloud-Native Applications with Microservices Architectures

Illustration - mail

Möchten Sie mehr zu diesen Themen erfahren?

Abonnieren Sie unseren kostenlosen Newsletter, Red Hat Shares.

Red Hat logo LinkedInYouTubeFacebookTwitter

Produkte

Tools

Testen, kaufen und verkaufen

Kommunizieren

Über Red Hat

Als weltweit größter Anbieter von Open-Source-Software-Lösungen für Unternehmen stellen wir Linux-, Cloud-, Container- und Kubernetes-Technologien bereit. Wir bieten robuste Lösungen, die es Unternehmen erleichtern, plattform- und umgebungsübergreifend zu arbeiten – vom Rechenzentrum bis zum Netzwerkrand.

Abonnieren Sie unseren Newsletter, Red Hat Shares

Jetzt anmelden

Wählen Sie eine Sprache

© 2022 Red Hat, Inc.