Service mesh: Observe and secure your mesh with metrics

Everything you need to coordinate microservices in a service mesh with powerful monitoring and management tools like Istio and Kiali.

What is a service mesh?

A service mesh is a combination of tooling and infrastructure that manages communication and interaction between individual services. The service mesh disconnects the network needs from each microservice so that each service can be observed and monitored across the whole system. Service meshes can also be applied to individual architectures that require multiple services to communicate.

How do service meshes help developers?

Service meshes are ideal for development teams that need to access services through network interfaces and protocols and well-defined management of service-to-service communication. They deliver advanced traffic control, security, resilience, and observability for cloud-native apps and enable standardization across service interactions. By allowing applications to offload these capabilities from application-level libraries, service meshes provide developers with quicker deployments and deployment cycles.

How does Istio work with microservices?

You can change Istio settings to invoke fault injection or support a Canary Deployment or anything else Istio supports, all while never touching your application source code. For example, let's say you want to direct all web traffic from your largest customer (Foo Corporation) to a new version of your website.

You may decide to do this by simply creating an Istio Route Rule that searches for @foocorporation.com in their user ID and directs them appropriately. To the rest of the world, this change would be transparent. Meanwhile, you can test your new software.

how istio works with microservices diagram

Service mesh FAQs

When should you consider using a service mesh?

You should consider a service mesh when you want to have centralized control, security, and observability over your application network. This centralized control enables:

Automatic and enforced mutual TLS encryption between services, including application identity and certificate management.
Fine-grained security policies based on application identities or request parameters.
Application-level traffic management policies to enable blue/green deployments, canary updates, and A/B testing.
Out-of-the-box observability with metrics, logs, and distributed tracing.
Improved resilience with automated network timeouts, retries, and circuit breaking.

These capabilities become particularly important when deploying a large number of services, as these concerns can become complex and expensive to manage at scale. A service mesh eliminates the need for developers to take on these complex tasks, allowing them to spend more time focusing on their business logic.

What is a sidecar proxy?

A sidecar proxy is a lightweight network proxy (Envoy, in the case of Istio service mesh) that is installed alongside an application container within the same Kubernetes pod. Because it is part of the same pod, it shares the same lifecycle and network namespace as the application container. This lets you configure the pod’s networking so that all incoming traffic is directed to the sidecar proxy before it enters the application container.

Likewise, all outgoing traffic traverses the sidecar proxy before leaving the pod. This allows the sidecar proxy to modify traffic and enforce policies on both incoming and outgoing traffic.

How is a service mesh different from an API gateway?

While an API gateway is used to manage external calls to API services (sometimes called north/south traffic), a service mesh is best suited for managing and securing internal service-to-service interactions (sometimes called east/west traffic). This means that an API gateway provides more advanced features for external users, such as user rate limiting, advanced user authentication and authorization features, and API monetization features.

In contrast, a service mesh is more concerned with features like service-to-service mTLS encryption, observability, traffic management for application updates, and more.

Is service mesh only for Kubernetes?

No. While the use of service mesh became popularized with Kubernetes due to the fact that the use of Kubernetes significantly increased the number of workloads teams could manage, it is possible to use a service mesh with workloads that are not part of a Kubernetes cluster, or a combination of workloads on cluster as well as independent virtual machines (VMs) or bare metal hosts.

Can a service mesh integrate with monitoring and observability tools?

Absolutely! A service mesh provides telemetry for monitoring and observability out of the box. When traffic in a mesh passes through one or more proxies, telemetry in the form of metrics, logs, and traces are made available that can be captured by monitoring and observability tools for storage and further processing. This automatic information includes request and response count, size, and duration.

Can Kiali be used with any service mesh?

No. Kiali can only be used with Istio service mesh. Red Hat supports Kiali as a component of OpenShift Service Mesh.

What are the challenges of using a service mesh?

Integration with systems

A service mesh can be difficult to set up, manage, and integrate with existing systems. Organizations can encounter challenges if they are working in a large, distributed environment across multicloud and on-premise systems, or have not previously used a service mesh in their environment.

Resource requirements

Service meshes can increase the operational overhead of managing applications because each service instance now has a sidecar proxy, which increases CPU and memory usage. Managing and troubleshooting, particularly in large-scale deployments, can be complex, and maintaining performance and scale can be more difficult as a result.

Skill gaps

Teams need training to understand service mesh features, configuration, and best practices. Debugging failures can be severe, especially when issues arise due to complex routing rules or mTLS misconfigurations. Many organizations find that their existing teams lack expertise in service mesh technology, which can present challenges with getting started and using service meshes effectively.

Red Hat resources for solving these challenges

Red Hat Connectivity Link

Connectivity Link attaches policies to gateways, enabling features like DNS connectivity, automatic TLS integration, authorization, and rate limiting for ingress traffic. This Kubernetes-native solution ensures seamless traffic management and policy enforcement in a single cluster or across multiple clusters.

Learn more

Red Hat Developer Toolset

Red Hat Developer Toolset delivers the latest stable versions of GCC (C, C++, and Fortran) GDB, and performance tools like SystemTap, OProfile, Valgrind, and much more. And importantly, compile once (on N) and deploy on N plus N+1 versions.

Learn more

Red Hat OpenShift

Red Hat OpenShift is a trusted, comprehensive, and consistent platform to develop, modernize, and deploy applications at scale, including today’s AI-enabled apps. Innovate faster with a complete set of services for bringing apps to market on your choice of infrastructure.

Learn more

What's next for service mesh?

Service Mesh communities are focused on improving the ease of adoption and reducing the resource requirements to run a service mesh. This can best be seen in new implementations that remove the need for sidecar proxies.

Examples of sidecar-less service meshes include:

Istio’s ambient mode: An Istio data plane mode that uses two levels of proxies to remove the need for sidecar proxies. The ZTunnel is a per-node lightweight proxy that provides layer 4 telemetry and mutual TLS encryption between services, including certificate management. Waypoints are independently scalable Envoy proxies that provide layer 7 telemetry and traffic management features. Put together, this topology significantly reduces resource usage compared to a sidecar-based service mesh, while providing a comparable feature set.
Cilium: This open-source project heavily utilizes eBPF to provide some service mesh capabilities without requiring sidecar proxies.

Article

Featured image for: SCTP over UDP in the Linux kernel.

Oct 19, 2023

eBPF application development: Beyond the basics

Donald Hunter +1

Explore best practices for eBPF application development on Linux, including...

Article

Jun 25, 2024

Get started with the bpfman eBPF manager on OpenShift 4.16

Andrew Stoycos

Get started with the bpfman eBPF manager with this tutorial. You'll see how...

Article

Mar 12, 2025

Try Istio ambient mode on Red Hat OpenShift

Sridhar Gaddam

Discover why Istio ambient mode is better than the traditional sidecar model...

Manage network communications with OpenShift Service Mesh

As your applications evolve into collections of decentralized microservices, monitoring and managing the network communications and security among those multiple services, is challenging. Red Hat OpenShift Service Mesh offers a uniform way to connect, manage, observe, and provide security for microservices-based applications, that includes behavioral insight into and control of the networked microservices in your service mesh.

Follow along to configure and run a demo application under OpenShift Service Mesh. Discover how the service mesh controls the application from a conceptual point of view, then walk through the steps to get the application up and running under an OpenShift Service Mesh.