Use Knative When You Can, and Kubernetes When You Must - David Hadas & Michael Maximilien, IBM

Use Knative When You Can, and Kubernetes When You Must - David Hadas & Michael Maximilien, IBM
Knative extends Kubernetes. It lowers costs and improves the security of the deployed services. …and yes! it also helps you become greener and save energy. This talk provides a fresh view of Knative. Forget about Serverless, consider Knative simply as an Opinionated Kubernetes. Knative advantages include Automation, Simplification, Auto-Scaling, Controlled-Revisions, and An Application Backbone. Deploying services via Knative is therefore a better choice than deploying the same services using Kubernetes directly. Knative requires each deployed service to work in a certain way. We show that many existing microservices are already built to run as Knative services offering an immediate benefit to users. Since Knative extends Kubernetes, it allows a mix and match between Knative services and Kubernetes microservices. We analyze the security benefits of deploying your services via Knative and show how Knative help protect users against configuration drift. We also show that even when users deploy vulnerable services, Knative protects such services from being exploited. Last, we show how using Knative reduces the energy footprint of your services and discuss what the future holds to continuing on this path of making Kubernetes energy efficient.

[@polyglotdev]

Awesome presentation by David and Michael!

[@polyglotdev]

I agree determining the number of pods and other scaling parameters varies greatly from project to project. I was once pressured to come out with a configuration that can cater for a huge public facing app and service. It took a couple of near total collapses of the application to finally get the right sizing. There are no magic numbers. The thing is there were issues that no amount of pods can solve. We fixed those and made drastic change in the way the services communicated from Http and stateful communication to using streams and publish-subscribe mode of communication.

[@prashar333]

Excellent presentation and demo!

[@black-snow]

Arguably, blue-green and rolling update are not the same. In blue-green you have twice the resources, roll out on green (stage), test, if okay you switch to green and blue becomes your new staging, whereas in a rolling update you just switch one pod after another, having both versions running simultaneously as long as the update takes.