Does Envoy intend to evolve to an application runtime?

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](https://github.com/dapr/dapr/releases/tag/v1.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](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/mysql_proxy_filter), [Kafka Broker filter](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/kafka_broker_filter), [Redis proxy](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/redis_proxy_filter), 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!