141–150 of 168 posts
Cold startup time and mitigation strategies like those on AWS?
Even better! Knative will allow you to even scale your containers out-of-band if you know that something BIG will happen. See https://github.com/knative/serving/issues/1656 for the discussion.
Earlier quoted context omitted.
I am giving you the higher level view on what I think it does ... read the docs! or even better the source code it is open. Explaining to you how the car works can be as far as explaining how physics work, because you need understand combustion, gravity etc. EDIT: and that will exceed 20 sentences by a few very heavy books.
According to the docs, the high level overview is misleading. You don't have to explain physics to explain how a car works. You only have to explain it in terms of something your audience is familiar with. Magnetization would be hard to explain to someone without physics, because there's no other parallel to quantum mechanics for the average person. But a car is based on general principles which most of us understand…
Earlier quoted context omitted.
You basically have a git repo that contains your business logic implemented as 'functions' and some configuration : knative will build, containerize, deploy, and glue/route those functions for you to make it a full fledged app. it will also take care of load balancing/scaling etc. So all you need really is focus on you business logic code and write some config for knative ... well this is at least the vision
This is just a summary of what it is. A car is a machine that moves you around the roads. But how does the car work ? Are you using it? Because the docs seem to show that what you describe is not the case. The devs seem to have to write integrations for everything, so almost nothing is done for them. Saying Knative will "do it for you" is like saying your car will "drive itself". You only have to steer it and work th…
[0] https://github.com/knative/docs/blob/master/serving/debuggin...
Earlier quoted context omitted.
so it can be anything really ... hmm
I think Knative (and the scale to zero in particular) are best suited for request/response or event-delivery workloads. So you wouldn't want to run (for example) memcache or mysql under knative. FaaS and (HTTP application) PaaS are both good matches. I think it's an open question whether a PaaS like Google Dataflow is a good match or not. It will certainly require more planning, but I think it's doable.
Earlier quoted context omitted.
Even better! Knative will allow you to even scale your containers out-of-band if you know that something BIG will happen. See https://github.com/knative/serving/issues/1656 for the discussion.
That tells me not much....is it pinging to keep instances warm?
This is an example of nesting reactive control (the autoscaler) with predictive control (the min/max values).
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
Based on the linked GitHub readme, it seems that this allows you to deploy autoscaling apps ready for public consumption without having to worry about defining load balancers, ingress routes, etc. There's a lot of documentation and it's difficult (for me) to completely grok. GitHub readme: https://github.com/knative/docs/blob/master/install/getting-... Example Ruby app: https://github.com/knative/docs/blob/master/ser…
Knative calls the role of the person providing the servers are "operator". Kubernetes is great for operators because it has a lot of common low-level primitives, and lots of choice if you want to pay someone else to be your operator.
Knative aims to give a similar great experience to developers if you can convince your operator to install it on top of the kubernetes they already have. In particular, if an operator charges you for container runtime minutes on knative, you're getting close to the pay-per use model of lambda or app engine. Also, as you noted, developers should have fewer concepts they need to grok in order to deploy a knative app compared with kubernetes.
Earlier quoted context omitted.
Is this something like what you're looking for? https://github.com/knative/serving/blob/master/docs/spec/ove... Or a little higher-level: https://docs.google.com/presentation/d/1CbwVC7W2JaSxRyltU8CS... There are a lot of technical docs in the individual repositories. You can get started, for example, with the serving docs under: https://github.com/knative/serving/tree/master/docs Same for the other repos, like build…
Not really, I'm afraid. Resource descriptions don't constitute a theory of operations, and the higher-level document you linked to is not public. By "theory of operations," I mean a design document, often but not always created before a line of code is written, that describes in plain English what is to be built (or, what was built). It often discusses things like: * What problems are being solved? * What attempts ha…
The first chapter, when I picked up the book, was a tour of Perl. I loved it. It showed me all of the highlights with no details at all. I never read another chapter, and instead picked up the second book in the series to use as a reference.
My counter in this argument HATED that first chapter. They almost didn't read another one, because it put all of these examples in front of them with no depth. They thought the book would be much improved by removing that chapter.
I would have been bored to tears by the book this person wanted to read.
I'm not going anywhere in particular with this, except to say that the world takes all kinds. Sometimes docs don't exist simply because nobody realized someone else would find that shape of document useful, so they decided not to write it.
The docs I love may well be the docs you hate :)
Earlier quoted context omitted.
it's a PaaS .. heroku for k8s https://github.com/knative/docs/tree/master/serving/samples/...
Thank you for the link to the samples, they are much more informative. But it still doesn't quite explain it. The samples show that you can make an app, make a container, and make a service config file, and deploy your app to K8s. Yes, we've been able to do that for some time now. This thing is supposed to provide a bunch of advanced features for devs to not have to think about. However, the build repo says this: "Wh…
This seems nice though: https://github.com/knative/docs/tree/master/serving#more-sam...
It seems to have OpenTracing (Zipkin) integration: https://github.com/knative/docs/blob/master/serving/debuggin... (you need to install elasticsearch and stuff for it of course: https://github.com/knative/docs/blob/master/serving/installi... )
And assigning a custom domain: https://github.com/knative/docs/blob/master/serving/using-a-... ... okay, I was hoping that I can specify a whole URL where to mount the "app" (something like https://my.fancy.pants.tld/api/app2/
It seems to me that the weakest part of this is build currently. Mostly because that's what's pretty linear and one-off, and well explored by other projects (GitLab CI/CD can easily run on and deploy to k8s), and knative is mostly about serving and eventing, meaning all the interaction between the lifecycles of stuff on k8s.
Earlier quoted context omitted.
it's a PaaS .. heroku for k8s https://github.com/knative/docs/tree/master/serving/samples/...
It'll be interesting to see the differences from other systems in this space (OpenShift, Deis Workflow). From the samples it appears to be more of a "pull code from github and push to Dockerhub" model than a "push code to the platform and push to an internal registry" that other PaaSes target. https://docs.openshift.com/container-platform/3.3/install_co... https://deis.com/docs/workflow/understanding-workflow/archit.…
I think looking at build is not interesting, because it seems that knative currently focuses on the serving and events part (some thoughts on this you might find interesting: https://news.ycombinator.com/item?id=17607401 )
The repository is just an example. Using an internal repo seems just as easy.