Envoy vs Kuma

Overview

Envoy

Stacks304

Followers546

Votes9

GitHub Stars27.0K

Forks5.1K

Kuma

Stacks16

Followers95

Votes0

GitHub Stars2.3K

Forks169

Envoy vs Kuma: What are the differences?

Introduction

Envoy and Kuma are both service mesh solutions that provide advanced networking capabilities for microservices-based applications. While they share some similarities, there are several key differences that set them apart.

Architecture: Envoy is a high-performance proxy that runs alongside every microservice, handling the network traffic between services. On the other hand, Kuma adopts a different approach by using a sidecar proxy model, where a separate proxy container is deployed alongside each microservice as a sidecar. This architecture allows Kuma to provide a more lightweight deployment and easier integration with existing environments.
Configuration: Envoy uses a complex and highly customizable configuration system based on YAML files. This gives users granular control over the proxy behavior, but it can also be more time-consuming and error-prone to set up. In contrast, Kuma focuses on simplicity and usability, offering a declarative configuration model that is designed to be more user-friendly and easier to manage.
Multi-mesh support: While both Envoy and Kuma support multiple meshes, the way they handle this feature differs. Envoy relies on a single instance that can handle multiple meshes, which may result in a more complex configuration setup. Kuma, on the other hand, is specifically designed to support multiple meshes out of the box, making it easier to manage and scale multiple environments.
Integration with service discovery: Both Envoy and Kuma integrate with service discovery systems, such as Consul or Kubernetes. However, Envoy requires manual configuration to connect with the service discovery system, while Kuma has built-in integrations that make it simpler to connect and synchronize with the service registry.
Traffic routing capabilities: Envoy provides powerful traffic routing capabilities, allowing users to define fine-grained routing rules based on various criteria like HTTP headers, paths, or weights. Kuma also offers advanced routing features but focuses more on simplicity and ease of use, providing a set of common routing patterns that cover most use cases without requiring complex configurations.
Extensibility: Envoy has a strong focus on extensibility and offers a rich set of APIs that allow users to customize and extend its functionality. Kuma also supports extension points but provides a more opinionated framework with predefined plugins for common use cases, aiming to simplify the extension process for users who don't require extensive customization.

In summary, Envoy and Kuma differ in their architecture, configuration approach, multi-mesh support, integration with service discovery, traffic routing capabilities, and extensibility. While Envoy offers a highly flexible and customizable solution, Kuma focuses on simplicity and ease of use, making it a more user-friendly option for those looking for a lightweight service mesh solution.

Share your Stack

Help developers discover the tools you use. Get visibility for your team's tech choices and contribute to the community's knowledge.

View Docs

CLI (Node.js)

Manual

Advice on Envoy, Kuma

Mohammed

CTO at Famcare

Jan 16, 2020

Needs advice

One of our applications is currently migrating to AWS, and we need to make a decision between using AWS API Gateway with AWS App Mesh, or Kong API Gateway with Kuma.

Some people advise us to benefit from AWS managed services, while others raise the vendor lock issue. So, I need your advice on that, and if there is any other important factor rather than vendor locking that I must take into consideration.

38.8k views38.8k

Comments

Detailed Comparison

Envoy	Kuma
Originally built at Lyft, Envoy is a high performance C++ distributed proxy designed for single services and applications, as well as a communication bus and “universal data plane” designed for large microservice “service mesh” architectures.	It is a universal open source control-plane for Service Mesh and Microservices that can run and be operated natively across both Kubernetes and VM environments, in order to be easily adopted by every team in the organization.
-	Universal Control Plane; Lightweight Data Plane; Automatic; Multi-Tenancy; Network Security; Traffic Segmentation: With flexible ACL rules
Statistics
GitHub Stars 27.0K	GitHub Stars 2.3K
GitHub Forks 5.1K	GitHub Forks 169
Stacks 304	Stacks 16
Followers 546	Followers 95
Votes 9	Votes 0
Pros & Cons
Pros 9 GRPC-Web	No community feedback yet
Integrations
No integrations available	YAML CentOS Kubernetes PostgreSQL Red Hat Enterprise Linux (RHEL) macOS Debian Ubuntu

What are some alternatives to Envoy, Kuma?

HAProxy

HAProxy (High Availability Proxy) is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications.

Traefik

A modern HTTP reverse proxy and load balancer that makes deploying microservices easy. Traefik integrates with your existing infrastructure components and configures itself automatically and dynamically.

AWS Elastic Load Balancing (ELB)

With Elastic Load Balancing, you can add and remove EC2 instances as your needs change without disrupting the overall flow of information. If one EC2 instance fails, Elastic Load Balancing automatically reroutes the traffic to the remaining running EC2 instances. If the failed EC2 instance is restored, Elastic Load Balancing restores the traffic to that instance. Elastic Load Balancing offers clients a single point of contact, and it can also serve as the first line of defense against attacks on your network. You can offload the work of encryption and decryption to Elastic Load Balancing, so your servers can focus on their main task.

Istio

Istio is an open platform for providing a uniform way to integrate microservices, manage traffic flow across microservices, enforce policies and aggregate telemetry data. Istio's control plane provides an abstraction layer over the underlying cluster management platform, such as Kubernetes, Mesos, etc.

Azure Service Fabric

Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices. Service Fabric addresses the significant challenges in developing and managing cloud apps.

Fly

Deploy apps through our global load balancer with minimal shenanigans. All Fly-enabled applications get free SSL certificates, accept traffic through our global network of datacenters, and encrypt all traffic from visitors through to application servers.

Moleculer

It is a fault tolerant framework. It has built-in load balancer, circuit breaker, retries, timeout and bulkhead features. It is open source and free of charge project.

Express Gateway

A cloud-native microservices gateway completely configurable and extensible through JavaScript/Node.js built for ALL platforms and languages. Enterprise features are FREE thanks to the power of 3K+ ExpressJS battle hardened modules.

ArangoDB Foxx

It is a JavaScript framework for writing data-centric HTTP microservices that run directly inside of ArangoDB.

Dapr

It is a portable, event-driven runtime that makes it easy for developers to build resilient, stateless and stateful microservices that run on the cloud and edge and embraces the diversity of languages and developer frameworks.

Related Comparisons

Envoy vs Kuma: What are the differences?

Introduction

Architecture: Envoy is a high-performance proxy that runs alongside every microservice, handling the network traffic between services. On the other hand, Kuma adopts a different approach by using a sidecar proxy model, where a separate proxy container is deployed alongside each microservice as a sidecar. This architecture allows Kuma to provide a more lightweight deployment and easier integration with existing environments.
Configuration: Envoy uses a complex and highly customizable configuration system based on YAML files. This gives users granular control over the proxy behavior, but it can also be more time-consuming and error-prone to set up. In contrast, Kuma focuses on simplicity and usability, offering a declarative configuration model that is designed to be more user-friendly and easier to manage.
Multi-mesh support: While both Envoy and Kuma support multiple meshes, the way they handle this feature differs. Envoy relies on a single instance that can handle multiple meshes, which may result in a more complex configuration setup. Kuma, on the other hand, is specifically designed to support multiple meshes out of the box, making it easier to manage and scale multiple environments.
Integration with service discovery: Both Envoy and Kuma integrate with service discovery systems, such as Consul or Kubernetes. However, Envoy requires manual configuration to connect with the service discovery system, while Kuma has built-in integrations that make it simpler to connect and synchronize with the service registry.
Traffic routing capabilities: Envoy provides powerful traffic routing capabilities, allowing users to define fine-grained routing rules based on various criteria like HTTP headers, paths, or weights. Kuma also offers advanced routing features but focuses more on simplicity and ease of use, providing a set of common routing patterns that cover most use cases without requiring complex configurations.
Extensibility: Envoy has a strong focus on extensibility and offers a rich set of APIs that allow users to customize and extend its functionality. Kuma also supports extension points but provides a more opinionated framework with predefined plugins for common use cases, aiming to simplify the extension process for users who don't require extensive customization.

Envoy vs Kuma

Overview

Envoy vs Kuma: What are the differences?