Microservices

Wie Microservices funktionieren

In einer Microservices-Architektur unterteilen Entwickler eine Anwendung in Dienste. Jeder Dienst führt einen eigenen Prozess aus und verwaltet normalerweise seine eigene Datenbank. Ein Dienst kann Warnmeldungen generieren, Daten protokollieren, Benutzeroberflächen (UIs) unterstützen, die Benutzeridentifizierung oder -authentifizierung übernehmen und verschiedene andere Aufgaben erfüllen.

Das Paradigma der Microservices bietet Entwicklern einen dezentralen Ansatz für das Erstellen von Software. Jeder Dienst kann isoliert, neu aufgebaut, neu bereitgestellt und unabhängig verwaltet werden. Wenn zum Beispiel ein Programm nicht ordnungsgemäß Berichte erstellt, verfolgen die IT-Mitarbeiter das Problem zu einem bestimmten Dienst zurück und überarbeiten diesen Dienst unabhängig von anderen Diensten, testen ihn, starten ihn neu, patchen ihn und stellen ihn neu bereit, wenn dies erforderlich ist.

Vorteile einer Microservices-Architektur

Microservices-Designs und -Bereitstellungen haben dank der Cloud, der Containerisierung und der hypervernetzten Systeme zugenommen. Für Softwareentwickler bringen Microservices jedoch eine Reihe von Kompromissen mit sich.

Was die Vorteile angeht, so können Microservices:

• mit verschiedenen Sprachen und Tools entwickelt und bereitgestellt werden;
• die Entwicklungszeit verkürzen;
• schnell skaliert werden;
• in verschiedenen Projekten wiederverwendet werden;
• die Fehlerisolierung erleichtern;
• sind schneller und weit weniger ressourcenintensiv in der Bereitstellung und im Lastausgleich;
• in relativ kleinen Teams eingesetzt werden und
• Container praktisch verknüpfen.

Herausforderungen einer Microservices-Architektur

Es gibt jedoch auch Nachteile von Microservices, wie zum Beispiel:

• Komplexität durch eine zu kleinteilige Aufteilung;
• zusätzlicher Aufwand bei der Entwicklung der Kommunikation zwischen den Diensten
• komplexe Tests;
• Latenzzeiten bei intensiver Nutzung;
• zusätzliche Verwaltung und Kontrolle; und
• umfassende Sicherheit.

Merkmale einer Microservices-Architektur und -Design

Die Microservices-Architektur besteht aus eigenständigen Komponenten und Diensten, deren Kommunikation und Datenaustausch zusammen die Funktionen einer kompletten Anwendung bilden. Typische Merkmale eines Designs und einer Architektur für Microservices sind unter anderem folgende

• Entwurf und Bereitstellung von Diensten, um eine bestimmte Funktion zu erfüllen oder eine bestimmte Anforderung zu erfüllen.
• Idealerweise haben Dienste nur wenige oder gar keine Abhängigkeiten, wobei die lose Kopplung eine häufige und umfangreiche Kommunikation erfordert.
• Widerstandsfähig. Entwerfen Sie Dienste für maximale Fehlertoleranz. Ein einziger Dienstausfall sollte nicht die gesamte Anwendung lahmlegen.
• Viele APIs. Eine Microservices-Architektur stützt sich stark auf APIs und API-Gateways, um die Kommunikation zu erleichtern.
• Im Idealfall greift jeder Dienst auf seine eigene Datenbank oder seinen eigenen Speicherplatz zu.

Microservices versus monolithische Architektur

In einer monolithischen Architektur befindet sich der gesamte Code in einer einzigen ausführbaren Hauptdatei. Das kann die Fehlersuche, das Testen und die Aktualisierung erschweren, da ein Problem in der Codebasis überall in der Software auftreten kann. Aufgrund der Menge des monolithischen Codes sind mehr und längere Tests erforderlich. Außerdem erfordert jede kleine Änderung oder Aktualisierung in einer monolithischen Anwendung, dass ein Unternehmen eine völlig neue Version der Anwendung erstellt und einsetzt. Insgesamt ist die Entwicklung monolithischer Anwendungen mit einem erheblichen Planungs-, Vorbereitungs-, Zeit- und Kostenaufwand verbunden.

Microservices-Architekturen bieten im Vergleich zu monolithischen Software-Architekturen eine schnellere Software-Entwicklung und -Bereitstellung, was die geschäftliche Agilität erhöht. Microservices erleichtern das Testen und Bereitstellen von Änderungen. Das Trennen von Diensten verbessert die Fehlerisolierung – wenn ein Problem in der Software auftritt, kann der fehlerhafte Dienst isoliert, behoben, getestet und erneut bereitgestellt werden, ohne dass die gesamte Anwendung einem Regressionstest unterzogen werden muss, wie dies bei herkömmlichen monolithischen Anwendungsarchitekturen der Fall ist.

Monolithische Anwendungen lassen sich nur schwer skalieren. Wenn eine monolithische Anwendung eine Kapazitätsgrenze erreicht, zum Beispiel beim Datendurchsatz oder einem anderen Engpass, besteht die einzige praktische Option darin, eine weitere vollständige Iteration der gesamten monolithischen Anwendung bereitzustellen und den Datenverkehr zwischen den Instanzen über Load Balancern zu verwalten.

Im Vergleich dazu skaliert man eine Microservices-Anwendung, indem man Container-Instanzen für die Dienste hinzufügt, die gegenwärtig überstrapaziert sind. Dadurch ist die Skalierung von Microservices wesentlich ressourceneffizienter als das Skalieren von Anwendungen mit einer monolithischen Architektur.

Microservices sind jedoch nicht verwaltungsfrei. Eine Microservices-Architektur trennt jeden Dienst von den anderen, und es kann schwierig sein, alle Teile des Ganzen zu verwalten. So ist beispielsweise eine sorgfältige Überwachung und Verwaltung erforderlich, um die Verfügbarkeit und Leistung aller Komponentendienste innerhalb einer Microservices-Anwendung zu überwachen.

Microservices und DevOps

DevOps kombiniert Aufgaben zwischen Anwendungs- und Systembetriebsteams. Die verstärkte Kommunikation zwischen Entwicklern und Betriebsmitarbeitern ermöglicht es einem IT-Team, die Infrastruktur besser zu erstellen und zu verwalten. Der IT-Betrieb budgetiert Kapazitäten, Betriebsaufgaben, Upgrades und mehr. Entwickler und Anwendungsteams können die in der Produktion verwendeten Datenbanken, Server, Software und Hardware verwalten.

Die Unterstützung des Lebenszyklus von Microservices erfordert Teamwork und Zusammenarbeit zwischen Entwicklungs- und Betriebsteams, was der Arbeitsweise von DevOps-Teams entgegenkommt. Erfahrene DevOps-Teams sind gut gerüstet, um Microservices-Architekturen in Softwareentwicklungsprojekten einzusetzen.

Microservices-Architektur versus SOA

SOA ist eine Softwarearchitektur, bei der jeder der Dienste Protokolle verwendet. Das ermöglicht es den Benutzern, Funktionen zu kombinieren und Anwendungen zu bilden, die aus früheren Diensten zusammengesetzt sind. SOA ist seit fast zwei Jahrzehnten eine Standardentwicklungspraxis. Der Einfallsreichtum von SOA stößt jedoch beim Cloud Computing an seine Grenzen: Es mangelt an Skalierbarkeit und verlangsamt sich bei Änderungen von Arbeitsanforderungen, was die Anwendungsentwicklung einschränkt.

Befürworter des SOA-Modells sind der Meinung, dass die Microservices-Architektur die natürliche Weiterentwicklung von SOA ist, um Cloud Computing zu ermöglichen und den steigenden Anforderungen an schnellere Softwareentwicklungszyklen gerecht zu werden.

Andere sind der Meinung, dass Microservices einen plattformunabhängigeren Ansatz für die Anwendungsentwicklung darstellen und daher einen eigenen Namen haben sollten. Dafür spricht, dass SOA in den Schichten des Microservices-Managements weiterlebt.

Microservices und Container

Ein Container ist ein ausführbares Softwarepaket, das alle Abhängigkeiten enthält, die für ein unabhängiges Funktionieren erforderlich sind. Container sind vom Rest der sie umgebenden Software getrennt, und es können viele Container in derselben Umgebung eingesetzt werden. In einer Microservices-Architektur wird jeder Dienst einzeln in der gleichen Umgebung containerisiert, zum Beispiel auf den gleichen oder verwandten Servern.

Eine virtuelle Maschine (VM) kann als Alternative zu Containern verwendet werden, um Microservices zu erstellen. Eine VM simuliert Computersysteme, um Funktionalitäten eines physischen Computers zu erzeugen. Jeder Dienst könnte potenziell eine VM nutzen, um eine bestimmte Funktion zu hosten. VMs sind jedoch in der Regel nicht ideal für Microservices, da jeder Dienst ein eigenes Betriebssystem und anderen Overhead benötigt. Container sind wesentlich ressourceneffizienter, da sie nur den zugrunde liegenden Code und die damit verbundenen Abhängigkeiten für den Betrieb des Dienstes benötigen.

Sicherheit von Microservices

Eine Microservices-Architektur kann einige Sicherheitsprobleme abmildern, die bei monolithischen Anwendungen auftreten. Microservices vereinfachen die Sicherheitsüberwachung, da die verschiedenen Teile einer Anwendung isoliert sind. Ein Sicherheitsverstoß kann in einem Bereich auftreten, ohne andere Bereiche des Projekts zu beeinträchtigen. Microservices bieten Widerstand gegen verteilte Denial-of-Service-Angriffe, wenn sie mit Containern verwendet werden, indem sie eine Übernahme der Infrastruktur durch zu viele Serveranfragen eingrenzen.

Microservices können sich aber auch negativ auf die Sicherheit auswirken:

• Mehr Netzwerkbereiche sind für Schwachstellen anfällig.
• Eine geringere Gesamtkonsistenz zwischen App-Updates ermöglicht mehr Sicherheitsverletzungen.
• Es gibt eine größere Angriffsfläche durch mehr Ports und APIs.
• Es ist nicht möglich, Softwareteile von Drittanbietern zu kontrollieren.
• Die Sicherheit muss für jeden Dienst aufrechterhalten werden.

Entwickler von Microservices haben proaktive Strategien entwickelt, um Sicherheitsprobleme zu vermeiden. Verwenden Sie einen Sicherheitsscanner, nutzen Sie Zugangskontrollbeschränkungen, sichern Sie interne Netzwerke einschließlich Docker-Umgebungen und arbeiten Sie außerhalb von Silos, um mit allen Teilen des Betriebs zu kommunizieren.

Bereitstellung von Microservices-Anwendungen

Drei Hauptfaktoren machen Microservices zu einer praktikablen Software-Architektur.

Container ermöglichen eine konsistente und ressourceneffiziente Paketierung einzelner Dienste. Docker ist ein beliebtes Tool für Container oder in einer Public oder Private Cloud. Es bietet eine Vielzahl von Bereitstellungsalternativen für Microservices-Entwickler und Unternehmen.

Orchestrierungswerkzeuge wie Kubernetes helfen bei der Automatisierung von Skalierung, Bereitstellung und Containerverwaltung.

Service Mesh ist eine Infrastrukturebene für die Kommunikation zwischen einzelnen Diensten. Wenn Hunderte von Diensten miteinander kommunizieren, wird es kompliziert zu bestimmen, welche Dienste miteinander interagieren. Service Mesh macht diese Kommunikation schneller, sicherer, sichtbarer und zuverlässiger, indem es das Verhalten erfasst

Das Dienstnetz ist eine Infrastrukturebene für die Kommunikation zwischen einzelnen Diensten. Wenn Hunderte von Diensten miteinander kommunizieren, wird es kompliziert zu bestimmen, welche Dienste miteinander interagieren. Service Mesh macht diese Kommunikation schneller, sicherer, sichtbarer und zuverlässiger, indem es Verhaltensweisen wie den latenzbewussten Lastausgleich oder die Diensterkennung erfasst.

Verbesserungen bei diesen und anderen Technologien, wie zum Beispiel komplexes Monitoring und Logging, haben die Komplexität von Microservices stetig reduziert und die Akzeptanz bei Unternehmen und Entwicklungsteams weiter gefördert.

Tools für die Bereitstellung von Microservices-Anwendungen

Dank der Synergie mit APIs, Containern und kontinuierlichen Entwicklungsprozessen können Microservices viele der gleichen Tools für Design, Test, Bereitstellung und Verwaltung nutzen.

Kubernetes ist der De-facto-Standard für die Container-basierte Orchestrierung, unabhängig davon, ob ein Unternehmen dies in seinen eigenen lokalen Umgebungen oder über einen Cloud-basierten Dienst verwendet. Weitere Orchestrierungs-Tools sind Docker Swarm und Compose sowie HashiCorp Nomad. Service-Meshes wie Linkerd und Istio werden ebenfalls häufig zusammen mit Microservices verwendet. Große Cloud-Anbieter bieten zusätzliche Dienste an, um die Verwaltung von Microservices zu unterstützen.

Unternehmen wählen aus einer breiten Palette anderer Tools, die das Testen, die Bereitstellung, die Überwachung und die Verwaltung von Microservice-Umgebungen umfassen. Beispiele für Tools, welche die Bereiche des Testens abdecken, sind Gatling, Hoverfly, Jaeger, Pact, Vagrant, VCR und WireMock.

Die Überwachung und Verwaltung von Microservices kann eine besondere Herausforderung darstellen, da jede Servicekomponente einer Anwendung und ihre Interaktionen verfolgt und gepflegt werden müssen. Zu diesen Funktionen gehören Observability, Fehlererkennung und das Sammeln von Metriken aus Protokollen, um Leistungs- und Stabilitätsprobleme zu erkennen. Beispiele für Überwachungstools sind Sentry, Sensu und Sumo Logic. Zu den Tools für die Protokollaggregation gehören Fluentd, Logstash, Ryslog und Loggly. Für die Visualisierung von Protokollen gibt es Tools wie Scalyr, Graylog, Kibana und Sematext.