Envoy Proxy is an open-source edge and service proxy designed for cloud-native applications. Lyft developed it, and is now a graduate project within the Cloud Native Computing Foundation (CNCF).

FRP (Fast Reverse Proxy) is a high-performance reverse proxy application that helps expose a local server behind a NAT or firewall to the internet. Fatedier developed it, and is open-source software.

Comparison of main features and functions:

  1. Performance: Envoy Proxy is built in C++ for high performance. It’s designed for high concurrency, low latency environments. On the other hand, FRP is written in Go, which generally can’t match the raw performance of C++ but is easier to develop and typically consumes less memory.
  2. Observability: Envoy provides a robust set of tools for observability, including distributed tracing, native stats output, and more. This is particularly beneficial in microservices environments where understanding the communication layer can be challenging. FRP does not have such a comprehensive feature set for observability.
  3. Protocol Support: Envoy supports a wide range of protocols, including HTTP/1.x, HTTP/2, HTTP/3, gRPC, TCP w/TLS and SNI, etc. It also provides features like automatic retries, circuit breaking, global rate limiting, request shadowing, and zone local load balancing. FRP supports TCP, UDP, HTTP, HTTPS, and Websocket and also includes some basic load balancing capabilities, but it doesn’t have such broad protocol support or feature set as Envoy.
  4. Extensibility: Envoy has a flexible architecture and allows extensions to be written in multiple languages (C++, Lua, WASM), providing various customization options. FRP is less flexible in terms of extensibility.
  5. Configuration: Both Envoy and FRP are configured via files, but Envoy also provides dynamic configuration capabilities via APIs, which makes it more flexible and adaptable in complex, dynamic environments.

Comparison as a Reverse Proxy or Load Balancer:

  1. Envoy as a Reverse Proxy/Load Balancer:
    • Pros:
      • Envoy provides out-of-the-box load balancing features supporting several strategies, including round-robin, most minor request, ring hash, etc.
      • Envoy is resilient and fault-tolerant, with built-in circuit breakers, health checks, and zone-aware load balancing.
      • Envoy offers advanced features such as rate limiting, retries, timeouts, and shadowing, which are helpful in high-traffic scenarios.
    • Cons:
      • Envoy has a higher learning curve due to its rich feature set.
      • Envoy configuration can be complex in dynamic environments, especially without using its xDS API.
      • Envoy consumes more resources compared to FRP.
  2. FRP as a Reverse Proxy/Load Balancer:
    • Pros:
      • FRP is very easy to use and set up, with a simple configuration for most cases.
      • It consumes fewer resources compared to Envoy.
      • It is a good fit for scenarios where exposing local services to the internet is the primary requirement.
    • Cons:
      • FRP’s load-balancing capabilities are not as rich as Envoy’s.
      • FRP lacks observability features, making it less suitable for debugging and monitoring in complex setups.
      • It doesn’t support dynamic configurations, which can be a limitation in rapidly changing environments.

Comparison for various protocols (HTTP, HTTPS, SSH, Websockets):

  1. HTTP/HTTPS: Both Envoy and FRP support HTTP and HTTPS protocols. Envoy provides a rich set of HTTP-based features, including rate limiting, retries, timeouts, and more. FRP delivers a more simple feature set.
  2. SSH: Both Envoy and FRP can proxy SSH. However, Envoy’s support for TCP (which SSH is based on) is less feature-rich than its HTTP capabilities. FRP is simpler to configure for SSH proxying and can handle most use cases adequately.
  3. Websockets: Both support Websockets. Envoy provides more extensive load balancing capabilities, observability, and fine-grained control, while FRP is easier to set up and configure for primary use cases.

Use Cases:

  • Envoy is more suitable for large-scale, complex, microservices-based architectures, where the rich feature set (observability, rate limiting, retries, circuit breaking, etc.) and high performance can be fully utilized.
  • FRP is great for more straightforward use cases where you must expose a local service to the internet or need a primary load balancer or reverse proxy. Its more straightforward setup and configuration make it a good fit for smaller projects or environments where the additional features of Envoy aren’t necessary.

Cluster Environments and Scalability:

  • Envoy shines in cluster environments. It supports dynamic service discovery and has built-in load balancing, fault tolerance, and zone-aware routing. Envoy’s design enables horizontal scaling, making it an excellent choice for large, distributed environments.
  • While more manageable to set up, FRP does not offer the same features that make Envoy ideal for cluster environments. Its scalability is also more limited than Envoy due to its lack of dynamic configuration capabilities.

In conclusion, while Envoy and FRP serve as reverse proxies and offer load-balancing capabilities, they cater to different needs and use cases. Envoy, with its extensive feature set, observability, and extensibility, is ideal for large, complex, and dynamic environments. FRP, with its simplicity and lightweight nature, is better suited for more straightforward scenarios or environments where the additional capabilities of Envoy are not required.