Enhancing Envoy with custom request checks: Golang Filter vs. External Processing Filter

[aabfalterer]

We are looking to implement a custom filter in Envoy to perform specific checks on every incoming request. Given our existing Golang codebase, a native Envoy filter is not a viable option. We are considering two alternatives:

• Golang Filter: Leveraging the StreamFilter API of Envoy's Golang filter to integrate the custom logic.
• External Processing Filter: Offloading the filtering logic to an external service, communicating with Envoy via gRPC.

Evaluation Criteria:

• Performance: We are particularly interested in understanding the performance implications of each approach, especially in high-traffic environments. While there seems to be no public benchmarking data, we would like to gather insights from the community on their experiences and recommendations.
• Complexity: We need to evaluate the development effort and maintenance overhead associated with each approach, considering factors such as configuration, deployment, and debugging.
• Flexibility: The chosen solution should provide sufficient flexibility to accommodate future enhancements and customizations.

Questions:

• What are the general performance characteristics of Golang filters and external processing filters in Envoy? Are there any known bottlenecks or limitations?
• Have you encountered any use cases where one approach significantly outperformed the other?
• What factors should we consider when choosing between these two options, beyond performance?

[yanavlasov]

You will get lower latency for the golang filter vs ext_proc filter, since ext_proc uses gRPC request to process requests. How much latency is added by ext_proc depends on a lot of factors. Your best approach is to load test your application with sample filters.

The ext_proc filter is deployed separately from Envoy, so it can be updated without needing to update Envoy.

[aabfalterer]

Thank you @yanavlasov for your feedback, which aligns with my own assessment. Given that the Golang filter has been available for a while (since v1.27) but the Go plugin API remains labeled as 'not stable,' are there specific concerns about using it in production? Or is it anticipated that the filter will receive more development to achieve the desired level of stability?

[yanavlasov]

Adding go extension maintainers @doujiang24 @wangfakang @StarryVae @spacewander @antJack for comments on using it in production

[doujiang24]

@aabfalterer The Golang Filter is stable enough for production now, we already use it in production over a years in Ant Group, at a very large scale, and more other companies.

The main risk comes from the stability of the API, please see:
#31685 (comment)