Plugable deployers

[jroper]

Continuing from #4152, discussing in an issue instead.

The idea behind making deployers plugable is to allow Knative to serve more than just plain functions. We (@lightbend) have implemented a proof of concept that allows Knative to serve commands for event sourced entities, where the side car manages the loading and persisting of events, and a gRPC protocol between it and the user function is used to pass the events and the commands/replies. Other use cases that we would like to implement using the same framework are CRDTs and point to point messaging (eg, to implement things like chat and other user to user interactions, as well as IoT device to device or device to user real time communications).

[jroper]

One comment made in #4152 is that there is a high amount of coupling between the autoscaler and the queue proxy with no well defined interface between them. I've just reached a point in our work on stateful serverless to be able to test autoscaling, and what I'm seeing for our work is that it looks like we'll have to write our own autoscaler, there are a lot of things that need to be taken into consideration in a sharded scenario (as our impl is doing) when scaling that it makes no sense for the knative autoscaler to take into consideration. So perhaps the scope of the plugin point could increase to include all aspects of the management of the deployment, including scaling, and the knative autoscaler would not touch revisions with custom deployments. That would greatly reduce the effective interface that a plugin would need to implement to possibly something that could feasibly be well specified. On the minus side, it would mean plugins would now all have to implement their own autoscaler, meaning there's less chance that this plugin point would be used for anything other than stateful serverless due to the work involved in implementing it.

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[knative-housekeeping-robot]

Stale issues rot after 30 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.
Rotten issues close after an additional 30 days of inactivity.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle rotten

[knative-housekeeping-robot]

Rotten issues close after 30 days of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/close

[knative-prow-robot]

@knative-housekeeping-robot: Closing this issue.

Details

In response to this:

Rotten issues close after 30 days of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.