Introduce ScaledJob & ScaledObject

[tomkerkhove]

We've discussed this topic a few times before but I think we have reached a point where ScaledObject needs to be split in ScaledJob & ScaledDeployment.

While they share a lot of same functionality, I think they are different by nature:

• Jobs are typically used to run one-off processes
• Deployments are more long-running demons who are constantly processing a resource

These also have different scaling needs which tend to be confusing people or give unexpected results:

• Job are typically scaled on a per-message basis to drain a queue, "serverless scaling" let's say
• Deployments are constantly polling messages from the queue and require a maximum instance count to fan out. This is more of a traditional fan-out scaling without any knowledge of total message count but more "enough messages to add an instance"

An example of this confusion is #652.

Next to that, it would make the CRDs a lot cleaner given the properties are all focused on one type rather than one or two, depending on the property.

Now I am curious to know what others think but it feels like we need a bigger seperation in this and that every trigger will need to define if they support jobs, deployments or both as they typically need different information (message count > X rather than total message count == instance count).

[zroubalik]

I have pretty much the same opinion on this, I have shared the same concerns when there was the initial discussion on including Jobs some time ago, so I incline to separate both types.

I am looking at the Duck typing concept (which should allow us to scale any scalable resource), so I think we should stick to ScaledObject and just add ScaledJob, since we will be able to not scale just Deployments, but ReplicaSets and other CRDs that implements scale subresource, eg. Argo Rollouts as requested in #595 .

I'll add more details on the Duck typing later in #591, once I have all data and full picture.

[tomkerkhove]

That's also fine for me, only problem I have is that ScaledObject is a bit vague so I'd suggest to call it ScaledWorker instead or so which covers both maybe? Similar to how OAM defines Workers.

[zroubalik]

We should try to gather requirements and features that we would like to see from ScaledJob. Then we can try to design ScaledJob API.

[zroubalik]

Changed the title to contain ScaledObject as it is the direction we are moving

[zroubalik]

ScaledObject is implemented, I have opened a separate issue for ScaledJob #789