Was sind Microservices?

Wieso Microservices wichtig sind

Für die Wettbewerbsfähigkeit und den anhaltenden Erfolg eines Unternehmens ist es unabdingbar, dass Microservices und Prozessautomatisierung angenommen werden und deren Funktionsweise verstanden wird. In diesem Leitfaden konzentrieren wir uns speziell auf Microservices: Wir geben eine Definition und erklären, wie sie funktionieren. Wir werden auch die Rolle der Cloud bei Microservices, Best Practices bei der Implementierung einer Microservices-Architektur und die Beziehung zur Prozessautomatisierung behandeln.

Was ist eine Microservices-Architektur?

Microservices sind eine Art Anwendungsarchitektur, bei der eine Anwendung aus kleinen, unabhängigen Services besteht, die über genau definierte APIs kommunizieren. Jeder Service wird von einem kleinen, eigenständigen Team betrieben, das für das Design und die Implementierung des Services verantwortlich ist. Eine Microservices-Architektur macht Teams innovativer und agiler und neue Funktionen können schneller entwickelt und eingesetzt werden. Hinweis: In diesem Leitfaden werden die Begriffe „Microservices“ und „Microservices-Architektur“ synonym verwendet, da „Microservices“ häufig zur Beschreibung der Microservices-Architektur eingesetzt wird.

Microservices-Architektur vs. monolithische Architektur

Eine Microservices-Architektur und eine monolithische Architektur ähneln sich insofern, als beide Anwendungen ausführen können, aber dies auf unterschiedliche Weise tun.

In einer Microservices-Architektur erstellen Entwickler unabhängige Komponenten (oder Services), die jeweils eine einzige Funktion erfüllen sollen. Diese Microservices kommunizieren über eine API und sind auf Geschäftsfunktionen ausgerichtet. Da sie unabhängig erstellt und ausgeführt werden, können Entwickler Microservices problemlos bereitstellen, ändern und aktualisieren, ohne dass andere Bereiche der Anwendung beeinflusst werden. Das macht Entwickler agiler und innovativer und neue Funktionen können schneller implementiert werden. 

Im Gegensatz dazu sind in einer monolithischen Architektur die Funktionen innerhalb der Anwendung eng mit allen anderen Prozessen verbunden. Alles läuft als ein einziger Service — bei einer Änderung muss die gesamte Architektur aktualisiert werden. Und da alles mit allem zusammenhängt, ist es für Entwickler schwierig, neue Features oder Funktionen einfach und schnell zu implementieren, was wiederum die Innovation einschränkt. Wenn ein Teil der monolithischen Architektur ausfällt, kommt höchstwahrscheinlich das gesamte System zum Stillstand, da alle Elemente eng miteinander gekoppelt sind.

SOA vs. Microservices-Arc

SOA vs. Microservices-Architektur

Eine serviceorientierte Architektur (SOA) ist eine Art der Softwareentwicklung, bei der Softwarekomponenten wiederverwendet werden. Jede Komponente (oder jeder Service) enthält den Code und die Datenintegrationen, die die Anwendung benötigt, um eine bestimmte Geschäftsfunktion auszuführen, z. B. die Überprüfung der Kreditkartengültigkeit während der Onlinebezahlung. Da sie Services und Komponenten in anderen Anwendungen unternehmensweit wiederverwenden können, spart SOA den Entwicklern sehr viel Zeit.

Wenn Sie jetzt denken, dass SOA sehr nach einer Microservices-Architektur klingt, liegen Sie richtig. Beide Architekturen bestehen aus lose gekoppelten, wiederverwendbaren Services, die oft unabhängig voneinander arbeiten. Es gibt jedoch auch einige Unterschiede:

• Zweck: Die Wiederverwendbarkeit von Komponenten ist das primäre Ziel von SOA; bei Microservices ist „Built for Replacement“ das Motto, wobei der Schwerpunkt auf der Teamorganisation und der Austauschbarkeit der einzelnen Komponenten liegt.

• Kommunikation: SOA-Services müssen über einen Enterprise Service Bus (ESB) kommunizieren, während Microservices jeweils ihr eigenes Kommunikationsprotokoll haben.

• Interoperabilität: SOAs verwenden meist heterogene Messaging-Protokolle wie AMQP (Advanced Messaging Queuing Protocol) und SOAP (Simple Object Access Protocol). Microservices verwenden einfachere, leichtgewichtige Messaging-Protokolle wie JMS (Java Messaging Service) und HTTP/REST.

Geschwindigkeit: SOAs arbeiten häufig langsamer als Microservices-Architekturen, da Ressourcen gemeinsam genutzt werden, anstatt dass sie dupliziert werden.

Wie funktioniert eine Microservices-Architektur?

Am besten lässt sich durch ein Beispiel erklären, wie Microservices funktionieren. Stellen Sie sich vor, Ihr Team entwickelt einen Microservice für die Bereitstellung von SIM-Karten. Sie können Ihren Tech-Stack frei wählen (innerhalb Ihrer Unternehmensarchitektur), und Ihr Team stellt den Service selbst bereit und betreibt ihn.

So können Sie den Service nach eigenem Ermessen implementieren oder ändern, ohne dass Sie andere bitten müssen, etwas zu erledigen oder Teil eines Release Trains zu werden. Das bedeutet, dass Ihr Team Änderungen schnell umsetzen kann. Gleichzeitig wird die Motivation erhöht, da das Team selbst für seine Services zuständig ist.

Eine Microservices-Architektur hat jedoch Auswirkungen auf die Prozessautomatisierung. Für die Automatisierung eines Geschäftsprozesses sind in der Regel mehrere Microservices nötig. Und im Gegensatz zur SOA, die einen Orchestrierungsprozess „außerhalb“ der Services erfordert, erlaubt die Microservices-Architektur keine Geschäftslogik außerhalb der Microservices. Die Zusammenarbeit zwischen Microservices findet also innerhalb der Microservices selbst statt.

Beispiel für eine Microservices-Architektur

Nehmen wir beispielsweise einen Service zum Onboarding von Kunden. Der Microservice ist für die Geschäftslogik rund um das Onboarding verantwortlich, einschließlich des zugehörigen Geschäftsprozesses. Das Team, das den Microservice implementiert, kann eine Workflow-Engine und BPMN verwenden, um diesen Prozess zu automatisieren, der dann andere Microservices orchestriert. Die Entscheidung wird innerhalb des Microservices getroffen und ist von außen nicht erkennbar; es handelt sich um ein Implementierungsdetail.

Die Kommunikation zwischen den Microservices erfolgt über APIs und nicht über die BPM-Plattform, wie es bei SOA der Fall ist. Prozesse sind Teil der Geschäftslogik eines Microservices; eine zentrale Workflow Engine ist nicht erforderlich.

Containers vs. Serverless Microservices

Container und Serverless Microservices ähneln sich insofern, als sie Entwicklern ermöglichen, Anwendungen in der Cloud zu erstellen, was weniger Aufwand erfordert als die Entwicklung auf einer Virtual Machine oder einem herkömmlichen Server. Es gibt jedoch einige Unterschiede:

• Kosten: Container laufen immer, d. h. dem Unternehmen wird der Platz auf dem Server in Rechnung gestellt, auch wenn die Anwendung nicht genutzt wird. Bei der Serverless-Architektur wird die Anwendung jedoch nur ausgeführt, wenn sie aufgerufen wird. Das bedeutet, dass Unternehmen nur die tatsächliche Nutzung der Serverkapazität berechnet wird.
• Skalierbarkeit: In einer containerbasierten Architektur legt der Entwickler im Voraus die Anzahl der Container fest, die er verwenden wird; Serverless Microservices skalieren automatisch, wenn sich die Nachfrage ändert.
• Deployment-Geschwindigkeit: Bei Containern müssen Entwickler Einstellungen, Bibliotheken usw. festlegen. Nach der Konfiguration dauert die Bereitstellung nur Sekunden. Serverlose Anwendungen benötigen nur Millisekunden für das Deployment, sodass Änderungen fast zeitgleich mit dem Upload des aktualisierten Codes in Betrieb genommen werden können.
• Wartung: In einer containerbasierten Architektur liegt die Verantwortung für die Verwaltung und Aktualisierung der Container bei den Entwicklern; in einer serverlosen Architektur übernimmt der Anbieter die gesamte Serverwartung und -aktualisierung.

Gängige Muster für Microservices-Architekturen

API Gateways

Ein API-Gateway-Muster ist ein Integrationsmuster, das als Single Entry Point zwischen Client-Anwendungen und Ihren Microservices dient. Es dient als Puffer zwischen den Anforderungen des Clients und den zugrunde liegenden Diensten des Systems.

Dekomposition

Entwickler können die Dekomposition auf zwei Arten anwenden: Dekomposition nach Domäne: Bei dieser Methode definieren Entwickler Services, die den DDD-Subdomänen (Domain-Driven Design) entsprechen, indem sie die Region, in der sie die Lösung einsetzen werden, und die für diese Region benötigten Services festlegen. Jede Subdomäne bezieht sich auf einen bestimmten Bereich, von der Gerätekommunikation bis zur Benutzerverwaltung. Dekomposition nach Modul: Bei der Dekomposition nach Modulen definieren Entwickler Komponenten auf der Grundlage von Modulen oder Funktionen. Dadurch können unterschiedliche Entwicklungsteams für jedes Modul verantwortlich sein.

Event Sourcing-Muster

Ein Event-Sourcing-Muster ist ein operativer Ansatz zur Verarbeitung von Daten, die durch eine Ereignisabfolge gesteuert werden. Darin werden alle Änderungen am Zustand einer Anwendung in der Reihenfolge aufgezeichnet, in der sie vorgenommen wurden, wodurch ein Audit-Protokoll entsteht. Event Sourcing ist ein hochgradig skalierbarer, dezentraler Ansatz zur Handhabung von Änderungen.

Service Discovery-Muster

Es gibt zwei allgemeine Arten von Service-Discovery-Mustern: clientseitige Erkennung und serverseitige Erkennung. Muster „Clientseitige Erkennung“: Der Serviceclient durchsucht die Registry mit Hilfe eines Algorithmus zum Lastausgleich, um einen geeigneten Service zu ermitteln. Dann stellt er eine Anfrage. Wenn der Service startet, merkt sich die Serverregistrierung den Speicherort der Instanz – und wenn er endet, löscht die Registrierung die Instanzinformationen. Muster „Serverseitige Erkennung“: Im Gegensatz zur clientseitigen Erkennung sind die clientseitigen Servicebenutzer bei der serverseitigen Erkennung nicht über die Service Registry informiert, sondern stellen ihre Anfragen über einen Router. Der Router durchsucht die Service Registry und leitet die Anfrage an die richtige Stelle weiter, sobald die richtige Service-Instanz gefunden ist. Das API-Gateway wählt den richtigen clientseitigen Anforderungsendpunkt, sodass die Lastverteilung kein Problem darstellt.

Muster „Aggregation“

Das Aggregationsmuster regelt, wie eine Anwendung die von den einzelnen Services zurückgegebenen Daten zusammenfassen und die Antwort an den Verbraucher liefern soll. Das Aggregatiosmuster kann dies auf zwei Arten bewerkstelligen:

• Das API-Gateway teilt die Anfrage auf mehrere Microservices auf und aggregiert die Daten, um sie an den Verbraucher zu senden, oder

• ein zusammengesetzter Microservice ruft jeden erforderlichen Microservice einzeln auf, aggregiert und transformiert die Daten, bevor sie an den Verbraucher zurückgegeben werden

Datenbank oder Shared Data

Es gibt zwei Hauptansätze für die Datenbankarchitektur von Microservices: Databank pro Service: Bei diesem Ansatz verfügt jeder Microservice über eine eigene Datenbank, die nur für diesen Microservice verfügbar ist und auf die nur über die Microservice-API zugegriffen werden kann. Gemeinsam genutzte Datenbank pro Service: Während eine Datenbank pro Service der bevorzugte Ansatz für Microservices ist, ist dies oft schwierig zu erreichen, wenn von einem Monolithen zu Microservices migriert wird. In diesem Fall ist eine gemeinsam genutzte Datenbank pro Service eine praktikable Lösung und eine gute Grundlage für die Aufteilung der Anwendung in kleinere, logischere Teile.

Wie kommunizieren Microservices miteinander?

Bei der Kommunikation von Microservices untereinander gibt es zwei gängige Messaging-Muster: Synchrone Kommunikation: Der Aufrufer wartet auf eine Antwort des Empfängers über ein Protokoll wie HTTP oder gRPC. Asynchrone Nachrichtenübermittlung: Bei diesem Microservice-Kommunikationsmuster wird nicht auf eine Antwort gewartet; stattdessen wird die Nachricht von einem (oder mehreren) Services asynchron verarbeitet.

Vor- und Nachteile von Microservices

Vorteile

Angesichts des zunehmenden Marktdrucks beschleunigen Unternehmen das Tempo und erhöhen ihre Investitionen in die digitale Transformation. Unternehmen, die eine digitale Transformation anstreben, möchten auf moderne Architekturen umsteigen, die die Cloud, Microservices und mobile Anwendungen umfassen. Microservices-Architekturen werden aufgrund ihrer Flexibilität und Agilität immer beliebter — aber das sind nicht die einzigen Vorteile. Weitere Vorteile von Microservices sind:

Höhere Produktivität

Da sie Anwendungen in kleinere, unabhängige Komponenten aufteilen, sind sie für Entwickler einfacher zu erstellen und zu warten. Entwickler können Services unabhängig voneinander erstellen, bereitstellen, verwalten und unterstützen, wodurch sich die Codebasis verringert. Das Testen ist überschaubarer und Teams können gleichzeitig an verschiedenen Bereichen der Anwendung arbeiten.

Höhere Skalierbarkeit

Entwicklungsteams können die beste Sprache oder Technologie für jeden Microservice bestimmen, ohne sich Gedanken über eine Inkompatibilität machen zu müssen. Sie können einzelne Services unabhängig voneinander skalieren und neue Komponenten hinzufügen, ohne dass das gesamte System neu implementiert werden muss.

Höhere Resilienz

Durch Microservices können Entwickler die Ursache von Leistungsproblemen leichter erkennen und beheben. Da es sich um einzelne Services handelt, wirkt sich ein einzelner Ausfall nicht auf die gesamte Anwendung aus. Außerdem ist es für Entwickler einfacher, Änderungen vorzunehmen und Aktualisierungen eines bestimmten Moduls zurückzunehmen, ohne dass die gesamte Anwendung neu bereitgestellt werden muss.

Kontinuierliche Integration/Kontinuierliche Bereitstellung (CI/CD)

Microservices ermöglichen es funktionsübergreifenden Teams, unabhängig voneinander Fehler bei Services zu beheben, Services zu testen, zu entwickeln, zu aktualisieren und bereitzustellen, wodurch der gesamte Lebenszyklus des Entwicklungsprozesses verkürzt wird. Zum

Herunterladen: Definitiver Leitfaden zur kontinuierlichen Prozessverbesserung

Einfach zu verstehen

Die Microservices-Architektur erleichtert es Entwicklern, die Funktionen der einzelnen Services zu verstehen.

Besserer Support für DevOps

Durch eine Microservices-Architektur können Unternehmen Anwendungen in kleinere Services aufteilen, sodass die Bereitstellungsteams die Services einzeln in Angriff nehmen und Entwicklung, Tests und Bereitstellung rationalisieren können.

Kürzere Entwicklungszyklen

Da Microservices sowohl eine kleinere Codebasis als auch einen engeren Anwendungsbereich haben, können Entwickler neue Features und Funktionen schnell bereitstellen.

Modularität

Die Microservice-Architektur bietet eine bessere Fehlereingrenzung. Der Ausfall eines einzelnen Microservices hat nicht den Ausfall des gesamten Systems zur Folge, da die anderen Microservices weiterhin einwandfrei funktionieren.

Skalierbarkeit

Da Microservices einzelne, separate Dienste sind, können Entwickler kritische Dienste skalieren, ohne die gesamte Anwendung skalieren zu müssen.

Vorteile einer Microservices-Architektur

Die Microservices-Architektur hat zwar viele Vorteile, bringt aber auch einige Nachteile mit sich.

Komplikationen beim Testen

Da Microservices individuell sind, ist es schwierig, allgemeine Tests durchzuführen; Entwickler müssen jeden abhängigen Service vor dem Testen bestätigen.

Informationsbarrieren

Die schiere Anzahl der Microservices kann die gemeinsame Nutzung von Informationen erschweren.

Mehr Komplexität

Ein verteiltes System mit vielen Microservices kann die Komplexität der Anwendung erhöhen.

Vorabkosten

Wenn Ihr Unternehmen derzeit eine monolithische Architektur verwendet, entstehen Vorabkosten für die Infrastruktur (z. B. Hosting, Wartung, Sicherheit). Für die Umstellung auf Microservices benötigen Sie zudem Entwickler.

Wer braucht Microservices?

Oft fragt man sich in Unternehmen, wer Microservices eigentlich braucht. Sind Microservices das Richtige für unser Unternehmen? In folgenden Fällen kann es sinnvoll sein, Microservices in Ihrem Unternehmen einzusetzen:

• Sie entwickeln agile Anwendungen, die ein Optimum an Innovation und Schnelligkeit bei der Bereitstellung erfordern.

• Sie sind bereit für einen Ansatz, der Agilität, Skalierbarkeit und Verwaltbarkeit erleichtert. 

• Sie stellen fest, dass Ihr Unternehmen Altanwendungen neu schreiben/überarbeiten muss, um mit den Geschäftsanforderungen Schritt zu halten.

• Sie haben individuelle, eigenständige Module, die wiederverwendet werden müssen.

Warum Cloud Microservices besser skalierbar sind

Microservices sind zwar nicht ausschließlich in einer Cloud-Umgebung zu finden, werden aber häufig zusammen mit ihr eingesetzt. Einer der Hauptgründe dafür ist ihre Skalierbarkeit. Da Microservices individuell bereitgestellt und skaliert werden können, maximieren sie den Nutzen der Cloud-Computing-Infrastruktur, bei der nur für die tatsächliche Nutzung gezahlt wird. So werden Kosten auf breiter Front gesenkt. Darüber hinaus kann die Flexibilität von Microservices zu komplexen Tech Stacks führen, die schwierig zu verwalten sind. Das vom Anbieter verwaltete Cloud Backend kann Unternehmen jedoch dabei helfen, die Vorteile von Microservices zu nutzen, ohne dass die Verwaltung Probleme bereitet. Video On Demand: 3 Superpowers for Next Level Microservices Orchestration

Implementierung von Microservices

Bei der Implementierung von Microservices ist vor allem Folgendes wichtig: die Migration von der bestehenden monolithischen Infrastruktur auf eine Microservices-Architektur. Anschließend muss festgelegt werden, wann Befehle und Ereignisse zur Kommunikation, Orchestrierung und Choreographie zwischen den Diensten verwendet werden sollen. Sehen wir uns das einmal genauer an.

Migration vom Monolithen zu Microservices

Wenn Sie sich entschlossen haben, von einem Monolithen auf Microservices zu migrieren, gibt es nur einen sicheren Weg, dies methodisch anzugehen.

Die Zerlegung eines Monolithen besteht im Grunde aus den drei folgenden Hauptpunkten:

• Definition — Definieren Sie, welche Funktionen zu Microservices migriert werden sollen.
• Kommunikation — Fügen Sie einen Proxy ein, um Anrufe abzufangen und sie an den neuen Microservice umzuleiten.
• Funktionen — Migrieren Sie die entsprechenden Funktionen Schritt für Schritt vom Monolithen zu Microservices.

Allerdings ist die Implementierung von Microservices anstelle eines Monolithen kein Allheilmittel. Wenn die Anzahl der an einem Geschäftsprozess beteiligten Microservices zunimmt, kann es zu ernsten Problemen kommen, wenn Sie nicht vorsichtig sind. Die End-to-End-Orchestrierung und -Überwachung von Geschäftsprozessen kann zu einem Albtraum werden und die Skalierbarkeit stark einschränken, wodurch alle Vorteile zunichte gemacht werden, die Microservices hätten bieten können. Daher ist es von entscheidender Bedeutung, dass Sie alles sorgfältig durchdenken, während Sie Ihren Monolithen zerlegen und Ihre neue Microservices-Architektur aufbauen.

Microservices Orchestration vs. Choreography

When designing and implementing your microservices-based architecture, be open to using both commands and events to communicate between services. Choreography and orchestration offer different benefits and drawbacks — smart businesses incorporate both styles into their microservices architecture.

Best Practices für eine Microservices-Architektur

Bei der Implementierung einer Microservices-Architektur lohnt es sich, ein paar Best Practices zu befolgen, um das bestmögliche Resultat zu erzielen.

Separater Build für jeden Microservice

Erstellen Sie immer einen separaten Build für jeden Microservice, damit er Komponentendateien auf den entsprechenden Anforderungsebenen abrufen kann. Auch wenn Ihre Microservices ähnliche Dateisätze auf unterschiedlichen Revisionsebenen abrufen können, wird so sichergestellt, dass die Einführung neuer Microservices einfach ist und dass das System als Ganzes nicht beeinträchtigt wird.

Der Einsatz einer Workflow Engine zur Verwaltung von Microservices bietet viele Vorteile:

Microservices bieten den Entwicklungsteams eine unvergleichliche Flexibilität, denn sie ermöglichen die Bereitstellung von Updates, ohne dass die gesamte Anwendung ständig neu aufgebaut und gestartet werden muss. In der Tat ist es so, dass die Verwaltung mehrerer Microservices — von denen jeder mit anderen Microservices kommuniziert, um Prozesse abzuschließen — notwendig ist, um das Beste aus Ihrer Investition herauszuholen.

Camunda Platform und die Workflow Engine bieten vollständige Transparenz bei allen Microservices. Geschäftsprozesse werden u. a. durch Berichte effektiv verwaltet. Einige Unternehmen gehen noch einen Schritt weiter und implementieren viele dezentrale Workflow Engines über Microservices hinweg, um die Autonomie ihrer Entwickler zu erhöhen.

• Ermöglicht zustandsübergreifende Persistenz bei Instanzen — vorteilhaft bei lang laufenden Prozessen (z. B. einem mehrstufigen Zahlungsprozess, der Tage oder Wochen dauert)
• Erleichtert es Entwicklern, Geschäftsprozesse zu finden, zu verstehen und zu ändern
• Koordiniert und korreliert Meldungen über Prozesse hinweg und bestimmt die nächsten Schritte
• Kompensiert, wenn Probleme auftreten, indem zuvor abgeschlossene Schritte rückgängig gemacht werden
• Verfolgt die Zeit und handelt/wechselt automatisch in einen anderen Pfad, wenn Nachrichten nicht rechtzeitig eintreffen
• Bietet Entwicklern die Möglichkeit, das Verhalten von Fehlerpfaden zu bestimmen
• Bietet Berichte zum Zustand der Prozessinstanz in Echtzeit

Deployment in Containern

Es ist klar ersichtlich, wie mühsam die Bereitstellung von Tausenden von Microservices werden kann, und hier kommen Container ins Spiel. Mit Containern benötigen Sie nur ein Tool, um mehrere Microservices bereitzustellen. Solange sich der Microservice in einem Container befindet, weiß dieser, was mit dem Service geschehen soll und wie er ausgeführt werden soll.

Teamwork

Die Umstellung von einer monolithischen Architektur auf eine Microservices-Architektur kann für alle Geschäftsbereiche mühsam und zeitaufwendig sein. Und auch wenn die höhere Benutzerfreundlichkeit und geschäftliche Agilität einen Mehrwert schaffen, kann sich der Übergangsprozess als schwierig erweisen. Arbeiten Sie mit den Beteiligten im gesamten Unternehmen zusammen, um die Akzeptanz zu erhöhen und die Benutzer während der Umstellung auf dem Laufenden zu halten.

Lose gekoppelte Microservices

In Microservices-Architekturen müssen Microservices so lose wie möglich gekoppelt sein. Lose gekoppelte Services sind nur minimal von anderen Services abhängig. Sie müssen aber dennoch so stark verknüpft sein, dass sie ihre Funktion gut erfüllen.

Überwachen, Überwachen, Überwachen

Begehen Sie nicht den Fehler „Einrichten und dann vergessen“, wenn es um Microservices geht. Es ist entscheidend, dass Sie die Leistung und Ressourcenverfügbarkeit von Microservices kontinuierlich überwachen. Auf diese Weise können Sie fehlerhafte Ressourcen schnell identifizieren und die Sicherheit erhöhen.

Domain-Driven Design

Eine Designphilosophie, die besagt, dass die Sprache und Struktur des Codes die Geschäftsdomäne widerspiegeln sollten, legt den Schwerpunkt des Produkts auf die Domänenlogik und die Kerndomäne. So entsteht ein kollaborativer Designprozess, der es technischen und fachlichen Experten ermöglicht, miteinander zu kommunizieren und ein Modell zu entwickeln, das Probleme im gesamten Unternehmen löst.

RESTful APIs

Es steht außer Frage, dass APIs eine Voraussetzung für jede Microservices-Architektur sind, damit die einzelnen Services miteinander kommunizieren können. Verwenden Sie RESTful-APIs für die Schnittstellen Ihrer Microservices. Sie basieren auf offenen Netzwerken.