Nachdem wir uns im ersten Blogbeitrag eine Übersicht zu der grundlegenden Struktur von Kubernetes-Clustern im Cloud-Native-Umfeld und im darauf folgenden die technischen Grundlagen zur Runtime näher angeschaut haben, wird es Zeit auf die nächste Ebene zu blicken. Das Layer “Orchestrierung & Management” ist der Einstiegspunkt für die meisten Anwender. Während die Runtime für den Betrieb von container-basierten Umgebungen wichtig ist, bildet dieses Layer die Grundlage für den Betrieb von Applikationen. Die Erklärungen zu den einzelnen Komponenten des Layers “Orchestrierung & Management” sind sehr komplex, weswegen wir sie einzeln erklären werden. In diesem Beitrag schauen wir uns den Service Mesh einmal genauer an.
Show me the way – Der Service Mesh
Ein Service Mesh ist eines der größeren Themen, die die Softwareentwicklung auf Kubernetes erwarten darf. Hierbei wird die Möglichkeit integriert, das “Netz” von Microservices bzw. Pods in ihrer Kommunikation zu verwalten. Das Management von Netzrouten, dedizierte Zugriffskontrollen und Ausfall- bzw. Auslastungsmechanismen sind hier einige Beispiele.
Das Problem hierbei ist aber der Mehraufwand der entsteht. Um ein Service Mesh zu nutzen, ist es notwendig, selbsterstellte Software so aufzubauen, dass sich die Aufgaben hierbei nicht überlappen. Sei es im Bereich des Routings, der Validierung oder der Limitierung des Traffics: all diese Aufgaben kann ein Service Mesh übernehmen und sollten nicht mehr in den eigenen Applikationen vorkommen.
Auf der anderen Seite kann man dabei aber die Entwicklungsarbeiten somit ausserhalb der Anwendung erbringen und damit gänzlich aus einem Team herausnehmen oder sogar ein komplett eigenes Team damit beschäftigen.
Welche Frage der Service Mesh beantwortet
Der Ansatz des Service Mesh zeigt auf, wie kleinteilig Microservices werden können. Es zeigt auch gleichzeitig, wie gut ein “Separation of Concern” funktionieren kann, wenn es einmal umgesetzt wird. Wenn man das als Grundlage ansieht, ist die Frage, ob ein Service Mesh sinnvoll wäre, dadurch bereits beantwortet.
Anders sieht es mit dem ”Wann” aus. Die Umstellung auf eine zentrale Komponente im Routing-Bereich kann jederzeit erfolgen. Effizient wird sie aber erst dann, sobald die eigene Firmenkultur die Mitarbeitenden befähigt, diese Komponente auch wirklich zu nutzen und selbst zu betreiben. Nicht zuletzt wird dabei auch die vorangegangene Planung im Netzwerk und damit in der Entwicklung einmal in Frage gestellt: Benötige ich dann noch ein Service Proxy oder soll das applikationsseitig abgesichert sein? Welche Application Tasks werden zusätzlich ausgelagert und wie kann ich in der komplexen Verteilung weiterhin einen Vorteil gegenüber dem klassischen Betrieb beibehalten?
Ein guter Ansatzpunkt ist die Prüfung der eigenen Anforderungen nach dem Wechsel zu Kubernetes. Wenn die eigenen erstellten Microservices immer weiter unterteilt werden, stateless Services ihre “eigenen Container” bekommen – dann kann man in einer Analyse sehr schnell feststellen, dass ein Service-Mesh-Plugin viel Entwicklungsarbeit abnimmt. Der Time-to-Market kann dann weiter reduziert werden und Fokus auf die eigentliche Mehrwertgenerierung im eigenen Code erhöht werden. Außerdem kann auch während des Debuggings die Fehlerquelle zielgerichteter ausgewiesen werden.
Welches Tool nehme ich denn nun?
Die bekanntesten Anbieter von Service Meshes sind im Vergleich zu manch anderem Layer der CNCF überschaubar. Ob es am Ende Istio, Linkerd oder Consul sein soll, entscheidet eure Präferenz. Während Istio viele Features beherbergt, ist Linkerd in der Performance besser und Consul als guter Allrounder empfehlenswert. In der Wartung ist besonders Istio durch seine Komplexität durch einen größeren Aufwand nicht zu unterschätzen.
Alle drei Komponenten arbeiten mit der SideCar-Technologie. Consul hat darüber hinaus zusätzliche Agents auf jeder Node vorgesehen.
Kubernetes ist für viele immer noch neu und es gibt mehr als genug Dinge zu lernen. Deswegen bleiben wir als SysEleven auch hier bei unserem Credo: Solltet ihr Fragen haben oder bei der Entscheidung Hilfe benötigen, helfen wir euch gern weiter. Wir haben für alle Fragen den richtigen Ansatz. Schreibt uns einfach!
