search

projectriff / riff

riff is for functions
https://projectriff.io
Apache License 2.0
798 stars 64 forks source link

RFC 0010: Drop core runtime #1373

Closed scothis closed 4 years ago

scothis commented 4 years ago

Feedback is open until Tuesday, January 14th

fbiville commented 4 years ago

The core runtime had the advantage of being very simple to comprehend, offering a good "getting started", minimal experience.

Users should not have to know anything about Knative to deploy simple workloads. Therefore, we should rework the UX around the current knative deployer commands.

It may sound silly at first but what about keeping the core commands and re-implement them so that they create Knative resources with sensible defaults under the hood?

scothis commented 4 years ago

It may sound silly at first but what about keeping the core commands and re-implement them so that they create Knative resources with sensible defaults under the hood?

I'm not sure what you're proposing. Can you give a couple concrete examples? How would this be different than the current Knative runtime?

Users should not have to know anything about Knative to deploy simple workloads.

It has never been a design goal to hide Knative from riff users. I'd say it's an anti-goal.

fbiville commented 4 years ago

It has never been a design goal to hide Knative from riff users. I'd say it's an anti-goal.

To me, riff is about allowing users to deploy (serverless) workloads to Kubernetes with as little friction as possible.

Today, if I want to deploy a simple request-reply workload, I create a function (riff function create...) and a core deployer (riff core deployer create...) and I'm done.

Tomorrow, for the same thing, I would create the function and the Knative deployer. Then, I would need to understand what the Knative autoscaler, Services, Routes and Revisions are and how to disable scale-to-0 (even autoscaling, maybe). That is significantly more complex than what I can do today with core.

I then have two questions:

  1. are these simple workloads our target?
  2. if they are, and considering that core is gone, do we plan to remove the "friction" I described above?
scothis commented 4 years ago

To reparaphrase your comment:

Today, if I want to deploy a simple request-reply workload, I create a function (riff function create...) and a ~core~knative deployer (riff knative deployer create...) and I'm done.

Tomorrow, for the same thing, I would create the function and the Knative deployer. Then, I would need to understand what the Knative autoscalerm, Services, Routes and Revisions are and how to disable scale-to-0 (even autoscaling, maybe). That is significantly more complex than what I can do today with core.

While I wouldn't recommend it for either runtime, a user can be equally naive about the implementation details of the core and knative runtimes. The surface area of the core Deployer and knative Deployer resources is by design nearly identical. The only different between the two is that the knative Deployer has knobs for min/max replicas. Since the core runtime doesn't have a scaler, there's no need for these knobs.

The core runtime is simpler because there are fewer moving parts, but that's because there are so many essential capabilities it doesn't provide. The core runtime, as is, is a day-2 dead end. As a user you must bring your own ingress, ssl termination, scaling. If you want that level of control, great, then also create a Deployment and Service.

trisberg commented 4 years ago

There seems to be some subtle differences between services exposed by the knative runtime vs the core - our demo storefront app can't seem to access the inventory-api service if it's deployed with the knative deployer. I'll post some more in the riff slack.

Update: This is getting resolved via https://github.com/projectriff-demo/storefront/pull/61

jldec commented 4 years ago

I'm concerned that we are rushing (and maybe over-simplifying) this decision

IMO @fbiville is making a valid point that there is a loss of simplicity.

I wonder if this RFC isn't really about limitations of Knative (too little ability to configure runtime strategies) leading to issues with the design of riff runtimes (artificial dichotomy).

I suggest keeping this open and starting a discussion to explore improvements to the Knative design which enable something as simple as what we have in the riff Core runtime.