top of page

Interact: ServiceMesh und MultiCloud demystified - Teil2

Im letzten Blog Post zum Thema ServiceMesh und ServiceDiscovery wurden die Grundlagen dieser Themtik beschrieben.


Die wesentlichen, technischen Herausforderungen sind hier noch einmal aufgelistet:

  • Service Discovery - Wie finden sich die Services?

  • Sicherheit (Security) - Welcher Service darf mit welchem sprechen (über sicheres mTLS)?

  • Routing - Wie wird zu den einzelnen Services geroutet?

  • Resilienz - Wie kann die Widerstandsfähigkeit eines Softwaresystems mit Mitteln der Infrastruktur verbessert werden (bspw. circuit breaker)?

Was ist ein ServiceMesh?


Dieser Abschnitt erklärt die grundlegenden, fundamentalen Komponenten und deren Funktionsweise im Service Mesh.


Control Plane


Die zentrale Control Plane eines Service Mesh hat folgende Aufgaben:


  • Service Discovery und Service Catalog

  • Autorisierung und Konfiguration der Proxies der Data Plane.

Data Plane


Die verteilte Data-Plane ist für die Verbindung und das Routing zwischen den Services zuständig.




















Funktionsweise 


  • Ein Proxy wird zusammen mit der Service-Instanz platziert, welcher den eingehenden Verkehr regelt (SideCar)


  • Der Client-Agent instanziert den Proxy und registriert ihn als Service


  • Der Proxy wird mit einem Port konfiguriert, der für den Dienst verwendet wird, sowie mit Ports für alle Upstream-Ziele, mit denen der Dienst eine Verbindung herstellen möchte.


Anmerkung: Es gibt auch ServiceMesh Implementierungen, welche ohne einen sog. SideCar-Proxy auskommen. In manchen Umgebungen kann dies ein valider und sinnvoller Ansatz sein - wir sehen in unseren Projekten hinsichtlich der Anforderungen an Multi-Plattform, Security & Governance sowie Compliance (z.B. ein Cert der eigenen CA für jeden Service) den SideCar-Ansatz jedoch in der Regel als den passendstem.


Service Discovery


Erklärung von "Service Discovery" - also wie finden Services zueinander - an Hand eines simplen Beispiels mit 2 Services: "web" und "db":


  • Der Proxy des Service “web”  verwendet die den Namen des Service “db”, um den Standort der DB abzufragen


  • Der lokale Agent gibt dem Proxy die IP-Adresse/Port einer gesunden DB-Instanz zurück.





Security


Wie war es früher (und oftmals heute noch)?


Firewalls regeln auf Basis von IP und Ports welche Kommunikation (Traffic Pattern) erlaubt ist:





Wie könnte es für ein Service Mesh aussehen?


In dynamischen Multi-Plattform oder Multi-Cloud Umgebungen wird die Pflege von Firewall-Regeln (ACL) zu einer nahezu unmöglichen Aufgabe. Von der Herausforderung “East-West” vs. “North-South” Traffic einmal ganz abgesehen:






Besser: Service Based Security - Intentions


Über einen Service Graphen wird geregelt, welcher Service mit welchem anderen Service kommunizieren darf. Unabhängig wo diese Services betrieben werden. Es wird die Identität eines Services verifiziert (dazu ist eine hochgradig automatisierte TLS CA in ein Mesh integriert - Basis: SPIFFE).






Best-Practice Tipp: HashiCorp Vault kann eine (eigene) und hochgradig automatisierte CA für das ServiceMesh darstellen.

Diese Berechtigungen bezeichnet man als "Intention". Sie kann bis auf die Semantik von OSI Layer 7 (z.B. einem API Call) parametrisiert werden.


Service Based Security


  1. Der lokale Agent gibt auch den URI für die erwartete Identität des Dienstes zurück, mit dem er verbunden ist.

  2. Proxies zwischen Web und Datenbank starten TLS-Handshake zur Authentifizierung der Identität.






  1. Der DB-Proxy sendet die Authorisierungsanfrage an seinen lokalen Agenten.

  2. Der lokale Agent autorisiert die Verbindung auf der Grundlage der lokal zwischengespeicherten Intention.

  3. mTLS wird aufgebaut





Routing


Multi Plattform


Die zentralen Herausforderungen sind


  • Überlappende IP Ranges

  • Mix / Integration von Kubernetes mit VM oder Bare-Metal Workloads

  • Security (nicht alle Ports öffnen müssen, etc.)





Multi Cloud


Wie zu Beginn bereits erwähnt, ist Multi Cloud Networking noch härter… 


Direct Connect, Express Route, BGP und dann noch ein VPN darüber?
Wirklich? Eher nicht!

Dieses Thema behandeln wir in einem der folgenden Blog Posts, da die Komplexität und der Umfang dieses Bereichs diesen Artikel sprengen würde.


Resilienz


Jede Kette ist nur so stark wie ihr schwächstes Glied

Dieses weitbekannte Zitat gilt natürlich auch für Software Systeme. Im schlimmsten Fall kann ein Teilsystem zum Ausfall des gesamten Systems führen, wenn nicht entsprechende Maßnahmen bereits im Vorfeld getroffen wurden.


Bevor Service Meshes populär wurden, konnten Entwickler mit unterschiedlichen Frameworks Maßnahmen treffen. Eines der wohl bekanntesten Beispiele war Hystrix welches jedoch nicht mehr aktiv weiter entwickelt wird. Je nach Framework können unterschiedliche Resilienzpatterns wie Retries, Fallbacks oder Circuit Breaker imTeilsystem berücksichtigt werden (konfigurativ oder programmatisch).


Das der ausschließliche Einsatz eines Frameworks bereits die Resilienz des Gesamtsystems erhöht kann jedoch ein Trugschluss sein. Ist nur ein Teilsystem nicht entsprechend konfiguriert, kann dies die Maßnahmen die in den anderen Teilsystemen getroffen wurden wirkungslos machen.


An dieser Stelle kommt nun ein Service Mesh ins Spiel. Viele Resilienzpatterns sind unter anderem aus dem genannten Grund in der Infrastruktur sinnvoller angesiedelt. Die so konfigurierten Maßnahmen sind transparent für die Teilsysteme und können unabhängig von diesen parametriert werden. Daraus ergibt sich der weitere Vorteil, dass Anpassungen an den Resilienzpattern flexibler und unabhängig von Applikationsreleases durchgeführt werden können.


Sind durch den Einsatz eines Service Mesh die Frameworks nun obsolet geworden? Diese Frage kann klar mit Nein beantwortet werden. Manche Patterns können nämlich nicht auf sinnvolle Art und Weise auf Infrastrukturebene zur Verfügung gestellt werden. Das klassische Beispiel dazu sind Fallbacks, da es sich bei der Entscheidung über den konkreten Fallback in der Regel um eine fachliche Entscheidung handelt, die im Applikationscode berücksichtigt wird.


Die Empfehlung ist daher, sämtliche Resilienzpatterns die besser auf Infrasturkturebene aufgehoben sind, auch genau dort zur Verfügung zu stellen. Bei Patterns die besser im Teilsystem direkt implementiert werden, sollte darauf geachtet werden das auf standardisierte Frameworks - wie beispielsweise MicroProfile Fault Tolerance - im Java-Fall - gesetzt wird.


Abschliessend wollen wir ein Summary geben und Fazit ziehen:


Warum Service Mesh - und warum Consul?


Warum entwickeln wir uns  hin zu nativen Cloud-Anwendungen?


Wir wollen in der Lage sein, Funktionen schneller zu entwickeln und bereitzustellen, um  schneller auf die Bedürfnisse unserer Kunden reagieren können.


Wir wollen alles automatisieren, um Risiken zu verringern und die Ausfallsicherheit zu erhöhen. 


Und schließlich wollen wir die Anwendung überall ausführen können, ohne sie dafür verändern zu müssen - kein Lock-In und ein echtes “RUN ANYWHERE”.


  • Schnelles Erstellen und Bereitstellen von Anwendungen 

  • Automatisieren von Abläufen, um das Risiko von Fehlern

  • Architektur für Ausfallsicherheit 

  • Vermeidung von Lock In eines Plattformbetreibers

  • Auswahl der besten und wirtschaftlichsten Services

  • Failover zwischen Plattformen oder Cloud-Anbietern

HashiCorp Consul deckt genau diese (und viele weitere Punkte) optimal ab. Mit höchster Security, Governance und Compliance. Natürlich auch mit voller Observability und Telemetrie.


Und genau hier zahlt ein ServiceMesh auf die Unternehmensziele ein.


Warum HashiCorp Consul?


  • Das aus unserer Sicht ausgereifteste ServiceMesh (Connect)

  • Single GO Binary, läuft in Bare Metal, VM, Container und Cloud (z.B AWS Lambda)

  • SPIFFE/SIRE

  • Intent based Networking & Security

  • Optimales Tracing

  • Features wie z.B. :

    • Canary Deployments

    • Splitter / Circuit Breaker

    • API Gateway

    • Rate Limiting

    • Blue / Green Deployments

  • Bestens in Hashicorp Ecosystem (z.B. Vault und Terraform) integriert

  • Eignet sich ideal für einen modernen, probaten "Plattform Ops"-Ansatz

  • Enterprise Support durch Hersteller HashiCorp

  • Design & Implementation auf höchstem Niveau durch FullStackS



68 Ansichten

Aktuelle Beiträge

Alle ansehen

Comments


bottom of page