Interview mit Roland Huß

„Knative ist wesentlich einfacher zu nutzen als ein ’nacktes‘ Kubernetes“

Katharina Degenmann

Gibt es eine Zukunft für Container mit Serverless auf dem Vormarsch? Und was ist der Unterschied zwischen Serverless und Function as a Service? Roland Huß, Principal Software Engineer bei Red Hat, beantwortet diese Fragen ausführlich im Interview von der Serverless Architecture Conference 2019 in Berlin.

JAXenter: Knative mischt die Serverless-Welt gerade ziemlich auf. Weshalb ist Knative so erfolgreich?

Roland Huß: Kubernetes hat sich als der de-facto Standard für Container Orchestrierung durchgesetzt. Es ist eine mächtige Plattform, die aber dadurch auch sehr komplex ist. Knative ist angetreten, diese Komplexität für Entwickler durch eine neue Abstraktionsschicht zu reduzieren, so dass Knative wesentlich einfacher zu nutzen ist als ein „nacktes“ Kubernetes. In gewisser Weise ist Knative eine „Hochsprache“, die letztendlich in Kubernetes „Assembler Code“ übersetzt wird.

Ein weiterer entscheidender Erfolgsfaktor ist, dass Knative ebenso wie Kubernetes Anbieter-neutral ist, und damit Knative-deployte Anwendungen flexibel portierbar zwischen verschiedenen Cloud-Anbietern bzw. on-premise Installationen ist.

JAXenter: Was ist Dein Lieblings Feature in Knative?

Roland Huß: Ein einzelnes Features alleine ist schwierig auszuwählen, aber sicherlich ist „Scale-to-zero“ eines der herausstechendsten Eigenschaften von Knative. Damit wird die Möglichkeit beschrieben, die Anzahl der Anwendungscontainer auf Null herunterzufahren, wenn die Applikation nicht genutzt wird. Bei den Cloud-Abrechnungsmodellen kann man hier sehr viel Geld sparen. Aber nicht nur das Pausieren von Anwendungen wird vom Knative Autoscaler abgedeckt, sondern auch die flexibel konfigurierbare, automatische Skalierung basierend auf gleichzeitig zu verarbeitender HTTP-Anfragen.

Ein weiterer entscheidender Erfolgsfaktor ist, dass Knative ebenso wie Kubernetes Anbieter-neutral ist.

Damit können Lastspitzen sehr elegant und kostengünstig abgefedert werden.

JAXenter: Das Thema Sicherheit spielt in der Entwicklung mit Cloud und Serverless immer eine große Rolle. Welche Sicherheitstipps hast du für die Arbeit mit Knative?

Roland Huß: Da Knative typischerweise zusammen mit Kubernetes betrieben wird, ist alles, was für einen sicheren Kubernetes Betrieb zu beachten ist, auch für Knative Anwendungen zu beachten. Knative Services sind HTTP(S) basiert, so dass für Verschlüsselung und Authentifizierung auf Applikationsebene die generelle HTTP Sicherheitsmechanismen wie TLS verwenden werden sollten. Die nötige Infrastruktur dafür bietet das Ingress Gateway von Kubernetes.

Neben dem direkten HTTP-Zugriff auf Knative Services sind Knative Event Quellen (Sources) weitere wichtige Eingangspforten. Hier ist zu beachten, dass die Zugangsinformationen zu diesen Quellen geschützt hinterlegt werden sollten, wobei sich hierfür einfache Anforderungen Kubernetes Secrets anbieten. Da externe Daten jedwelcher Art generell mit Vorsicht zu geniessen sind, sollten auch die über Knative Eventing erhaltenen Daten mit der entsprechenden Sorgfalt verarbeitet werden.

JAXenter: Was ist der Unterschied zwischen Serverless und Function as a Service?

Roland Huß: Der größte Unterschied liegt sicherlich darin, dass Serverless eine Deployment-Modell ist, während FaaS ein Programmiermodell darstellt.

Mit Serverless wird die Infrastruktur für den Anwendungsbetrieb soweit abstrahiert, dass sie für den Nutzer dieser Serverless-Plattformen nicht sichtbar und auch für den Betrieb der Anwendung nicht relevant ist. In Zusammenhang mit Knative auf Kubernetes ist es so, dass das Applikations-Container-Image „irgendwo“ und „irgendwie“ auf einem aus Anwendersicht „unendlich großen“ Kubernetes-Cluster betrieben wird. Wie groß der Cluster tatsächlich ist, und ob überhaupt Kubernetes direkt zugrunde liegt, ist nicht wichtig.

Funtion-as-a-Service dagegen ist ein event-zentriertes Programmiermodell, bei dem eingehenden Events von verschiedenen Quellen verarbeitet werden und dabei weiter Dienste der Plattform genutzt werden. Eine Charakteristik dieser FaaS Funktionen ist, dass diese typischerweise sehr klein sind und von dem Reichtum der zur vorhandenen Eingabe-Trigger und Dienste profitieren. Insofern kann man FaaS-Funktionen auch als „glue code“ verstehen, der sich aus dem Wunderkasten von AWS, Azure, IBM Cloud oder Google Cloud bedient und durch Kombination bestehender Dienste neue Werte schafft.

In Zukunft wird es definitiv noch viele weitere Anbieter geben, die Knative direkt unterstützen.

FaaS ohne Serverless macht wenig Sinn, da ohne Serverless die Abstraktionsstufe, auf die FaaS aufbaut, fehlt. Serverless ohne FaaS, so wie sich auch Knative versteht, hat jedoch definitiv seine Daseinsberechtigung, insbesondere wenn es on-premise und nicht in einer Public Cloud mit einer vielzahl vorhandener Dienste genutzt wird.

JAXenter: Inwiefern unterscheidet sich bzw. welche Vorteile hat Knative gegenüber AWS Lambda und Google Cloud Functions?

Roland Huß: Da AWS Lambda und Google Cloud Functions Function-as-a-Service-Dienste sind, während Knative eine reine Serverless- Container-Plattform ist, lassen sich diese nur bedingt vergleichen.

Ein Unterschied ist sicherlich, dass Knative Container-Images als Format für das Applikations-Deployment nutzt, während dies bei AWS Lambda direkt Funktionscode in einer unterstützen Programmiersprache ist. Damit ist die Ziel Granularität bei Knative gröber als bei FaaS Plattformen, so dass sich Knative insbesondere für klassische Microservice gut nutzen lässt.

Eine der großen Stärken von Knative ist, dass es nicht nur in der Public Cloud betrieben werden kann, sondern auch on-premise in den eigenen Datenzentren. Damit kann eine Anbieterabhängigkeit vermieden werden. Dass das nicht nur reine Theorie ist, kann man jetzt schon schön an den Beispielen von Google’s Cloud Run sehen, dass sowohl eine voll gemanagte Variante („Cloud Run“) als auch eine Kubernetes basierte Variante auf GKS anbietet. Die gleiche Knative Anwendungen, die in der Google Cloud laufen, können aber auch direkt auf „Red Hat OpenShift Serverless“ von Red Hat OpenShift 4 installiert werden (und vice versa). In Zukunft wird es definitiv noch viele weitere Anbieter geben, die Knative direkt unterstützen.

Serverless Expert Check 2019

Comprehensive Expert Knowledge For Free

16 experts from all over the world discuss how serverless is changing the way developers, operators, and administrators work. Expand your knowledge with the help of our Serverless Architecture Whitepaper. Stay on top of the latest trends in the field of knative, kubernetes, serverless testing as well as their drawbacks and advantages.

JAXenter: Was sollten Besucher aus Deiner Session mitnehmen?

Roland Huß: Zunächst einmal wird mein Vortrag einen Überblick über Knative geben und zeigen, wann der Einsatz von Knative Sinn macht. Wir werden dabei sowohl Knative Serving und Knative Eventing im Detail und mit Live Demos betrachten. Ziel ist es, dass die Besucher am Ende eine Idee haben, was Knative eigentlich ist, welche Mehrwert es zu Kubernetes bringt und wo es Sinn macht, Knative zu nutzen (und wo nicht).

JAXenter: Danke für das Interview!

Roland Huß is a Principal Software Engineer at Red Hat and tech-lead for Red Hat Fuse Online, an open source hybrid integration platform running on OpenShift. He has been developing mostly in Java for over twenty years now but never forgot his roots as a system administrator. Roland is an active open source contributor, developer of the JMX-HTTP bridge Jolokia and the popular fabric8 Maven plugins for Docker, Kubernetes, and OpenShift. He is also co-author of a “Kubernetes Patterns” book. And he loves chilli pepper.
Geschrieben von
Katharina Degenmann
Katharina Degenmann
Katharina Degenmann hat Politikwissenschaft und Philosophie studiert. Seit Februar 2018 arbeitet sie als Redakteurin bei der Software & Support Media GmbH und ist nebenbei als freie Journalistin tätig.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "„Knative ist wesentlich einfacher zu nutzen als ein ’nacktes‘ Kubernetes“"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
TestP
Gast

Hi,

also noch eine Abstraktion auf eine Abstraktion? Weil die Abstraktion namens Kubernetes, welches den riesigen Microservice-Park wegabstrahieren sollte selbst so komplex geworden ist, dass man noch eine Abstraktion drüber wirft? Klingt nach einem Plan. 🙂

MfG