In-tree pluggable components #19
Conversation
| The problems we've seen include, but are not limited to: | ||
|
|
||
| * Amount of data loaded in memory. | ||
| Dapr 1.10 has a virtual memory footprint of almost 900MB. Most of that is code pages that are not really a burden on the system, as they're offloaded easily by the kernel; nevertheless, the amount is growing with each release as we ship more code. A lot of that code is indeed due to components. |
There was a problem hiding this comment.
Might be interesting pointing out that 900MB is a real problem for serverless architectures and although Dapr main use-case is not targeting those, it is an deterrent of using Dapr on those environments.
| * Effect of security vulnerabilities in third-party packages. | ||
| Most of our components depend on third-party packages such as SDKs, and we import dozens of them in Dapr. Suppose that component X depended on a library for which a vulnerability was found. Users who do not leverage component X are likely not impacted by the vulnerability, but they are still running a binary that depends on a vulnerable package, possibly causing compliance conerns. | ||
| * Ability to ship some components with outsized impact on performance. | ||
| Already in the last months we've had components that were accepted in `dapr/components-contrib`, after being reviewed, and then we had to remove them because we noticed they had an unacceptable impact on the resources used by `daprd`. Sadly, our processes and tools don't allow us to catch these things easily until the component is actually registered in `daprd`. |
There was a problem hiding this comment.
Already in the last months we've (...)
It would be belter to anchor this time reference by specifically mentioning the last months (or even better, final weeks) of 1.10 release development. "In the last months" will be ambiguous 6 months from now.
| * Removing components from Dapr entirely is an option as well, for example to ship them as external, pluggable components. These would be separate from `daprd` in all ways, including: they're shipped in separate Docker images, need to be explicitly added to applications (see [0005-R-pluggable-components-injector.md](./0005-R-pluggable-components-injector.md)), and can have separate release lifecycles and support. | ||
| * Users can also re-compile Dapr with a custom set of components. Although we don't officially support this, we are aware of at least some users who do this as a practice. This is something only advanced users may consider doing due to the very high complexity and operational burden. | ||
| * **Are there any trade-offs being made?** | ||
| * Components that are instantiated as in-tree pluggable components will likely have *slightly* degraded performance, due to the overhead of inter-process communication and gRPC serialization/unserialization. Based on the research that was done for pluggable components, that should be negligible for most users. |
There was a problem hiding this comment.
It woud be great if we could quantify this but I don't think we ever came with those numbers in pluggable components final incarnation.
|
|
||
| ### Packaging | ||
|
|
||
| The last step is packaging. After building all binaries, **they are included in the same container image as `daprd`**, for example in the `/components/` path within the container. |
There was a problem hiding this comment.
If in this way, the image size is still big.
I have an idea that when dapr init, download all biniaries at each machine, daprd mount that dir when run. End users still deploy as before.
There was a problem hiding this comment.
I don't think we have concerns with the size of the image. What is most concerning to us is the size of the binary when is loaded in memory.
I am not a fan of downloading binaries on each machine, because:
- It will make each container startup slower since the binaries need to be fetched over the network. If they're included in the Docker image, they are generally cached in the host already.
- On K8s, it would require a volume claim, which is not ideal.
- There are security and availability concerns in this case:
- We will need to host a download server and make it always available
- Users may have concerns with downloading code at runtime, as it could be used as an attack vector
- Some users run Dapr on hermetic environments, where no network connections are allowed
Formalizing a proposal initially discussed on Discord
This is a proposal for implementing the infrastructure to allow in-tree components to be shipped with Dapr, in the same Docker image as daprd, but instantiated as pluggable components by the Dapr runtime.
This is not a proposal to remove components from Dapr's distribution or remove them from the Dapr repositories. Components that are instantiated as in-tree pluggable components should work for end-users in the same way that statically-compiled components do.