Warum benötigt man ein Service Mesh bei einem Cloud Deployment

Hinterlasse einen Kommentar
cloud native

Im Cloudcast #298 wurde Linkerd vorgestellt. Linkerd (gesprochen linker-dee) ist ein Service Proxy, der dazu dient die Kommunikation zwischen lose gekoppelten System oder Microservices zu orchestrieren. Früher nannte man sowas manchmal auch ESB (Enterprise Service Bus).

Der Unterschied zu den ehemaligen SOA (Service Oriented Architecture) Ansätzen der Nuller Jahre, wo man in der Regeln versucht hat statische Systeme miteinander zu koppeln folgt der Ansatz des Service Mesh der Annahme moderner Cloud Paradigmen wonach die Services unstet sind. Das bedeutet sind sind in Teilen verfügbar, werde teilweise aufskaliert („Autoscale“), oder abgebaut bei weniger Last. Im Idealfall orchestriert sich das System selbst, sei es nun gesteuert durch entsprechende Container-Manager wir Kubernetes oder Docker Swarm oder durch andere Mechanismen.

Das Konzept eines Service Mesh dient nun dazu entsprechende Inter-Service-Requests zu gewährleisten und zu steuern.

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. (But there are variations to this idea, as we’ll see.)

The concept of the service mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled by an orchestrator like Kubernetes. Not only is service communication in this world incredibly complex, it’s a pervasive and fundamental part of runtime behavior. Managing it is vital to ensuring end-to-end performance and reliability.

Da setzt linkerd nun an. Aus ehemaligen twitter Produktleuten und hinreichend mit VC Kapital ausgestattet, ist es sicherlich kein komplett neues Konzept.

The service mesh is ultimately not an introduction of new functionality, but rather a shift in where functionality is located. Web applications have always had to manage the complexity of service communication. The origins of the service mesh model can be traced in the evolution of these applications over the past decade and a half.

Consider the typical architecture of a medium-sized web application in the 2000’s: the three-tiered app. In this model, application logic, web serving logic, and storage logic are each a separate layer. The communication between layers, while complex, is limited in scope—there are only two hops, after all. There is no “mesh”, but there is communication logic between hops, handled within the code of each layer.

Inter-Service Kommunikation, load-balancing, latency-assurance, all diese Features können durch ein Service Mesh unterstützt werden. Die Plugin Architektur von linkerd finde ich am reizvollsten, da hierdurch sogar einfache Protokollumsetzungen möglich sind.

linkerd ist seit neuem auch Teil der CNCF.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s