Moderation: Hallihallo und herzlich willkommen zur Radiotux-Sendung im April 2024.
Moderation: Und das Hauptthema dieser Sendung wird die CubeCon 2024 sein,
Moderation: die CubeCon Europe genauer gesagt, die einmal im Jahr stattfindet und mittlerweile
Moderation: über 12.000 Besucher anzieht.
Moderation: 12.000 Besucher waren in Paris und das macht das Ganze zur größten Open Source
Moderation: Konferenz tatsächlich auf diesem Planeten.
Moderation: So viele Leute wieder rumgewuselt sind, habe ich tatsächlich schon lange nicht mehr gesehen.
Moderation: Die KubeCon wird zusammen mit der Cloud Native Computing Foundation veranstaltet
Moderation: und wie gesagt, dieses Mal wurden so viele Leute nach Paris geladen.
Moderation: Ich bin nach Paris natürlich mit dem Zug gefahren, wie es bei mir üblich ist.
Moderation: Zurück bin ich sogar mit dem Nachtzug gefahren.
Moderation: Hinzu bin ich mit der Deutschen Bahn gefahren und ich muss sagen,
Moderation: es hat tatsächlich alles geklappt.
Moderation: Und wir haben ein Interview mit jemandem von der Deutschen Bahn und es geht tatsächlich darum,
Moderation: wie die Deutsche Bahn Cloud-Native-Technologien, in dem Fall Kubernetes,
Moderation: einsetzt und wie sie es auch schaffen will mit bestimmten Tools,
Moderation: CO2-neutral werden will für die Zukunft.
Interviews: Ich bin jetzt hier auf der KubeCon 2024 in Paris.
Interviews: Bei mir ist Gualta Baptista. Er ist Lead Consultant for Platform Strategy bei
Interviews: der Deutschen Bahn. Hallo Gualta. Hallo.
Interviews: Und du hast heute eine Keynote gehalten hier.
Interviews: Ihr setzt auf jeden Fall Kubernetes ein. Wie kam es dann dazu?
Interviews: Warum habt ihr gesagt, okay, bei der Deutschen Bahn brauchen wir Kubernetes? Ja, also wie kam dazu?
Interviews: Vor meiner Zeit, muss ich sagen.
Interviews: Wir hatten, aber ich denke, wir können damit anfangen mit der gesamthaften Entscheidung
Interviews: der Konzerne in der Cloud zu migrieren.
Interviews: Also wir waren gerade in 2016 und es gab die Entscheidung, wir verkaufen unser
Interviews: Rechenzentrum komplett,
Interviews: sofort und mieten eine Zeit lang, aber wir migrieren komplett in der Cloud bis
Interviews: zum, ich glaube 2021 war der Plan.
Interviews: Wir haben damit, war natürlich der erste Impuls,
Interviews: nicht unbedingt eine optimierte Migration in der Cloud zu schaffen,
Interviews: denn wir hatten natürlich eine sehr vielfältige Landschaft, was Anwendungen
Interviews: angeht, von großen Monolithen-SAPs bis auch moderne Architekturen.
Interviews: Aber viele gingen nicht anders, als ein Lift and Shift zu machen.
Interviews: Das war tatsächlich der große Anstoß, zu sagen, ja, wir enden das.
Interviews: Wir geben auch ein klares Signal aus dem Management, dass es hier was zu enden ist.
Interviews: Nicht nur, weil wir ein Rechenzentrum verkaufen, sondern die ganze Art und Weise,
Interviews: wie wir Technologie angehen, ändern. Mit mehr agiler Arbeit,
Interviews: agiler Organisation, mit einem DevOps-Produktion-Modell als favorisiertes Modell.
Interviews: Und in dieser Konstellation kam auch tatsächlich dazu, dass einige Teams in
Interviews: diesem agilen Umfeld, Selbstorganisation und so weiter.
Interviews: Nebenbei angefangen haben, Kubernetes zu nutzen.
Interviews: Kubernetes war gerade relativ neu in dem Umfeld.
Interviews: Und ich denke, 2017 kam der erste Einsatz mit OpenShift, Red Hat OpenShift.
Interviews: Und auf dieser Basis wurde die erste Kubernetes-Plattform aufgebaut.
Interviews: Auch andere Teams haben angefangen, Richtung EKS, Rancher und so weiter.
Interviews: Kubernetes umzusetzen.
Interviews: Und da ist dann eine Landschaft von verschiedenen Kubernetes-Lösungen entstanden,
Interviews: die parallel zu dieser ganzen Lift & Shift auch was dazu beigetragen haben.
Interviews: Was interessant auch war, hier ist das, obwohl das nicht der Kern der Strategie
Interviews: für die Migration der Cloud war und hat auch gehofft, direkt diese Cloud-Native-Gedanke reinzubringen.
Interviews: Wie baue ich eine Microservice-Architektur? der Konzept von 12-Factor-App und so weiter und so fort.
Interviews: Und dieser ganze Gedanke hat angefangen da zu spielen. Wir hatten tatsächlich
Interviews: auch die OpenShift-Cluster auch Anwendungen, die eigentlich da nicht gehören hätten.
Interviews: Die haben total erschwert am Anfang der Betrieb,
Interviews: indem zum Beispiel wir könnten nicht Nodes abschalten, weil sonst würden diese
Interviews: Anwendungen kaputt gehen, weil Lizenzen bedingt und so weiter,
Interviews: könnte nicht gleichzeitig in zwei Nodes laufen.
Interviews: Und das hat sehr viel, ich sage
Interviews: auch, Erziehungsarbeit bedeutet für das Plattform-Team, das damals da war.
Interviews: Und es war auch ein Lernprozess, sowohl für die End-User der Plattform,
Interviews: als auch für das Plattform-Team, das auch relativ neu und unerfahren in dem
Interviews: Bereich war und am Anfang alles akzeptiert hat und immer alle Ausnahmen gemacht hat.
Interviews: Und dann haben wir uns progressiv mehr in Richtung Einstandardisierung bewegt.
Interviews: Im Sinne von, die Plattform hat bestimmte Standards, das sind Bedingungen,
Interviews: Share Responsibility und dann könnt ihr das nutzen, aber ihr müsst auch diese
Interviews: Prinzipien auch achten.
Interviews: Das heißt, jetzt habt ihr gar kein Rechenzentrum mehr? Das ist alles abgeschlossen?
Interviews: Die Deutsche Bahn macht alles in der Cloud? Alles migriert, alles in der Cloud.
Interviews: Es gibt natürlich ein paar Ausnahmen, Anwendungen, die noch im gemieteten Rechenzentrum
Interviews: dann noch laufen, sind eher die Ausnahme, aber grundsätzlich haben wir eine
Interviews: Cloud-first-Strategie.
Interviews: Wir haben zwei Cloud-Providers, unsere strategischen Partner,
Interviews: AWS und Azure und wir sagen, da gehen wir mit voller, voll in der,
Interviews: genau, in dieses Service der Providers.
Interviews: Jetzt hast du schon gesagt, ihr habt OpenShift, ihr habt Brancher im Einsatz.
Interviews: Welche Toolchain haben die Entwickler dann? Bietet der immer noch alles an oder
Interviews: habt ihr irgendwann gesagt, okay,
Interviews: nee, also ihr müsst euch jetzt für eins entscheiden und wir nehmen das und ihr
Interviews: müsst GitOps machen mit GitHub oder mit GitLab oder können sich die Entwicklerteams
Interviews: immer noch ihre Toolchain aussuchen?
Interviews: Wir haben auch aufgrund von, es ist eine sehr vielfältige Organisation und das
Interviews: besteht immer noch eine relativ vielfältige Landschaft, aber es gibt eine Konvergenz.
Interviews: Wir haben in den letzten Jahren zum Beispiel eine Initiative konzernweit aus
Interviews: der Plattformstrategie angegangen, die heißt Build IT.
Interviews: Die Build-IT-Plattformen sind konzernweite Entwicklungsplattformen oder Technologie-Plattformen
Interviews: zu Developer Experience, zu Artificial Intelligence, Low-Code,
Interviews: No-Code, Data Management und Enterprise Integration.
Interviews: Und diese sollen als Standard angeboten werden und favorisiert über andere Lösungen.
Interviews: Insbesondere die Developer Experience Plattform wird sehr stark gepusht im Sinne
Interviews: von, es ist zum Teil schon verpflichtend einige Komponenten dafür zu nutzen,
Interviews: zum Beispiel ein GitLab oder ein Artifactory, wo die Artefakten eingesammelt
Interviews: sind wenn ich davon abweiche,
Interviews: muss ich sehr gut das begründen und gegebenenfalls auch in diese Plattform auch
Interviews: zusätzlich dann noch die Artefakten einsammeln Es wird jetzt auch gepusht,
Interviews: dass wir zum Beispiel die Standard-Pipelines,
Interviews: da haben wir einen Service, CICD-Service, die ein modularisierter Pipeline hat.
Interviews: Dass diese auch ein Standard und wenn keine Architectal Decision Record sozusagen
Interviews: eine andere Begründung gibt, die sagt, okay, ich nutze das nicht,
Interviews: weil ich so oder so nicht das machen kann, was ich brauche.
Interviews: Wenn das nicht vorliegt, dann ist es schwer zu sagen, dass es verpflichtend
Interviews: ist, aber es ist schon schwer, das nicht zu nutzen.
Interviews: Man muss sich schon sehr gut rechtfertigen und das pushen wir immer weiter.
Interviews: Okay, also die Entwickler kriegen eine Toolchain an die Hand und wenn sie sagen,
Interviews: ja gut, das geht jetzt gar nicht und das gut begründen können,
Interviews: dann könnten sie schon was anderes machen. Wie kriegt ihr dann oder wie sammelt ihr das Feedback an?
Interviews: Wie nehmt ihr die Entwickler mit, die ja kommen und sagen, ja,
Interviews: ich kenne aus Unternehmen X irgendwie die und die Sachen und ich fände gut, wenn das jetzt hier ist.
Interviews: Also wie holt ihr euch das Feedback an und sagt, okay, das ist unsere Toolchain
Interviews: und das machen wir jetzt so? Wir haben mehrere Wege zum Anforderungsmanagement.
Interviews: Also mit den BuildIT-Plattformen haben wir zum Beispiel einen Plattform-Circle
Interviews: gegründet, der regelmäßig Informationen ausgibt über den aktuellen Stand der Plattformen,
Interviews: was ist vorgesehen in den Roadmaps und auch Feedback von den Teilnehmern zusammenbringt.
Interviews: Und da sind alle Geschäftsfälle beteiligt.
Interviews: Dann haben wir ein Werkzeug, das auch sehr nützlich ist für die Anforderungsmanagement.
Interviews: Das nennt sich der Anwender Echo.
Interviews: Und da kann jeder Mitarbeiter Anforderungen an mehrere Services einkehren.
Interviews: Einige von denen die Plattformen, die werden auch aktiv betrachtet und ein wichtiger
Interviews: weiterer Aspekt ist, alle diese Tooling sind aus InnoSource verfügbar.
Interviews: Das heißt, auch zum Beispiel, wenn ich diese Modular-Pipeline nicht finde,
Interviews: der Modul, den ich brauche, um genau das zu machen, was ich möchte,
Interviews: kann ich ein Contribution machen, ein Much-Request und die wird dann reviewed
Interviews: von dem Plattform-Team und integriert.
Interviews: Und damit schaffen wir tatsächlich diesen Netzwerkeffekt und diese Ökosystem-Wirkung,
Interviews: indem unsere Toolchain immer.
Interviews: Nicht nur durch die Plattform-Teams aus Produzenten, sondern dass wir das gesamte
Interviews: Ökosystem von End-Nutzer auch zum Teil aufs Produzent reinbringen.
Interviews: Das heißt jetzt aber auch, wenn ich jetzt nicht nur Inhouse entwickle und eure
Interviews: Toolchain erweitere, sondern wenn ich jetzt an einem Open Source Projekt was
Interviews: weiß ich, ich habe bei GitLab irgendwie einen Fehler gefunden und kann ich das
Interviews: dann auch ins Upstream Projekt geben?
Interviews: Also kann ich dann auch sagen, okay, hier, ich fixe jetzt den Fehler im Open
Interviews: Source Tool und dann kommt es irgendwann wieder zurück in meine Pipeline? Also das geht auch?
Interviews: Genau, also wir haben sogar von unserer Vorständin auch auch ein Open-Source-Manifest
Interviews: veröffentlicht, in dem wir wollen der Nehmen und Geben mit dem Open-Source haben.
Interviews: Ich denke, dass es noch ein wachsendes Feld ist. Es fehlt ihm oft im Enterprise-Umfeld
Interviews: die Zeit, um diese Contributions zu machen.
Interviews: Aber es gibt schon einige. Wir haben ein eigenes, zum Beispiel von der Debit
Interviews: System, gibt es eine eigene Gruppe in GitHub, wo verschiedene Contributions
Interviews: in den Open-Source-Projekten sind.
Interviews: Und es gibt dann ein Open-Source-Contribution-Policy und Dokument,
Interviews: an dem durch ein sehr einfaches Prozess diese Open-Source-Contributions auch
Interviews: dann formell genehmigt sind.
Interviews: Das ist schön. Dann habe ich auch, oder ich sehe öfter mal, dass ihr auch so
Interviews: Hackathons habt, wo sich Entwickler dann zusammensetzen und dann kommt irgendeine
Interviews: Webseite raus, wo man sieht, wo die Züge jetzt gerade unterwegs sind oder irgendwas.
Interviews: Also ihr guckt auch, dass die Entwickler ab und zu mal zusammenkommen und auch
Interviews: da sagen können, was sie gerne an was sie gerne bauen würden.
Interviews: Ja, das finde ich ganz wichtig, vor allem so in einem Umfeld,
Interviews: wo die Teams sehr in dieser Selbstorganisation arbeiten und oft wenig miteinander
Interviews: kommunizieren, dass solche Community Events stattfinden.
Interviews: Und die sind meistens thematisch. Wir können einen Hackathon zu Plattformen
Interviews: haben, wir können einen Hackathon zu Data haben. Und das ermöglicht,
Interviews: dass die Menschen tatsächlich zusammenkommen und Prototypen entwickeln.
Interviews: Die bringen Ideen zusammen, vielleicht finden, dass die ähnliche Herausforderungen
Interviews: haben und finden auch Zeit außerhalb dieses Scrum Sprints, alles abzuarbeiten,
Interviews: ein bisschen Zeit raus, um einfach kreativ, innovativ zu denken und vor allem
Interviews: sich zu vernetzen miteinander.
Interviews: Genau, mal zusammenzukommen, mal denselben, nicht nur in irgendeiner Telekommunikation,
Interviews: Konferenz mal zu sehen, sondern ihn auch mal echt zu sehen.
Interviews: Beste Idee, kommen wir bei Kaffee. Bei Kaffee trinken, setzen sich die Menschen
Interviews: und sprechen über etwas, die vielleicht nicht mal geplant war,
Interviews: in diesem Raum stattzufinden und das sind...
Interviews: Sehr wichtige Momente. Solche Sachen kommen dann wahrscheinlich auch,
Interviews: also ja, dass es dann Verbesserungen gibt, was weiß ich, am DB Navigator oder
Interviews: so, dass dann irgendein Team sagt, okay, lasst uns doch das einbauen.
Interviews: Also ich nehme an, alles, genau, die Webseite, wenn man auf Deutsch Bahn kommen
Interviews: geht oder auf DB, das ist alles dann, das ist alles, was ihr oder was auf der Plattform läuft, oder?
Interviews: Nicht alles, aber vieles, genau. Also der Website, wenn wir sprechen von BAN.de,
Interviews: das sind sehr viele Komponenten zusammengestellt, also das ist nicht so ein
Interviews: Monolith, die da mit einem Backend, sondern das sind tatsächlich sehr viele
Interviews: Komponenten und Systeme da, die dahinter laufen,
Interviews: die ganze Reiseinformation zum Beispiel und viele laufen auf Plattform.
Interviews: Manche laufen auch auf Plattform-ähnliches Service, also da sprechen wir zum
Interviews: Beispiel andere Teams, die auch Kubernetes genähtes Betreiben als fast ein Plattform-Service,
Interviews: aber nur für einen bestimmten Bereich, zum Beispiel für die Reiseinformation.
Interviews: Aber auch mit dieser gibt es Konvergenz. Es gibt ja auch den Wunsch,
Interviews: eine Standardisierung zu schaffen,
Interviews: weil wir merken, also wir kriegen nicht mehr Personal, sagen wir so.
Interviews: Fachkraftmangel gibt es überall und die Digitalisierung wird immer vorangetrieben.
Interviews: Das heißt, wir müssen mehr schaffen mit der gleichen Menge oder manchmal sogar wenige Menschen.
Interviews: Und das ist der Herausforderung. Deswegen, die Teams suchen auch,
Interviews: wie können wir unsere bestehende Plattform, die uns enormen Aufwand in den Betrieb
Interviews: kostet und vor allem in der Mitkommen mit den neuen Governance-Vorgaben,
Interviews: die regelmäßig auch rauskommen,
Interviews: wie kann ich das ablagern in eine Standardplattform und auf diese Plattform switchen.
Interviews: Und da gibt es auch sehr viele Dialoge intern und ich denke,
Interviews: die Tendenz ist da, dass es in den nächsten Jahren viel weniger von diesem einzelnen
Interviews: System gibt es so mehr Konvergenz auf einstandardisierte Plattformen.
Interviews: Jetzt hat die Deutsche Bahn ja auch eine Nachhaltigkeitsstrategie.
Interviews: Es gibt immer, das ist grün, Projektnummer sowieso.
Interviews: Auch in deinem Vortrag heute ging es so in die Richtung Green IT.
Interviews: Was macht die Deutsche Bahn, also was macht die IT der Deutschen Bahn,
Interviews: um auch grüner zu werden an der Stelle?
Interviews: Also ein ganz wichtiger Punkt dabei war, dass wir bei der Ausschreibung bei
Interviews: unseren Cloud-Providers groß geschrieben haben, wir möchten Carbon-Neutralität haben.
Interviews: Das heißt, die Cloud-Providers werden in den nächsten Jahren uns garantieren
Interviews: müssen, dass die Leistung, die wir verbrauchen, auf irgendwelchen Weg auf null,
Interviews: CO2-Emissionen kommen.
Interviews: Das ist natürlich mit Kompensation zusammen. Das heißt nicht,
Interviews: dass alles mit nur erneuerbarer Energie ist oder so, oder wie das ist,
Interviews: das muss natürlich Cloud-Provider sagen.
Interviews: Wir haben aber auch deswegen die Idee, um die anderen Bereiche der Nachhaltigkeitsstrategie,
Interviews: wie zum Beispiel die Effizienz und die Suffizienz anzugehen,
Interviews: andere Initiativen eingegriffen.
Interviews: Wir haben angefangen mit dieser Initiative Grüne Digitalisierung aus dem Konzern,
Interviews: wo verschiedene CIOs sich zusammen gestoßen haben,
Interviews: zusammen mit dem Graswurzel sozusagen ein paar Entwickler und interessierte
Interviews: Leute in diese Initiative konfiguriert haben in 2022 und damit haben wir die
Interviews: ersten auch Pilotprojekte da in der Richtung angefangen.
Interviews: Und einer von diesen Projekten, was ich heute hier auch gezeigt habe,
Interviews: war mit Kepler, um ein Dashboard für Entwickler in die Hand zu geben.
Interviews: Weil über die Cloud-Providers bekommen wir zu wenig Information.
Interviews: Also wir bekommen allgemein eine Berechnung des CO2 für einen gesamten Account.
Interviews: Aber zum Beispiel in unserem Fall, wie oft Service-Teams oder Plattform-Teams,
Interviews: da laufen mehrere Anwendungen auf einen Account.
Interviews: Außerdem ist diese Information nicht granular genug oder nicht zeitaktuell.
Interviews: Und davor haben wir uns dann in die Open-Source-Umfelder und die CNCF-Ökosysteme
Interviews: umgeschaut und diese Kepler-Tool gefunden.
Interviews: Und Kepler ermöglicht uns tatsächlich, dass wir in fast Echtzeit Energiedaten
Interviews: für Kubernetes-Clusters, aber auch für deren Anwendung bis auf Container-Ebene erfassen können.
Interviews: Das heißt, ich sehe dann nicht nur auf Jahresebene, wie viel CO2 die ganze Plattform
Interviews: braucht, sondern ich kann das, weiß ich nicht, sehe das auf Sekundenbasis oder
Interviews: wie granular ist das Ganze?
Interviews: Genau, die Granularität hängt von wie oft wir scrapen.
Interviews: Das ist letztendlich, Kepler macht nicht anders, als dann ein Export zu haben,
Interviews: die dann von Prometheus abgefragt ist und diese Daten kommen dann in die Time
Interviews: Series Datenbank von Prometheus. ist.
Interviews: Und wie granular es ist, können wir definieren. Wir haben allerdings erfahren, dass es zu,
Interviews: häufige Anfragen auch zu Skalierungsproblemen bringt, weil das sind sehr hohe
Interviews: Kardinalität, sehr viele Metrics und das brauchen wir auch nicht.
Interviews: Das kostet auch alles Energie.
Interviews: Dann am Ende kostet mehr unsere Metrics-Erfassung mehr Energie als die Auswirkung,
Interviews: dass wir damit einsparen können.
Interviews: Das wollen wir natürlich nicht und es ist wichtig, da einen Trade-off zu finden.
Interviews: Aber Aber auch wichtig ist, und deswegen ganz interessant mit diesem Tool,
Interviews: dass ich den Entwicklern in der Hand was gebe, die ihnen ermächtigt,
Interviews: Entscheidungen zu treffen.
Interviews: Und auch die Auswirkung von diesen Entscheidungen direkt zu sehen.
Interviews: Ich mache einen Merge-Request.
Interviews: Ich merge das, die Pipeline läuft, vielleicht macht deine Pipeline sogar eine
Interviews: Notation in Grafane und ich sehe, okay,
Interviews: Commit X wird da gemacht und wie hat das ausgewirkt auf Container Y und kann
Interviews: sofort ein Feedback bekommen.
Interviews: Und das finde ich einen ganz wichtigen Aspekt, um genau diese Themen,
Interviews: was ich heute auch da gebracht habe, Developer Empowerment.
Interviews: Weil es geht darum, dass jeder Akteur, jeder Agent mitwirken kann,
Interviews: um effizient zu steigen in der IT.
Interviews: Genau, das ist dann also nicht nur das Management, was drauf guckt und dann
Interviews: dem Team sagen würde, ey, ihr müsst so und so viel CO2 jetzt einsparen,
Interviews: sondern es kann, jeder Entwickler kann in dieses Dashboard alleine reingehen
Interviews: und sieht gleich, welche Auswirkungen seine aktuelle Arbeit hat. Genau.
Interviews: Und ich sage auch immer, ein Entwickler interessiert sich weniger vielleicht
Interviews: für die Kosten, weil wir könnten sagen, ja, wenn du Kosten machst, dann reicht das schon.
Interviews: Und ich sage, nee, reicht nicht, weil ich als Entwickler, was interessiert mich,
Interviews: ob das mir 5.000 kostet oder 10.000?
Interviews: Also solange der PO nicht kommt und sagt, wir sind über dein Budget und stellt
Interviews: ein Story dazu, dann werde ich nichts davor machen, weil es ist nicht mein Geld.
Interviews: Aber es ist unser Planet für alle. Und deswegen meine Hypothese ist,
Interviews: es gibt eine intrinsische Motivation und ich denke viele Mitarbeiter in der
Interviews: Bahn noch stärker vielleicht dazu, dass
Interviews: die sich zu einem nachhaltigen Mobilitätsunternehmen dazu gekommen sind.
Interviews: Genau, deswegen fahren wir ja alle gerne Bahn und eben nicht im Flugzeug oder so. Genau.
Interviews: Und ja, und davor haben wir diese interessierte Motivation.
Interviews: Aber wir brauchen, was in der Hand der Entwickler zu geben, die ja dann auch
Interviews: ein Inzentiv hat, um was da zu machen.
Interviews: Das heißt, ich sehe dann in diesem Dashboard, was mein Merge-Request ausgelöst
Interviews: hat und könnte dann ein Rollback machen und könnte sagen, okay,
Interviews: ja, plötzlich braucht die Anwendung doppelt so viel CPU oder so.
Interviews: Genau. Kostet dann so und so viel CO2.
Interviews: Dann habt ihr, ich glaube, du hast es auch im Vortrag oder in deiner Keynote
Interviews: gesagt, auch solche Sachen, dass ihr nachts ein paar Sachen ausschaltet, oder?
Interviews: Dass ihr gemerkt habt, bestimmte Sachen brauche ich ja nur tagsüber.
Interviews: Ja, das ist aus meiner Sicht direkt der größte Waste und eigentlich was am einfachsten zu lösen ist.
Interviews: Da muss ich nichts machen, außer Workloads ausschalten, die keiner in der Nacht
Interviews: nutzt. Also eine Entwicklung Umgebung.
Interviews: Wofür ist eine Entwicklung Umgebung? Oder eine Abnahme Umgebung?
Interviews: Die sind da, um zu testen. Aber um Mitternacht ist keine da, die das testen wird.
Interviews: Also ich kann das, danke Kubernetes, sehr einfach und sehr simpel ausschalten.
Interviews: Es gibt ein kleines Komponent, das heißt Cube Downscaler.
Interviews: Es reicht dann, ein Annotation zu machen, wo ich sage, von der Uhrzeit bis zur
Interviews: Uhrzeit läuft meine Anwendung und außerhalb dieser Zeit, zum Beispiel außerhalb
Interviews: der Office Hours, schaltet der automatisch ab. Am nächsten Tag wird die wieder aufgebaut.
Interviews: Ich spare direkt bis zu 70 Prozent. Das ist der Zeit, an dem ich nicht im Büro bin.
Interviews: Aber ich habe auch damit einen gewissen SRE-Einsatz, weil ich kann jederzeit
Interviews: sehen, ist meine Anwendung bereit, wieder hochzukommen, wenn ich den wieder
Interviews: abschalte. Und das ist auch absolut relevant.
Interviews: Also ich habe einen Double Win da, im Sinne von, ich spare Geld und ich sehe,
Interviews: dass meine Anwendung tatsächlich stabil in einer dynamischen Umgebung laufen kann.
Interviews: Und wie ist das Feedback der Entwickler? Freuen die sich alle,
Interviews: dass es dieses Dashboard gibt?
Interviews: Ja, wir sind gerade in der Ausrollphase. Also die existiert schon zum Testen. Der Dashboard ist da.
Interviews: Kepler Metrics werden schon erfasst aktiv in unserer Plattform.
Interviews: Es kommt immer die Anfrage, wie kann ich das installieren? Und wir warten,
Interviews: dass das Observability Team die offizielle Release macht. Das ist vielleicht
Interviews: eine kleine Sache, die wir noch anpassen wollen.
Interviews: Aber viele können nicht warten und installieren schon die Testversion und so
Interviews: weiter. Also ich denke, die Adoption ist relativ gut.
Interviews: Menschen mögen Dashboards, das ist einfach schön zu sehen auch.
Interviews: Und da ist die Adoption groß. Und bei CubeDownScaler haben wir auch ein enormes
Interviews: Wachstum gesehen, seit wir das veröffentlicht haben und gesagt haben, komm, nutz das.
Interviews: Und wir haben seit November ein Wachstum von ca.
Interviews: 300% in der Adoption von der CubeDownScaler. Und das ist bestimmt auch wieder
Interviews: schön zu sehen, wie viel CO2 ihr einspart. Ich weiß nicht, veröffentlicht ihr das irgendwo?
Interviews: Gibt es dann irgendwo mal eine Pressemitteilung oder so, dass man weiß,
Interviews: wie viel ihr jetzt vielleicht eingespart habt durch dieses Projekt?
Interviews: Ne, das haben wir noch nicht. Das sind auch manchmal Daten, müssen wir dann
Interviews: immer checken, dürfen wir das veröffentlichen oder nicht.
Interviews: Also erstmal haben wir das für die interne Nutzung bei uns.
Interviews: Es geht auch weniger darum, dass wir genaue Daten haben, weil wir wissen auch
Interviews: nicht, sind die Daten, haben wir wirklich eine Qualität in den Daten?
Interviews: Sind die Energiemessungen korrekt, was Kepler aus Basis von diesen Modellen
Interviews: hat? Oder brauchen wir bessere Modelle, damit wir bei unseren Rechenzentren
Interviews: oder bei unseren Public Clouds gute Zahlen bekommen?
Interviews: Aber es geht weniger um die Genauigkeit der Daten, sondern mehr über die Trends.
Interviews: Weil ich agiere auf Basis der Trends. Ich sehe, habe ich 30% reduziert oder 20% erhöht?
Interviews: Ich denke, solche Daten werden wir vielleicht gegen Ende des Jahres auch im
Interviews: Sinne von prozentualer Ansatz.
Interviews: Etwas sagen können, da bin ich sicher. Aber genaue Daten würde ich auch nicht
Interviews: machen, weil, wie gesagt, dafür brauchen wir ein Forschungsprojekt,
Interviews: um genau zu verstehen, ist das richtig.
Interviews: Dann brauchen wir auch die Kooperation mit den Cloud-Providers.
Interviews: Da gehen wir auch aktiv dran. Okay, also wie seid ihr?
Interviews: Ja, klar, weil wie gesagt, wir haben ja diese Ausschreibung gemacht,
Interviews: die sind auch interessiert, was zu geben, haben auch natürlich Schwierigkeiten,
Interviews: also manche von diesen Daten sind so nah an betrieblicher Effizienz,
Interviews: dass es schwierig macht, sie zu veröffentlichen.
Interviews: Aber wir sind dabei in der Dialog, nicht nur wir, sondern es gibt auch Initiativen
Interviews: mit Vodafone, mit Allianz und so weiter, wo wir in Netzwerke sind,
Interviews: wo wir zusammen mit den Cloud-Providers dann in Austausch sind und schauen,
Interviews: wie können wir ein Stück weiter da auch in diese Datenlage dann kommen.
Interviews: Und ich hoffe, in den nächsten Zeiten wird einiges auch da passieren.
Interviews: Super. Dann drücke ich euch die Daumen, dass ihr bis 2040 warst,
Interviews: bis 2040 CO2-neutral werden wollt.
Interviews: Die IT ist auf jeden Fall dran, wie ich jetzt gehört habe.
Interviews: Schönes Projekt. Also Kepler gucke ich mir auch mal näher an.
Interviews: Also fand ich sehr interessant, habe ich zum ersten Mal gehört.
Interviews: Und ja, drücke euch die Daumen, dass das alles klappt und dass die Teams da
Interviews: alle mitmachen und dass die Entwickler auch so ein bisschen Spaß haben.
Interviews: Also das war dann so ein bisschen angepickt, ich will jetzt noch das kleine
Interviews: bisschenchen rausholen. Wir sind alle ein bisschen Hackers, also wir wollen
Interviews: auch ein bisschen da experimentieren und was Gutes machen damit.
Interviews: Vielen Dank Gualter, dass du uns das alles mal erklärt hast und viel Erfolg mit eurer Strategie.
Moderation: Das war Square is Saw mit Quiet Place.
Moderation: Letztes Jahr auf der KubeCon war Security das bestimmende Thema.
Moderation: Dieses Jahr hat man das natürlich auch noch gesehen, aber es ging vor allem um AI.
Moderation: AI hier, AI da.
Moderation: Das zieht sich auch ein bisschen hier durch diese Interviews,
Moderation: hört man dann auch immer mal wieder.
Moderation: Ich habe es versucht, aber jetzt nicht überall so groß reinzubringen,
Moderation: weil es gibt jetzt von der CNCF eine AI-Working-Group,
Moderation: es gibt lauter White Paper und ganz, ganz groß natürlich muss man sagen, viele, viele GPUs.
Moderation: Nvidia ist ganz groß zu Gast gewesen und hat vorgestellt, was es da alles macht,
Moderation: insbesondere mit seinen Dynamic Resource Allocation,
Moderation: das zurzeit ein Alpha-Feature ist in der neuen Kubernetes-Version,
Moderation: aber ja, so richtig geflasht hat mich das Ganze nicht, auch wenn ich ganz klar
Moderation: weiß, das ist gerade das Hype-Thema.
Moderation: Ja, natürlich muss die CNCF, muss Kubernetes auch in diese Richtung zurzeit gehen.
Moderation: KI braucht in dem Fall sozusagen Standards und ja, wir werden gucken,
Moderation: wie sich das entwickelt.
Moderation: Wenn ihr in dem Bereich irgendwie tätig seid, dann habt ihr das vielleicht auch schon gehört.
Moderation: Ich würde jetzt nochmal zurückkommen zu diesen Security-Sachen und habe da ein
Moderation: spannendes Interview führen dürfen mit Janik Hollenbach.
Moderation: Da geht es um ein Tool, das nennt sich Secured Code Box und wie ihr das einsetzen könnt,
Moderation: vielleicht auch nur, um eure, um mal ein bisschen zu spielen,
Moderation: um mal zu gucken, ist denn meine Applikation überhaupt so sicher, wie ich denke?
Moderation: Dann ist das vielleicht ein Tool, das ihr euch angucken solltet.
Interviews: Ich bin jetzt hier auf der CubeCon
Interviews: 2024 in Paris. Bei mir ist Yannick Hollenbach. Hallo Yannick. Moin.
Interviews: Und du machst bei einem Projekt mit, was sich Secure Code Box nennt.
Interviews: Was ist das denn? Was macht ihr da? Ja genau.
Interviews: Erstmal danke, dass ich da sein darf. Die Secure Code Box ist ein Tool,
Interviews: um auf Kubernetes Security Scanner, im speziellen Open Source Security Scanning Tools,
Interviews: zu orchestrieren und die Ergebnisse zu vereinheitlichen und dann einheitlich
Interviews: verarbeiten und auswerten zu können.
Interviews: Sodass man jetzt quasi eine ganze Reihe an
Interviews: verschiedenen Scannern quasi gleichmäßig quasi mit
Interviews: einem gleichen Konfigurationsformat konfigurieren kann oder zumindest
Interviews: anlegen kann und die Ergebnisse dann einheitlich verarbeiten kann das heißt
Interviews: wir haben so eine Parser-Ebene die diese ganzen Ebenen und die ganzen Formate
Interviews: von den einzelnen Scannern in ein einheitliches Format übersetzt sodass man
Interviews: die Findings dann quasi in einem Format zurückbekommt und auch gleichzeitig,
Interviews: Gleichzeitig bietet die Secure Roadbox eine ganze Reihe an sogenannten Hooks an.
Interviews: Das sind so Integrationspunkte, wo man diese Findings dann auch noch weiterschicken kann,
Interviews: um sie dann automatisch in Alerts, sowas wie in Slack reinzuschicken,
Interviews: um dann automatisch mitzubekommen, dass da jetzt ein neues Finding hochgekommen
Interviews: ist oder sie auch in andere Open-Source-Finding-Management-Tools hochzuladen.
Interviews: Das Haupt-Tool, was dabei bei uns im Fokus steht, ist das Overspliff-Effect-Dojo.
Interviews: Ein weiteres OWASP-Tool, also die Secure-Code-Box selber ist auch ein OWASP-Projekt,
Interviews: also vom Open Web Application Security Project,
Interviews: Program. Die OWASP hat sich auch irgendwie letztens umgenannt.
Interviews: Das macht das jetzt auch nochmal komplizierter.
Interviews: Ich glaube aber, dass das aber das OWASP Defacto, das ist jetzt quasi eine webbasierte Plattform.
Interviews: Da steckt ja auch WASP drin, ne? Also das ist Logo. Das ist so ein Wortspiel,
Interviews: genau. Die OWASP, der vielleicht nochmal als Erklärung ist, eine Open Source
Interviews: Security Organisation.
Interviews: Vielleicht ganz leicht vergleichbar wie sowas die Linux Foundation,
Interviews: aber quasi rein fokussiert quasi auf Web Application Security Tools,
Interviews: also das bekannteste aus dem OWASP-Katalog ist wahrscheinlich dieses OWASP Top 10.
Interviews: Aber auch noch andere Projekte drin, zum Beispiel, das ist jetzt auch aus komplett
Interviews: eigenem Interesse hier nochmal genamedropped, der OWASP-Ju-Shop,
Interviews: einfach eine Vulnerable-Web-Application für Security-Trainings.
Interviews: Namedroppe ich jetzt mal, weil ich da auch mit dran wirke. Okay,
Interviews: die ist also von vornherein kaputt, mit der kann man dann testen oder wie funktioniert das?
Interviews: Genau, also es ist hauptsächlich dafür, also jetzt wechseln wir komplett das
Interviews: Thema, weil es geht von der CEO-Coupon weg, aber da rede ich natürlich auch
Interviews: gern drüber. Ja, ich komme wieder darauf zurück.
Interviews: Also der Over-Strew-Shop ist genau eine.
Interviews: Bewusst kaputtgeschriebene Anwendung, um dann selber mal richtig zu lernen,
Interviews: wie man so eine Anwendung denn hacken kann.
Interviews: Und auch einfach jetzt für, ich würde sagen, das Target-Audienz ist schon ein
Interviews: Anwendungsentwickler, quasi zu verstehen, wie diese Lücken aussehen und dann
Interviews: innerhalb von Trainings oder auch einfach komplett selber drauf loszuhacken,
Interviews: zu schauen quasi, was denn da für Vulnabilities drin sind.
Interviews: Und genau diese OWASP ist jetzt einfach so eine Parent-Organisation,
Interviews: in der diese Projekte dann organisiert sind,
Interviews: die dann irgendwie bestimmte Prinzipien verfolgt und einfach irgendwie so versucht,
Interviews: einen Fokus auf offene Projekte zu legen, um Software Security weiter voranzubringen.
Interviews: Open Worldwide Application Security Project. Ich glaube, das Worldwide ist neu,
Interviews: weil ich glaube, es hieß früher Open Web Application Security Project,
Interviews: aber das fanden sie irgendwann zu eingrenzend und sind jetzt lieber auf Worldwide gegangen.
Interviews: Genau, also so steht es hier auf der Webseite. Genau.
Interviews: Okay, dann haben wir jetzt geklärt, was OWASP ist und du durftest nochmal in
Interviews: ein neues Projekt gehen.
Interviews: Jetzt kommen wir wieder zurück zu dieser Security, Secure Code Box.
Interviews: Ist das jetzt irgendein Container, den ich irgendwo hinschmeiß und dann sage
Interviews: ich da, scan mal alles oder wie funktioniert das?
Interviews: Also wie das im Prinzip funktioniert ist, die Secure Code Box ist ein sogenannter
Interviews: Kubernetes Operator und Operator sind jetzt quasi mal versucht einfach zu erklären,
Interviews: ist eine Art Kubernetes zu erweitern, um mit quasi anderen Ressourcen auch umgehen zu können.
Interviews: In unserem Fall sind das primär sogenannte Security-Scans. Das heißt,
Interviews: was man denn tut, ist, anstatt zu Kubernetes hinzugehen und zu sagen,
Interviews: hallo Kubernetes, starte mir bitte einen Container,
Interviews: ist, dass du dann durch hingehen kannst und sagen kannst, hallo Kubernetes,
Interviews: starte mir bitte zum Beispiel einen Nmap-Scan.
Interviews: Und was die Secure-Code-Box denn tut, ist, diesen Scan quasi zu übersetzen in
Interviews: Sachen, die Kubernetes denn versteht.
Interviews: Also in dem Fall einen Container, in dem ein Nmap drin läuft und der dann ein
Interviews: bestimmtes Target scannt.
Interviews: Und was die Secure-Goat-Box dann auch noch macht, sind quasi auch noch Sachen,
Interviews: die wir quasi sagen, die gehören dazu,
Interviews: nämlich jetzt quasi diese Finding-Auswertung oder zumindest diese Finding-Unification zu machen,
Interviews: diese Findings, die dann der Nmap ausgespuckt hat, von so einem sehr Nmap-spezifischen
Interviews: XML-Format in ein einheitliches JSON-Format zu übersetzen, was dann jetzt auch
Interviews: ähnlich aussieht wie zum Beispiel die Findings von einem anderen Security-Scanner,
Interviews: wie jetzt zum Beispiel einen Nikto,
Interviews: einen Oversp-Zap-Scanner, wo Oversp liegt auch gar nicht mehr bei der Oversp,
Interviews: aber es gibt da eine ganze Reihe an verschiedenen anderen Scannern,
Interviews: die wir da auch integriert haben.
Interviews: Ja, man könnte auch SSH-Scannen sehen hier, Typo3-Scannen, irgendwie WordPress-Scanner.
Interviews: SSL-Analyze, solche Sachen sind hier irgendwie alle mit drin.
Interviews: Genau, das ist inzwischen ein ziemlicher Katalog von, ich weiß die genaue Zahl
Interviews: gar nicht, aber ich glaube, es sind so vielleicht schon so 15 bis 20 Stück.
Interviews: Die wir dann jetzt quasi integriert haben.
Interviews: Das heißt, es gibt diese Scan-Types, die kann man dann auch erstmal nochmal modular aufgebaut.
Interviews: Das heißt, wenn man jetzt die Secure-Code-Box erstmal installiert,
Interviews: dann kriegt man nur diesen Operator und dann kann man noch die einzelnen Scan-Types
Interviews: nachzuinstallieren, um dann quasi jetzt der Secure-Code-Box noch noch beizubringen,
Interviews: wie man einen Nmap-Scan macht.
Interviews: Das ist aber auch komplett erweiterbar. Das heißt, wenn da jetzt ein Scan-Type
Interviews: fehlt, dann kann man das auch selber nachschreiben.
Interviews: Da muss man jetzt quasi nur ein Manifest schreiben, was dann der Secure-Code-Box
Interviews: sagt, wie es diesen Scan in die Container übersetzt.
Interviews: Was im Zweifelsfall einfach nur die Definition ist, welcher Container da gebraucht wird.
Interviews: Und dann so ein Parser zu schreiben, um diese Feinigkeiten zu vereinheitlichen,
Interviews: das ist vielleicht noch das Komplizierteste.
Interviews: Aber es ist ein komplett erweiterbares System. Also wenn ich jetzt weiß,
Interviews: ich kann mit einem bestimmten Curl-Request irgendwas auslösen und will das jetzt
Interviews: bei euch einbinden, dann könnte ich das über den Weg machen,
Interviews: den du gerade beschrieben hast.
Interviews: Genau, also das ist jetzt vielleicht ein sehr spezifischer Use Case,
Interviews: wie ich sagen würde, da gibt es vielleicht sogar eine bessere Lösung für.
Interviews: Also da gibt es dann, also wenn man halt wirklich weiß, okay,
Interviews: ich kann das mit einem einzelnen Request machen, dann gibt es halt auch noch
Interviews: Scanner, die quasi von Haus aus erweiterbar sind.
Interviews: Also der eine Scanner, den wir da im Portfolio haben, nenne ich das mal,
Interviews: ist da der Nuclei, wo man dann selber auch noch Scan-Templates mitgeben kann
Interviews: und den Nuclei quasi sagen kann, okay, ich hätte jetzt gerne hier diesen einen
Interviews: spezifischen Check, den ich gerne machen möchte.
Interviews: Da könnte man das auch quasi hinbekommen, ohne selber eine eigene komplette
Interviews: Scanner-Integration schreiben zu müssen.
Interviews: Aber tendenziell lässt sich quasi wirklich einfach eigentlich alles einbauen,
Interviews: solange man das halt irgendwie in einen Container gesteckt bekommt.
Interviews: Also ich glaube, eine Sache, mit der wir mal Probleme hatten,
Interviews: war so ein Windows-spezifischer Scanner, wo wir dann so ein bisschen Probleme
Interviews: bekommen haben, da halt irgendwie so mit Windows-Containern rumzuspielen.
Interviews: Das sind dann so Sachen, die dann halt irgendwie schwieriger sind.
Interviews: Aber ich glaube, hier in Radio Tux ist das vielleicht sowieso nicht die Zielgruppe,
Interviews: deswegen die meisten Tools.
Interviews: Man will ja vielleicht Windows auch angreifen, keine Ahnung.
Interviews: Apropos, gibt es dann auch so Integration, weiß ich nicht, Metasploit oder sowas,
Interviews: dass ich mich irgendwie so alles einfach runterlade und dagegen schmeiße, gegen irgendein Ziel?
Interviews: Also Metasploit ist eine Sache, die wir häufig requested bekommen,
Interviews: weil das ist bei uns das Problem, dass eigentlich keiner bei uns sich im Core-Team
Interviews: mit Metasploit auskennt.
Interviews: Und sich in Metasploit erstmal einzuarbeiten, ist halt ordentlich Arbeit.
Interviews: Also falls sich jemand richtig gut mit Metasploit auskennt,
Interviews: Hätten durchaus Interesse dran, quasi das auch einzubauen, aber das müsste wahrscheinlich
Interviews: jemand machen, der nicht wir sind, weil bei uns fehlt da gerade einfach aktuell
Interviews: leider das Mitarbeiter-Leute-Leute-Leute, aber da findet man auch bei uns im
Interviews: GitHub-Projekt dann irgendwie die Issues zu.
Interviews: Da sind wir gerne offen auf jedes Feedback oder irgendwie Hinweise quasi,
Interviews: wie man das sonst auch einbauen könnte oder Hilfe für den Leuten,
Interviews: die das dann tatsächlich für uns einbauen könnten.
Interviews: Okay, das heißt, ihr habt ein GitHub-Projekt und da kann einfach jeder mitmachen.
Interviews: Habt ihr auch irgendwie ein Chat-System, wo man sich einklinken kann oder macht
Interviews: ihr die ganze Entwicklung über GitHub?
Interviews: Wir haben auch, also es gibt von der OVAS-Organisation, die haben einen Slack-Channel.
Interviews: Oder einen Slack-Workspace, heißt das glaube ich richtig.
Interviews: Da haben wir auch einen Secure-Code-Box-Channel. Wir sind aber gerade so ein
Interviews: bisschen dabei zu versuchen, das noch stärker zu GitHub zu treiben,
Interviews: weil wir einfach oft das Problem hatten, dass halt in Slack die Diskussionen
Interviews: einfach quasi immer und immer wieder gleichgeführt wurden.
Interviews: Weil Slack halt einfach so schlecht durchsuchbar ist, dass die Leute einfach
Interviews: immer wieder mit den gleichen Problemen gekommen sind und Fragen gekommen sind.
Interviews: Also wir versuchen natürlich auch irgendwie unsere Dokumentation anzupassen,
Interviews: dass die Fragen dann gar nicht mehr aufkommen.
Interviews: Aber das ist manchmal eben nur begrenzt möglich. Deswegen sind wir gerade so
Interviews: ein bisschen dabei, die Leute eher zu ermuntern, dieses GitHub-Discussions-Feature
Interviews: zu benutzen und dann auch Fragen zu stellen.
Interviews: Einfach nur, dass die dann halt irgendwie von Search-Engines auch irgendwie
Interviews: indexierbar sind und gut durchsuchbar sind. Kann ich jetzt die Secure-Code-Box
Interviews: auch irgendwie in meine CI-CD-Pipeline einbinden oder?
Interviews: Ja, das ist ein bisschen interessant, weil da habe ich glaube ich ein bisschen
Interviews: von der Norm abweichende Meinung zu, weil wir haben das ganz lange versucht
Interviews: quasi so Security-Tools in CI-Pipelines einzubauen, um quasi Software vorm Deployment zu scannen.
Interviews: Genau, da gibt es auch einige. Da gibt es auch einige wirklich richtig gute Lösungen.
Interviews: Da ist jetzt vielleicht noch so das Ding, wir mit der Secure-Code-Box sind primär
Interviews: auf dynamische Scanner quasi aktuell fokussiert.
Interviews: Wir haben auch ein bisschen statische Scanner drin, aber primäres Ziel ist aktuell
Interviews: quasi das Ausführen und die Orchestrierung von dynamischen Scanning-Tools,
Interviews: also Scanning-Tools in diesem Fall, die gegen eine laufende Software laufen
Interviews: und nicht nur auf quasi plainen Source-Code konzentrieren.
Interviews: Und da ist das Problem, wenn du sowas in eine CI-Pipeline integrieren willst,
Interviews: hast du einen ganzen Haufen an Problemen. Das erste ist, du musst diese Software
Interviews: erstmal quasi in Gänze in deiner CI-Pipeline zu laufen zu bekommen.
Interviews: Was im Zweifel heißt, du müsst dann jetzt quasi auf deinem CI-Server auch irgendwie
Interviews: noch die Datenbank starten, irgendwie Frontend, Backend, was auch immer,
Interviews: Microservice-Container, irgendwie alles zum Laufen bekommen.
Interviews: Und dann kannst du erst das Tool dagegen schmeißen und dann wird dir vielleicht
Interviews: auch noch auffallen, dass viele von diesen Tools arschlangsam sind,
Interviews: weil sie halt einfach quasi versuchen, jede mögliche Vulnerability,
Interviews: die die Sonne je gesehen hat, in dieser Software zu finden.
Interviews: Das heißt, sie machen teilweise Tausende an Requests, was jetzt quasi je nach
Interviews: Software und auch je nach Wumms, die dieser CI-Server dann hat, ewig lange dauern kann.
Interviews: Das heißt, unser aktuelles Recommendation dafür ist, quasi die Software quasi
Interviews: erst zu deployen, vielleicht auf einer entsprechenden Staging-Umgebung und dann
Interviews: die Secure-Code-Box dagegen laufen zu lassen.
Interviews: Da spricht jetzt auch nichts gegen, quasi die Software dann zu deployen und
Interviews: dann den Secure-Code-Box-Scan dagegen zu triggern.
Interviews: Was wir aber auch haben, ist quasi jetzt noch eine weiterführende Komponente,
Interviews: das heißt so, wie ich das eben schon erklärt habe, quasi so die Core-Komponente
Interviews: ist so dieses Ausführen und Orchestrieren von Scans.
Interviews: Wir haben noch eine weitere Komponente, die nennen wir die Secure-Code-Box-Auto-Discovery.
Interviews: Das ist eine Komponente, die quasi versucht, automatisch aus der Kubernetes-API
Interviews: rauszuziehen, was für Software in diesem Cluster drin läuft und dann automatisch
Interviews: Scans gegen diese Software erstellst, sodass du in der Autodiscovery sagen kannst,
Interviews: okay, ich möchte gerne, dass jede Software, die hier auf diesem Cluster läuft,
Interviews: quasi einmal diesen Scan abbekommen hat.
Interviews: Ich glaube, das Default-Setup, was wir da haben, ist quasi ein weiteres OVAS-Projekt, der OvaSAP-Scanner.
Interviews: Das ist so ein sehr bekannter, sehr verbreiteter Web-Application-Security-Scanner.
Interviews: Denen gegen diese Software zu laufen. Und was die Autodesk KW dann macht,
Interviews: ist, indem sie halt automatisch oder quasi durchgehend auf die Kubernetes-API
Interviews: guckt und dann da jetzt auch eine Change Events mitbekommt,
Interviews: dass sie dann automatisch für jede Version der Software, die auf diesem Cluster deployed ist,
Interviews: diese Scans startet und dann kann man diese Ergebnisse dann halt auch wieder
Interviews: rausleiten aus der Secure-Code-Box in sowas wie eine Defect-Dojo,
Interviews: sodass du dann halt quasi ein Web-Interface hast mit diesem Defect-Dojo,
Interviews: wo du alle deine Findings zu deiner Software sehen kannst.
Interviews: Und durch diese Autodiscovery wird automatisch dieser Scan getriggert,
Interviews: ohne dass man ihn jetzt noch über eine CI-Pipeline anstoßen muss.
Interviews: Sondern es passiert dann alles rein aus dem Cluster heraus. Heißt aber,
Interviews: das ist dann nur für die Cluster, in denen ich die Secure-Code-Box deployed habe.
Interviews: Also wenn ich mehrere habe, muss ich das in jedem... Genau, da wäre jetzt auch
Interviews: unsere Empfehlung, also besonders, wenn du dynamische Scans startest,
Interviews: das dann eher quasi gegen das Staging-Cluster zu werfen, zumindest mit diesen dynamischen Scans.
Interviews: Einfach nur, dass man jetzt quasi wirklich diese Scans gegen die Software startet,
Interviews: bevor sie auf Produktion deployed ist,
Interviews: und auch potenziell, ich hatte es eben schon gesagt, diese Scanner sind relativ
Interviews: ressourcenhungrig und da wir die Scanner jetzt ja quasi direkt neben der Software
Interviews: deployen, wollen wir gerne vermeiden, dass Leute aus Versehen quasi ihre eigenen
Interviews: Cluster dadurch dossen, dass sie jetzt halt,
Interviews: gerade sich die Autos also lässt sich auch inkrementell,
Interviews: ausrollen, aber so ein bisschen so das Horrorszenario ist, dass Leute uns dann
Interviews: schreiben so, ey, ich hab die Secure-Code-Box auf unserer Produktionscluster deployed.
Interviews: Und jetzt ist das komplette Cluster
Interviews: überlastet, weil überall sind diese Security-Scanner hochgefahren worden.
Interviews: Also das ist jetzt die klare Empfehlung, quasi, wenn ihr diese Autodesk-KW benutzt,
Interviews: probiert das erstmal auf eurem Staging- oder Dev-Cluster aus.
Interviews: Vielleicht gibt da so eine Funktion, das quasi Namespace für Namespace,
Interviews: also Namespaces sind so die Unterprojekte innerhalb eines Kubernetes-Clusters,
Interviews: das sind quasi jetzt projektweise auszurollen,
Interviews: um da jetzt quasi dann nicht irgendwie aus Versehen die Ressourcenhungrigkeit
Interviews: dieser Scanner irgendwie komplett gegen das Cluster loszulassen,
Interviews: sondern das ein bisschen vorsichtiger zu machen.
Interviews: Und falls man denn jetzt auch das Produktionscluster scannen möchte,
Interviews: was ja durchaus ein valider Use Case ist,
Interviews: das dann vielleicht nicht mit solchen dynamischen Scannern wie zum Beispiel
Interviews: einem ZEP zu machen, sondern das eher mit Container-Level-Scans zu machen,
Interviews: wie jetzt so diesem Trivi.
Interviews: Ich führe jetzt hier ganz viele neue Scanner ein, die für mich total normal sind.
Interviews: Also der Trivi-Scanner ist ein richtig cooles Tool, das quasi auf Container-
Interviews: Images guckt und dieses Container-Image nach Schwachstellen durchsucht.
Interviews: So nach dem Motto, du benutzt diese eine Library und die ist eh schon immer kaputt.
Interviews: Genau, also das ist auch das Coole inzwischen, dass es bei Trivi jetzt quasi
Interviews: sowohl für Libraries ist, aber auch so
Interviews: für so Kernel-Level oder jetzt so Operating-System-Level-Dependencies ist.
Interviews: Das heißt, da kann man sich jetzt echt eine richtig coole Übersicht über das
Interviews: Security-Standing von so einem Container-Image geben.
Interviews: Und sowas ist halt wirklich sehr wenig invasiv, weil das guckt halt auf dieses
Interviews: Image und nicht auf die laufende Software. wäre.
Interviews: Das heißt, das ist auch etwas, was man richtig super auf einem Produktionscluster
Interviews: machen kann, aber mit solchen dynamischen Scannern wäre ich zumindest ein bisschen
Interviews: vorsichtig, das quasi jetzt erstmal auf einem kompletten Produktionscluster
Interviews: auszurollen. Weil man sich eventuell dedosst dann selber.
Interviews: Genau, aber das ist mit einem Trivi eher unwahrscheinlich.
Interviews: Jetzt hast du vorhin gesagt, man hat dann auch so eine Web-Oberfläche,
Interviews: wo man sich Sachen anzeigen lassen kann, wie was sehe ich da?
Interviews: Also steht da dann, Achtung, hier musst du dich um den Teil kümmern oder wie sieht das aus?
Interviews: Genau, das ist halt auch noch etwas schwer zu beantworten, weil das ist alles sehr konfigurierbar.
Interviews: Also ich hatte jetzt eben schon gesagt, quasi so die Hauptoberfläche oder das
Interviews: Haupt oder so eine der Hauptplattformen, in dem sich diese Findings quasi rausleiten
Interviews: lassen, ist dieses Overspeed-Defektojo.
Interviews: Und das Defektojo ist so eine Art Vulnerability-Management-Datenbank mit einer Web-Oberfläche.
Interviews: Das heißt, man kann dort Findings, also so eine Security-Findings hochladen,
Interviews: wie, hallo, hier ist eine SQL-Injection quasi unter dieser Adresse mit diesen und diesen Parametern,
Interviews: dass wenn jetzt Sachen quasi ein Defekt-Dojo da anzeigen würde und was das Defekt-Dojo
Interviews: zudem auch noch macht, ist, dass es die Feinigsten dedupliziert.
Interviews: Das heißt, wenn ich jetzt heute diese SQL-Injection gefunden habe und morgen
Interviews: wird der Scanner nochmal ausgeführt und findet dann die gleiche SQL-Injection nochmal.
Interviews: Dass dieses Defekt-Dojo das dann quasi automatisch dedupliziert und sagt,
Interviews: ha, das ist doch eigentlich nur einmal die gleiche Schwachstelle,
Interviews: quasi jetzt einfach nur doppelt eingetragen dass man dann im Defekto nur noch
Interviews: diesen einen Eintrag hat und
Interviews: dann sehen kann, okay, das wurde da und da oder dann und dann gefunden.
Interviews: Dass man jetzt nicht da dumm und dämlich klickt, weil da jeden Tag die Findings neu aufkommen.
Interviews: Das heißt, diese Deluplizierung ist da so eines der Hauptfeatures von dem Defect-Dojo,
Interviews: dass die Findings da dann quasi nur einmal reinkommen und dann kann man sie
Interviews: halt auch irgendwie kommentieren, als false positives markieren,
Interviews: wenn es dann doch nicht gestimmt hat.
Interviews: Also wenn das Finding quasi vom Scanner angezeigt wurde, aber tatsächlich gar nicht existiert.
Interviews: Okay, da kann ich also schon eingreifen an der Stelle. Kann dann sagen,
Interviews: nee, du hast dich hier irrt.
Interviews: Genau, also der Scanner wird das halt trotzdem am nächsten Tag noch fleißig
Interviews: weiter reporten, aber im Defect-Dojo ist es dann halt als quasi fehlerhaft markieren,
Interviews: dass man das dann einfach quasi nicht mehr mit auseinandersetzen muss.
Interviews: Wir haben noch andere Integrationen, das ist auch das, was man jetzt sieht,
Interviews: wenn man die Webseite aufmacht, die Bilder da draus.
Interviews: Also mir wird es hier gerade ins Gesicht gehalten auf einem Laptop.
Interviews: Das ist, also wir haben noch andere Integrationen, das ist primär das Elasticsearch
Interviews: Integration, wo die Finix jetzt quasi als einzelne Datensätze in das Elasticsearch gekippt werden.
Interviews: Und dann jetzt da jetzt quasi in dieser Elasticsearch-Document-Database quasi
Interviews: einfach als JSON-Blobs rumliegen.
Interviews: Das ist jetzt quasi bei, quasi jetzt erstmal komplett nicht dedupliziert.
Interviews: Das heißt, da tauchen dann jeden Tag immer wieder die gleichen Findings bei raus.
Interviews: Und da gibt es jetzt quasi keine False-Positive-Behandlung. Also dafür müsste
Interviews: man ein Defect-Dojo benutzen.
Interviews: Aber jetzt für sowas, wenn man jetzt tatsächlich zum Beispiel sowas benutzt,
Interviews: wie ich hatte es vorhin schon mal erwähnt, wenn man jetzt zum Beispiel einen
Interviews: NMAP-Scanner benutzt, um ein Netzwerk zu scannen, das hat halt relativ wenig
Interviews: False Positives, sondern sagt mir halt einfach, dieser Port da ist offen und
Interviews: dann stimmt das in der Regel auch.
Interviews: Damit kann man sich halt auch irgendwie eine relativ coole Übersicht so über
Interviews: Netzwerke bauen, quasi was für Ports sind, wann wo offen.
Interviews: Und für sowas ist dieses Elasticsearch richtig super, weil dann kannst du dir
Interviews: halt mit diesem Kibana so eine Dashboard zusammenklicken, um dann zum Beispiel
Interviews: einfach auf einen Blick zu sehen, wo sind denn jetzt hier in dem Netzwerk noch Telnet-Ports offen.
Interviews: Nicht nirgendwo, aber ja, gut. Ja, genau, das wäre die Hoffnung.
Interviews: Dass man da dann halt jetzt quasi eine einfach zu durchsuchende Oberfläche noch
Interviews: hat, um da diese Finings zu haben, jetzt quasi mit der Einschränkung,
Interviews: dass sie dann halt nicht dedupliziert sind.
Interviews: Du hast gesagt, man kann im Produktiv-Cluster auch die Images scannen.
Interviews: Wenn ich das jetzt so einfach die ganze Zeit nebenbei laufen lasse,
Interviews: will ich mich ja vielleicht nicht erst auf eine Web-Oberfläche einloggen und
Interviews: gucken, was da gerade abgeht.
Interviews: Hat man irgendeine Art von Alerting?
Interviews: Genau, also es funktioniert tatsächlich relativ ähnlich wie jetzt quasi das
Interviews: Hochladen von den Findings in das Elasticsearch.
Interviews: Also wir haben, habe ich glaube ich ganz am Anfang einmal gesagt,
Interviews: dieses Konzept von Hooks.
Interviews: Also es sind einfach quasi eine Programmierschnittstelle, um quasi mit diesen Scans zu interfacen.
Interviews: Da gibt es aber auch eine ganze Reihe an Vorgefertigten, wie jetzt zum Beispiel
Interviews: die Defect-Dojo-Hooks, diese Findings, die dann an das Defect-Dojo hochlädt
Interviews: oder die Elasticsearch-Hook.
Interviews: Ähm, wir haben dann aber auch zusätzlich noch eine Hook,
Interviews: die nennt sich, glaube ich, einfach Notification-Hook, die es einem erlaubt,
Interviews: denn, äh, quasi jetzt basierend auf bestimmten Regeln, die man dann auch wieder vordefinieren kann,
Interviews: äh, Alerts an externe Systeme zu senden, äh, was in diesem Fall halt einmal
Interviews: so Chat-Systeme sind, also ich glaube irgendwie Slack und Microsoft Teams sind
Interviews: da so die Hauptdinger, ähm, um dann quasi jetzt direkt zu sagen,
Interviews: dass da jetzt ein neues Feinde gefunden wird.
Interviews: Das lässt sich dann auch mit der Defect-Dojo-Hook zu quasi kombinieren,
Interviews: dass man die Findings quasi zuerst ins Defect-Dojo hochlädt,
Interviews: dann quasi wartet, bis die Deduplizierung abgeschlossen ist.
Interviews: Also es gibt da quasi so einen Sync-Back-Modus, dass er die Findings hochlädt
Interviews: und dann an die Secure-Code-Box-Finding später noch ranschreibt quasi so,
Interviews: ey, ja, das wurde hier zwar gefunden, aber es ist eigentlich ein false positive gewesen.
Interviews: Dass man das dann noch quasi kombiniert mit der Notification-Hook,
Interviews: dass man dann auch nur Notifications rausschickt für Findings,
Interviews: die tatsächlich neu sind.
Interviews: Genau, dass man da dann automatisch Alerts raussenden kann an Leute,
Interviews: dass sie nicht durchgehend alle fünf Sekunden das Webinterface refreshen müssen.
Interviews: Okay, für wen würdest du sagen, wer sollte sich SecureCodeBox angucken? Alle?
Interviews: Oder? Ach, alle wäre jetzt wahrscheinlich zu viel gesagt.
Interviews: Aus meiner Sicht ist das ein durchaus sehr spannendes Tool, besonders für Leute,
Interviews: die schon ein Kubernetes-Cluster irgendwo am Laufen haben.
Interviews: Dann ist es nämlich auch der Overhead, das einmal auszuprobieren,
Interviews: relativ gering, weil es ist relativ einfach zu installieren.
Interviews: Also es ist eigentlich einfach nur ein Helm-Chart, also für die Leute,
Interviews: die sich jetzt Kubernetes auskennen, Helm ist so ein Package-Manager für Kubernetes.
Interviews: Dann ist das sehr einfach, das auszuprobieren. Besonders mit der Autodiscovery
Interviews: ist das halt auch einfach, finde ich, ein super spannendes Tool,
Interviews: um halt automatisch so die Security von Software zu verifizieren.
Interviews: Aber das finde ich auch so für klassischere Unternehmen ein super spannendes
Interviews: Tool, besonders wenn es so um Network Security geht.
Interviews: Also einfach das Scannen von kompletten Netzwerken.
Interviews: Dann ist das auch super spannend. Also wenn es da Probleme gibt,
Interviews: quasi wie so alle Software, die im Netzwerk läuft,
Interviews: quasi im Auge zu behalten, ist das ein super spannendes Tool,
Interviews: weil du kannst dann dadurch halt auch so Regeln festlegen, wie zu sagen,
Interviews: okay, ich möchte jetzt erstmal so einen kompletten Netzwerkscan machen machen
Interviews: über alles, was hier in dem Netzwerk läuft,
Interviews: und dann basierend auf den Ergebnissen automatisch weitere Scans zu triggern,
Interviews: wie zum Beispiel, wir hatten das eben schon gesagt, es gibt zum Beispiel einen
Interviews: NMAP-Scanner, aber es gibt auch einen SSH-Scanner, dann zu sagen, okay,
Interviews: liebe SecureCodeBox, bitte quasi für jeden Host, den du mit einem offenen SSH-Port gefunden hast,
Interviews: bitte start doch jetzt gleich nochmal so einen spezialisierten SSH-Scan hinterher,
Interviews: um automatisch jetzt auch für alle SSH-Ports oder alle SSH-Services,
Interviews: die ich in einem Netzwerk am Laufen habe, halt auch automatisch noch einen SSH-Security-Scan
Interviews: machen zu lassen, lassen zu können.
Interviews: Das ist halt super spannend, auch mit so anderen Spesen, also ein weiterer Scanner,
Interviews: ich name-droppe jetzt hier gefühlt fast alle Scanner, die wir haben.
Interviews: Also ein weiterer Scanner, den wir haben, ist der N-Track-Scanner,
Interviews: das ist so ein Schwesterprojekt vom N-Map-Scanner.
Interviews: Stimmt das, glaube ich? Ich glaube zumindest vom Namenstamm ist das ähnlich.
Interviews: Das ist so eine Art Credential Enumeration Scanner, den du quasi jetzt einfach
Interviews: gegen einen bestimmten Service richten kannst und einfach mit einer Liste von
Interviews: Nutzernamen und Passwörtern,
Interviews: und dann einfach mal den versuchen lassen kannst, die Passwörter zu bruteforcen.
Interviews: Das lässt sich dann halt auch wieder super mit diesem, also wir nennen das so
Interviews: eine Cascading Scans kombinieren, also das heißt, dass man erst einen Nmap-Scan
Interviews: startet zum Beispiel, um alle SSH-Ports zu finden und Und dann einfach mal einen
Interviews: Endcrack-Scan dagegen,
Interviews: gegen diese SSH-Ports laufen lassen zu können, ob da jetzt hier irgendwo SSH-Ports
Interviews: mit irgendwie bekannten Admin-Passwörtern rumliefern.
Interviews: Also da kann ich nur mal empfehlen, das auszuprobieren, wenn man da irgendwie
Interviews: Sorgen hat in einem Unternehmen, dass sowas passieren könnte.
Interviews: Also es lässt sich sehr gut kombinieren, indem man einfach mal bei den Admins
Interviews: fragt, was so die Standard-Passwörter sind, die sie vor ein paar Jahren noch
Interviews: verwendet haben. Also ich hoffe, dass die inzwischen alle davon weggeswitcht sind.
Interviews: Aber sich da einfach mal so eine Liste geben zu lassen von den Sachen,
Interviews: die früher vielleicht mal benutzt wurden,
Interviews: und das dann mit so einem N-Track-Scan zu kombinieren, um einfach mal wirklich
Interviews: quasi kontinuierlich alle Systeme, die in diesem Netzwerk laufen,
Interviews: auf solche Standard-Passwörter.
Interviews: Durchtesten zu lassen, das ist halt wirklich Gold wert, einfach nur um jetzt
Interviews: quasi das irgendwie nochmal von seiner Liste abhaken zu können,
Interviews: sich einfach sicher zu sein zu können, dass da jetzt kein totaler Quatsch mehr im Netzwerk läuft. Ja.
Interviews: Okay, habt ihr denn so Blueprints oder Beispiele auf der Webseite?
Interviews: Also das ist ja jetzt schon ein bisschen komplexer. Es ist nicht nur,
Interviews: ich schmeiß das Helmschad dagegen und dann passiert alles automagisch.
Interviews: Also wenn du jetzt sagst, du hast die Abhängigkeiten und der soll die ganzen
Interviews: Schritte machen und das schon wissen, was ich tue.
Interviews: Gibt es da so Beispiele? Genau, also wir haben auf unserer Webseite übrigens
Interviews: einfach Secure Codebox IO.
Interviews: Unter der Dokumentation gibt es einen Menüreiter namens How-To's,
Interviews: was so ein bisschen quasi so Walkthroughs sind, um einfach mal quasi durchzulesen,
Interviews: quasi bestimmte Use Cases, wie man die durchspielen kann.
Interviews: Ich glaube zum Beispiel dieses Automatically Scanning Networks oder so heißt
Interviews: der glaube ich, ist glaube ich auch genau dieser Use Case beschrieben mit dem
Interviews: Nmap und Ncrack Beispiel.
Interviews: Auch irgendwie quasi jetzt einfach gibt es auch noch Beispiele,
Interviews: wie man diese Autodiscovery aufsetzt.
Interviews: Also da gibt es irgendwie inzwischen eine ganze Reihe, ich glaube es sind so
Interviews: fünf bis zehn verschiedene Use Cases, die da irgendwie einfach einmal ausführlich
Interviews: beschrieben sind quasi mit Beispielen zum,
Interviews: Nachtippen in die Shell, um das einmal durchzuspielen, falls es da irgendwie
Interviews: noch Probleme gibt oder jetzt quasi Use Cases sind, die euch da irgendwie einfallen,
Interviews: dann gerne eine Discussion aufmachen, ist immer spannend zu hören quasi,
Interviews: was die Leute da gerne gesehen hätten, was vielleicht noch fehlt.
Interviews: Okay, super Vielen Dank, Yannick, dass du uns mal erklärt hast,
Interviews: was Secure Code Box ist, was es machen kann.
Interviews: Und genau, wenn ihr da draußen Fragen habt, dann einfach auf GitHub gehen und
Interviews: Issues aufmachen oder eine Discussion starten und dann helfen euch Yannick und
Interviews: seine Kollegen dabei. Super, vielen, vielen Dank. Danke dir.
Interviews: Ja, ich bin jetzt hier auf der CubeCon 2024. Bei mir ist Andreas Gramner und
Interviews: er ist CNCF-Ambassador und Captain-Maintainer.
Interviews: Du bist seit 16 Jahren bei Dynatrace und da für Observability zuständig oder
Interviews: mit zuständig. Hallo Andreas.
Interviews: Servus, ja. Freut mich, dass wir die Zeit finden hier in Paris. ist.
Interviews: Und ich habe tatsächlich überhaupt gar keine Ahnung, was Captain ist,
Interviews: aber das ist so eins der Sachen, die du als Maintener da häufig mit am meisten gerade machst.
Interviews: Vielleicht kannst du uns mal erklären, was bedeutet Captain?
Interviews: Klingt schon so, als hätte es irgendwas mit Kubernetes zu tun,
Interviews: aber so richtig, genau, was ist das, wofür brauche ich das? Ich erkläre dir
Interviews: mal das Problem, was wir damit lösen wollen.
Interviews: Und zwar das Problem bei Kubernetes, einige der Hörer werden hoffentlich wissen,
Interviews: was Kubernetes ist und wie Kubernetes funktioniert,
Interviews: aber um es simpel zu sagen, wenn man eine Anwendung auf Kubernetes deployed,
Interviews: dann deployed man ja einen oder mehreren sogenannten Workloads,
Interviews: zum Beispiel ein Frontend, ein Backend, eine Datenbank, die deployed man,
Interviews: indem man Manifeste schreibt, indem man definiert, was man da deployed haben will.
Interviews: Dann macht man entweder ein kubectl apply oder man verwendet Tools wie Argo
Interviews: oder Flux dafür und dann hofft man, dass einfach alles am Schluss gut läuft.
Interviews: Und Kubernetes selbst ist ein bisschen wie ein Blackbox. Da gibt es einen Kubernetes
Interviews: Pod Scheduler, der nimmt diese Anfragen und sagt, okay, ich brauche hier drei
Interviews: Pods, dann dann sucht der Kubernetes-Pod-Scheduler den richtigen Platz und deployt
Interviews: es dann und hoffentlich alles ist grün.
Interviews: Das Problem ist aber, was ist, wenn das nicht so funktioniert?
Interviews: Was ist, wenn man wartet eine halbe Minute, eine Minute, zwei Minuten,
Interviews: fünf Minuten und irgendwie wird das Deployment nie fertig?
Interviews: Wieso ist das so? Natürlich kann man dann Troubleshooting machen.
Interviews: Man kann dann reingehen, wenn man sich auskennt mit Kubernetes,
Interviews: Logs gucken, Describen vom Deployment und alles Mögliche.
Interviews: Jetzt ist aber so, dass natürlich nicht jeder so versiert ist mit Kubernetes
Interviews: und außerdem willst du in einer Organisation nicht jedem das Ganze lernen.
Interviews: Was Captain jetzt macht, Captain bietet Observability in das Deployment selbst,
Interviews: das heißt, wie auch immer du jetzt deployst auf Kubernetes, sei es mit kubectl
Interviews: apply, mit Argo, mit Flux, mit Jenkins, wie auch immer.
Interviews: Erzeugt Captain einen sogenannten Distributed Trace, verwendet OpenTelemetry.
Interviews: OpenTelemetry ist auch ein großes, prominentes Projekt in der CNCF.
Interviews: Das heißt, wir erzeugen einen Trace, der genau zeigt, von Anfang,
Interviews: wo du den Request absetzt auf Kubernetes, um einen oder mehreren Workloads zu deployen.
Interviews: Bis zum Schluss erzeugen wir einen Trace, der genau zeigt, wann Kubernetes,
Interviews: welchen Pod, wohin deployed hat, wie lange es gedauert hat, wo was gut gegangen
Interviews: ist, wo was schlecht gegangen ist.
Interviews: Das heißt, wir verwenden Distributed Tracing, nicht im traditionellen Sinn vom
Interviews: Tracen eines Requests in einer End-User-Anwendung vom End-User bis zur Datenbank,
Interviews: sondern vom ersten bis zum letzten Pot.
Interviews: Und das Zweite, was dann Captain auch noch macht, Traces sind gut für Error-Analyse,
Interviews: wenn ein Deployment nicht gut läuft.
Interviews: Wir erzeugen aber auch Metriken, Metriken zum Beispiel, wie oft wird ein Deployed,
Interviews: wie lange dauert das Deployment, wie viele gehen gut, wie viele gehen schlecht von den Deployments.
Interviews: Und das sind so Teile dieser DORA-Metrics, dieser DevOps-Metriken,
Interviews: die viele Organisationen eigentlich verwenden, um zu messen,
Interviews: wie gut die Entwicklungsumgebung eigentlich
Interviews: ist oder wie gut die Entwicklungsmannschaft, wie oft deployed wird.
Interviews: Und das heißt, Captain bietet das einfach an, indem man Captain installiert
Interviews: und ihn pro Namespace aktiviert und man bekommt dann automatisch Prometheus-Metriken
Interviews: und OpenTelemetry-Adresses.
Interviews: Und diese Sachen muss ich mir ja noch irgendwie anzeigen. Da benutzen Sie einen Grafana für oder?
Interviews: Genau, was auch immer. Das heißt, im Endeffekt erzeugen wir ja quasi OpenTelemetry
Interviews: Traces und Prometheus Metriken.
Interviews: Wenn du jetzt die Daten kannst, die kannst du jetzt auf Jäger schicken,
Interviews: um einen Jäger-Tracer anzusehen. Du kannst das irgendwo in ein Backend schicken
Interviews: und dann zum Beispiel mit Grafana visualisieren.
Interviews: Du kannst es natürlich auch an irgendeinen der EPM oder Observability-Vendoren
Interviews: schicken, weil die meisten verstehen mittlerweile OpenTelemetry und Prometheus.
Interviews: Das heißt, die Visualisierung überlassen wir dem End-User, weil der End-User
Interviews: hat ja schon irgendwie sich festgelegt, wie er observierte Daten visualisiert.
Interviews: Ja, die meisten haben natürlich eine Lösung dafür. Das heißt, im,
Interviews: muss aber jetzt keine CI-CD-Pipeline haben, um Captain zu benutzen?
Interviews: Nein, gar nicht. Es ist im Endeffekt nur ein Tool, das ich quasi in meiner Plattform habe.
Interviews: Wir sprechen sehr viel mit Plattform-Ingenieurs, die jetzt gerade auf Kubernetes
Interviews: aufbauend gewisse Tools einsetzen, um eben diese Developer-Experience einfacher zu machen.
Interviews: Das heißt, da wird Argo oder Flux verwendet für GitOps-Deployments.
Interviews: Dann, wie gesagt, Captain spielt da, glaube ich, sehr gut rein und Captain wird
Interviews: im Endeffekt nur mehr auf Namespace-Ebene enabled über eine Annotation.
Interviews: Das heißt, das kann man auch wieder dann pro Namespace aktivieren oder eben
Interviews: nicht aktivieren und die Traces werden dann automatisch dann das Observability Backend geschickt.
Interviews: Das heißt, Captain arbeitet auch mit vielen verschiedenen Tools an der Stelle zusammen.
Interviews: Also ich bin da jetzt nicht festgelegt, wenn ich jetzt sage.
Interviews: Oder wenn jetzt jemand denkt, okay, ich setze Captain ein, dann heißt es nicht,
Interviews: ich muss unbedingt Argo CD nehmen, ich muss unbedingt das und jenes nehmen.
Interviews: Also die sind austauschbar. Ganz genau, weil Captain hängt sich ich quasi in
Interviews: den Kubernetes-Pod-Schedule rein.
Interviews: Da kommt der Pod-Schedule, das ist die zentrale Komponente in Kubernetes,
Interviews: die, wenn eine Anfrage reinkommt über, ich möchte gerne dieses Diplom machen,
Interviews: der Pod-Schedule nimmt diese Anfrage und versucht sie dann quasi zu erfüllen,
Interviews: indem er sagt, okay, welchen Pod habe ich hier?
Interviews: Okay, der braucht so viele Micro-Cores, so viel Memory, wo wird denn der hindeployed?
Interviews: Und wir haben da quasi eine Möglichkeit über Webhooks in Kubernetes,
Interviews: um uns dort reinzuhängen und somit können wir unabhängig, welches Tool jetzt
Interviews: deployed oder welches Tool die Anfrage an Kubernetes stellt,
Interviews: etwas zu deployen, können wir diese Adresses erzeugen und das ist das Schöne daran.
Interviews: Ich verwende jetzt nicht immer Argo und Flux als Beispiel, weil es ja sehr prominente
Interviews: Tools sind in diesem Umfeld.
Interviews: Aber ihr könnt auch das mit GitLab einfach so machen oder mit GitLab Runner
Interviews: oder darauf verzichten wie wir.
Interviews: Oder darauf verzichten, genau. Und das per Hand sozusagen machen.
Interviews: Und Captain, muss ich das als Developer mir überlegen, dass ich das verwenden
Interviews: will oder frage ich da meinen Infrastruktur-Team und sage,
Interviews: ich hätte gerne diese Observability-Daten schon und dann überlegt sich das Infrastruktur-Team,
Interviews: okay, dann machen wir es mit Captain.
Interviews: Ja, grundsätzlich glaube ich, sind es immer die Teams, die auch das Delivery
Interviews: reinbringen in eine Kubernetes-Umgebung.
Interviews: Also die gleichen Teams, die GitLab oder Jenkins oder Argo und Flux reinbringen
Interviews: in eine Organisation, sagen dann, hey, wir sehen, dass oft Pipelines schieflaufen,
Interviews: wie können wir bessere Diagnose bringen? Und da gibt es Captain als Tool.
Interviews: Das heißt, das Team, ich sage jetzt mal Plattform Engineering,
Interviews: sehen wir halt sehr oft oder DevOps Team oder Infrastructure,
Interviews: wer auch immer verantwortlich ist, um diese Tools auf Kubernetes zu bringen,
Interviews: die würden dann auch Captain reinbringen.
Interviews: Aber der Entwickler hat dann pro Namespace die Option, über eine Annotation
Interviews: zu sagen, ich möchte jetzt auf meinem Namespace, wo ich meine App deploye,
Interviews: wirklich auch Captain aktivieren.
Interviews: Okay, also es ist selbst keine Pflicht. Nein, keine Pflicht.
Interviews: Das heißt auch nicht, dass ein Team dann, oder wenn Infrastruktur festgelegt
Interviews: hat, okay, wir würden Captain verwenden, aber jemand sagt, brauche ich nicht.
Interviews: Ich will jetzt diese, weil keine Ahnung, wie viel Potz das Ding dann jetzt noch
Interviews: mit aufmacht. Kannst du vielleicht nochmal erklären?
Interviews: Genau, es ist einfach nur ein Operator. Das heißt, der Operator hängt sich dann
Interviews: über einen Webhook in Kubernetes rein und wir haben selbst sonst keinen Overhead mehr.
Interviews: Das ist das Schöne daran. Wir haben jetzt eigentlich sehr low Overhead,
Interviews: weil wir hängen uns zwar eine zentrale Komponente in Kubernetes rein über einen
Interviews: Webhook, aber wir sind nur aktiv,
Interviews: wenn dann Kubernetes uns sagt, hey, da gibt es jetzt ein Deployment in diesem
Interviews: Namespace und wir sehen dann noch, ist dieser Namespace annotiert,
Interviews: ob Captain aktiv sein soll, ja oder nein.
Interviews: Wenn nicht, macht man gar nichts. Wenn ja, erzeugt man einen Trace.
Interviews: Apropos Hooks. Ich habe auch gelesen, dass ihr so Pre-Hooks oder Post-Hooks
Interviews: irgendwie haben könnt, dass man davor und danach im Deployment noch Dinge macht.
Interviews: Danke, dass du das aufbringst, weil das ist der zweite große Use-Kist.
Interviews: Also der erste ist quasi die Observability.
Interviews: Wie oft wird deployed? Was passiert beim Deployment? Wie lange dauert es?
Interviews: Wo läuft es schief? Das zweite ist, was wir auch gelernt haben,
Interviews: nur wenn man jetzt deployed und am Schluss vom Deployment sind alle Pods laufen
Interviews: und healthy, heißt das nicht, dass die Anwendung läuft.
Interviews: Da gibt es viele Sachen. Entweder man hat eine Anwendung deployed,
Interviews: aber die dependente Datenbank ist eigentlich auch falsche und im Endeffekt gehe
Interviews: ich jetzt auf ein falsches externes System oder ich deploye,
Interviews: habe aber meinen Ingress falsch konfiguriert, deswegen kommen jetzt keine User drauf.
Interviews: Es gibt ja Sachen, die schief laufen. Ich sage immer, pod healthy does not mean
Interviews: application healthy and accessible.
Interviews: Jetzt bietet Captain zwei Möglichkeiten an.
Interviews: Pre- und Post-Deployment, das heißt, bevor dann Kubernetes, PodSketch oder wirklich
Interviews: anfangen zum Deployen, können wir Tasks und Evaluations ausführen.
Interviews: Das heißt, wir haben im Captain die Möglichkeit zu sagen, bitte führ diesen Task aus.
Interviews: Ein Task ist, ähnlich wie bei GitHub Actions, einfach ein Container,
Interviews: beziehungsweise wir bieten auch an, über TypeScript Functions zu schreiben,
Interviews: die wir in einem Container ausführen, die zum Beispiel sagen,
Interviews: ist das die Pending Environment da, sind auf dem Git-Commit alle Requirements
Interviews: drauf. Also ich kann einfach Pre-Checks machen.
Interviews: Ich kann aber auch Checks machen gegen Observability-Daten. Zum Beispiel habe
Interviews: ich genug Ressourcen zur Verfügung.
Interviews: Ich kann auf Prometheus gehen oder auf andere Observability-Vendoren und sagen,
Interviews: ist das Environment überhaupt ready?
Interviews: Wenn das Environment nicht ready ist und diese Checks fehlen,
Interviews: dann geben wir an den Pod Scheduler auch weiter, du, zur Zeit können wir nicht
Interviews: deployen, weil die Pre-Checks nicht successful sind.
Interviews: Das würde dann auch anhalten an der Stelle? Genau, das würde im Endeffekt das
Interviews: Gleiche bewirken, als wenn du auf deinem Kubernetes-Cluster nicht genug CPU oder Memory hast.
Interviews: Dann würde im Endeffekt auch der Pod-Scheduler sagen, du, es tut mir leid,
Interviews: ich habe nichts gefunden.
Interviews: Und in dem Fall sagt dann der Pod-Scheduler, du, es tut mir leid,
Interviews: aber der Captain sagt, es geht zurzeit nicht.
Interviews: Und das Gleiche, was wir Pre-Check machen, Pre-Deployment-Checks,
Interviews: machen wir auch Post-Deployment.
Interviews: Das heißt, als Post-Deployment-Check kannst du auch wieder sagen,
Interviews: hey, jetzt möchte ich wirklich sicherstellen, dass meine Anwendung auch von
Interviews: außen zugreifbar ist. jetzt setze ich meinen Curl-Request ab auf dem Endpoint.
Interviews: Oder ich frage jetzt mein Observability-Tool, ob meine SLOs nachher vor allem grün sind.
Interviews: Das heißt, vorm Deployment,
Interviews: verhindern oder zumindest validieren, ob das Environment überhaupt ready ist
Interviews: und nach dem Deployment verifizieren, dass nicht nur die Pods laufen,
Interviews: sondern auch wirklich die Anwendung zugreifen.
Interviews: Funktioniert, okay. Und weil du jetzt gesagt hast, ich kann ein Curl-Request
Interviews: oder sowas absetzen, wie programmiere ich das?
Interviews: Muss ich mich da an irgendeine bestimmte Programmiersprache halten oder kann
Interviews: ich einfach jedes Skript aufrufen oder wie funktioniert das?
Interviews: Es gibt grundsätzlich die Möglichkeit, einfach einen Container zu definieren.
Interviews: Das heißt, wir starten dann einfach den Container via GitHub Action.
Interviews: Du kannst jeden ledigen Container einfach. Dieser Container bekommt natürlich
Interviews: dann Kontext mit von uns, das heißt, in welchem Kontext wird ausgeführt.
Interviews: Pre- oder Post-Deployment-Check, für welche Anwendung, das heißt,
Interviews: das wird alles mitgegeben.
Interviews: Wir bieten auch an, eine TypeScript-basierte Sprache, also auch in TypeScript
Interviews: kannst du schreiben und das packen wir dann in eine Dino-Runtime,
Interviews: das heißt, für schnelle Checks kannst du einfach in TypeScript programmieren
Interviews: und einfach ein schnelles Curl-Request absetzen.
Interviews: Aber die einfachste Variante ist vermutlich einfach einen Container zu nehmen, nehmen wollt.
Interviews: Wo alles schon drin ist. Wenn man vielleicht sowieso hat, weil man das vorher
Interviews: ja auch schon irgendwie mal gemacht hat, geguckt hat, ob es an der Anwendung
Interviews: läuft oder solche Sachen.
Interviews: Genau, und diese Metric-Checks oder wir nennen es Objectives-Checks oder SLO-Checks,
Interviews: Service Level Objectives-Checks, da braucht man selbst nicht Coden,
Interviews: sondern da kann man einfach nur definieren, ich möchte von Prometheus diese
Interviews: Query absetzen oder ich möchte, ich arbeite bei DeinAdress, bei DeinAdress gibt
Interviews: es auch eine Integration,
Interviews: ich möchte von DeinAdress diese und diese Metric haben und ich möchte gerne
Interviews: validieren, vorm oder nach dem Deployment, dass diese Metrik in einem gewissen Wertebereich steckt.
Interviews: Wir nennen diese Komponente den sogenannten Captain Metrics Server.
Interviews: Das heißt, der Captain Metrics Server selbst holt sich Metriken von Datensourcen,
Interviews: Prometheus, Dynatrace, Datadog, New Relics, Blank, was auch immer,
Interviews: holt sich diese Metriken rein, zurück in Kubernetes und wir verwenden sie dann
Interviews: für diese Checks, wo dann der Entwickler dann sagen kann, ich möchte gerne,
Interviews: nach dem Deployment, dass meine Availability basierend auf meinem Monitoring-Tool
Interviews: immer noch 100% ist oder dass ich eine gewisse Response-Time habe.
Interviews: Und wenn so ein Post-Check dann fehlt, was mache ich dann? Also beim Pre-Check,
Interviews: okay, da höre ich auf. Beim Post-Check baue ich jetzt alles wieder ab und sage Hilfe.
Interviews: Nein, beim Post-Check können wir das Rollback natürlich nicht direkt machen,
Interviews: aber beim Post-Check wäre es dann so, dann würde das im Endeffekt als Status
Interviews: aufscheinen, zum Beispiel in Algo oder man würde dann zum Beispiel einen Workflow
Interviews: triggern, der dann das Rollback gemacht hat, man würde Leute notifizieren.
Interviews: Wir haben dort leider von der Kubernetes-Architektur nicht mehr die Möglichkeit,
Interviews: das Kubernetes selbst zu sagen, Rollback.
Interviews: Aber da würde man zum Beispiel zum Thema Progressive Delivery,
Interviews: da gibt es ja viele Tools wie zum Beispiel Argo Rollouts.
Interviews: Man könnte doch Argo Rollouts steuern damit und dann würde Argo Rollouts,
Interviews: also ein higher level Tool, eigentlich das Rollback dann vornehmen. Okay.
Interviews: Wäre natürlich auch wichtig, gerade wenn es irgendeine produktive Anwendung
Interviews: ist, zu sagen, ja okay, mein Deployment hat nicht richtig funktioniert,
Interviews: ich muss schnell wieder zurück, um auf den Stand zu kommen, der bis vor ein
Interviews: paar Sekunden eben noch richtig funktioniert hat. Das will ich natürlich schon haben.
Interviews: Das heißt, ich kann auf jeden Fall eine Message, egal ob das E-Mail oder Slack
Interviews: oder irgendwas rausschicken und dann meine Entwickler sagen, halt hier.
Interviews: Genau, es geht wieder über diese Tasks. Das heißt, diese Tasks werden ausgeführt,
Interviews: nachdem die Evaluations ausgeführt werden. Das heißt, der Task bekommt dann auch mit.
Interviews: Post Deployment ist jetzt der Post Deployment sind Evaluation Tasks,
Interviews: also die SLOs, diese Metriken, sind die grün oder rot?
Interviews: Und aufgrund von dem kannst du dann auch reagieren und sagen,
Interviews: hey, alles ist grün, super, ich schicke nur eine Info-Message oder rot,
Interviews: jetzt schicke ich, jetzt mache ich ein Jira-Ticket auf.
Interviews: Was ist denn jetzt gerade neu bei Captain? Was habt ihr denn in letzter Zeit
Interviews: zusätzlich entwickelt oder wo seid ihr gerade dran vielleicht auch?
Interviews: Ja, vielleicht muss man historisch, muss man sehen, wir arbeiten seit sechs
Interviews: Jahren an Captain und vor sechs Jahren hat die Welt anders ausgesehen in Kubernetes
Interviews: und wir haben auch, glaube ich, damals versucht,
Interviews: zu viele Probleme zu lösen.
Interviews: Wir haben dort unsere eigene UI gehabt, um eben diese Daten zu visualisieren.
Interviews: Wir haben auch eigene Workflows drinnen gehabt.
Interviews: Und fünf Jahre später, also jetzt, haben wir gesehen, unsere Community hat uns
Interviews: gesagt, hey, es ist zwar super, dass ihr eine eigene UI habt,
Interviews: aber eigentlich generiert sie OpenTelemetry-Daten und Prometheus und wir wollen
Interviews: diese Daten in unseren Observability-Tool.
Interviews: Also das heißt, ganz genau, super Feedback.
Interviews: Ein paar haben natürlich die UI geliebt, aber der Großteil sagt, brauchen wir nicht.
Interviews: Das heißt, wir haben uns erstens einmal geschiftet auf, wir erzeugen wirklich
Interviews: OpenTelemetry in Prometheus und somit haben wir alles da abgehandelt. done.
Interviews: Wir haben eine eigene, wir haben Sequences genannt, ähnlich wie Workflow.
Interviews: Wir brauchen keine Workflow-Engine mehr, weil es gibt Algo-Workflows und es
Interviews: gibt viele andere Workflow-Tools in Kubernetes.
Interviews: Das heißt, wir haben uns wirklich gesagt, wir fokussieren uns auf das,
Interviews: wo wirklich die Probleme, wo die Leute noch die Probleme haben.
Interviews: Das ist Deployment Observability, was wird deployed, was ist langsam,
Interviews: was schlagt fail und diese Pre- und Post-Deployment-Checks und Tasks.
Interviews: Und auf das haben wir uns jetzt fokussiert und heuer, also diese Woche,
Interviews: haben wir auch offiziell die Version 2.0 released.
Interviews: Das, was wir vor sechs Jahren gestartet haben, hat jetzt lange Version 1.0 geheißen.
Interviews: Dann haben wir in der Transition-Phase, das hat jetzt ungefähr eineinhalb Jahre
Interviews: gedauert, haben wir Captain Lifecycle Toolkit genannt, weil es ist um den Lifecycle
Interviews: von einem Deployment gegangen.
Interviews: Und dies haben wir jetzt offiziell auf Captain 2.0 benannt. Das heißt,
Interviews: Captain 2.0, die aktuelle Version, ist genau das, was ich jetzt erklärt habe.
Interviews: Und wir haben einen langen Weg gehabt bis dahin, aber wir haben uns jetzt wirklich
Interviews: den Sweet Spot gefunden. und wir bekommen auch das Feedback von der Community,
Interviews: speziell jetzt von der GitOps-Community, Argo Flux, dass wir hier wirklich ein Problem lösen.
Interviews: Okay, dass die Leute da wirklich happy sind, dass ihr das die Probleme angeht,
Interviews: die da auch wirklich drängend sind und nicht euch verkünstelt sozusagen. Ganz genau, ja.
Interviews: Okay, also ihr habt sogar rebranded, weil ich mich nämlich auch gefragt habe,
Interviews: was ist denn dieses Toolkit jetzt noch? Ist es nochmal ein anderes Produkt?
Interviews: Oder, nee, Captain 2.0 ist Ist Captain, genau, ja.
Interviews: Ist genau das. Jetzt hast du ganz oft Open Telemetry gesagt.
Interviews: Was ist denn genau das? Was macht das besonders?
Interviews: Also Open Telemetry ist ja quasi ein Standard, wie Telemetry-Daten,
Interviews: Traces, Logs und Metriken eigentlich in einer Anwendung gecaptured werden.
Interviews: For a lack of better terms. Oft verlerne ich leider die deutschen Wörter schon.
Interviews: Ja, geht uns zu allen so, glaube ich. Genau.
Interviews: Vielleicht muss man ein bisschen zurückgehen in der Geschichte.
Interviews: Ich bin ja seit 16 Jahren bei der Dynadress und die Dynadress gibt es schon
Interviews: länger und davor hat es auch schon Observability-Tools gegeben.
Interviews: Nur die haben halt damals Monitoring-Tools geheißen, jetzt heißen sie Observability-Tools.
Interviews: Das heißt, viele dieser Tools, genauso wie bei der Dynadress,
Interviews: wir haben Agenten geschrieben, also quasi Software-Komponenten,
Interviews: einen Software- Agenten, den man installiert hat und dieser Agent hat dann versucht,
Interviews: aus Anwendungen aus Java, .NET und so weiter Daten zu extrahieren.
Interviews: Metriken, Logs und Traces. es und jeder hat sein eigenes Süppchen irgendwie gekocht.
Interviews: Mit OpenTelemetry gibt es einen Standard. Da gibt es Standard Libraries für.
Interviews: Anwendungsentwickler, um zu sagen, wie kann ich jetzt meine Anwendung so erweitern,
Interviews: damit meine Anwendung Metriken generiert, Traces generiert oder sogenannte Spans generiert und Logs so,
Interviews: dass sie über OpenTelemetry, über diesen Standard dann nach außen gegeben werden
Interviews: und von jedem Observability Tool, von jedem Backend aufgegriffen werden können,
Interviews: egal ob das jetzt Jäger ist, Grafana, Elastic,
Interviews: Datadog, Dynatrace, New Relic.
Interviews: Es gibt quasi einen Standard auf der, wie werden die Daten generiert und das
Interviews: Protokoll, quasi die Daten, die da rauskommen.
Interviews: Und dann gibt es unterschiedliche Backend-Provider, sowohl Open-Source als auch
Interviews: kommerzielle, die dann diese Daten verstehen.
Interviews: Und das ist auch der Grund, wieso wir bei Captain Open Telemetry einsetzen,
Interviews: weil wir erzeugen sogenannte Traces und wir erzeugen Metriken und deswegen steigen
Interviews: wir natürlich auch auf einen Standard auf,
Interviews: weil wenn wir Standarddaten erzeugen, gibt es unterschiedliche Tools,
Interviews: die der End-User verwenden kann, um diese Standarddaten anzuzeigen und zu analysieren.
Interviews: Ja, und das eine Tool hat vielleicht den einen Vorteil und das andere Tool…
Interviews: Ganz genau, ja, genau. Genau.
Interviews: Ich muss aber als Entwickler jetzt wirklich aufpassen, dass meine Applikation
Interviews: diese Daten irgendwie erzeugen kann.
Interviews: Oder gibt es da, oder muss ich einfach nur eine Library reinhängen und dann
Interviews: funktioniert das automatisch? Genau, also bei OpenTelemetry,
Interviews: wir sprechen jetzt über OpenTelemetry und nicht mehr über Captain.
Interviews: Bei OpenTelemetry gibt es mittlerweile auch sehr viele Auto-Instrumentoren.
Interviews: Auto-Instrumentatoren. Ich hoffe, das ist ein richtiges deutsches Wort.
Interviews: Quasi angefangen hat es natürlich, es gibt ein SDK für die unterschiedlichen
Interviews: Sprachen und als Entwickler muss ich meinen Code ändern, um eben diesen Daten zu erzeugen.
Interviews: Mittlerweile gibt es für die meisten Sprachen schon Agenten,
Interviews: auch wieder Agenten, die halt automatische Instrumentierung machen und automatisch
Interviews: schon Traces und Metriken erzeugen.
Interviews: Das gibt es natürlich bei unterschiedlichen Runtimes. Ich bringe jetzt Java
Interviews: und .NET zum Beispiel, weil die kenne ich am besten.
Interviews: Dort gibt es Möglichkeiten, wie man sich in diese Runtime reinhängt und dann
Interviews: dynamisch bei der Ausführung vom Code sich in gewisse Hooks reinhängt und somit
Interviews: im Endeffekt für kritische Methoden, die aufgerufen werden, automatisch Traces erzeugt.
Interviews: Das heißt, als Entwickler brauche ich bei vielen Sachen eigentlich nichts mehr
Interviews: machen, sondern ich bekomme eigentlich diese Traces und Metriken.
Interviews: Nur jeder Agent, jeder Auto-Instrumentor kann nicht wissen, welche Daten wirklich
Interviews: komplett relevant sind für jeden Entwickler.
Interviews: Weil ich kenne die Anwendung im Vorhinein nicht, wenn ich so einen Agenten schreibe.
Interviews: Und deswegen hat der Entwickler immer noch die Möglichkeit, seine spezielle
Interviews: Methode, die er haben will.
Interviews: Wenn er sagt, diese Methode ist wichtig für mich, ich möchte wissen,
Interviews: wann sie ausgeführt wird, wie oft und ich möchte auch noch diese und diese.
Interviews: Methodenargumente capturen, dann kann der Entwickler das noch sagen,
Interviews: indem er einen Aufruf macht auf die OpenTelemetry Library und dann wird das,
Interviews: was er emittet, was er da erzeugt mit diesem Aufruf quasi gemerged mit allem
Interviews: Restlichen, was OpenTelemetry so erzeugt.
Interviews: Okay, dann muss ich natürlich wieder auf der anderen Seite gucken,
Interviews: dass ich diese Daten mir entsprechend anzeige und dann daraus irgendwas mache oder eben noch nicht.
Interviews: Ich muss natürlich wissen, okay, wenn ich jetzt so eine Funktion habe,
Interviews: vielleicht, weiß ich nicht, hängt das Programm gerade in der dann öfter mal
Interviews: auf oder ich brauche einfach zu lange oder es ist eine Funktion,
Interviews: die Daten irgendwo her beziehen soll und die Datenquelle ist gerade nicht da
Interviews: oder wie auch immer, dass ich das irgendwas benutze.
Interviews: Und was auch schön ist, also ich bin in dieser Industrie schon relativ lange
Interviews: jetzt, seit 16 Jahren bei der Dynatrace, aber das coole an der Open Telemetry
Interviews: ist, dass sich hier wirklich alle Vendoren eigentlich jetzt zusammengegeben
Interviews: haben und gesagt haben, wir kontributen,
Interviews: weil im Endeffekt ist es ein Benefit auch für die ganzen kommerziellen Hersteller,
Interviews: weil das schwierigste oder eine sehr schwierige Komponente für Observability-Vendoren ist,
Interviews: diese Agenten zu entwickeln und zu maintainen.
Interviews: Und wenn man das für jede Sprache machen soll, dann… für jede Sprache, immer up-to-date.
Interviews: Und eigentlich ist es viel einfacher, wenn man sich auf einen Standard fokussiert
Interviews: und im Endeffekt dann die Entwickler von Runtimes,
Interviews: von Libraries, ich spreche jetzt mal Hibernate zum Beispiel an,
Interviews: ich sage immer nach wie vor eine sehr prominente Library oder andere Libraries,
Interviews: die Entwickler von diesen Libraries, die verwenden wir in vielen Anwendungen,
Interviews: die wissen ja am besten, was eigentlich wichtig ist, wenn deren Libraries aufgerufen werden.
Interviews: Das heißt, es ist viel besser, wenn die ihre Library schon vorinstrumentieren mit OpenTelemetry.
Interviews: Sodass jeder Entwickler, der dann die Library verwendet, sicher sein kann,
Interviews: dass die Traces, die dann rauskommen, die richtigen Daten enthalten.
Interviews: Und das hilft auch den Vendoren, weil wir brauchen uns dann nicht mehr hunderte
Interviews: Entwickler halten, die ständig die Agenten updaten müssen.
Interviews: Ja, die immer nur hinterher programmieren. Das heißt, das ist auch der Grund,
Interviews: warum Dynatrace da hinterher ist und sagt, okay, wir committen uns da jetzt
Interviews: OpenTelemetry zu machen.
Interviews: Genau, plus wir haben auch Engineers, die wirklich aktiv an OpenTelemetry mitarbeiten,
Interviews: weil es ist ja nicht so, dass einfach, ja, ihr Community macht einfach mal.
Interviews: Natürlich, also sehr viele von den Observability-Herstellern haben auch Engineering-Ressources
Interviews: wirklich committed auf OpenTelemetry als Open-Source-Brick, genauso wie wir.
Interviews: Wir haben einige Engineers, die aktiv 100% nur an OpenTelemetry arbeiten.
Interviews: Wir haben unseren Code für gewisse Instrumentierungen von gewissen Sprachen
Interviews: zurückcontributed an OpenTelemetry und jetzt, wie gesagt, arbeiten wir aktiv
Interviews: daran, das weiterzuentwickeln.
Interviews: Das heißt, Open Telemetry ist jetzt sozusagen der Standard da an der Stelle.
Interviews: Es ist auch mittlerweile eins der größten CNCF-Projekte, wenn ich das richtig gelesen habe. Genau.
Interviews: Und wie entwickelt ihr da mit anderen Firmen zusammen?
Interviews: Also habt ihr da irgendwie, ist das alles in der CNCF? Alles in der CNCF.
Interviews: Dass ihr da, weiß ich nicht, trefft ihr euch dann ab und zu mal und besprecht
Interviews: irgendwas oder ist es, weil es ein Community-Projekt ist, ist es sowieso aus
Interviews: jeder Firma, sind da Leute dabei?
Interviews: Naja, es ist so, also wie jedes CNCF-Projekt und wie die meisten Open-Source-Projekte
Interviews: gibt es halt dort regelmäßige Meetings, da wird im Endeffekt besprochen,
Interviews: was wird als nächstes angegangen und im Endeffekt sind wir halt dann einer dieser
Interviews: Firmen, die halt dort oder Community-Members,
Interviews: die dort mitwirken und sich aktiv einbringen.
Interviews: Also wie jedes andere Community-Projekt genauso und dort versuchen wir gemeinsam.
Interviews: Auch mit unserer offiziellen Konkurrenz dort das Projekt weiterzutreiben.
Interviews: Weißt du, was als nächstes bei OpenTelemetry ansteht oder bist du da ein bisschen rauf?
Interviews: Ja, ich glaube, mit Traces hat es ja angefangen, Logs, Events, Metriken.
Interviews: Es geht einfach darum, die alle Signale von Observability abzudecken.
Interviews: Profiling ist, glaube ich, gerade announced worden. Sie wollen jetzt auch Richtung Profiling gehen.
Interviews: Das heißt, es geht darum, dass man OpenTelemetry noch erweitert,
Interviews: um eben diese weiteren Signale von Observability, weil wenn ich jetzt wieder
Interviews: historisch zurückgehe, was wir als Venturen gemacht haben in den letzten Jahren,
Interviews: wir haben ja Dynatrace mit Tracing angefangen, auch im Namen Dynatrace und wir
Interviews: haben es dann erweitert auf Logs, Metriken, Events,
Interviews: End-User-Daten, Profiling und so weiter.
Interviews: Wenn ich mir andere ansehe, wie zum Beispiel das Planck, das Planck kommt ja
Interviews: traditionell jetzt nicht aus dem Logging, hat natürlich sehr viel in Logs angefangen
Interviews: und hat sich dann in andere Signale weiterentwickelt.
Interviews: Und das ist das Gleiche jetzt mit Open Telemetry. Open Telemetry hat mit Traces
Interviews: angefangen und versucht hat jetzt alle anderen Signale abzudecken.
Interviews: Indem zuerst einmal quasi Basis-Support eingebaut wird, dann Refined,
Interviews: bis man im Endeffekt dann eine Version hat von Open Telemetry, wo man sagt,
Interviews: das ist jetzt GA Version 1.0, die Spezifikationen sind alle da und dann können
Interviews: auch Vendoren wie wir sagen, okay, wenn jetzt eine Anwendung instrumentiert
Interviews: ist mit OpenTelemetry und da kommen Logs raus,
Interviews: dann wissen wir, die kommen in diesen Format und das können wir auch so verarbeiten.
Interviews: Und ihr habt dann als Standard Trace irgendwie eine schöne Web-Oberfläche und
Interviews: natürlich, ja, ja, genau.
Interviews: Und natürlich auch eine AI, weil jeder eine AI hat, aber wir haben die AI schon
Interviews: relativ lange, aber anscheinend waren wir ein bisschen zu früh dran mit dem ganzen.
Interviews: Ja, wir haben die AI, die heißt Davis bei uns, die im Endeffekt alle Daten natürlich
Interviews: analysiert und der man auch Fragen stellen kann und alles mögliche.
Interviews: Okay, und dann bastle ich mir irgendwelche Sachen zusammen und kriege dann auch
Interviews: irgendwelche Alerts oder so, wenn irgendwas nicht stimmt.
Interviews: Genau, die Idee ist eigentlich, ich will jetzt nicht zu viel Commercial machen
Interviews: für dein Adress, ich glaube, das ist nicht der Sinn und Zweck von dem Podcast,
Interviews: aber viele Observative Venturen, die schon lange im Geschäft sind.
Interviews: Wir haben natürlich sehr viel Erfahrung mit der Analyse von sehr vielen Datenmengen
Interviews: und nicht nur von Daten, die unabhängig voneinander gesehen werden, sondern im Kontext.
Interviews: Das heißt, wenn wir zum Beispiel sehen, eine Response Time von einer Anwendung,
Interviews: die auf Java läuft und gleichzeitig hat Java High Garbage Collection,
Interviews: weil einfach zu wenig Memory da ist, dann liefern wir nicht unterschiedliche
Interviews: Alerts, wir sagen dann nicht Response Time High und Garbage Collection hat ein
Interviews: Problem und du bist auf 100% CPU, sondern da erzeugen wir ein Problem und sagen.
Interviews: Ein Problem ist, du hast eine hohe Response-Zeit, der Root-Course ist Garbage-Collection
Interviews: und die Aktion, um das zu lösen, wäre im Endeffekt es zu skalieren oder andere
Interviews: Memory-Settings zu machen.
Interviews: Das heißt, das ist dann der Mehrwert von einer kommerziellen Analytics-Solution.
Interviews: Nicht nur dir jetzt Daten zu geben, die du dann auf ein großes Dashboard gibst
Interviews: und selbst die Schlüsse ziehst, sondern die Schlüsse werden für dich automatisch
Interviews: schon gezogen. Zumindest ein Großteil.
Interviews: Okay, wenn ich selber hoste, mir selber die Daten angucke oder darstelle,
Interviews: müsste ich mir solche Regeln eben selber bauen. Genau.
Interviews: Oder ich weiß nicht, gibt es irgendwelche Community-Projekte dazu, weißt du, oder was?
Interviews: Das weiß ich jetzt leider nicht, nachdem es da viel gibt. Ja,
Interviews: aber dann müsste ich mich selber hinsetzen und sagen, okay, ich sehe die ganzen
Interviews: Daten sozusagen, ich habe eine Ahnung, wie meine Applikationen funktionieren sollen, aber um dann,
Interviews: aus den Daten irgendwas Sinnvolles zu machen, müsste ich mir halt eigene Regeln
Interviews: bauen und dann meinen Entwicklern Bescheid geben und sagen, hier,
Interviews: guck dir mal das Problem da ein bisschen genauer an, da stimmt irgendwas nicht.
Interviews: Genau, und eben diese Regeln, da gibt es natürlich sehr viele unterschiedliche
Interviews: Ansätze, wir machen sehr viel an Anomalie-Detection mit unterschiedlichen Algorithmen,
Interviews: um herauszufinden, gibt es ein abnormales Verhalten,
Interviews: ist jetzt die Response-Time abnormal oder normal, basierend auf Baselines,
Interviews: das heißt, es ist Montag in der Früh.
Interviews: Ist jetzt Montag in der Früh die Response-Time immer so oder ist es heute anders,
Interviews: das läuft irgendwas anders am System, was einen Impact drauf hat.
Interviews: Das heißt, das ist auch der Vorteil, weshalb man dann vielleicht kommerzielle
Interviews: Venturen verwendet, um eben die Daten zu analysieren. Man kann alles selbst machen.
Interviews: Die Frage ist, wie viele Leute muss man investieren und wie viel Expertise hat
Interviews: man selbst im Haus, um die Schlüsse dann zu ziehen?
Interviews: Oder sagt man, man investiert dann doch das Geld und schickt die Daten an eine
Interviews: Lösung, die dann schon sehr vieles automatisch kann.
Interviews: Trotzdem sollte man sich ja ein bisschen mit Open Telemetry auskennen,
Interviews: weil da bringt es nichts, wenn ich eine größere Lösung kaufe und dann keine Ahnung habe.
Interviews: Wobei, da muss man nochmal ganz kurz sagen, Open Telemetry fokussiert sich darauf,
Interviews: wie wir die Daten bekommen.
Interviews: Open Telemetry sagt nichts aus, wie die Daten analysiert werden.
Interviews: Deswegen hast du vorhin auch zum Beispiel Jäger nochmal erwähnt.
Interviews: Also mir war am Anfang auch nicht klar, ich hatte das irgendwie so in dieselbe Ecke gesteckt.
Interviews: Ich habe gedacht, die machen quasi dasselbe. Aber nee, das eine ist die API,
Interviews: die mir die Sachen anzeigt und dann brauche ich ein anderes Produkt,
Interviews: was diese Daten dann nimmt und daraus irgendwas auch macht.
Interviews: Genau, also OpenTelemetry sagt, welche Daten wollen wir haben von den Anwendungen,
Interviews: welche Traces, welche Logs, welche Metriken sind interessant.
Interviews: Diese Daten müssen dann irgendwo hingeschickt werden an ein Backend und wenn
Interviews: es ein Backend ist, können sie visualisiert werden oder analysiert.
Interviews: Jaeger ist ein Tool, um Traces zu analysieren.
Interviews: Visualisiert. Ich kann mir einen Trace ansehen. Ich kann mir auch 100 Traces
Interviews: ansehen und Jäger bietet mir dann eine UI an, um zu sagen, ich möchte jetzt
Interviews: nur die Traces sehen, die länger als 5 Sekunden dauern.
Interviews: Genau. Das ist dann so wie in der Webkonsole hier bei Browsern oder sowas,
Interviews: wo ich einfach sagen kann, okay, zeig mir das mal und sehe, okay,
Interviews: die eine Abfrage nach dem Bild hat so und so lange gedauert oder hat es nicht gefunden.
Interviews: So nach dem Motto würde ich das dann in Jäger oder anderen Tools sehen. Genau. Ganz genau.
Interviews: Gut, gibt es noch einen Grund, Captain einzusetzen? Gibt es noch einen Grund,
Interviews: sich wirklich mit Open Telemetry auseinanderzusetzen?
Interviews: Oder sagst du, nee, ist eigentlich, muss man machen heutzutage.
Interviews: Ich sage mal so, wenn du dich in ein Flugzeug setzen möchtest und du weißt,
Interviews: der Pilot hat keine einzigen Instrumente, er weiß nicht, wie schnell er fliegt
Interviews: und wie viel Sprit noch im Tank ist, dann brauchst du nicht auf Open Telemetry
Interviews: zu sein und nicht auf Captain.
Interviews: Wenn du aber gerne willst, dass du weißt, was passiert, dann würde ich sagen,
Interviews: schaut euch OpenTelemetry an oder generell Observability.
Interviews: Und der Captain bietet, wie gesagt, die Observability in die Deployments.
Interviews: Schon integriert. Genau, deswegen hoffe ich, dass die Leute sich das ein bisschen ansehen.
Interviews: Klingt auf jeden Fall nach einem coolen, interessanten Projekt,
Interviews: was man sich mal angucken kann.
Interviews: Vielen Dank, Andreas, dass du uns mal diese beiden Projekte vorgestellt hast
Interviews: und dass man ein bisschen auseinanderklamüsert hast.
Interviews: Weil, genau, also auch mir waren da so ein paar Sachen unklar und ich hoffe,
Interviews: das hat man jetzt ein bisschen besser verstanden. Ich hoffe auch, ja.
Interviews: Und es ist natürlich nicht leicht, up-to-date zu bleiben bei allem,
Interviews: was sich im Kubernetes-Umfeld in der CNCF tut.
Interviews: Es gibt ja mittlerweile 170, 180 unterschiedliche Projekte und das alles zu
Interviews: verstehen ist natürlich sehr schwer.
Interviews: Und mittlerweile aktuell ist ja zumindest diese Woche natürlich alle der ganze
Interviews: Fokus ist auf AI und alles mögliche, dagegen,
Interviews: vielleicht andere wichtigere Sachen auch runter, aber es gibt Gott sei Dank
Interviews: genug Informationen und Videos um sich dort ein bisschen einzulesen Genau,
Interviews: kannst du vielleicht nochmal sagen, was ist eure,
Interviews: Webseite von Captain, wo kann man sich vielleicht noch ein paar Informationen holen?
Interviews: Ja, www.captain.sh ist die Webseite Wir sind zwar Captain mit E,
Interviews: ich habe auch K-E-P-T-N, ja genau.
Interviews: Ja genau, Captain K-E-P-T-N, ja und am besten aber im CNCF Slack.
Interviews: So CNCF hat ja einen eigenen Slack-Workspace und dort haben wir mit Captain
Interviews: K-E-P-T-N auch unseren Channel, wo man dann die Community und die Maintainers und alle findet.
Interviews: Verlaufen sich da manchmal ein paar Leute? Also wie gesagt, ich habe Captain
Interviews: mal gesucht und habe gedacht, okay, da gibt es eins mit A, eins mit E.
Interviews: Das war irgendwie ein bisschen... Das ist ja interessant natürlich.
Interviews: Der Name kommt ja quasi von der Käpt'n, der eigentlich am Steuerrad sitzt,
Interviews: der den Container richtig in den Hafen bringt.
Interviews: Und das ist die deutsche phonetische Variante von einem Käpt'n.
Interviews: Deswegen haben wir K-I-P-T-N. Und ich glaube, es hat.
Interviews: Interessanterweise, es gibt irgendeine Web, irgendeine Firma in Norddeutschland
Interviews: sogar, die auch einen ähnlichen Namen, aber machen komplett was anderes,
Interviews: ist auch eine ähnliche Variante von Captain.
Interviews: Es kann schon sein, dass sich Leute verlaufen, aber ich hoffe,
Interviews: sie finden dann trotzdem irgendwie zu uns, weil sie Podcasts wie deinen hören
Interviews: und jetzt wissen, wie man Captain richtig buchstabiert. Richtig buchstabiert.
Interviews: Genau, vielen Dank. Dann hoffe ich mal, vielleicht schlagen ein paar neue Leute
Interviews: bei euch auf, lesen sich die Dokumentationen durch oder kommen sogar in den Slack-Channel.
Interviews: Ich nehme an, da sind auch Entwickler, die einem dann ein bisschen helfen können,
Interviews: wenn man dann mal auf irgendwelche Fragen stößt oder. Ja, genau.
Interviews: Okay, wunderbar. Vielen Dank, Andreas. Dankeschön.
Moderation: Und habt ihr schon genug Tools gefunden, die ihr vielleicht noch ausprobieren
Moderation: müsst, wie zum Beispiel Captain oder Open Tracing?
Moderation: Ich habe mich ja wie gesagt mit Open Tracing noch nie beschäftigt,
Moderation: bin aber auch nicht so groß der Programmierer, aber wenn man das anderen Leuten
Moderation: zur Verfügung stellen muss, ist das glaube ich eine wichtige Sache auch Open Tracing anzubieten.
Moderation: Ich bin dann eher die Fraktion, die sich wahrscheinlich mal Jäger anschauen
Moderation: muss und das bei uns in die Chain mit einspielen sollte.
Moderation: Aber Captain, definitiv ein tolles Tool, was seinen Platz hat und hoffentlich
Moderation: immer mehr Fans finden wird.
Moderation: Mich hat Andreas auf jeden Fall überzeugt, das mir etwas näher anzusehen.
Moderation: Und davor haben wir Musik gehört, diesmal Piercy Murphy mit Athens.
Moderation: Und bevor ich euch jetzt nochmal mit einem Lied beglücke, machen wir glaube
Moderation: ich das letzte Interview aus der Reihe von der CubeCon.
Moderation: Und zwar werden wir uns ein bisschen in die kommerzielle Schiene nochmal begeben,
Moderation: aber keine Angst, wir kommen auch wieder zurück zu den Open Source Themen.
Moderation: Wir gucken uns an, was Suse zurzeit treibt.
Moderation: Suse hat ja Rancher vor einiger Zeit gekauft.
Moderation: Was Rancher ist und was es da Neues gibt, werden wir klären.
Moderation: Was Suse im Edge-Bereich machen will, versuchen wir zu klären und natürlich,
Moderation: was uns ganz doll umtreibt, für mich zumindest,
Moderation: als jemand, der Suse Linux oder OpenSuse tatsächlich an einigen Stellen immer
Moderation: noch einsetzt und hier auf meinem Desktop gerade auch OpenSuse Tumbleweed läuft.
Moderation: Natürlich, was Suse vorhat mit seiner Adaptable Linux Plattform und wie es dort
Moderation: weitergeht mit der ganzen Community.
Moderation: Dazu wird es im nächsten und letzten Interview dieser April-Sendung gehen.
Interviews: Ja, ich bin jetzt hier auf der CubeCon 2024 in Paris.
Interviews: Bei mir ist Joachim Werner, er ist Principal Product Manager Edge bei Suse.
Interviews: Hallo Joachim. Hallo, guten Morgen.
Interviews: Und ihr macht ja eines der großen Themen, die ihr habt, ist Rancher.
Interviews: Vielleicht fangen wir damit einfach mal an. Vielleicht kannst du mal sagen,
Interviews: was Rancher genau ist, wofür brauche ich das?
Interviews: Ja, ich glaube, die einfachste Erklärung ist, wir helfen den internen IT-Organisationen,
Interviews: die mit der Cloud konkurrieren, dass sie intern Platform as a Service,
Interviews: also die Services, die vorkonfiguriert sind für ihre Fachabteilungen, bereitstellen.
Interviews: Ja, es ist ja heute so, dass eine Fachabteilung häufig fragt,
Interviews: okay, warum muss ich da zu meiner IT gehen?
Interviews: Ich kann ja einfach die Kreditkarte nehmen und hole mir ein Software-as-a-Service,
Interviews: gibt es ja genug im Internet und dann steht ja Compliance dagegen, darf ich das überhaupt,
Interviews: sind das Ausgaben, die dann, wie man so sagt, Schatten-IT sind und mit Rancher
Interviews: und der gesamten Toolchain außenrum helfen wir diesen Fachabteilungen letztendlich
Interviews: in interner Anbieter von Platform-as-a-Service zu werden.
Interviews: Aber mit der Compliance, die die Unternehmensrichtlinien auch vorgeben.
Interviews: Und dadurch, dass Rancher so konstruiert ist,
Interviews: dass es eigentlich Kubernetes-Cluster, egal ob die jetzt auf Amazon gehostet
Interviews: sind, auf Google gehostet sind oder bei Microsoft Azure oder eben auf eigener
Interviews: Hardware managen kann, ist dann auch die Freiheit,
Interviews: okay, was gebe ich in die Public Cloud, was behalte ich lokal.
Interviews: Und was jetzt auch neu dazu kommt das haben wir auch eben zur CubeCon angekündigt wir liefern auch für.
Interviews: Den Edge-Bereich, also beispielsweise Einzelhandelsketten, Restaurants und so weiter, alle Tools,
Interviews: damit man auch kleine Kubernetes-Cluster in einen Laden oder in ein Restaurant
Interviews: zum Beispiel reinbringen kann, das sind oft ganz kleine Setups,
Interviews: zwei oder drei, Mini-PCs oder Serversysteme, manchmal jetzt auch schon ARM,
Interviews: also wir haben auch Support für die ARM-Hardware-Plattform jetzt durch das gesamte Portfolio.
Interviews: Und das ermöglicht eben dann sogar,
Interviews: dass die IT-Teams sagen können, okay, wenn das interne Entwicklungsteam zum
Interviews: Beispiel ein neues Feature für die Kundenbindung einbringen will,
Interviews: das hat ja vielleicht auf der einen Seite einen Aspekt, da wird die Web-App
Interviews: angepasst, dann wird was für die Mobile-App angepasst, das Backend muss gemacht
Interviews: werden und im Laden kommt vielleicht ein neuer Kartenleser dazu,
Interviews: der muss angebunden werden. Das geht dann alles in einer Plattform.
Interviews: Also das heißt wirklich, dass, keine Ahnung, ich treibe eine Ladenkette und
Interviews: dann hätte ich in jedem Laden so einen kleinen Kubernetes Cluster mit Rancher zu stehen.
Interviews: Rancher muss nicht im Laden sein, also Rancher managt viele Kubernetes Cluster,
Interviews: das ist eigentlich die Hauptaussage, deswegen ja auch ursprünglich der Name,
Interviews: also der Rancher, der die ganze Farm mit den ganzen Kettle, wie man so schön sagt,
Interviews: also den ähnlich aussehenden, es gibt ja diese Idee, es gibt Kettle und Pet,
Interviews: also früher hat man jeden Server einzeln wie ein Haustier gepflegt und ja,
Interviews: also der moderne Ansatz ist eben mehr wie in der,
Interviews: In der Landwirtschaft, jede Kuh hat vielleicht eine Nummer am Ohr,
Interviews: aber keinen Namen unbedingt.
Interviews: Und das kann Rancher sehr gut.
Interviews: Und da sind dann eben vielleicht an hunderten Standorten jeweils kleine Kubernetes
Interviews: Cluster und Rancher kann die alle eben konsistent managen.
Interviews: Okay, da gibt es halt ein Plattformteam oder sowas, den Rancher managt und in
Interviews: den Einzelhandelsläden oder was du auch gesagt hast, selbst im Restaurant oder
Interviews: wenn ich eine Fertigungshalle oder sowas habe,
Interviews: dann steht halt irgendwo in der
Interviews: Fertigungshalle so ein kleiner Cluster und arbeitet vor sich hin. Genau.
Interviews: Kann ich, wenn ich jetzt zu euch komme und sage, okay, ich will so ein Cluster
Interviews: haben, verkauft ihr die Hardware dann mit oder muss ich mir das selber überlegen?
Interviews: Wir sind wirklich fokussiert auf Infrastruktur-Software.
Interviews: Wir arbeiten aber natürlich mit allen gängigen Hardwareherstellern zusammen.
Interviews: Vom Data Center her sind das natürlich die großen Namen, brauche ich jetzt nicht
Interviews: einzeln nennen, weil wir auch keinen bevorzugen.
Interviews: Wir sind da wirklich agnostisch.
Interviews: Mehr und mehr jetzt dann eben auch im Edge-Bereich müssen wir mit neuen Partnern
Interviews: arbeiten, weil es da eben wie gesagt Hardware auf ARM-Basis gibt.
Interviews: Da kommen jetzt neue Anbieter dazu. Also das sind auch oft Formfaktoren wie
Interviews: diese, es gab ja von Intel diese NUCs.
Interviews: Das macht Intel zwar nicht mehr weiter, aber der Formfactor wird also von einer
Interviews: großen Vielzahl an Hardware-Herstellern übernommen und das ist jetzt letztendlich unser Partner.
Interviews: Aber wir bieten zusammen mit Partnern, wir haben auch Integrationspartner,
Interviews: die gerade im Einzelhandelsbereich, die die ganze Lösung dann zum Beispiel machen
Interviews: würden, die bieten dann die Hardware mit an.
Interviews: Jetzt habt ihr hier eine neue Version von Rancher oder Rancher Prime vorgestellt.
Interviews: Was ist denn da neu drin? Ja, es sind eigentlich zwei Bereiche.
Interviews: Der eine Bereich, der klingt erstmal gar nicht so spannend, aber da geht es
Interviews: eben in die Richtung Compliance, was ich vorhin schon angesprochen habe.
Interviews: Mit der Bezahlversion von Rancher Prime,
Interviews: die an sich genauso Open Source ist wie die Version, die man sich einfach runterladen
Interviews: kann, garantieren wir nach dem Salsa-Standard,
Interviews: den ursprünglich glaube ich Google in die Welt gesetzt hat,
Interviews: Supply Chain Konsistenz.
Interviews: Das heißt, man weiß für jedes Paket, für jedes Open-Source-Paket,
Interviews: für jede Zeile Code, die da drin ist, wo kommt die her, kümmert sich jemand
Interviews: darum, dass die Sicherheits-Updates auch wirklich regelmäßig nachgezogen werden, eingespielt werden.
Interviews: Da haben wir ja im Linux-Bereich bei SUSE wirklich 25 Jahre Erfahrung.
Interviews: Wir waren die Ersten, die das auch voll automatisiert haben und das haben wir
Interviews: jetzt auch in die Ranger-Welt gebracht.
Interviews: Das ist der Compliance-Bereich, das klingt jetzt erstmal unsexy, wenn man so will,
Interviews: aber ist sehr wichtig eben gerade im Einsatz in business-kritischen Bereichen
Interviews: und es gibt ja auch in all diesen Kundenkreisen,
Interviews: die wir bedienen, von Banking bis Einzelhandel, sehr viele Regularien inzwischen,
Interviews: sei es mit Datenschutz oder auch mit der IT-Sicherheit, die man eben sonst gar nicht einhalten kann.
Interviews: Der andere Bereich, den man wirklich rausgreifen kann.
Interviews: Wenn man jetzt an diese Plattform-Teams denkt, wir wollen es so einfach wie
Interviews: möglich machen, auch für einzelne Szenarien Blaupausen zu bieten,
Interviews: also Templates auf Englisch.
Interviews: Und da gibt es jetzt eben Cluster-Templates, wo ich einen kompletten Cluster
Interviews: mit dem Hardware-Setup, also es sollen zum Beispiel fünf Server-Nodes sein,
Interviews: mit dem Betriebssystem installiert bis hoch zur Applikation eben definieren
Interviews: kann und das dann wirklich wie eine Vorlage immer wieder verwenden kann.
Interviews: Also das sind diese Cluster Templates, das ist glaube ich das ganz große.
Interviews: Die meisten anderen Features sind eher, ja neue Versionen gibt es natürlich,
Interviews: aber das sind wirklich die zwei ganz großen Blöcke, die man rausgreifen muss.
Interviews: Und beides eben mit dem Hintergedanken, wie bringe ich mehr geschäftskritische Kunden dazu zu sagen,
Interviews: okay ich kann hier wirklich darauf vertrauen, dass mit dieser Open Source Software
Interviews: auch mein Betrieb sicher und zuverlässig abläuft.
Interviews: Was auch in die Richtung geht, wir haben ja schon immer in Rancher einen Anwendungskatalog,
Interviews: wo man auch andere zusätzliche Komponenten letztendlich als Helmcharts in Kubernetes
Interviews: rein installieren kann.
Interviews: Das wird jetzt professionalisiert und wie gesagt mit dem gleichen Denken,
Interviews: wie man es vielleicht von Linux kennt, dass eben auf einer Linux-Distribution
Interviews: viele Pakete sind, die auch regelmäßig upgedatet werden.
Interviews: Haben wir jetzt da zum Beispiel Datenbanken wie PostgreSQL wirklich in einer supporteten Form.
Interviews: Die werden in dem SUSE-Bildsystem gebaut, regelmäßig upgedatet,
Interviews: bereitgestellt. Und wenn man sich vorstellt, was häufig im Cloud-Native-Bereich
Interviews: passiert, dass man selbst in Produktion oft Container aus.
Interviews: Irgendwelchen letztendlich unklaren Quellen zieht, weil der Entwickler sich
Interviews: halt mal entschieden hat, ich nehme diesen Container.
Interviews: Da ist dann wirklich alles aus einer Hand. Also wenn man sagt,
Interviews: der Endanwender kann nur aus diesem Katalog Applikationen auswählen,
Interviews: dann weiß man, die sind von Suse vorher verifiziert.
Interviews: Wir öffnen das auch für Partner. Also es wird dann nicht nur ein reiner Suse
Interviews: Marketplace, wenn man so will, sein, sondern da kommen dann auch Partner Anwendungen
Interviews: mit rein, wo man dann natürlich wo ich unter Umständen beim Partner extra Lizenzen zahlen muss.
Interviews: Heißt das, das ist direkt in Rancher eingebaut oder ist das nochmal ein extra
Interviews: Tool, wo ich mir dann die Helmschatz runterladen muss?
Interviews: Na, der Applikationskatalog ist voll integriert in Rancher, ja.
Interviews: Gut, hier auf der Konferenz wäre jetzt AI ein großes Thema.
Interviews: Ich habe auch gesehen, auch zumindest in eurem Bereich stand das jetzt mit drauf.
Interviews: Was bedeutet das für die Kunden oder die Rancher oder die entsprechende Kubernetes-Distribution
Interviews: von euch einsetzen wollen?
Interviews: Ja, das ist sehr wichtig. Also AI ist, glaube ich, auch einer der größten Treiber
Interviews: für neue Hardware-Deployments.
Interviews: Auch im Edge-Bereich. Also es gibt immer mehr Anwendungen, wo zum Beispiel mit
Interviews: Kamerasystemen im Laden gearbeitet wird, bis hin zu Inventory-Management.
Interviews: Also dass man wirklich statt einer manuellen Inventur letztendlich eine Kamera
Interviews: aufs Regal schauen lässt und beobachtet, was wird rein und raus genommen.
Interviews: Und wenn man das alles, die ganzen Rohdaten immer in die Cloud schicken müsste,
Interviews: dann würden einfach ungeheure Datenmengen entstehen.
Interviews: Deswegen werden auch kleine GPU-Cluster durchaus ins Edge gebracht.
Interviews: Und ja, mit den neuesten Versionen jetzt auch von unseren Kubernetes-Distributionen,
Interviews: erlauben wir eben, dass diese GPUs, also diese Beschleuniger,
Interviews: für die AI-Workloads, für die AI-ML-Workloads auch an die Container durchgereicht werden können.
Interviews: Da gibt es sicher noch sehr viel zu tun, aber das ist einer der Bereiche,
Interviews: wo wir, glaube ich, in den nächsten ein, zwei Jahren eine Menge auch von Soße sehen werden.
Interviews: Gibt es sonst noch irgendwelche Neuigkeiten bei euren Kubernetes-Distributionen,
Interviews: also insbesondere RKE2 und ich glaube die etwas kleinere Sachen ist diese K3S? Ja, K3S oder K3S.
Interviews: Beide kommen in den neuesten Versionen und ich habe es ja schon angesprochen,
Interviews: ganz wichtig ist wirklich der ARM-Support.
Interviews: Also das ist auch nicht nur ein Thema.
Interviews: Man denkt bei ARM oft nur an Raspberry Pis, kleine Geräte.
Interviews: Genauso im Data Center. Also man hat es auch auf der KubeCon jetzt öfter gehört,
Interviews: einfach nur um Energie zu sparen, werden Workloads häufig auf ARM-Server-Systeme umgestellt.
Interviews: Da gibt es auch riesige Server inzwischen mit Dutzenden oder Hunderten von ARM-Cores
Interviews: und das ist eben sehr wichtig, dass da auch der Support jetzt durchgängig verfügbar ist.
Interviews: Was dann letztendlich eben auch heißt, dass die Applikationen,
Interviews: die darauf laufen, also auch Rancher selbst und so weiter, alle auf ARM letztendlich
Interviews: grundsätzlich auffähig sind.
Interviews: Natürlich muss ein Container jedes Mal für die entsprechende Plattform gebaut
Interviews: sein, das ist klar, aber das ist eben auch in unserem Fall mit dem Application
Interviews: Catalog dann automatisch sichergestellt, dass wir für beide Plattformen die Container bauen.
Interviews: Ja, bis zu 60% Energieeinsparung habe ich gehört auf ARM-Basis.
Interviews: Aber wenn ich jetzt klein erstmal anfangen will, könnte ich mir natürlich auch
Interviews: erstmal einen Raspberry Pi nehmen und damit mit Ranger erstmal rumspielen und
Interviews: gucken, ob das jetzt auf der ARM-Plattform alles tut.
Interviews: Absolut, ja. Also ich würde dann schon eher, sagen wir mal, mindestens 4 GB
Interviews: aufwärts, 8 GB einen Raspberry Pi 4 zum Beispiel nehmen, aber man kann den kompletten
Interviews: Stack inklusive der Ranger-Management-Konsole durchaus auf dem Raspberry Pi betreiben.
Interviews: Ihr habt ja auch Storage-Systeme wie Longhorn. Gibt es da jetzt irgendwas Neues,
Interviews: wo man sagt, okay, sollte ich mir vielleicht nochmal angucken oder wenn ich
Interviews: einen Rancher deploye, weiß ich nicht, deploye ich das gleich mit oder wie funktioniert das?
Interviews: Ja gut, da gibt es zum einen ein neues, das ist jetzt eher auf der kommerziellen
Interviews: Seite, ein neues Bundle.
Interviews: Also Ranger Enterprise ist dann eigentlich die Möglichkeit, das gesamte Produktportfolio
Interviews: ohne große Komplikationen einzukaufen.
Interviews: Man kann auch à la carte wählen, wenn man sagt, ich brauche jetzt eben den Storage-Bereich
Interviews: nicht oder unser New Vector, unser Sicherheitsprodukt.
Interviews: Aber bei Ranger Enterprise ist das alles im Bundle.
Interviews: Longhorn ist wirklich eine ganz tolle Möglichkeit, den Block-Storage für die
Interviews: Container bereitzustellen.
Interviews: Ist auch integriert in unserer VM-Management-Solution Harvester.
Interviews: Das ist wirklich eine schöne Möglichkeit,
Interviews: auf Kubernetes-Basis eine Virtualisierungsumgebung aufzubauen.
Interviews: Da gibt es im Detail Verbesserungen, gerade im Bereich Replikation, Updates, ja.
Interviews: Aber im Großen und Ganzen, ich glaube, die wichtige Message ist,
Interviews: die Produkte vom Betriebssystem aufwärts, also dem SUSE Linux Enterprise Micro,
Interviews: das ist unsere Distribution speziell für diese Container-Workloads,
Interviews: bis hin zur Venture-Management-Konsole werden immer besser integriert.
Interviews: Die meisten der Sachen sind natürlich, oder weil wir jetzt gerade viel über
Interviews: Enterprise oder so geredet haben, Aber es sind aber alles Open Source Produkte.
Interviews: Also ich kann mir auch Longhorn so angucken und einsetzen, wenn ich sage,
Interviews: okay, ich brauche irgendwie eine Art Block Storage, was ich darüber baue,
Interviews: ist sozusagen egal. Genau.
Interviews: Und wir freuen uns natürlich auch immer, wenn die Communities wachsen.
Interviews: Wir arbeiten da im Open-Source-Bereich ja mit Kunden, mit Endbenutzern,
Interviews: mit Leuten von der Uni und anderen Firmen sehr eng zusammen.
Interviews: Und das ist wirklich schön anzuschauen, wie oft auch Konkurrenten im Markt oder
Interviews: Marktbegleiter, wie man so schön immer sagt, euphemistisch, dann in den Open-Source-Projekten
Interviews: wunderschön zusammenarbeiten.
Interviews: Und die sind ganz normal auf GitHub oder irgendwo zu finden und dass ich dann
Interviews: Issues machen kann und einfach mit einsteigen kann.
Interviews: Ja, wir haben wirklich auch die Dokumentation und die Hilfsskripte,
Interviews: auch viele von den QR-Tools, alles auf GitHub.
Interviews: Also das ist wirklich auch die Policy, dass wir so offen wie möglich sein wollen.
Interviews: Und da sind wir auch wirklich, also wir sind glaube ich die einzige große Open
Interviews: Source Firma und vor allem Linux Distribution, die die gesamten Tools auch,
Interviews: wie bauen wir unsere Distribution, also unser Build Service,
Interviews: alles auch als Open Source bereitstellen.
Interviews: Also man kann sich theoretisch auch selber eine komplette Infrastruktur aufbauen.
Interviews: Wir haben auch einige Kunden, die das tatsächlich machen. Die sagen,
Interviews: wir müssen für ganz bestimmte Sicherheitsanwendungen oder so unser eigenes Linux,
Interviews: wenn man so will, bauen und nutzen dann die Tools und passen sehr viel an. Also da...
Interviews: Also ich kann zum einen diesen Open-Build-Service, gibt es im Internet,
Interviews: kann ich selber benutzen, um dann RPM-Pakete oder Container oder sowas zu bauen.
Interviews: Also den gibt es als Software, als Service, wenn man so will,
Interviews: aber man kann den auch, das sind auch letztendlich Container,
Interviews: kann man auch alles selbst installieren und sich einen eigenen Build-Service aufbauen.
Interviews: Und der kann dann auch mit dem SUSE Build Service sogar kommunizieren und eben
Interviews: die neuesten Builds, die wir bauen, wieder als Grundlage für eigene Pakete oder
Interviews: auch einfach nur eigene Installationsmedien oder Container-Images eben benutzen.
Interviews: Ja, ich sehe es immer, wenn man mal auf OpenSUSE noch ein Paket installieren
Interviews: will und es nicht in der normalen Distribution ist, dass dann tatsächlich Leute
Interviews: den OpenBuild-Service verwenden, um dann ihre eigenen Pakete zu bauen und die auch bereitzustellen.
Interviews: Das ist, denke ich, ein ganz schöner Service.
Interviews: Muss wahrscheinlich auch ein bisschen Power dahinterstehen.
Interviews: Ja, in der Build-Service? Der Build-Service ist natürlich, ja,
Interviews: ein großer Cluster, ein sehr großer Cluster von Computern, auch mit verschiedenen Architekturen.
Interviews: Also da haben wir auch sehr große ARM-Server zum Beispiel. Wir haben für die
Interviews: Mainframes auch... Mainframe? ja.
Interviews: Plattform haben wir ja auch rumstehen.
Interviews: Ja, derzeit ist das noch nicht auf Kubernetes, aber es ist schon Containerized
Interviews: und es ist klar, wie man so schön sagt, IDO und Dogfood, da geht es natürlich hin.
Interviews: Aber der Build-Service geht schon so weit zurück, da gab es noch keine Container,
Interviews: gab es noch kein Kubernetes. Stimmt, den gibt es schon lange.
Interviews: Ja, aber natürlich wird es immer mehr integriert. Jetzt haben wir schon ganz
Interviews: oft Suse Linux gesagt, also genau, ihr habt auch ein Betriebssystem und auch
Interviews: da hat sich letztes Jahr ziemlich viel verändert oder ihr habt zumindest viel angekündigt.
Interviews: Also ich nenne mal immer diese Adaptable Linux Plattform, da hat sich einiges geändert.
Interviews: Was genau und wie wird sich das dieses Jahr auswirken? Ja, das wird jetzt sehr konkret.
Interviews: Im Mai kommt die erste Version, die auf dieser neuen Plattform beruht und das
Interviews: ist wirklich Linux neu gedacht, muss man fast schon sagen.
Interviews: Also wir bauen natürlich immer noch mit unserem Build-Service eine Linux-Distribution.
Interviews: Wir bauen auch weiterhin erstmal Pakete, also RPM-Pakete, aber die Idee ist
Interviews: wirklich, dass das Betriebssystem immer mehr selbst organisiert wird,
Interviews: Updates auch in den Hintergrund rutschen, dass ich nicht als Anwender mir überlegen muss,
Interviews: da muss ich jetzt wieder das Paket updaten und das, sondern das Betriebssystem
Interviews: kommt letztlich als ein Bündel auch sehr vorgegeben.
Interviews: Also wir wollen da auch gar nicht mehr, dass man überall reingreifen muss.
Interviews: Das haben wir angefangen mit dem SLE Micro, Succeeding Enterprise Micro,
Interviews: das auch die Grundlage für den kompletten Rancher-Stack ist. Also wenn man K3S...
Interviews: Auf SUSE Linux betreiben will und dann mit Ranger managen kann.
Interviews: Die neue Version, die im Mai kommt, SUSE Linux Micro 6 oder 6.0,
Interviews: die ist eben die erste, die auf dieser Alp-Plattform aufbaut.
Interviews: Und da ist wirklich die Idee, dass wir jetzt endgültig die Anwendungsschicht
Interviews: und das Betriebssystem auch von den Lebenszyklen her entkoppeln können.
Interviews: Weil man kann eben sagen, das Betriebssystem ist sehr, sehr klein.
Interviews: Das sind nur noch die allernötigsten Komponenten.
Interviews: Und da optimieren wir die Lebenszyklen eben an der Hardware.
Interviews: Wie oft muss ich einen Linux-Kernel eben updaten, damit auch der Hardware-Support
Interviews: für neue Hardware gewährleistet wird. Aber man kann dann Anwendungen eben im
Interviews: Container auch auf anderen Lebenszyklen aufsetzen.
Interviews: Also wenn ich eine Anwendung habe, die eben sehr konservativ ist und wirklich
Interviews: über fünf oder zehn Jahre, wir können da sehr lange Support-Zyklen anbieten,
Interviews: immer auf der gleichen Version bleiben muss, dann ist das sehr einfach dadurch.
Interviews: Das ist eigentlich einer der wichtigsten Aspekte.
Interviews: Und ansonsten geht es wirklich eben darum, dass auch die Installation,
Interviews: also da gibt es keine Installationsmedien mehr im klassischen Sinne,
Interviews: wo ich dann Paket nach Paket installiere, sondern es gibt halt zwei Ansätze,
Interviews: entweder vorgebaute Images, also wenn ich zum Beispiel eine Virtual Machine betreibe,
Interviews: dann möchte ich ja eigentlich das Image einfach nur starten können.
Interviews: Oder eben auch Installations-Images, wo das gesamte Betriebssystem schon vorkonfiguriert
Interviews: draufkommt und dann gibt es eben Tools wie Ignition, Combustion,
Interviews: also in der gleichen Denke,
Interviews: wie es in der Public Cloud mit Cloud-Init ja sehr verbreitet ist,
Interviews: wo man dann Benutzer anlegen kann, Netzwerkkonfiguration machen kann, sehr einfach.
Interviews: Und da haben wir jetzt auch, was wir auf der KubeCon announced haben,
Interviews: Wir haben eben für den Edge-Bereich speziell noch ein zusätzliches Tool jetzt,
Interviews: den Edge-Image-Builder.
Interviews: Der macht es sehr einfach, dass man sagt, okay, ich muss für einen Standort,
Interviews: der vielleicht nicht am Internet angebunden ist oder nicht sein darf,
Interviews: zum Beispiel von einem USB-Stick aus einen kompletten Server aufsetzen.
Interviews: Da kann man dann alles vorkonfigurieren, inklusive zum Beispiel dem K3S oder
Interviews: dem AKE2, also einem Kubernetes-Stack. und letztendlich steckt man den USB-Stick
Interviews: rein und das System wird durchinstalliert.
Interviews: Und das ist eben auch deklarativ, also gibt es eine ganz einfache Syntax,
Interviews: wo man so ein Template anlegen kann, User-Netzwerk-Konfiguration,
Interviews: auch sehr komplizierte Netzwerk-Setups,
Interviews: wo im Hintergrund ein Network-Manager letztendlich konfiguriert wird.
Interviews: Und das ist jetzt ein extra Tool?
Interviews: Das ist ein Tool, das eben auch wieder Open Source, aber als Teil unserer Edge-spezifischen
Interviews: Bundles, eben dem Edge 3.0, angeboten wird.
Interviews: Ein anderer Bereich, wo man da im Edge-Bereich.
Interviews: Viel investiert haben, ist die Installation
Interviews: über, ja, wenn Systeme einen Management-Board-Controller haben,
Interviews: also IPMI oder Redfish-Protokoll und man kann sagen, okay, boot ich jetzt Installationsmedium,
Interviews: da gibt es den KPI-Standard, Cluster-API-Standard in Kubernetes,
Interviews: der sowohl mit den Cluster-APIs reden kann, zum Beispiel von einem Amazon oder
Interviews: Azure und sagen kann, gebe mir jetzt in Microsoft Azure oder Google oder Amazon eben,
Interviews: 15 Nodes mit den und den Parametern, aber eben auch mit Hardware sprechen kann,
Interviews: über die Management-Port-Kontrolle.
Interviews: Und dann kann ich meine Hardware, die irgendwo steht, damit auch managen und
Interviews: sozusagen mit Software bespielen.
Interviews: Genau. Oder neu booten, ein Image booten, damit Cloud-Init irgendwelche Sachen
Interviews: treiben und dann dann bootet man mein System da und den Cluster kann man verwenden.
Interviews: Jetzt, genau, hattest du ja gesagt, ihr habt diese Micro-Plattform, die kommt dieses Jahr.
Interviews: Trotzdem, wenn ich so ein Slash früher eingesetzt habe mit irgendwie,
Interviews: keine Ahnung, 15 Jahren Support oder so, das ist ja ein bisschen größer als
Interviews: das, was mit Micro klingt ja schon so, als wäre es irgendwas Kleines.
Interviews: Wie geht es da weiter? Ja, keine Angst. Also wir werden auch in absehbarer Zeit
Interviews: dann wieder einen Nachfolger vom derzeitigen SUSE Linux Enterprise Server 15 rausbringen.
Interviews: Der wird auf der gleichen Plattform aufbauen, aber der ist wirklich für die
Interviews: Kunden gedacht, die weiterhin das voll konfigurierbare Linux brauchen.
Interviews: Das ist auch eine Sache, die wir auf Micro durchziehen, eben aus Sicherheitsgründen.
Interviews: Da ist das Root-Filesystem nur lesend, also read-only gemountet.
Interviews: Da kann man die Updates im Hintergrund dann auf einer Snapshot-Partition machen
Interviews: und neu starten und auch wieder zurückrollen.
Interviews: Das hat natürlich im Betrieb sehr große Vorteile, weil wenn irgendwas im Update
Interviews: schief geht, man immer ein Rollback hat.
Interviews: Aber es ist natürlich auch einschränkend. Also wenn ich derzeit irgendwelche
Interviews: Bash-Skripte laufen lassen muss, wenn ich eine Applikation neu installiert habe
Interviews: oder irgendwelche Anpassungen.
Interviews: Eben mit Skripten mache und die Prozesse laufen noch, da würde dann das SLE-Micro
Interviews: manchmal eher im Weg stehen und deswegen werden wir auch weiterhin den vollen Stack mit,
Interviews: wahrscheinlich wird es dann irgendwie 16 heißen, nehme ich mal an, ja.
Interviews: Ja, so die Linux Enterprise Server 15 ist die derzeitige Release.
Interviews: Die ist auch noch für viele Jahre supported.
Interviews: Also die Leute, die wirklich sagen, ich möchte eigentlich gar nichts ändern,
Interviews: das funktioniert alles so toll.
Interviews: Die können auch noch für viele Jahre noch mit Service Packs für den Slash 15
Interviews: rechnen. Aber es wird einen 16 geben.
Interviews: Es wird auch wieder für den Schwerpunkt SAP-Systeme eine eigene Version davon geben.
Interviews: Genau, also da wollen wir schon das volle Portfolio auch an Kundenbedürfnissen abdecken.
Interviews: Wir glauben, dass die Zukunft in vielen Fällen wirklich bei dem Mikroansatz
Interviews: ist, bei dem Betriebssystem, das eigentlich nur noch mehr oder weniger unsichtbar wird.
Interviews: Und immutable irgendwie. Immutable, also nicht veränderbar oder zumindest im
Interviews: Betrieb nicht veränderbar.
Interviews: Natürlich muss es updatable sein, aber wir wollen das natürlich auch jetzt nicht
Interviews: mit der Brechstange irgendwie dem Kunden aufdrücken.
Interviews: Also das war vielleicht auch letztes Jahr in der Kommunikation manchmal nicht
Interviews: so deutlich geworden, dass es uns jetzt nicht darum geht,
Interviews: Dinge schwieriger zu machen, sondern wir sehen einfach ungeheure Einsparungen
Interviews: im Betrieb und glauben, dass es auf Dauer der richtige Weg ist.
Interviews: Aber die Prozesse bei vielen Kunden ändern sich langsam.
Interviews: Es gibt auch eben immer wieder Spezialfälle, wo ich halt sehr,
Interviews: sehr starke Anpassungen brauche, wo ich vielleicht sehr komplexe Hardware-Szenarien
Interviews: habe mit Disk-Arrays und Ähnliches,
Interviews: die halt wirklich vielleicht nicht so einfach aufzusetzen sind Und wo dann der
Interviews: flexible Ansatz von einer vollen Linux-Distribution Sinn macht.
Interviews: Es wird ja auch weiterhin im Open-Source-Bereich bei OpenSUSE das komplette Portfolio geben.
Interviews: Und wo wir noch sehen müssen, wo es hingeht, ist natürlich der Bereich Desktop.
Interviews: Also da wollen wir auch diese Ideen von einem Immutable-System reinbringen.
Interviews: Da gibt es in der Open-Source-Community bei OpenSUSE ja auch schon den Aeon-Desktop,
Interviews: der das so mal ein bisschen zeigt, wie das gehen kann. Also ein Container-basierter Desktop.
Interviews: Aber da müssen wir noch sehen, wie man eben zum Beispiel im Bereich Point-of-Service-Systeme,
Interviews: also Kassensysteme oder Kiosk und ähnliche Geldautomaten, solche Themen,
Interviews: wie man da eben auch diese Technologien reinbringen kann und trotzdem noch einen
Interviews: Bildschirm anschließt.
Interviews: Weil für die meisten Cloud-Themen ist ja der Bildschirm jetzt eher sekundär.
Interviews: So ein Computer ist einfach nur Headless, wie man so schön sagt,
Interviews: Webfrontend vielleicht. Ja, wird zum Rechnen verwendet.
Interviews: Aber Desktop ist natürlich trotzdem ein Thema. Also wenn du jetzt sagst,
Interviews: diese Aeon, kann ich da dann trotzdem ein KDE oder irgendwas starten oder ist
Interviews: das dann irgendwas Spezielleres?
Interviews: Ja, das ist eigentlich sehr flexibel. Da kann man sowohl komplette virtuelle
Interviews: Distributionen letztendlich betreiben, also auch sagen,
Interviews: ich möchte jetzt KDE auf der Version, GNOME auf der Version und alles letztendlich
Interviews: wie eine Virtual Machine, muss man sich das vorstellen,
Interviews: als auch einzelne Anwendungen.
Interviews: Ja, also da ist dann Flatpak zum Beispiel eben.
Interviews: Also das ist sehr flexibel. Da muss man dann nur sehen, was möchte man zum Beispiel
Interviews: mit Unternehmen supporten. Also bei der Open-Source-Seite, da geht es natürlich
Interviews: darum, so offen wie möglich zu sein.
Interviews: Man möchte die ganze Freiheit der Open-Source wirklich den Leuten bieten.
Interviews: Das ist dann vielleicht im Firmenumfeld eher ein bisschen eingeschränkter.
Interviews: Gut, aber da wisst ihr noch nicht, wo die Reise hingeht. Ja,
Interviews: wir sind jetzt auf dem Weg.
Interviews: Wie gesagt, wir haben in dem Bereich noch den SLES 15 für viele Jahre,
Interviews: auch in der Maintenance für die Kunden, die einen klassischen Linux Desktop haben wollen.
Interviews: Aber ich denke, die Richtung geht auch dahin, dass das Basisbetriebssystem eben
Interviews: sich eher an dem Micro-Ansatz orientiert.
Interviews: Und dann, ja je nachdem, ich meine man muss sehen, wo es da hingeht.
Interviews: Man sieht ja auch im klassischen Linux-Desktop-Umfeld ist eine Menge in Richtung,
Interviews: Android abgewandert, also ganz viele Geräte. Chromebooks und sowas.
Interviews: Ja, nicht nur Chromebooks, sondern tatsächlich auch echtes Android,
Interviews: also wenn man es im Einzelhandel sich das anschaut.
Interviews: Und ja, das ist natürlich was, wo die Linux-Community als Ganzes auch ein bisschen
Interviews: eine Antwort finden muss. Also das wird auch nicht nur mit Zuse allein möglich
Interviews: sein, weil das natürlich auf der einen Seite Linux-basiert ist, aber auch wieder.
Interviews: Ein eigenes, mehr oder weniger geschlossenes Ökosystem ist.
Interviews: Jetzt hast du OpenSUSE ja schon erwähnt, also das bedeutet auch,
Interviews: es wird auch Änderungen bei OpenSUSE geben müssen mit dieser neuen Plattform,
Interviews: mit dieser Altplattform, die ihr da habt.
Interviews: Oder habe ich das falsch verstanden? Ja, grundsätzlich, ja, das hast du richtig verstanden.
Interviews: Wobei da natürlich die Entscheidungen auch wirklich von der OpenSUSE Community
Interviews: getroffen werden. Die arbeiten schon sehr eng mit uns zusammen.
Interviews: Aber wie genau jetzt da dann das Portfolio aussehen wird, also wir haben ja
Interviews: derzeit OpenSUSE Leap, wir haben OpenSUSE Tumbleweed,
Interviews: wir haben dann diese verschiedenen auch Spins, wenn man so will,
Interviews: von Micro im OpenSUSE Bereich,
Interviews: eben inklusive dieses Eon-Desktops.
Interviews: Ja, da wollen wir auch von Suses Seite keine Vorgaben machen oder so,
Interviews: dass die Community hat ihre eigenen Entscheidungsgremien,
Interviews: da gibt es ja auch die entsprechenden Boards und da werden diese Entscheidungen getroffen.
Interviews: Aber von der Technologie her, wie gesagt, wir haben die volle Distribution als
Interviews: Basis, von der kann man ausgehen.
Interviews: Das heißt, wenn eine Community sich entscheidet, wir wollen weiterhin einen
Interviews: eher traditionellen, voll flexiblen Desktop anbieten, dann wird das durchaus auch passieren.
Interviews: Okay, also ihr stellt da jetzt nicht irgendwelche Pakete ein und sagt,
Interviews: was weiß ich, KDE wird es nicht mehr geben, LibreOffice wird es nicht mehr geben,
Interviews: ihr müsst euch jetzt irgendwie alles neu erfinden, ihr müsst das jetzt alles
Interviews: mit Containern oder Flatpak machen.
Interviews: Dahin geht es jetzt nicht? Nein, also wir werden natürlich an manchen Stellen
Interviews: unsere eigenen Investitionen steuern, das ist klar, aber wir drehen nirgends
Interviews: irgendwie einfach den Hahn ab oder so.
Interviews: Das wird nicht passieren. Okay, super.
Interviews: Ja, vielen Dank, Joachim, dass du uns mal erklärt hast, was ihr mit Drencher
Interviews: macht, wo da die Reise hingeht und auch genau, wie das mit dieser Adaptable
Interviews: Linux Plattform geht, wie du schon gesagt hast.
Interviews: Also das ist glaube ich ein großes Thema, das hat ein bisschen die Leute verunsichert
Interviews: und ja, dann gucken wir mal,
Interviews: was das Jahr so bringt und auch wo sich dann OpenSUSE entwickeln wird,
Interviews: wie da die Entscheidungen aussehen und ja, dass immerhin noch viele Leute da
Interviews: die SUSE Plattformen finden.
Interviews: Form verwenden und eben die netten Services, die ihr da drauf so entwickelt.
Interviews: Vielen Dank, Joachim. Ja, vielen Dank.
Moderation: Ja, das war Roy Smiles mit Twisted City, ein Singer-Songwriter aus Großbritannien.
Moderation: Und wir sind damit schon wieder am Ende dieser kleinen, feinen Sendung,
Moderation: dieser April-Ausgabe von Radio Tux.
Moderation: Und genau, ich habe euch einige Interviews von der CubeCon mitgebracht.
Moderation: Ich glaube, das war ein CubeCon, habt ihr jetzt ganz, ganz oft gehört.
Moderation: Ich würde mich freuen, wenn ihr zu uns in den Blog kommt und ein paar Kommentare
Moderation: schreibt oder ich habe die ganzen Interviews auch einzeln nochmal gerade auf YouTube gepackt.
Moderation: Also auch da, wenn ihr Lust habt, könnt ihr natürlich kommentieren.
Moderation: Noch lieber ist es mir aber natürlich, wenn ihr das auf unserem eigenen Blog macht.
Moderation: Und natürlich, wenn ihr die ganzen Projekte, die wir hier heute vorgestellt
Moderation: haben, mal ausprobiert und auch dort entsprechend in die Communities geht.
Moderation: Vielleicht habt ihr das eine oder andere Interessante ja heute hier gehört,
Moderation: was ihr noch nicht kanntet, was ihr ausprobieren wollt. Dann viel Spaß damit.
Moderation: Und ja, mir bleibt nur noch zu sagen, wie immer wünsche ich euch eine frohe
Moderation: Zeit. Passt auf euch auf.
Moderation: Habt Spaß. Am Gerät natürlich.
Moderation: Und genießt die Sonne da draußen. Und wir hören uns hoffentlich im Mai,
Moderation: spätestens im Juni, wieder hier hier bei der nächsten Rade-Tux-Ausgabe.
Moderation: Bis dahin. Ciao, ciao.