Does Envoy intend to evolve to an application runtime?
#15,113 opened on Feb 19, 2021
Repository metrics
- Stars
- (27,997 stars)
- PR merge metrics
- (Avg merge 8d) (378 merged PRs in 30d)
Description
Envoy is a great service proxy and is now the default data plane for many service mesh products, which works well to solve many companys' service connectivity challenges.
Yet, in real world cases, a typical company may face much more challenges in areas like cache, database, message queue, configuration management, etc. Which means we still need to maintain a set of heavy weight SDKs along with the application code.
With the release of dapr 1.0.0, we see another possiblity: the sidecar becomes an application runtime that abstracts away the details of backend servcies, so that the application code could safely program against one set of standard api and forget about the issues such as how to handle database failover, how to work with different cloud providers, etc.

I understand envoy currently does have a set of filters such as MySQL proxy, Kafka Broker filter, Redis proxy, etc. But they looks to me more like a transparent proxy instead of an abstraction layer, and the client side still need to talk the same language as the backend services, which means the client is still tightly coupled to the backend services.
So my question is: Does Envoy intend to evolve to an application runtime?
Looking forward to your ideas/comments on this topic!