Microservices vs. APIs: Was ist der Unterschied?

Microservices vs. APIs: Was ist der Unterschied?

  • ITOps & DevOps
6 Minuten Lesezeit Aktualisiert Dec 16, 2020

Auf einen Blick: Microservices sind einzelne Dienste, die APIs für die Kommunikation nutzen und so ein besseres Softwaremanagement und Skalierbarkeit ermöglichen. Sie ermöglichen es Anwendungen, über kleinere, fokussierte Komponenten zu funktionieren, während APIs als Schnittstelle für diese Dienste dienen und Interaktion und Zugänglichkeit ermöglichen.

  • Microservices verbessern das Softwaredesign, indem sie Funktionen dezentralisieren.
  • APIs sind unerlässlich, damit Mikroservices effektiv interagieren können.

Ein Microservice ist ein kleiner, einzelner Dienst, der von einem Unternehmen angeboten wird. Er entsteht aus der verteilten Rechenarchitektur, die viele kleine Dienste verbindet, anstatt einen großen Dienst zu haben. Der Microservice kann dann über eine Application Programming Interface (API) bereitgestellt werden. Eine API ist eine Kommunikationsmethode zwischen einem Anforder und einem Host, meist zugänglich über eine IP-Adresse. Die API kann verschiedene Arten von Informationen an Nutzer kommunizieren, wie zum Beispiel:

  • Daten, die du teilen möchtest
  • Eine Funktion, die du bereitstellen möchtest

Kurz gesagt, die Diskussion über einen Microservice hat mehr mit der Architektur der Software zu tun, und die API hat damit zu tun, wie der Microservice dem Verbraucher zugänglich gemacht wird.

Wie Microservices funktionieren

Microservices ergeben sich aus der Vorstellung, dass ein Unternehmen einen großen, einzigen Service anbietet. Microservices entstehen als einzelne Funktionen. Wenn Microsoft Word in Microservices aufgeteilt würde, gäbe es vielleicht einen als leeres Blatt Papier, einen als Rechtschreibprüfung und einen Service als Formatierungswerkzeug. Kubernetes hat es Computersoftware ermöglicht, sich anzupassen. Obwohl Kubernetes seine eigenen Vorteile hat, hat es das Softwaredesign auch von einem einzigen Monolithen von Diensten wegbewegt – hin zu einer Kombination vieler kleiner Services, die zusammenarbeiten. Das liegt am Kubernetes-Design, das kann:

  • Orchestrieren Sie effizient den Einsatz einzelner Container auf Servern
  • Erhöhung der Systemzuverlässigkeit und Skalierbarkeit
  • Verringerung der damit verbundenen Verwaltungs- und Ressourcenkosten
Monolith-Architektur
Verteilte Mikrodienste

(Erfahren Sie mehr über Microservice vs. Monolith-Architektur.)

Beispiele für Microservices

Microservices sind sehr einfach. Einfachheit ist ein Hauptziel. Sie können als Rollen in einem Unternehmen betrachtet werden; ein Microservice erfüllt eine ganz bestimmte Rolle und hat nur eine Aufgabe zu erfüllen. DZone hat eine ausgezeichnete Grafik verschiedener Microservices erstellt, die Uber anbietet, kommunizieren miteinander über APIs und führen verschiedene Aufgaben aus. Uber entwickelt für jede Aufgabe unterschiedliche Services:

  • Fahrgastverwaltung
  • Passagier-Web-UI
  • Abrechnung
  • Fahrermanagement
  • Treiber-Web-UI
  • Zahlung
  • Reisemanagement
  • Benachrichtigungen

(Quelle)

Microservices können auch durch Graphen illustriert werden, bei denen ein Microservice ein einzelner Knoten ist, der über eine API mit einem anderen Dienst kommuniziert. Die Architektur kann wachsen und wachsen, je mehr Services an das System angehängt werden. Wie Sie sich vorstellen können, können die Grafiken der großen Unternehmen umfangreich sein, wie eine kleine Stadt. Hier sind die angeblichen Grafiken von Amazon und Netflix:

(Quelle)

Microservices basieren auf APIs

Die API ist ein Kommunikationswerkzeug – sie ermöglicht es einem Dienst, mit einem anderen zu interagieren. Eine API selbst kann nichts tun, es sei denn, sie ist mit etwas verbunden, wie einem Handy, das einfach dort steht. Die API wird nützlich, wenn sie mit Diensten und Microservices verbunden ist, wie zum Beispiel:

Die API ist die Möglichkeit, den Microservice an die Nutzer zu verteilen. Anstatt Software herunterzuladen oder eine Disc einzubauen, verteilt die API deinen Service. Die API ist notwendig, damit die Microservice-Architektur funktioniert, weil die API das Kommunikationswerkzeug zwischen ihren Diensten ist. Ohne eine API gäbe es viele nicht zusammenhängende Microservices. Technisch gesehen würde der Microservice einfach wieder zu einem Monolithen werden.

Wie APIs funktionieren

APIs sind äußerst vielseitig. Sie können:

APIs können sowohl die Benutzerfreundlichkeit als auch die Sichtbarkeit Ihres Dienstes erhöhen. Mit der viel einfacheren Verteilung können Sie kleinere Dienste anbieten. (Schließlich müssen Sie nicht eine komplette Adobe-Suite bauen, nur um die Viabilität zu beweisen). Viele APIs sind RESTful-fähig und über einen Endpunkt wie einen HTTP-Endpunkt zugänglich. Das bedeutet, dass der Zugriff auf Informationen aus einer API so einfach ist wie das Pingen einer URL. GET, POST, PUT, DELETE-Befehle funktionieren in Verbindung mit der URL wie erwartet, indem sie Daten abrufen oder Daten an die API geben. Obwohl REST-APIs in modernen Webanwendungen am häufigsten verwendet werden, gehören weitere Optionen:

Als Produkt wird der API-Endpunkt üblicherweise zusammen mit einem Entwicklerportal bereitgestellt, das Entwicklern erklärt, wie sie es verwenden sollen, und den Entwicklern einen API-Schlüssel zuweist. Wenn das Ziel eines Microservices darin besteht, Daten zu den registrierten Fahrzeugen in einem bestimmten Landkreis bereitzustellen, erklärt das Entwicklerportal:

  • Was der Service macht
  • Wie die Daten strukturiert sind (d. h. ein Datenschema)
  • Was ist erforderlich, damit ein Entwickler die API nutzen kann

Microservices vs. APIs

Die meisten guten Microservices haben irgendeine Art von API. Wenn du möchtest, dass dein Microservice genutzt wird, wirst du eine API erstellen. Die API ist für Entwickler das, was ein Social-Media-Konto für Künstler und Creator bedeutet. Wenn du möchtest, dass die Leute es nutzen, nutzt du eine API, damit sie es empfangen können.

Verwandte Literatur

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.

Mehr aus ITOps & DevOps

Interessieren Sie sich für mehr von BMC?

The Brief ist unsere monatliche E-Mail zum Mainframe und zur Enterprise-Orchestrierung: Recherchen, Kundenberichte, Produktnachrichten, Events.

Mit der Registrierung für dieses Angebot bestätigen Sie, dass Sie die Datenschutzrichtlinie von BMC gelesen und zugestimmt haben.

Sie haben The Brief abonniert

Das Briefing umfasst die Mainframe- und Enterprise-Orchestrierung – BMC AMI und Control-M – sowie die Analystenforschung, Kundeneinsätze und Events in beiden Bereichen.