Can we see a design document/theory of operations, please? It’s difficult to evaluate this effort without understanding exactly what it is - namely, the constituent components, their respective functions, how they work and relate to one another, etc.
> Knative provides a set of middleware components that are essential to build modern, source-centric, and container-based applications that can run anywhere
Are these middleware components that someone else is supposed to package together into something useful like a platform? The other bits lead me to think it's a platform of sorts in itself. So, why the talk of middleware?
> Knative offers a set of reusable components that focus on solving many mundane but difficult tasks such as orchestrating source-to-container workflows, routing and managing traffic during deployment, auto-scaling your workloads,
PaaS systems already do this. Other serverless things, like kubeless, do this too. 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.
> Kubernetes-native APIs
This is found in the docs repo. The examples are long form k8s style objects. Have developers (those being targeted) been interested in these? In my experience they like shorter form ones (there are numerous tools making that possible).
I'm curious of the meat and usefulness behind the hype.
> Are these middleware components that someone else is supposed to package together into something useful like a platform? The other bits lead me to think it's a platform of sorts in itself. So, why the talk of middleware?
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.
I kinda have a hard time understanding what it is ... is it kinda a 'glue' layer between Kubernetes and istio ?
Can somebody give us a 2 sentences explanation? please and thank you
I've been around Knative for a few months on behalf of Pivotal (our blogpost here[0] and TheNewStack here[1]). Other leading contributors are IBM, SAP and Red Hat.
Subject to my biases, what would people like to know?
It looks like I have some more catch up to play, I see a rails logo on this page...
I emailed you a couple of days ago or yesterday about the Ruby support in Riff. There's not a PR yet but we got Ruby into a working state again! It looks like not a lot of people are interested in Ruby on serverless platforms.
Can you shed any light on why? And what kind of Ruby support can I expect from knative, given that it's not apparently coming from the Riff project now... as a Rails dev who wants to use this stuff today, how do I get started?
(It has a Rails logo on the page linked by the post, so I assume I can use it now, but I haven't gone deeply enough to see if there are limitations... I'm used to Ruby support being neglected in the serverless areas, I don't know if it's because we Ruby devs are slacking, or there's a fundamental flaw I haven't seen yet, or what...)
So, what can you tell me about that Rails logo on the landing page?
Can we see a design document/theory of operations, please? It’s difficult to evaluate this effort without understanding exactly what it is - namely, the constituent components, their respective functions, how they work and relate to one another, etc.
Just a comment here about this in general - given all the resources at Google’s disposal, I’m perplexed as to why we don’t see world-class (or even at least halfway decent) documentation being shipped along with the product at first release. As a community I think we need to demand higher standards in this area. If GNU can do it, Google certainly can.
This looks really cool, I'll definitely be looking into it more closely when I get a chance.
Obviously this is a conflict of interest for Google, but just curious if you know of any plans in the works for being able to run this on AWS EKS? It's the obvious omission from the list of supported clouds on the installation page[0].
Just a quick reminder from the installation documents (emphasis mine):
"If you already have a Kubernetes cluster you're comfortable installing alpha software on, use the following instructions"
This looks cool, and will likely be useful in the future, but this is still alpha quality software. Don't bet your business on it by installing it to your production clusters. Don't let your development cycle by driven by the latest shiny thing, no matter whose logo is on it.
The current Build design allows for a relatively straightforward extension to use S2I as a BuildTemplate. You can see other examples here: https://github.com/knative/build-templates
As and when Builds becomes Pipelines, I anticipate that it will remain relatively trivial to integrate existing build infrastructure without too much fuss.
We definitely want to support knative, integrated well with existing concepts (like triggering deployments and builds when images change), to stitch in the new build resource so it works well with existing tools like s2i (as Jacques mentioned), and generally make sure these are good building blocks for applications. There’s a lot of good ideas in knative that will benefit anyone who uses Kubernetes.
I'm a bit confused about the "eventing" application. Is it a message bus like NATS? a persistent event log like Kafka? or is it an adapter that allows applications to interact with both?
Have you ever used Kubernetes? The abstraction it focuses on is running container images; building them and getting them to a registry is a whole separate abstraction.
I am glad to see attempts at making a high-level platform. However, I feel like it will be too opinionated for many to pick Istio and solve build and FaaS all at once.
Will there be some push-down of some of the functionality into Kubernetes? Will any of this turn into specification with alternative implementations?
One of the goals is to make the components loosely coupled at the top (so a product can choose among them as needed), and also pluggable at the bottom (so you can swap out implementations as needed, for example logging and monitoring).
I expect that some of this will end up upstreamed into Kubernetes proper if it's broadly useful (autoscaler work, to pick an example), but this is still super early so let's see what people want.
And yes, we're documenting the control plane APIs, the data plane requirements, and the contract for serverless container environments, with the hope that they can be reimplemented consistently wherever needed.
One of the explicit goals is workload portability, so separating spec from implementation is critical.
Some of the attributes of serverless workloads will require changes deeper down in the stack (read Kubernetes). For instance constantly getting containers up or throwing them away at high rates stresses parts of Kubernetes more than its used to. I fully expect lots of requirements to make their way into Kubernetes itself.
There will probably be stuff pushed down based on things Knative needs. For example, we've discussed the effect of what we call "the warmth hierarchy" on autoscaling (tl;dr, bad).
Solving those problems can't be done entirely at the layer in which Knative is developing -- some changes will need to turn up in Kubernetes (node-local caching awareness) and Istio (workload/node-aware routing).
We have several days of keynotes at GCP Next and way more to share throughout the week. But for the curious, there's a serverless spotlight session at 1:55 today that will cover this, as well as a Knative-specific talk at 4:35.
We decided to announce this first thing with the blog posts just to get the word out as soon as possible and give our amazing partners (Pivotal, SAP, RedHat, IBM, and more) a chance to share their news as well.
And frankly, it's just more fun to run an open source project out in the open, so we were pretty keen to flip the git repo bits to public as early as we could. : )
knative has "distributed tracing" and supports scaling to zero, and aims to be loosely coupled. that said I have no idea how kubeless works, but I like that they have a CLI for quickly deploying functions.
It strikes me as highly significant that a large portion of the questions here are along the lines of "what the heck is this thing?" I'm certainly in that boat: as far as I can tell Knative is some kubernetes based cloud something something that maybe let's you host your own FaaS? Like Openwhisk? Or maybe it helps you deploy or something (isn't that already what k8s does?)?
This is hopefully received by Knative devs (or marketers) that the homepage needs a major overhaul, as it's not at all clear what the product is to the average visitor.
1) It is mentioned that KNative "deliver a serverless experience to developers on any cloud". How does it work with any cloud? Are you referring to fact that all clouds has k8s? Is it already supported in any cloud or will be supported?
2) If any cloud is supported, does it virtualize services such as storage, queues, API management and Identity
3) Does Knative can seamlessly switch monitoring to what is provided by each cloud.
> Can I run functions written on any platform on Knative? Java? .net core? Js?
Anything that meets the Container Runtime Contract[0] should work.
> What about startup times? How do they compare to other solutions?
Startup times need a lot more work. Knative has a number of moving pieces which are contributing delay to startup time and they're being discussed or attacked by various groups. Some of this work will probably require changes to be contributed upstream to Kubernetes and Istio.
I'm the engineering manager at Google responsible for both Knative and App Engine Flex. What we heard from a lot of customers is that they want a serverless / App Engine Flex-like experience but one that works multi-cloud or in hybrid/on-prem setups. The goal for Knative is to fill that need, especially for people that already use kubernetes.
That being said, App Engine Flex is a solid GA service that provides a fully managed experience and runs huge services today. Knative is not there yet but is getting better by the day.
[+] [-] markusthoemmes|7 years ago|reply
Happy to answer any questions that might arise as well. Answers might be biased and opinions are my own.
See IBM's statement: https://www.ibm.com/blogs/cloud-computing/2018/07/24/ibm-clo...
[+] [-] otterley|7 years ago|reply
[+] [-] scksback|7 years ago|reply
[+] [-] TuringNYC|7 years ago|reply
[+] [-] mfer|7 years ago|reply
> Knative provides a set of middleware components that are essential to build modern, source-centric, and container-based applications that can run anywhere
Are these middleware components that someone else is supposed to package together into something useful like a platform? The other bits lead me to think it's a platform of sorts in itself. So, why the talk of middleware?
> Knative offers a set of reusable components that focus on solving many mundane but difficult tasks such as orchestrating source-to-container workflows, routing and managing traffic during deployment, auto-scaling your workloads,
PaaS systems already do this. Other serverless things, like kubeless, do this too. 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.
> Kubernetes-native APIs
This is found in the docs repo. The examples are long form k8s style objects. Have developers (those being targeted) been interested in these? In my experience they like shorter form ones (there are numerous tools making that possible).
I'm curious of the meat and usefulness behind the hype.
[+] [-] jacques_chester|7 years ago|reply
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.
[+] [-] sytse|7 years ago|reply
[+] [-] gdsdfe|7 years ago|reply
[+] [-] jacques_chester|7 years ago|reply
Subject to my biases, what would people like to know?
[0] https://content.pivotal.io/blog/knative-powerful-building-bl...
[1] https://thenewstack.io/knative-enables-portable-serverless-p...
[+] [-] evankanderson|7 years ago|reply
https://medium.com/@mchmarny/build-deploy-manage-modern-serv...
https://www.ibm.com/blogs/cloud-computing/2018/07/24/ibm-clo...
and one by this "Google" thing:
https://cloudplatform.googleblog.com/2018/07/bringing-the-be...
[+] [-] yebyen|7 years ago|reply
It looks like I have some more catch up to play, I see a rails logo on this page...
I emailed you a couple of days ago or yesterday about the Ruby support in Riff. There's not a PR yet but we got Ruby into a working state again! It looks like not a lot of people are interested in Ruby on serverless platforms.
Can you shed any light on why? And what kind of Ruby support can I expect from knative, given that it's not apparently coming from the Riff project now... as a Rails dev who wants to use this stuff today, how do I get started?
(It has a Rails logo on the page linked by the post, so I assume I can use it now, but I haven't gone deeply enough to see if there are limitations... I'm used to Ruby support being neglected in the serverless areas, I don't know if it's because we Ruby devs are slacking, or there's a fundamental flaw I haven't seen yet, or what...)
So, what can you tell me about that Rails logo on the landing page?
[+] [-] caniszczyk|7 years ago|reply
[+] [-] dewitt|7 years ago|reply
[+] [-] otterley|7 years ago|reply
Just a comment here about this in general - given all the resources at Google’s disposal, I’m perplexed as to why we don’t see world-class (or even at least halfway decent) documentation being shipped along with the product at first release. As a community I think we need to demand higher standards in this area. If GNU can do it, Google certainly can.
[+] [-] dcosson|7 years ago|reply
Obviously this is a conflict of interest for Google, but just curious if you know of any plans in the works for being able to run this on AWS EKS? It's the obvious omission from the list of supported clouds on the installation page[0].
[0] https://github.com/knative/docs/tree/master/install
[+] [-] jacques_chester|7 years ago|reply
[+] [-] pas|7 years ago|reply
[+] [-] mchmarny|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] cmonfeat|7 years ago|reply
[+] [-] falcolas|7 years ago|reply
"If you already have a Kubernetes cluster you're comfortable installing alpha software on, use the following instructions"
This looks cool, and will likely be useful in the future, but this is still alpha quality software. Don't bet your business on it by installing it to your production clusters. Don't let your development cycle by driven by the latest shiny thing, no matter whose logo is on it.
[+] [-] lima|7 years ago|reply
How does this relate to OpenShift?
I really hope that, for instance, Knative's builder will be merged with Red Hat's source-to-image (S2I) builder.
[+] [-] jacques_chester|7 years ago|reply
As and when Builds becomes Pipelines, I anticipate that it will remain relatively trivial to integrate existing build infrastructure without too much fuss.
[+] [-] smarterclayton|7 years ago|reply
[+] [-] isdal|7 years ago|reply
[+] [-] dgllghr|7 years ago|reply
[+] [-] perfunctory|7 years ago|reply
[+] [-] bigdubs|7 years ago|reply
[+] [-] rifung|7 years ago|reply
Everyone builds upon other people's work.
[+] [-] mkj|7 years ago|reply
[+] [-] gregwebs|7 years ago|reply
[+] [-] dewitt|7 years ago|reply
I expect that some of this will end up upstreamed into Kubernetes proper if it's broadly useful (autoscaler work, to pick an example), but this is still super early so let's see what people want.
And yes, we're documenting the control plane APIs, the data plane requirements, and the contract for serverless container environments, with the hope that they can be reimplemented consistently wherever needed.
One of the explicit goals is workload portability, so separating spec from implementation is critical.
[+] [-] markusthoemmes|7 years ago|reply
[+] [-] jacques_chester|7 years ago|reply
Solving those problems can't be done entirely at the layer in which Knative is developing -- some changes will need to turn up in Kubernetes (node-local caching awareness) and Istio (workload/node-aware routing).
[+] [-] minimaxir|7 years ago|reply
[+] [-] dewitt|7 years ago|reply
We decided to announce this first thing with the blog posts just to get the word out as soon as possible and give our amazing partners (Pivotal, SAP, RedHat, IBM, and more) a chance to share their news as well.
And frankly, it's just more fun to run an open source project out in the open, so we were pretty keen to flip the git repo bits to public as early as we could. : )
[+] [-] reilly3000|7 years ago|reply
[+] [-] pas|7 years ago|reply
[+] [-] sequoia|7 years ago|reply
This is hopefully received by Knative devs (or marketers) that the homepage needs a major overhaul, as it's not at all clear what the product is to the average visitor.
[+] [-] hemapani|7 years ago|reply
2) If any cloud is supported, does it virtualize services such as storage, queues, API management and Identity
3) Does Knative can seamlessly switch monitoring to what is provided by each cloud.
[+] [-] shaohua|7 years ago|reply
[+] [-] evankanderson|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] polskibus|7 years ago|reply
What about startup times? How do they compare to other solutions?
[+] [-] jacques_chester|7 years ago|reply
Anything that meets the Container Runtime Contract[0] should work.
> What about startup times? How do they compare to other solutions?
Startup times need a lot more work. Knative has a number of moving pieces which are contributing delay to startup time and they're being discussed or attacked by various groups. Some of this work will probably require changes to be contributed upstream to Kubernetes and Istio.
[0] https://github.com/knative/serving/blob/5b8542fb58044834d50f...
[+] [-] mikevm|7 years ago|reply
[+] [-] isdal|7 years ago|reply
[+] [-] snug|7 years ago|reply
[+] [-] jacques_chester|7 years ago|reply