3 ms·

I have a few questions. > Knative provides a set of middleware components that are essential to build modern, source-centric, and container-based applications

by mfer 8y ago

I have a few questions. > 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 8y ago
> 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.
- dewitt 8y ago
  Just to amplify jacques_chester's reply, yes, we do see products being built on Knative components. Google is doing that (serverless container support in GCF, serverless add-on in GKE), and you can see similar announcements being made from partners in this thread. 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!
- mfer 8y ago
  > Knative is PaaS-- 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?
  - jacques_chester 8y ago
    > 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. 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/1PicF7UhvSBpZLwichuY5hdhTX7Sl6aak2OzwDK8G78s/edit https://docs.google.com/document/d/1PicF7UhvSBpZLwichuY5hdhT... (to view, join the knative-dev group: https://groups.google.com/forum/#!forum/knative-dev https://groups.google.com/forum/#!forum/knative-dev)
sytse 8y ago
I just had a call with Josh, a GitLab product manager, that maybe helps with some of your questions https://www.youtube.com/watch?v=k1jK4F4NoBw https://www.youtube.com/watch?v=k1jK4F4NoBw
- mfer 8y ago
  Thanks for sharing. Noticed you talked a bit about kaniko. It has some security issues that have been talked about but last I checked not addressed by the kaniko team. How are you dealing with those?
  - joshlambert 8y ago
    Thanks for watching mfer! Kaniko certainly doesn't address all of the challenges with building containers securely, but I think it's the best solution available _today_ that supports the common Dockerfile workflow. There are a number of other promising tools like img, but aren't readily usable yet because of a dependency on some upstream PR's. At GitLab, we're trying to think of ways to help developers understand the challenges, as well as provide easy to adopt solutions as these tools become available. Would love your thoughts and feedback: https://gitlab.com/gitlab-org/gitlab-ce/issues/48913 https://gitlab.com/gitlab-org/gitlab-ce/issues/48913

by mfer 8y ago

jacques_chester 8y ago

> 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.

dewitt 8y ago
Just to amplify jacques_chester's reply, yes, we do see products being built on Knative components. Google is doing that (serverless container support in GCF, serverless add-on in GKE), and you can see similar announcements being made from partners in this thread. 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!
mfer 8y ago
> Knative is PaaS-- 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?
- jacques_chester 8y ago
  > 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. 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/1PicF7UhvSBpZLwichuY5hdhTX7Sl6aak2OzwDK8G78s/edit https://docs.google.com/document/d/1PicF7UhvSBpZLwichuY5hdhT... (to view, join the knative-dev group: https://groups.google.com/forum/#!forum/knative-dev https://groups.google.com/forum/#!forum/knative-dev)

sytse 8y ago

I just had a call with Josh, a GitLab product manager, that maybe helps with some of your questions https://www.youtube.com/watch?v=k1jK4F4NoBw https://www.youtube.com/watch?v=k1jK4F4NoBw

mfer 8y ago
Thanks for sharing. Noticed you talked a bit about kaniko. It has some security issues that have been talked about but last I checked not addressed by the kaniko team. How are you dealing with those?
- joshlambert 8y ago
  Thanks for watching mfer! Kaniko certainly doesn't address all of the challenges with building containers securely, but I think it's the best solution available _today_ that supports the common Dockerfile workflow. There are a number of other promising tools like img, but aren't readily usable yet because of a dependency on some upstream PR's. At GitLab, we're trying to think of ways to help developers understand the challenges, as well as provide easy to adopt solutions as these tools become available. Would love your thoughts and feedback: https://gitlab.com/gitlab-org/gitlab-ce/issues/48913 https://gitlab.com/gitlab-org/gitlab-ce/issues/48913