{"id":3652,"date":"2021-08-20T13:39:55","date_gmt":"2021-08-20T17:39:55","guid":{"rendered":"https:\/\/chrisgrundemann.com\/?post_type=avada_portfolio&p=3652"},"modified":"2021-08-25T13:40:08","modified_gmt":"2021-08-25T17:40:08","slug":"gigaom-radar-report-for-evaluating-service-mesh-v-1-0","status":"publish","type":"avada_portfolio","link":"https:\/\/chrisgrundemann.com\/index.php\/portfolio\/gigaom-radar-report-for-evaluating-service-mesh-v-1-0\/","title":{"rendered":"GigaOm Radar Report for Evaluating Service Mesh v 1.0"},"content":{"rendered":"

Historically, developers independently implemented error handling, observability, and security within each application or microservice to ensure the success of inbound and outbound communication requests. However, as different teams repeated the process and coded similar functionality into each application (often using different programming languages), complexity, fragmentation, and security vulnerabilities were introduced into the environment.<\/p>\n

A service mesh addresses this problem by \u201coutsourcing\u201d the management of service-to-service communication requests to an out-of-process application. Typically implemented alongside the workload as a \u201csidecar\u201d proxy, a service mesh simplifies and streamlines runtime operations. Comprising a \u201cdata plane\u201d of interconnected network proxies and a \u201ccontrol plane\u201d for configuring the proxies and collecting metrics, it provides a shared infrastructure layer to manage intra-service runtime communications within a distributed, microservice-based software architecture.<\/p>\n

Application agnostic and fully portable, the service mesh can be adopted by an organization to support any service written in any language or framework. Adding uniform capabilities across the environment, a service mesh provides authentication, authorization, discovery, encryption, load balancing, logging, observability, routing, and tracing.<\/p>\n

While implementing a service mesh has zero impact on application code (other than \u201cdesired changes\u201d such as the removal of redundant functionality handled by the mesh, propagating mesh headers to enable tracing, or other changes to maximize the benefits of the mesh), it does affect operational procedures and requires the familiarization of DevOps personnel with new concepts and technologies. Additionally, as an emerging technology, taking the time to choose the right service mesh for your organization is essential due to the additional complexity, latency, and resource consumption involved.<\/p>\n

Although service mesh patterns can be applied to both monolithic and microservice-based applications, this study focuses on the latter running on various platforms, including containers\/Kubernetes and virtual machines (VMs). Also known as K8s, Kubernetes is an open source orchestration platform automating the deployment, management, and scaling of containers.<\/p>\n

This report provides an overview of the service mesh landscape based on the following table stakes, which are mature, stable solution features common across all service meshes:<\/p>\n