Need advice about which tool to choose?Ask the StackShare community!
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.
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.
The benefit of using Kuma + Kong Gateway are:
- Feature-set: Kong + Kuma provide an end-to-end solution for both APIM and Service Mesh with a feature-set, and a performance, that is not matched by AWS services. In addition to this you can extend Kong Gateway with 70+ plugins out of the box and choose between 500+ plugins from the community to cover every use-case. In comparison, the feature-set of AWS API Gateway is quite limited and basic.
- Performance: Especially in the case of Kong Gateway, performance has always been a top priority for the project (more performance deliver more reliable applications). In some benchmarks the latency added by AWS API Gateway can be 200x more than what you would achieve with Kong Gateway natively which has been hand-crafted for maximum throughput.
- Cost: While cloud vendors like AWS make it very easy to get up and running with their services at a lower initial cost, that cost ramps up very quickly (exponentially) as the number of requests are increasing. With Kong GW you don't have this problem, since you can run tens of thousands of concurrent requests on a small EC2 instance (or Kubernetes Ingress, via the native K8s ingress controller for Kong Gateway).
- Portability: You can replicate your infrastructure on any other cloud, or on your development machines with ease. Want to run your gateway + mesh on your local Kubernetes cluster? You can do that. Want to run your infrastructure on another cloud provider? You can do that. Strategically you have full ownership of your infrastructure and its future. When it comes to Kuma, you can also run a Mesh on VM-based workloads in addition to Kubernetes (Kuma is universal).
- And much more.
Disclaimer: I am the CTO of Kong.
AWS App Mesh is useful when your micro services are deployed across Ec2 , EKS or ECS. Assume you are in process of migrating microservices from ec2 instances to ecs, its easy to switch using Virtual router configuration. As App Mesh is managed service and easy to bring up ,its worth giving it a try for your use case before choosing Kuma or any other tool.
Pros of Envoy
- GRPC-Web9
Pros of Kuma
Sign up to add or upvote prosMake informed product decisions
What is Envoy?
What is Kuma?
Need advice about which tool to choose?Ask the StackShare community!
What companies use Envoy?
What companies use Kuma?
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with Envoy?
What tools integrate with Kuma?
Sign up to get full access to all the tool integrationsMake informed product decisions
Blog Posts
+6