Network, Ingress, Load Balancing Was ist ein Service Mesh?

Die Herausforderungen von Microservice Architekturen

Bekanntlich führen viele Wege nach Rom. Bei der Entwicklung moderner Software-Anwendungen schlagen viele Entwickler aber den gleichen ein – über Microservice-Architekturen. Anders als bei den Software-Monolithen der Vergangenheit wird jede Funktion einer Anwendung bei diesem Ansatz von einem unabhängigen Dienst (Microservice) übernommen. Solche Systeme sind skalierbar, verteilt (Distributed Systems) und robust.

Da jeder Microservice für sich steht, können Entwickler Veränderungen am Source-Code vornehmen oder Dienste skalieren, ohne dass die grundsätzliche Erreichbarkeit und Funktionsfähigkeit von Anwendungen beeinträchtigt wird. Auch die Bereitstellung hat sich verändert und Microservice-Architekturen können verteilt über mehrere Clouds oder Serverlandschaften hinweg betrieben werden – oft auf Basis von Kubernetes oder anderen Container-Verwaltungs-Lösungen.

Die Leistungsfähigkeit solcher Anwendungen ist allerdings wesentlich von der Kommunikation der einzelnen Dienste untereinander abhängig. Alle Microservices müssen sorgsam integriert und die Kommunikation geplant werden. Effiziente Interservicekommunikation ist somit eine Grundvoraussetzung für Microservice-Architekturen.

Die der Anwendung zugrundeliegende Kommunikationslogik muss in jedem einzelnen Microservice definiert werden. Das bedeutet, dass jede Änderung in der Struktur eine große Zahl an Anpassungen nach sich zieht. So erhöhen sich Aufwand und Komplexität, besonders für große und umfangreiche Anwendungen. Ausfälle einzelner Dienste beeinträchtigen dann schnell die Leistungsfähigkeit und Performance. In einer Microservice Umgebung werden womöglich auch unterschiedliche Programmiersprachen genutzt. Was ein Vorteil für Entwickler und Anwendung darstellt, macht das Identifizieren und Beheben von Fehlern aber oft kompliziert und aufwendig. Anstatt sich auf den Geschäftszweck zu fokussieren, verbringen Entwickler dann oft viel Zeit mit Service Discovery und dem Ausmerzen von Fehlern in der Kommunikationslogik.

Ein Service Mesh trennt netzwerkbezogene Logik von Geschäftslogik, indem es die Kommunikation der Microservices untereinander über einen separaten Infrastruktur-Layer steuert.

Was ist ein Service Mesh?

Ein Service Mesh besteht im Kern aus zwei Ebenen, der Datenebene (Data Plane) und der Kontrollebene (Control Plane). Auf der Datenebene werden den Services einer Anwendung Netzwerk-Proxys vorangestellt, die man Sidecar-Proxys nennt. Zu jedem Service gehört jeweils ein Sidecar-Proxy. Die Control Plane liegt über der Datenebene und ist die Schaltzentrale des Service Mesh. Hier ist die eigentliche Informationslogik in Form von Prozessen definiert, die anstehende Aufgaben verwalten und das Verhalten der Sidecar-Proxys und damit letztendlich der Services koordinieren.

Auf diese Weise überwacht und verwaltet das Service Mesh den Netzwerkverkehr zwischen den Microservices einer Anwendung. Anfragen und Zugriffe werden gewährt, eingeschränkt, weiter- oder auch umgeleitet und so die Kommunikation innerhalb des Systems optimiert und geschützt. Außerdem können Sidecar-Proxys auch Aufgaben zugewiesen werden, die von der reinen Inter-Service-Kommunikation losgelöst sind. Beispielsweise das Ausstellen von Zertifikaten.

Welche Vorteile bietet ein Service Mesh?

Besonders für Unternehmen, die verteilte Systeme mit vielen Microservices betreiben, bietet das Service Mesh Vorteile. Mit steigenden Zugriffszahlen werden auch die, zwischen den Diensten laufenden Anfragen exponentiell höher, was effizientes Routing erfordert. Die Verwendung eines Service Mesh bringt aber noch viele weitere Vorteile mit sich. Einige wollen wir euch im Folgenden vorstellen:

Service discovery: damit Microservices und Anwendungen miteinander kommunizieren können, werden deren Standorte vom Service Mesh automatisch lokalisiert. In Internal-Registries werden alle Services mit ihren Endpoints katalogisiert. Wird ein neuer Service bereitgestellt, wird dieser automatisch im Register hinterlegt.

Traffic management: Werden mehrere Instanzen eines Microservice an unterschiedlichen Standorten betrieben, kann der Traffic zu den Diensten per Service Mesh unkompliziert verteilt werden. Für anspruchsvollere Deployment- und Update-Strategien, bei denen Verfügbarkeits-Unterbrechungen vermieden werden müssen (z.B. Green/Blue-Deployment) bietet ein Service Mesh außerdem viele Optionen.

Security & Policies management: Security Policys können über ein Service Mesh in kürzester Zeit, einheitlich für alle Microservices einer Anwendung, bereitgestellt werden. Während in einem herkömmlichen Cluster die Dienste oft ungesichert kommunizieren, bietet ein Service Mesh viele Möglichkeiten für die Absicherung und Verschlüsselung cluster-interner Kommunikation sowie der einzelnen Netzwerkebenen.

Observability: Telemetry & Metrics: Service Mesh-Technologien machen es einfach, die kritischen Metriken verteilter Systeme zu erfassen (Latenz, Traffic, Fehler, Auslastung, usw.), indem sie auf Backend-Prozesse und Webserver-Hardware zugreifen und so eine detailliertere Echtzeit-Überwachung und Analyse der Netzaktivitäten ermöglichen. Außerdem lassen sich Metriken über APIs einfach an externe Tools exportieren.

Fazit

Ein Service Mesh lagert die Kommunikation zwischen den Microservices einer Anwendung in eine konfigurierbare Infrastrukturebene aus. Netzwerkverkehr kann verwaltet und überwacht werden und über die Beschränkung von Zugriffen können Systeme abgesichert werden.

Durch die Verwendung eines Service Mesh können Sie verbessertes Monitoring, Sicherheit sowie granulare Kontrolle des Netzwerkverkehrs erreichen. Außerdem kann es die Anwendungsverwaltung vereinfachen und das Hinzufügen oder Entfernen von Microservices zu einer Anwendung ohne Auswirkung auf den Rest des Systems ermöglichen.

Die Konfiguration eines Service Mesh bringt allerdings ganz eigene Herausforderungen mit sich. Für Unternehmen, die kleinteilige Anwendungen betreiben, ist ein Service Mesh nicht zwingend erforderlich. Für umfangreiche Anwendungen und solche, die es einmal werden sollen, ist jedoch anzuraten, rechtzeitig Zeit und Geld in die Entwicklung eines Service Mesh zu investieren.