Service Mesh Overview

Summary of reasons to use service mesh

1. API gateway focuses on requests from the outside to services, while service mesh focuses on communication between applications within the infrastructure
2. Visibility: Logs, metrics, and tracing provided by default.
3. Traffic management: Config changes are reflected in real time (header changes, L7 routing, etc.)
4. Security: mTLS (Mutual TLS) can be easily set up, so security can be strengthened without changing the application code through policy settings
5. Layer: Since it is a layer that runs completely separate from the application, there are fewer things to consider when changing the service mesh, adding applications, changing security settings, etc.

Comparison of well-known solutions with GPT4

Istio (CNCF, Apache License 2.0)

• Features: Istio is one of the most widely used service meshes, offering a rich feature set. It manages traffic using Envoy proxies and provides a wide range of features including traffic routing, policy settings, secure communication between services, observability, and more.
• Advantages: Powerful traffic management capabilities, comprehensive security features, high scalability.
• Disadvantages: Relatively complex setup and learning curve, may be resource intensive.

Linkerd (CNCF, Apache License 2.0)

• Features: Linkerd is a lightweight service mesh solution focused on performance and simplicity, written in Go and Rust. Compared to Istio, it is simpler to install and use, and provides features such as automated mTLS (mutual TLS authentication), traffic splitting, and observability.
• Advantages: Simple to install and use, low resource usage, fast performance.
• Disadvantage: Features may be somewhat limited compared to Istio.

Consul (HashiCorp, Mozilla Public License 2.0)

• Features: Consul is a multi-platform service mesh solution developed by HashiCorp, which started out as a tool for service discovery and composition. In addition to the service mesh function, it provides various functions such as service discovery, health check, key/value storage, and multi-data center support.
• Advantages: Wide feature range, multi-data center support, integration with various platforms.
• Disadvantages: Can be more complex to use and manage than other options; service mesh features are less emphasized than other tools.

What is the difference between service mesh and API Gateway?

• Where it applies

API Gateway is a centralized control area and is responsible for controlling traffic coming from outside.

(Between external network and internal network)

A service mesh is a method of separating application functionality into microservices managed by an infrastructure layer.

The service mesh is responsible for controlling communication within the service.

(Internal network Kubernetes cluster)

• Architecture

If API Gateway is a centralized architecture, creating a SPOF (Single Point of Failure), the service mesh has a distributed architecture, so it is easy to expand without creating a SPOF.

• Pattern

API Gateway generally uses the Gateway proxy pattern.

Consumer (caller) does not need to know the implementation, just knows how to call the Gateway and the Gateway does it for you.

Service Mesh typically uses the Sidecar proxy pattern.

Consumer (caller) code contains information such as how to find the provider’s address and code related to failover. However, the caller’s code is not embedded in the application code, but is managed separately in the form of a sidecar.

When used together, API Gateway and service mesh can act as a mediator in a service mesh architecture.

This improves security and speed.

Looking at the table above, it seems that API Gateway compensates for the shortcomings of the service mesh.

And from the API Gateway perspective, the service mesh seems to manage the details.

References