These are early days of course, but given that the goal is to codify the commonalities (the 80% we all do roughly the same anyway) and to improve customer workload portability overall, I hope to see new products built using Knative, and existing products re-base on Knative as well.
Good questions, btw!
Except it bills itself as serverless. In a PaaS your apps need to have a server (e.g., http server). Serverless (e.g., FaaS or Brigade) elsewhere doesn't need this. Stuff isn't long running.
How is long running software servers like this serverless?
> My personal view is that Build (and before long Pipelines) will be the main entryway to Knative.
Pipelines? That doesn't appear to be in the docs. What is Pipelines?
I think this comes down to the difficulties of terminology. I think of FaaS as a PaaS with some extra features (scale-to-zero being the most-noticeable). "Serverless" is a catch-all term for a variety of workloads, of which FaaS is the most visible.
> Pipelines? That doesn't appear to be in the docs. What is Pipelines?
It's a proposal[0] to evolve Concourse into being a Knative component, picking up from Build for complex workflows. I've been working on parts of this with various folks over the past few months.
I should emphasise that it is a proposal. For what you do with Knative today, use Build. It's a simple abstraction and it works right now.
[0] https://docs.google.com/document/d/1PicF7UhvSBpZLwichuY5hdhT... (to view, join the knative-dev group: https://groups.google.com/forum/#!forum/knative-dev)
It's intended to be usable as a single installation with the option to install individual parts. The textbook case is Build -- you can get things done with or without it.
> Are these reusable components supposed to be packaged in a higher level system? It sounds like that but other parts of the page suggest it's a platform to use now.
I think a bit of both. The joke I've made is that if Kubernetes is IaaS++, Knative is PaaS--. It's usable as-is, it aims to provide a common set of primitives for shared concerns, but it can also serve as a base for higher-level systems. The Project riff team, for example, have pushed some of their efforts down into Knative.
> In my experience they like shorter form ones (there are numerous tools making that possible).
Mine too. My personal view is that Build (and before long Pipelines) will be the main entryway to Knative.