Podcast mit Sebastian Kister vom Kubernetes-Kompetenz-Zentrum bei Audi Cloud-Native-Plattform-Teams in der Prinzregententorte

Anbieter zum Thema

Audi AG

AUDI AG

Vogel IT-Akademie

Kentix GmbH

Data Center Group – Büro Köln

Was hat der Automobilhersteller Audi mit Cloud Native beziehungsweise Kubernetes am Hut? Wie kommt der Konzern in der VW-Gruppe mit Open Source klar? Was macht ein Plattformteam? Das sind nur einige Fragen, die Sebastian Kister, Product Team Lead von Audi und bei der Cloud Native Computing Foundation „Transformation Evangelist“ in der #11 des „DataCenter Diaries“-Podcast erörtert.

Wie kam Audi zu Kubernetes?

Sebastian Kister: Kubernetes ist der Standard in der IT-Infrastruktur. Aber: „Was machst du eigentlich? Was ist das, dieses Zeug von dem du redest?“ fragen mich auch viele meiner Freunde. Einfach erklärt: Die digitale Welt braucht Rechenleistung und diese Rechenleistung bringen wir skalierbar und automatisiert dahin, wo sie gerade benötigt wird. Kubernetes ist das Mittel unserer Wahl und in der IT das anerkannte Mittel, um Rechenleistung zu alloziieren, also bereitzustellen. Und die Container sind das Mittel der Wahl, um dieses ressourcenschonend zu tun und auf ökonomischer Seite skalierbar zu halten.

Welche Aufgaben hat das Kompetenzzentrum?

Sebastian Kister: Wir haben mehrere Teams, mehrere Produktteams bei mir. Das eine ist mehr im Enablement Layer, Professional Services – hier geht es darum Projektteams beizubringen, mit Containerisierung zu arbeiten. Dann haben wir natürlich ein Plattformteam, das eine Kubernetes-Plattform in der Public Cloud bereitstellt, nämlich die Standard-Plattform für Public Cloud Multi-Tenancy-Kubernetes im VW-Konzern.

Und dann haben wir noch das enorm wichtige Sicherheitsteam. Hier geht es um Container-Security as a Service beziehungsweise darum Container Image- und -Runtime-Scanning oder auch Layer-7-Firewall Load Balancer zur Verfügung zu stellen … all die Mittel, die notwendig sind, um Kubernetes sicher zu betreiben. Das ist genauso wichtig, wie die Plattform selbst.

Die meisten dürften wissen, dass Audi Autos baut. Damit ist der Konzern ein Anwenderunternehmen. Geht es darum, Kubernetes als Softwaregrundlage für den nächsten "E-Tron GT RS" zu produzieren?

Sebastian Kister: Tatsächlich nicht, nein. Es ist viel komplexer. Der VW Konzern hat 400.000 Mitarbeiter, Audi ungefähr 87.000. Wir haben 6.600 Workloads im Audi-Sinn, das heißt: Applikationen und kleine Snippets, Projekte, Algorithmen, Berechnungsvorlagen, die Last verursachen. Das heißt: Wir haben alles, sowohl Applikationen pro Kunde, im IoT-Umfeld (IoT = Internet of Things), die Shopfloor-relevant sind, also in der Fabrikation, etwa damit Roboter Updates bekommen, sowie Produktivitäts-Tools wie Office-Applikationen, wie die Automatisierung einer Rechtsdienstleitung, damit diese skaliert und wir nicht etwa 500 Anwälte brauchen, sondern vielleicht nur zwei.

Aber genauso haben wir technische Entwicklungen, zum Beispiel für das autonome Fahren. Hier sind zum Beispiel immer wieder Dinge notwendig, um Fahrteile zu simulieren. Bauteile für solche Autos etwa müssen 1 Million gefahrene Kilometer nachweisen. So versucht man, diese Kilometer im Entstehungsprozess zu simulieren.

Aber warum muss sich um die Grundlagen ein Anwenderunternehmen kümmern. Im Kubernetes-Umfeld gibt es Tausende Unternehmen, die Software schreiben. Warum geht Audi nicht einfach einkaufen?

Sebastian Kister: Sebastian Kister: Die Make-or-Buy-Decision ist tatsächlich einer der wichtigsten Fragestellungen für jeden Business Case, den wir im Team angehen. Tatsächlich kaufen wir sehr viel ein. Wir müssen Value Add fokussieren und schauen, wo wirklich Enablement für unsere Innovatoren, also für das Kerngeschäft entsteht.

Beispielsweise 2019 war der Control-Planes-Markt im Cloud-Native-Umfeld gigantisch: 20 Firmen haben verschiedene angeboten – jetzt aber haben sich ein paar Branchengrößen herauskristallisiert. Aber 2017 haben wir noch eine proprietäre Audi-Control-Plane gehabt, quasi ein Audi-eigenes Kubernetes. Das war ja zu dem Zeitpunkt auch noch die frühe Kubernetes-Phase. Jedenfalls wurde die Lade-Funktion für den ersten „E-Tron“ auf dieser Plattform entwickelt.

Die Entstehung des Control-Plane-Markts 2019 macht es heute vollkommen überflüssig, über die Entwicklung einer eigenen Control Plane zu diskutieren. Das machte keinen Sinn; denn das ist kein Business Value, sondern absolut Commodity.

Im Bereich Security kaufen wir auch viel ein, betreiben aber zum Beispiel aber das Policy Enforcement für die Container-Images selbst. Das muss ich selbst betreiben. Das sind VW-Policies, das sind unsere eigenen Maßnahmen, die wir ergreifen wollen. Das können wir keinem anderen überlassen.

Da sind wir Enabler, weil wir Dinge sehr, sehr sicher gestalten. Ich sehe Security tatsächlich als Teil der Wertschöpfungskette und nicht als Kostenfaktor, weil sie Time-to-Market ermöglicht und Dinge beschleunigt. Das ist ein ganz klarer Business Case, der an einer guten Security dranhängt.

Was ist unter den Security Policies zu verstehen? Wer wann auf welche Daten zugreift? Wer welche Logik verändern darf?

Sebastian Kister: Bleiben wir bei dem Beispiel im Infrastruktur-Level. Wenn ich das Container-Image-Scanning nehme und die Automatisierung vom Developer bis zur Runtime, der Laufzeitumgebung im Kubernetes-Cluster, soweit mit Quality Gates versehe, dass der Entwickler schon während des Erstellens sieht, dass die neue Software auf der Infrastrukturebene akzeptiert werden würde, dann kann ich die ganzen Reibungsverluste, zum Beispiel mit Betriebsübergaben minimieren oder gar eliminieren. Er oder sie kann etwa in der Build-Phase oder schon im Code erkennen, ob die Library, die verwendet wird, einen kritischen Vulnerability-Prozess, einen Alert oder sogar ein Blocking auslösen würde.

Wie viele Leute arbeiten im Competence Center und wie viele profitieren von der Arbeit?

Sebstian Kister: Ich habe heute die 15. Person den anderen vorgestellt. Wie viele genau in unserem Knowledge Sharing Layer arbeiten, weiß ich nicht genau, aber es dürften etwa 500 in der gesamten VW-Gruppe sein.

Wie geht der Konzern mit Open Source um?

Sebastian Kister: Das ist ein harter Kampf gewesen; ich habe ihn 2019 initiiert.

Warum war das hart?

Sebastian Kister: Es geht darum, Audi-Intellectual-Property herzuschenken. Das ist rechtlich keine triviale Geschichte.

Im „Podcast #11: Sebastian Kister, Audi, über Cloud-Native-Plattform-Teams in der Prinzregententorte“; erläutert der Leiter des Kubernetes-Kompetenz-Zentrums bei Audi, unter anderem, wie bei ihm Open Source gehandhabt wird.

Das heißt, dass in Audi entwickeltes Know-how und Code an die Community zurückgegeben und nicht nur Open-Source-Software genutzt wird?

Sebastian Kister: Ja, tatsächlich unterscheiden wir das. Dass man Open Source nutzt, war unvermeidbar und auch schon vor meinem Einstieg 2019 der Fall. Fünf Monate später habe ich dann den Prozess begleitet, mit geistigem Eigentum von Audi zu Open-Source-Projekten zu kontribuieren, zu annotieren oder ganze Audi-Projekte zu Open Source zu machen. Das hatte vor allem ein Business Case ausgelöst, den ich geschrieben habe. Denn der wurde letztlich von den Rechtsabteilungen, vom Vorstand und vom Betriebsrat abgesegnet.

Heute ist man glücklich damit oder ist es immer noch ein Thema?

Sebastian Kister: Man ist tatsächlich sehr glücklich damit. Die Cloud Native Community umfasst inzwischen 80.000 Mitglieder. Wir haben pro Jahr 200.000 Code-Commits auf Kubernetes, bei Audi hätten wir ohne Operations fünf oder sechs Entwickler oder auch vielleicht 20 – die Zahl ist egal - …. Entweder ich umarme die Öffnung zu Open Source und nehme komplett, was sie bietet, dann kann ich quasi jedes Update inhalieren und davon profitieren, muss dann aber im Gegenzug die Proprietaries, die ich entwickle, wieder zurückgeben, so dass alle davon profitieren können.

Schließlich sind wir in der Infrastruktur. Und hier ist es egal, ob ich Autos oder Turnschuhe entwickle. Wir machen keinen Wettbewerbsvorteil, indem wir Infrastruktur proprietär betreiben, absolut nicht.

Wie ist das organisiert?

Sebastian Kister: Es gibt in der VW-Gruppe tatsächlich die Full-Open-Source-Abteilungen, die völlig frei beisteuern können. Somit gibt es tatsächlich Leute, die voll ausgeprägt Kontributoren sind. Wir jedoch machen bei uns vor allem ein Adaptions-Driving. Das heißt: Wir versuchen die Umsetzung von Cloud-Native-Technologien in die Organisation zu tragen, also unsere eigenen Leute im Umgang zu schulen aber auch bei der Entwicklung damit umzugehen.

Was war das Spannende, das Bahnbrechende auf der vergangenen KubeCon/CloudNativeCon in Amsterdam?

Sebastian Kister: Die CNCF hat ihre neue Foundation gepusht und im CTO-Summit ging es nur um FinOps. Auch bei uns, bei Audi und im Kompetenz-Zentrum, ist das Thema sehr tief angekommen. So haben wir schon FinOps-Teams laufen, die sehr, sehr gute Ergebnisse, richtig gute RoI-Kennzahlen erzielen. Wir sind richtig begeistert von unseren FinOps-Teams. Sie sind auch kulturell wichtig, um nicht einfach irgendwelche Kosten-agnostische Infrastrukturen irgendwohin zu klatschen – Hauptsache es hat den Namen Cloud.

FinOps ist eigentlich nicht der heiße Scheiß, jeder weiß, dass er es braucht. Aber ich habe auch gesehen, dass das bei vielen Firmen noch gar nicht da ist. Deswegen war das das große Ding für die meisten.

Was gehört zu FinOps?

Sebastian Kister: Ganz klar, es ist immer eine gesamtheitliche Betrachtung notwendig. Wire gesagt, wir betrachten etwa Security als Teil der Wertschöpfungskette, weil das Auswirkungen auf die KPIs hat. FinOps ist eine holistische Komponente, das Generalisten braucht, etwa um in der Architektur zu beraten oder gesamtwirtschaftliche Betrachtungen anstellen zu können, um eventuell auch so etwas wie start of production zu beeinflussen.

Kubernetes / Cloud Native erobert den IT-Betrieb

Neue Aufgaben für die CNCF-Community

Für mich stark im Vordergrund haben sich Thematiken rund um Plattformteams beziehungsweise Plattform-Engineering gedrängt. Kannst du erläutern, warum die Bildung solcher Gruppen zur Beschleunigung und Effizienzsteigerung in der Entwicklung und im Bereich Operations beitragen können sollen?

Sebastian Kister: Wir haben auch Plattform-agnostische Produktteams. Je größer eine Organisation und komplexer und heterogener die Kundengruppe ist, desto mehr Schichten bekommt deine Prinzregententorte - Layer. Aber irgendwann reicht das Schichtenmodell nicht und du brauchst einen Schoko-Rand draußen herum, in diesem Fall die vertikalen Services.

Aber alles zu zentralisieren ist tatsächlich ein großes Problem und nicht die Lösung. Zum Beispiel spricht die Aufgabe, Risiken zu verteilen ganz klar gegen den Zentralsierungsgedanken. So mache ich jeden Managed Service auf einer Plattform zu einem Produktteam; denn es gibt nicht Schlimmeres als eine Plattform, die ein dezidiertes Requirement bekommt und einen Managed Service on top macht.

Weiter geht es im DataCenter-Diaries-Podcast #11:

Es geht um Echtzeit und KI, um Standardisierung und Best of Breed. Einfach hineinhören! Die Folgen von Datacenter Diaries gibt es beiAmazon Music, Apple, Deezer, Google Podcast und bei Spotify.

(ID:49429229)