How-To

Microservices: Mit Service-Meshes den Überblick behalten

(Abbildung: Shutterstock / ayzek)

Je stärker eine Anwendung aus Microservices besteht, desto flexibler und leichter ist sie in der Theorie zu warten. In der Praxis steigen aber die Anforderungen an Übersicht und Sicherheit. Service-Meshes können Ordnung ins Komponentenchaos bringen.

Während monolithische Applikationen die Tanker der Software­welt sind, gleichen modulare Anwendungen eher einer Armada schneller, wendiger Motorboote. Kein Wunder also, dass immer mehr Systeme aus immer kleineren Komponenten bestehen – die sogenannten Microservices. Die Vorteile: Entwickler können dadurch die Entwicklung, das Testing und das Deployment ­eines Systems unabhängig voneinander durchführen. Außerdem lässt sich wenig Code besser überblicken und warten. Fällt eine ­Komponente aus, ist im Idealfall nur eine einzelne Funktionalität betroffen.

So jedenfalls die Theorie. In der Praxis haben diese mehr oder weniger klassisch verteilten Anwendungen auch Nachteile. Wenn einzelne Teile ausfallen oder – schlimmer noch – nur noch teilweise funktionieren, betrifft das oft eben doch das ganze System. Das hat zu neuen Anforderungen an die Softwarearchitektur, die Steuerung eines Netzwerks und das Monitoring geführt.

Cloud Native

Anwendungen, die konsequent auf Microservices und eine Cloud-­Infrastruktur setzen, bezeichnet die Fachwelt auch als „Cloud Native“. Solche Applikationen setzen konsequent auf die Infrastrukurvorteile der Cloud-Architektur. Container und Containermanager wie ­Kubernetes sorgen dabei für Ordnung in der Welt der Microservices. Dadurch können Entwicklerteams nicht nur die Entwicklung der Applikationen, des CI und CD sowie die ­Nutzer- oder Rollenkonzepte harmonisieren. Auch optimieren sie die Kommunikation der verschiedenen Module einer Applikation miteinander.

Als Plattform ist Kubernetes quasi zum Standard für die Verwaltung von Applikationen in einem Cluster geworden. Es macht im Wesentlichen nichts anderes, als Container zu starten, zu überwachen, gegebenenfalls wieder zu beenden und mit einem Cluster von Knoten zu arbeiten. Dabei sorgt es auch für eine Vernetzung der ­Container. Die kleinste Einheit ist allerdings kein Container, sondern ein Pod – also ein Behälter für einen oder mehrere Container. Die Container eines Pods teilen sich ­Ressourcen wie Volumes oder die IP-Adresse. Dies ermöglicht einige interessante Optionen, um Applikationen zu modularisieren: Ähnlich wie bei den aus der OOP bekannten Patterns gibt es hier sogenannte Container-Patterns. Dieses Konzept machen sich auch die Service-Meshes zunutze.

Was ist ein Service-Mesh?

Service-Meshes sind steuerbare Komponenten, die sich zwischen die Service-zu-Service-Kommunikation einer Applikation schalten. Dies muss nicht zwangsläufig in einem Kubernetes ­Cluster passieren, ist dort aber besonders einfach. Service-­Meshes ­nutzen dazu die Tatsache, dass sich Pods mithilfe gängiger ­Container-Patterns flexibel erweitern lassen. Dies kann etwa in Form eines Sidecars geschehen, was ein zusätzlicher Container in einem Pod ist, der als Proxy dient. Der Proxy kann als Teil eines Service-Meshs die gesamte Kommunikation kontrollieren und lässt sich durch ein sogenanntes Control Plane steuern. Dadurch kann ein Service-Mesh folgende Fragen beantworten:

  • Wer spricht mit wem?
  • Wie lässt sich die Kommunikation notfalls einschränken?
  • Wie lässt sich die Kommunikation wechselseitig ­verschlüsseln?
  • Welche Kette an Services ist an einer bestimmten ­Transaktion beteiligt?
  • Wie lässt sich der Traffic feingranular steuern?
  • Wie lässt sich zum Beispiel die Bereitstellung von der ­Inbetriebnahme trennen?
  • Wie lässt sich die Widerstandsfähigkeit der Applikation erhöhen?

Dazu nutzt ein Service-Mesh eine Reihe von Maßnahmen wie ­automatisches Monitoring, Traffic-Management oder ­Multi­cluster. Im Folgenden gibt es einen Überblick über die wichtigsten Maßnahmen:

Automatisches Monitoring

Ein Service-Mesh kann die gesamte Kommunikation über die ­Proxies in einem Monitoring-System wie Prometheus protokollieren. Dadurch lässt sich beispielsweise auswerten, wie, wann oder mit welcher Latenz die Services miteinander kommunizieren. Es ist oft wertvoll, zu wissen, welche Services im realen Umfeld überhaupt miteinander kommunizieren. Alleine aus dem, was ­deployed ist, können Entwickler das als eine Art ­statische ­Analyse schlecht erkennen. Ebenso interessant ist es für Entwickler zu sehen, welche Fehler es bei der Kommunikation gibt, wie hoch die Fehlerrate ist und welche Services die Ursache dafür sind. Und schließlich hilft Entwicklern ein schneller und einfacher Überblick über die Durchlaufzeiten und die beteiligten Services einer komplexen Transaktion, die durch mehrere unterschiedliche Services ausgeführt wird.

Traffic-Management

Kubernetes regelt den Zugriff auf Pods durch sogenannte Service­ressourcen. Dabei lassen sich im wesentlichen nur Rundlauf­verfahren (Round Robin) anwenden, bei denen die Prozesse in einer Warteschlange nacheinander ablaufen. Der prozentuale Anteil des Traffics ist somit durch die Anzahl der Instanzen eines Deployments bestimmt. Eine freie Steuerung des Traffics – etwa auf Basis von Nutzernamen oder Herkunft – ist nicht möglich. Ein Service-Mesh bietet hier wesentlich mehr Möglichkeiten.
Sicherheitsmaßnahmen

Die Aufteilung einer monolithischen Applikation in einzelne ­Services – die über Netzwerke und nicht in einem einzelnen Prozess miteinander kommunizieren – bringen auch andere Anforderungen an die Sicherheit mit sich. Um sich zum Beispiel gegen einen Man-in-the-Middle-Angriff zu schützen, bei dem der Angreifer zwischen zwei Kommunikationspartnern steht, muss die Kommunikation verschlüsselt sein. Das gilt besonders, wenn Entwickler einem Netzwerk nicht trauen können. Darüber hinaus sind anpassbare Richtlinien für die Zugriffe und eine flexible Zugangskontrolle notwendig. Dazu gehört zum Beispiel Mutual TLS, mit dem sich Dienste gleichzeitig gegenseitig authentifizieren können. Wer prüfen möchte, wer was zu welchem Zeitpunkt getan hat, benötigt außerdem Audit-Werkzeuge.

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Ein Kommentar
teek
teek

Imho ist eine API basierte Microservice Architektur kaum besser als in den 90ern die DLLs mitt ihrer berüchtigten Hölle. Der sinnvollste Weg kann es lt Erfahrung also nicht sein, dies besser zu managen, sondern durch andere Architekturen zu vermeiden. Beispiel: Event driven architecture

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung