Also ich nehme bei noch, entwickle.

Das spannend, das gehört natürlich dann auch zu deiner Rolle Mehrwert auf anderen Ebenen zu bringen. Wie schwer war das denn für dich? Ich nehme dich jetzt wahr als ein wirklicher Techie, der da auch die ersten Grundpfeiler gelegt hat von dem Produkt. Wie schwer war das für dich, dich zu entfernen aus der Tastatur, in einer anderen Ebene, das den Experten dann oder anderen Mitarbeitern zu überlassen?

Das Gute war, glaube ich, dass es ein fließender Übergang war. war nie so quasi, okay, bis heute war ich Vollzeit am Coden und morgen mache ich andere Sachen, sondern es kamen andere Sachen auf. Wir haben erste Mitarbeiter gehired, die haben mehr Sachen übernommen. Also von daher war es immer ein sehr fließender Übergang. Und es war nie wirklich so, dass es irgendwie gefühlt war, ich kann jetzt nicht mehr Coden oder so, sondern es war immer so bisschen, okay, ich mache weniger.

Aber ich bin immer noch nah an der Technik dran und das würde ich heute auch noch behaupten. Also wenn es darum geht, in welche Richtung wollen wir mit einem Produkt oder auch, wenn wir irgendwelche größeren Sachen bauen, wie bauen wir die Architektur, bin ich schon immer noch sehr nah dran. Nur das eigentliche Coding, da sind dann die Kollegen viel tiefer und viel besser unterwegs, weil ich glaube, das können die einfach besser als ich.

Du bist ja in deiner Rolle als CEO für den strategischen Teil des Produkts auch zuständig. Ich glaube, du hast nur einen Co-Founder, der ihr einen anderen Teil übernimmt und dementsprechend ist es natürlich ganz wichtig, auch an der Technologie nach wie vor eng dran zu sein.

Genau, also Julian kümmert sich bei uns das ganze Thema Sales und ich bin nah am Produkt und auch Marketing, weil wir natürlich ein sehr technisch zu technisches Produkt haben, was gut beschrieben werden muss und unterstütze da natürlich auch viel, zu gucken, okay, wie kriegen wir das, was wir jetzt eigentlich da im Produkt gebaut haben, wirklich auch das Messaging und zu den Leuten erklärt, dass es vielleicht auch nicht so technisch affine Leute verstehen oder

die noch nicht bis im Detail im Cloud Native Thema drin sind, verstehen, was machen wir eigentlich, wie machen wir das und warum hat das gewisse Vorteile, wie wir das machen.

Ja, jetzt sind wir schon tief eingestiegen. Vielleicht machen wir noch mal zwei, drei Schritte zurück. Wie bist du denn eigentlich zur Technologie gekommen? Was ist so dein Werdegang? Wo sind deine Roots? Wie hast du angefangen?

Genau, ich fand immer schon Technik interessant. jetzt noch nicht mal unbedingt auch rein auf IT bezogen, sondern generell Technik. dann relativ früh einen ersten Computer gekriegt. Zwar gebrauchten, aber ich glaube, mein erster Computer war 286, 386, also ganz early. Irgendwie mein erstes Betriebssystem, Windows 3.11, dann kam Windows 95 und durch ...

alle Schmerzen und alles was so gab mitgegangen und fand das immer extrem interessant. Bin dadurch auch im Früh zum Entwicklung gekommen. Hab angefangen selbst zu entwickeln. Damals gab es ja leider noch nicht das schöne Internet, sondern man musste sich durch Bücher bühlen, hatte dann Demo-CDs damit bei oder Beispiel im Buch, die meistens nicht funktionierten.

wo man sich dann noch mehr selber beibringen musste, weil man erstmal die Demos im Buch fixen musste und debuggen musste und frustriert dran saß und dann gedacht hat, warum funktioniert dieses Beispiel jetzt nicht? Das kann nicht so schwer sein. Aber wenn man es dann eben rausgekriegt hat, dann doch wieder ein Erfolg hatte. Genau, und als es darum ging zu studieren, habe ich gesagt, okay, ich will jetzt, ich finde Informatik interessant und ich möchte was in die Richtung studieren und ja.

habe dann angefangen Informatik zu studieren.

Spannend. Technische Informatik, Richtig Informatik, Wirtschaftsinformatik, in welcher Ausbringung?

Allgemeine Informatik,

genau, habe dann aber hinterher viel, weil bei uns in Dortmund gab es dann auch Wirtschaftsinformatik parallel dazu, viel in den Bereich Wirtschaftsinformatik, viele Kurse mitgenommen, weil mich hat immer schon das Thema Informatik in Kombination mit Wirtschaftsinteressiert und ja, habe dann eben viele Themen auch von denen mitgenommen. Damals gab es da Kurse in Bezug auf SAP.

Ich dann, weil ich im Ferienjob bei einem Unternehmen immer gearbeitet habe und dort war eine Abteilung, die sich rein SAP gekümmert hat und ich fand das immer ganz interessant, was die da machen, habe ich dann im Studium auch so ein Fach gewählt, Einführung in SAP und

Ich fand das Thema ganz interessant, weil da hat so eben so bisschen das, was du in der IT machst mit dem Thema, was so in der wirklichen Welt passiert, also wie du irgendwie Prozesse oder andere Sachen verknüpft. Und das fand ich mal sehr interessant und zu sagen, hey, ich mache hier was, wo ich auch wirklich vielleicht nicht sehen, aber theoretisch sehen kann, wie das irgendeinen Einfluss hat und wie das funktioniert.

Das heißt, das hat dich dann auch zur SAP wirklich dann gebracht als nächsten Schritt. glaube im Vorgespräch hattest du so was erwähnt.

Genau, als ich dann fertig war mit dem Studium, habe ich mir überlegt, okay, wo fängst du jetzt an? ich wollte dieses Thema SAP weiterverfolgen und habe mir dann gedacht, wenn, dann am besten beim Hersteller selber und bin so bei der SAP gelandet und am Anfang in der Beratung, was ganz interessant war, weil man da natürlich relativ viele verschiedene Kunden getroffen hat, gesehen hat, verschiedene Beispiele und hat so auch ganz gutes Verständnis, okay.

Gerade so im Enterprise-Bereich, warum ticken die alle unterschiedlich? Warum geht es bei meinem vielleicht einfacher oder schneller, beim anderen langsamer? Und dadurch, dass man da regelmäßig neue Sachen gemacht hat, ist man nie so wirklich in diese eine Schiene gekommen und gesagt, okay, ich bin jetzt irgendwie drei oder vier oder fünf Jahre, mache ich nur ein Thema, relativ viel neue Aufgaben, neue Sachen. Und das fand ich am Anfang insbesondere recht interessant, da viel zu lernen, viel zu erfahren, dass man

im Studium überhaupt nicht so mitgekriegt hat.

Ja, genau.

Ja, ich war dann im Consulting auch immer noch relativ technisch unterwegs, also hab da viel dann auch noch entwickelt, also hab nicht nur Prozesse irgendwie gemacht, sondern wirklich auch damals ABAP entwickelt. Hab dann nach einer gewissen Zeit gesagt, okay, ich will jetzt doch mal wieder wirklich technischer werden. Zu der Zeit das neue Hypethema innerhalb der SAP, die HANA Datenbank und hab dann innerhalb der SAP in den Bereich entwickelt, wo

gewechselt, wo die HANA Datenbank entwickelt wurde, weil ich gesagt habe, ich will einfach mehr, ich will mal raus aus der Beratung. Ich will mal wirklich wissen, wie man Produkt entwickelt, gerade auch wie man größere Produkte entwickelt und bin dann erstmal in die HANA Datenbank gegangen, war da im Produktmanagement unterwegs, da viel geholfen, insbesondere was jetzt bei der SAP so schön heißt, S4HANA, also die Welten der Datenbank mit dem ERPCRM zu verschmelzen, weil

Da kannte ich mich und ein Kollege sehr gut aus. Wir wussten natürlich, wie so CRM- und ERP-Systeme funktionierten und dass beide mit, wie man das Ganze hilft, zusammenzubringen. Genau, war so bisschen, dass ich mehr technischer wurde. Da kam ich dann auch wieder mehr in Kontakt mit Linux zum Beispiel, weil HANA lief natürlich nur auf Linux. Weil vorher ...

Ja, hat man eine Entwicklung umgeben, hat man Abap entwickelt, aber hat man dem unteren Stack eigentlich wenig zu tun gehabt. Ich wusste zwar ungefähr, wie das aussieht, aber selber im Daily Business, da ich nicht in der Basis von SAP irgendwie unterwegs war, habe ich das nie getouched und dann hinterher eine Handentwicklung schon regelmäßig, dass man da viel viel näher doch wieder am unterliegenden Betriebssystem und ja, da...

geguckt habe, was für Optimierungsmöglichkeiten gibt es, wie suche ich da Probleme und so weiter und habe da wieder viel mehr technisch, also wirklich tief technisch gemacht, neben dem, was ich private noch immer so bisschen nebenbei gemacht habe.

Ja, krass. Also SAP schafft das ja wirklich sehr gut, das alles wegzuabstaurieren. Also du kannst deine ganze Karriere mit SAP zu tun haben und siehst nie einen Server oder irgendwie eine Command Line. Jetzt hast du nach dem Studium einen Job bei SAP gehabt. Du arbeitest bei dem Zukunftsprodukt HANA. Also du bist da mittendrin in der Produktentwicklung, du kannst das mitgestalten. Und jetzt bist du selbstständig.

Wie war das denn? Wie ist das denn passiert? was war denn dein entscheidender Gedanke, dich selbstständig zu machen und das nicht weiter voranzutreiben und jetzt weiterhin bei SAP der Lead Engineer oder Lead Architekt von HANA zu sein?

Ja, zu der Zeit kamen dann eben so Themen auf, gerade so im Open Source-Umfeld wie Node.js, Docker, Container und so. Und ich fand dieses Thema, was selber zu gründen oder selber zu machen, immer schon interessant. Aber nach dem Studium auf der einen Seite, glaube ich, fehlt mir so bisschen der Mut, aber auch die Idee, was macht man da? Und ich deswegen erstmal quasi in einen Konzern gegangen und habe gesagt, okay, ich mache das erstmal für eine gewisse Zeit lang. Hab mir dann aber eben

nach sieben Jahren Konzern eben gedacht, okay, wenn ich jetzt dann nie und ich denke mal das Risiko war zu der Zeit auch überschaubar, so dass ich gesagt habe, wenn das hier komplett mit der eigenen Selbstständigkeit irgendwie schief geht, ich bin in der IT, ich finde definitiv wieder einen guten Job und habe dann gesagt, okay, da draußen gibt es viele interessante Themen, ich will da mal was mitmachen, ich will mal mit anderen Themen was machen.

Und falls das gar nichts was wird, kann ich immer noch wieder zurück in eine Konzernkarriere oder so gehen. Aber jetzt erstmal vielleicht mal was eigenes ausprobieren und gucken, okay, schaff ich's oder vielleicht auch nicht.

Ja, und dass es der richtige Schritt war, sieht man ja jetzt. Ihr seid erfolgreich mit Kubermatic. Kubermatic selbst hat viel mit Kubernetes zu tun. Also ihr habt ein Produkt, was hilft, Kubernetes zu skalieren und auch zu verteilen und aufzubauen. Wann hast du denn zum ersten Mal von Kubernetes gehört?

Ich habe seinerzeit dann wieder viel selber entwickelt, also auch mit zum Beispiel Java, Spring und solchen Themen und dann kam eben das Thema Container auf und Docker und habe dann selber und auch mit Bekannten eine Applikation gebaut und wir haben die in einen Container gepackt und fanden das Konzept immer schon gut, aber dann war eben die Frage, wie deployen wir das Ganze, wie verwalten wir das Ganze und als

Google dann Kubernetes released hat, habe ich das mitbekommen und gesagt, hey, das könnte interessant sein, wir hatten immer das Problem, okay, wie deployen wir oder wie managen wir das? Gerade wenn wir nicht nur einen Server, sondern mehrere Server hatten und hatten uns da selber Skripte und so geschrieben, aber es fühlte sich alles irgendwie so nicht richtig an oder irgendwie fehlte da was. dann kam das Thema eben auf und ich hatte mir das angeguckt.

Und zu der Zeit, ja, bin ich regelmäßig mit Julian, meinem Mitgründer, immer Fahrrad gefahren und er meinte dann irgendwann auch, hey, ich bin jetzt bald draußen, mein Job. Und wir hatten vorher schon mal gesprochen, wenn ich ihn mal zusammen machen wollte, haben wir gesagt, okay, wenn nicht jetzt, wann dann? Weil wie hoch ist die Wahrscheinlichkeit, dass wir beide irgendwie zur passenden Zeit am passenden Ort sind und sagen, ja, jetzt passt es für beide? Und dann habe ich gesagt, hey, ich kenne da so ein Thema.

Container und Kubernetes. Und Julian hat mich angeguckt was das ich mir erklärt und so sind wir mit dem ganzen Thema erst mal angefangen, haben dann erst mal so bisschen auch unseren Kontakt angerufen. Die haben uns dann alle erzählt, nee, wir machen jetzt gerade VMs. Mussten dann erstmal lernen, wer braucht das ganze Thema denn jetzt am Anfang, wer ist denn so early early nutzt das ganze Thema schon.

Aber in dem Umfeld gab es ja auch andere Lösungen. Es gab ja Mesos, Docker hat ja mit Docker Swarm ähnliche Ansätze dadurch versucht an den Markt zu bringen. Was war denn so der Moment, du gewusst hast, hey, ich baue meine Zukunft auf Kubernetes auf? Was war das Entscheidende, was gesagt hast, okay, unser Startup hat als Grundlage Kubernetes.

Naja, ich glaube, es waren primär zwei Punkte. Auf der einen Seite hatten wir dann die Idee, dass wir irgendwie ein Tool brauchen, das Ganze zu verwalten, also Kubernetes Cluster zu verwalten, weil wir immer gesagt haben, okay, wir glauben nicht, dass man nur ein Cluster hat, sondern dass man in Zukunft quasi mehrere Cluster betreiben muss, will. Und das Problem, was wir da gesehen haben, hätte, glaube ich, auch für Mesos oder aber Docker Swarm, da hätte man dasselbe Problem gehabt.

lösen können. Von daher sind wir nie am Anfang dahingegangen und gesagt, okay, wir machen das jetzt nur oder wir werden das nur und für immer auf Kubernetes machen, sondern wir haben immer natürlich geguckt, was macht der Markt und was nutzen die Leute eigentlich und hätte sich irgendwann abgezeichnet, dass eines der anderen Tools doch viel mehr genutzt werden, hätten wir geguckt, gibt es da noch eine Möglichkeit, dass man da was mitmachen kann oder dass man das selbe Problem da lösen Hat sich zum Glück nicht

bewahrheitet, sondern Kubernetes hat das Rennen gemacht. Also von daher hat man dann ganz guten Riecher und auf der anderen Seite haben wir uns eben bei Kubernetes waren von Anfang an Google und Red Hat, also erstmal schon mal mehr Unternehmen dahinter und aber auch große Unternehmen und wir haben eben darauf gehofft nach dem da hängt jetzt nicht nur eine Company hinter, sondern mehrere. Das überzeugt die Leute vielleicht bisschen eher, als dass da eben nur eine Company hinterhängt.

Und die Leute da vielleicht denken, ja, vielleicht geht es dann doch eher in Richtung Kubernetes. Ich denke mal, gerade der Foundation-Gedanken hinterher der CNCF hat hinterher insbesondere auch geholfen, das Ganze nach vorne zu pushen. denke mal, als dann wirklich hinterher alle drei Hyperscaler, Google war von vornherein mit dabei, aber spätestens AWS hinterher gesagt hat, okay, wir bringen jetzt da unser eigenes Managed Offering raus, war glaube ich klar, dass...

das Rennen machen wird, weil allein durch deren Dominanz da extrem viel Traktion und Visibilität darauf kommen würde.

Ja, das hat man gemerkt. So, im Anfang wurde das alles sehr noch im Nischenumfeld quasi behandelt. Das war eine starke Community, die das Thema getrieben hat. Und dann kamen die Hyperscaler mit rein. Mittlerweile nutzen ganz, ganz, ganz viele Kubernetes, kontributen auch viele. Wie siehst du denn Kubernetes? Sind wir noch am Anfang? Sind wir mittlerweile commodity? Hat sich das so etabliert, dass das jeder hat? Oder wo sind wir dann? Nicht im Hype-Cycle, aber so im Cycle des Produktes, aus deiner Sicht.

Ich glaube, das kommt ganz drauf an, wie man fragt und was die Besichtweise auf Commodity ist. Wenn man so die Early Adapters natürlich anschaut, werden die sagen, ja, das ist ja sowas, Commodity und haben wir schon Ewigkeiten. Versus wenn man andere anguckt, gibt es, glaube ich, noch genug, die gerade mit dem Thema erst anfangen. ich glaube, natürlich hat es sich jetzt durchgesetzt und ich glaube, es stellt keiner mehr groß in Frage nach dem Modell, brauche ich Container überhaupt, sondern ich glaube, die Technologie ist

ausgereift hat auch auf großem Scale gezeigt, es kann funktionieren aber eben auch auf kleinem Scale, dass es Vorteile bringt. Ich glaube es kommt einfach auf die wie weit die Unternehmen schon sind, die early adapters da ist glaube ich die Adaptionsrate auch was in Summe quasi wie viel Sachen sie kontinentalisiert laufen lassen sehr hoch versus die erst vor ein oder zwei Jahren oder drei Jahren angefangen ist, wo vielleicht die ersten Applikationen gerade laufen und

jetzt angefangen wird mehr und mehr Richtung Container zu migrieren oder auch gerade erst anfangen mit Containern sich zu beschäftigen. Also es ist sicherlich Commditiy im Sinne, wie ausgereift ist es, was funktioniert damit alles. Aber von der Adaptionsrate ist natürlich noch über die nächsten Jahre bis quasi Jahrzehnte noch viel Zeit, bis das wirklich sich komplett durchgesetzt hat und als Layer

da alle Workloads oder die meiste Workload drauf läuft. Also heißt ja auch nicht, dass wirklich alles alles darauf laufen muss oder wird.

Also

die Technologie ist stabil und jeder hat so seine eigene Journey sozusagen, wie er da mit dem Thema anfängt, wie dem Cloud-Thema. Was sind denn die wildesten Dinge, die du auf Kubernetes mal gesehen hast, also entweder im Umfeld der Community oder auch bei deinen Kunden? Was hat dich denn mal so richtig beeindruckt oder wo du gedacht hast, mein Gott, was haben die denn gemacht?

Auch da kommt es immer so ein bisschen drauf an, it depends. Ich glaube, da muss man ein bisschen unterscheiden, wie best practice bin ich da unterwegs oder ist das, was ich mache und ich mache das mit gewissen Einschränkungen, aber mir sind diese Einschränkungen schon bewusst. Wir hatten aber an Kunden das Problem, dass die Applikationen

der Container irgendwie 70 Gigabyte groß ist, was schon extrem großes natürlich, wo du sagst, na vom Best Practice ist das der richtige Ansatz und da war aber auch nicht viel zu optimieren, aber auf der anderen Seite hättest das in VM-Images gepackt, wär's auch nicht kleiner geworden. und irgendwie 70 Gigabyte große Container zu starten, die dann doch sehr lange laufen. Ja, ist es Cloud Native as Best Practice? Auf keinen Fall.

Ist es jetzt verboten, das damit zu machen oder ist es jetzt total antipattern, würde ich auch nicht sagen, weil natürlich habe ich immer noch die ganzen Vorteile, die ich aus dem Toolshap von Kubernetes rauskriege, dass ich eine standardisierte API habe, standardisierte Deployment Weg und und und und. Nur dieser Container ist zum Beispiel ein riesengroß und dass man immer so ein bisschen in-between ist. Natürlich interessant sind dann gerade auch.

heutzutage dann die ganzen großen Use Cases around AI, dass eben alles quasi oder die meisten Sachen da auf Kubernetes laufen und dass man dann sieht, wie groß dann auch solche Cluster wirklich werden können, einzelne Cluster auch, aber bis hin auch zu wirklich kleinen Use Cases, dass man sagt, okay, ich habe viele ganz viele kleine Cluster, die irgendwo verteilt sind am Edge in jedem Supermarkt oder bis hin zum Flugzeug oder Schiff, wo Sachen laufen können.

Ja, spannend. Das zeigt auch die Vielfalt, wie Kubernetes eingesetzt wird. Es ist wirklich interessant. Wie sieht denn aus deiner Sicht die Zukunft aus von Kubernetes? Du hast gesagt, wir sind schon in so einem stabilen Zustand. Man kriegt mit im Moment, dass viel über Workloads vom Thema AI diskutiert wird, wie man das in Kubernetes reinkriegt, GPU-Access und solche Sachen. Was sind denn solche Zukunftsthemen, die du siehst in dem Umfeld?

Genau, also ich glaube für Kubernetes selber, also für die Workload ist glaube ich das gerade das größte Thema, wie kriege ich diese ganzen AI-Use-Cases auf den verschiedensten Ebenen sauber zum Laufen, also sei es von ich kriege die GPUs oder entsprechende Devices ins Cluster rein zu Containern, bis hin, dass diese Workloads natürlich ganz andere Workload Behaviours haben als

ich sag mal, eine klassische Web-Applikation. Also was muss ich da ändern oder was muss ich am Scheduler oder oder ändern, sowas wirklich zu optimieren und zu verbessern. Aber das Gute ist, durch die Flexibilität selber gibt Kubernetes einen da auch diese Möglichkeit. Und ich glaube, für Kubernetes selber ist das gerade das größte Thema, was wirklich noch an diesem Core von Kubernetes oder wirklich an einem Kern Erweiterungen gebaut wird. Ich glaube, viel interessanter, wenn man sich anguckt,

wo passieren die Innovationen, jetzt eben über Kubernetes drüber. Also wenn man eben sieht, okay, wie groß das Ecosystem da drum geworden, wie einfach ist es auch, Kubernetes zu erweitern über CRDs oder, Passiert natürlich da extrem viel, dass Leute eben, ja, entweder für ihren speziellen Use-Case, aber auch generische Use-Cases, sei es zum Beispiel Policy-Management.

top auf Kubernetes bauen, was jetzt aber nicht unbedingt zwangsläufig in den Kern von Kubernetes rein muss, sondern man wirklich sagen kann, okay, das Ganze ist in gewisser Weise pluggable und ich kann da oben drauf dann spezielle Sachen bauen, die mir dann das Leben ereinfachen oder die mir mehr Möglichkeiten bieten, die mir der Core an sich nicht bietet. dann damit auch jeder so ein bisschen die Flexibilität hat zu sagen, okay, brauche ich das oder brauche ich das nicht.

Ja, das ist ja die spannende Geschichte an Kubernetes, es so erweiterbar ist, also dass man da wirklich ein Format gefunden hat, über die Custom Resource Definitions oder auch die Cluster API, wie man mit Kubernetes arbeiten kann, ohne im Core dann irgendwie Kubernetes zu erweitern. was man, du hast es schon angesprochen, das bringt natürlich ein ganzes Ökosystem oder fast eine ganze Industrie an Zulieferern, die Tooling bereitstellt für Kubernetes oder wie man Kubernetes handelt.

Eine davon seid ihr. Ihr habt auch ein Produkt oder mehrere Produkte in dem Umfeld. Sagt uns doch ganz kurz mal, was macht KubaMatic? Wie groß seid ihr? Und was ist KKP und CubeOne und die Produkte, die ihr so habt?

Genau, also wir sind ein Hamburger Unternehmen, aber komplett remote. wir haben uns eben am Anfang schon gefragt, so schön wir beiden Gründer auf Hamburg finden, ist es realistisch, dass wir alle Leute überzeugen, die in dem Umfeld unterwegs sind, nach Hamburg zu ziehen und haben dann gesagt, nee, einer der ersten Mitarbeiter war dann zum Beispiel in Polen und der hat schon an Upstream Kubernetes gearbeitet.

den wollten wir unbedingt hiren und haben gesagt, im Endeffekt spielt es keine Rolle. sind deswegen aktuell ungefähr 70 Leute verteilt über 20 Länder. Also überall, wo wir Leute finden, die sich damit auskennen, Kubernetes zu entwickeln, also wirklich Kubernetes-Operator zu bauen, tief sich im Kubernetes-Umfeld auskennen. Genau und hatten...

von Anfang an die Idee, wie können wir unseren Kunden helfen, über Software zu skalieren als, und nicht nur mit Leuten, also unsere Company, ich glaube Vision, heißt Power Through Automation. Also wirklich, wie können wir über Software unseren Kunden helfen, Cloud Native Workloads insbesondere skalieren zu betreiben, also zum Beispiel mit KKP, sowohl weniger Cluster,

aber auch hunderte bis zu tausenden Clustern über verschiedene Hyperscaler On-Premise Edge zu betreiben. sind eben mit unserer Community Kubernetes-Plattform angefangen und haben darum jetzt eben noch weitere Produkte gebaut. Auf der einen Seite hatten wir dann gerade so im On-Prem data center immer das Problem, dass wir Loadbalancer brauchten und

Die kommerziellen Lösungen, da draußen waren, oftmals dann beim Netzwerkteam gemanagt waren, aber auch nicht so wirklich multi-tenancy-fähig waren oder das Netzwerkteam und nicht den Plattformteam, die Cluster betrieben hat, API-Access geben wollte, sodass man, wir konnten immer gut Compute automatisieren, aber dann war immer so, ja, aber wir kriegen Traffic ins Cluster und haben dafür QLB gebaut, sodass ich einen zentralen Loadbalancer-Cluster habe, wo die ganzen Loadbalancer laufen, weil die

Cloud Native Lösungen gehen immer davon aus, dass sie in das einzelne Entwicklercluster oder Applikationscluster deployen werden. Aber das ist dann wieder schwierig für das Platformteam, die alle zu managen, weil du keine Zentrale hast, die verteilt hast in all deinen Clustern. Genau, da haben wir KubeLB dann haben wir noch Kubernetes Virtualization, insbesondere mit dem Fokus im On-Prem-Data-Center. Ja, hatten unsere Kunden immer die Herausforderung? Entweder hatten sie schon.

schon Virtualisierungsplattformen, aber teilweise keine mit gutem API-Zugriff. Und da war es auch oftmals so, das Thema, das Plattformteam hatte da nicht den Zugriff, den es brauchte. Und wir haben uns dann irgendwann mal gefragt, kann ich nicht den ganzen Stack mit Kubernetes betreiben? Also von Web-Metal-Cluster über Virtualisierung, Netzwerk und so weiter. Dann kam das vor sechs Jahren, fünf Jahren, irgendwie kam das ganze Thema

Cube Word auf, haben da schon relativ am mit entwickelt und haben da darauf aufbauend eben unsere Kubermatic Virtualization gebaut, ⁓ ja, Virtualisierung insbesondere für Container-Management, also dass ich meine großen Bermetall-Maschinen in kleinere VMs partitionieren kann und diese VMs kommen dann eigentlich in das Application-Cluster oder Entwicklungs-Cluster rein.

Genau und dann jetzt eben als neues Produkt unserer Kubernetes Developer Platform da eben vor dem Hintergrund oftmals oder unser Gedanke für alle Produkte war immer, ich möchte das Ganze als As-A- Service anbieten, also die Platform Teams enablen, dass sie quasi Cluster As-A- Service oder Load Balancer As-A- Service anbieten kann. Aber wie kann ich denn eigentlich andere Sachen As-A- Service anbieten, also Datenbank oder

sei es auch nur Entwickler Workflows, weil die großen Cloud-Provider, die haben diese API, ⁓ alle ihre Services über eine API verfügbar zu machen. Und wir haben eben gesehen, wenn man eine eigene API baut, bei unserem Produkt schon selber, ist es immer schwierig, dann hast du diese ganze Integration nicht. Dann musst du einen eigenen Terraform-Provider bauen. Dann musst du eventuell eine Integration in diese ganzen CI-Tools bauen. Wenn du das überhaupt hinkriegst.

Aber haben uns angefragt, was ist eigentlich eine API, die alle diese Tools unterstützen? Und im Endeffekt ist es die Kubernetes API. Und Kubernetes als dieser Control-Plan-Pattern, den Kubernetes unterstützt, der ist ja nicht durch Kubernetes erfunden worden, den gab es ja schon vorher. Aber ich glaube, Kubernetes hat insbesondere durch seine erweiterbare API da einen guten Standard gesetzt. Ja, und was wir in unserer Developer-Plattform eben machen, ist quasi die Kubernetes API zu nutzen.

⁓ alles mögliche As-A-Service anzubieten, ohne dass es unbedingt zwangsläufig auf Container Workload läuft oder auf Kubernetes hinausläuft, sondern ich habe eine eher weiterbare Enterprise API, ich nutzen kann, meine Teams zu enablen, meine Services einfach konsumierbar zu machen.

Krass. Also das heißt, ihr nutzt Kubernetes auf allen Ebenen im Portal quasi die API, ⁓ die Ressourcen zu bootstrappen. Auf der KKP-Ebene, wo ihr die Cluster managt, nutzt ihr, glaube ich, auch Kubernetes, die Cluster zu managen selbst. Und quasi alle eure Produkte drehen sich rund ⁓ Kubernetes. ich glaube, wir hatten es irgendwann mal im Gespräch. Anfangs sind viele Firmen hingegangen, haben gesagt, wir wollen einen ganz großen Cluster haben.

wo wir einfach Namespaces zur Verfügung stellen. Und da hattest du mir glaub ich damals gesagt, der Trend geht eigentlich dahin, viele kleinere Clusters zu haben, auch die Upgrade-Cycles besser mitmachen zu können, dort sich flexibler aufzustellen. Und gerade für diesen Bereich braucht man natürlich auch passendes Tooling, was ihr dann auch zur Verfügung stellt an der Stelle.

Genau, genau, wie unser Name schon sagte, Kubernatic Kubernetes Automation. Bis jetzt alles, was wir machen, funktioniert auf Kubernetes. Und genau, also am Anfang haben wir eben gesehen und haben uns auch viele Kunden gesagt, nee, wir haben ein paar große Cluster und unsere Namespaces da drin. Und da sieht man eben, aber dass es dann Schwierigkeiten hat, weil alle die Probleme, die ich irgendwie auf der Applikationsschicht lösen möchte, dass ich irgendwie

unabhängig deployen kann, unabhängig updaten kann, schiebe ich damit in den Infrastructure-Layer, weil wann mache ich das Update meines unterliegenden Kubernetes-Clusters, weil ich habe wahrscheinlich immer dann ein Team, sagt, gerade ist gerade schlecht, ein Upgrade des unterliegenden Kubernetes zu machen. Und wenn ich den Teams oder wenn ich meine Applikationen anerschneiden kann und ich viel flexibler belehne, wie viel Cluster ich mache, einzelnen Teams oder einzelnen Applikationen, unterschiedliche Cluster geben kann.

kann ich natürlich viel unabhängiger voneinander Sachen updaten. Also, dann können die, die quasi latest, greatest immer auf der latest Version sein wollen oder müssen, weil sie Sachen nutzen wollen, die gerade erst neu rauskamen, in Kubernetes zum Beispiel, relativ früh updaten. Aber die Applikationen, sagen, hey, wir haben gar nicht mehr so viele Entwicklungen, das läuft einfach stabil und ich brauche jetzt nicht über das Neueste, ich habe gar keine Zeit dafür, das zu adaptieren oder ich will einfach nur, dass stabil läuft.

haben dann einfach viel mehr Zeit, zu sagen, wann mache ich das Upgrade, wann passt das eigentlich in meinen Zeitplan rein.

Ja, das ist irgendwie so das Microservices-Pattern als tiefer gelegt auf die Infrastruktur, eben also kleinteiliger unterwegs zu sein, unabhängiger die Upgrades durchzuführen und das Patchen quasi.

Genau,

und wenn ich das Microservice-Pattern quasi von oben drüber mache und unten nicht diese Flexibilität habe, schiebe ich die Probleme, ich eigentlich mit Microservices oben versuche zu lösen, in den unterliegenden Layer und gut, als Microservice-Team kann ich sagen, nicht mein Problem, weil es ein anderes Team vielleicht macht, aber im Endeffekt als Organisationen verlagern sich die Probleme einfach nur anderen Layer und die Probleme sehen vielleicht ein bisschen anders aus, aber funktionieren.

Ich immer noch dieselben Probleme in meiner Organisation und muss mir immer noch überlegen, wie ich das Ganze lösen kann. Wenn ich das Ganze wirklich Ende zu Ende denke, muss ich das natürlich auch auf den unterliegenden Layern berücksichtigen und sagen, die Flexibilität, ich im Microservice Layer haben will, muss ich auch auf dem Container- und Cluster-Level-Layer haben, weil sonst kriege ich das nicht sauber gelöst.

Und irgendwann muss es gelöst werden und das letzte Team in der Kette beißen sozusagen die Hunde dann. Das wollen wir nicht. Ihr habt eine Gartner Recognition bekommen mit euren Produkten. Das heißt, im Gartner Halbcycle seid ihr gelistet. Wie kam es denn dazu?

Genau, ja, ich habe schon das Thema Kubermatic Virtualization erwähnt. Das ganze Thema VMs zu managen mit Kubernetes nimmt natürlich jetzt aufgrund der bekannten Umstände VMWare doch wieder mehr Fahrt auf und interessiert natürlich doch relativ viele, weil sie alternativ nach alternativ gucken und in dem Zuge, ja.

hat Gartne in ihrem Hypecycle gesehen, dass das Thema auch immer mehr hochkommt und hat uns als einer der Beispiel-Vendor da gelistet, die sowas eben machen können und die auch schon relativ früh bei diesem ganzen Thema dabei sind. Auch da wieder dieser Gedanke, den wir hatten, warum brauche ich eigentlich noch ein anderes Orchestrier-Tool, wenn ich das Ganze eigentlich mit Kubernetes machen kann? in unserem Data Center, was wir in unserer Entwicklung haben, sind wir sogar so weit gegangen, dass wir unsere Switche mit Kubernetes bestückt haben.

und die Konflikt auf die Switche mit Kubernetes ausrollen, weil im Endeffekt brauche ich auch da ein Orchestrationstool und eigentlich kann ich da auch Kubernetes nutzen, also was spricht dagegen? Und das macht den Betrieb dann natürlich auch viel einfacher, weil ich nicht mehr 20 verschiedene Wege und Techniken verstehen muss, das Team, was den oberen Layer managt, kann relativ einfach den unteren mitmanagen und ich kann viel mehr Synergien in meiner Organisation ziehen.

Ja, spannend. Also ihr seid wirklich von oben bis unten, hinten nach vorne Kubernetes. Jetzt aber eine Frage, wann ist denn Kubernetes nicht das Richtige? Also wann würdest du es auf keinen Fall einsetzen?

Es gibt natürlich einige Punkte, wo ich sage, das würde ich mir noch mal genau angucken, also geht schon damit los. glaube, Container und Kubernetes spielen unbesonder seine starke Rolle aus, wenn es selbstgeschriebene Applikationen geht, wenn ich irgendwie Software von Third-Party-Vendern habe und Software einkaufe. Muss ich da erstmal schon mal gucken, was supporten die eigentlich? Also darf ich da so kontainerisiert?

betreiben. Liefern die überhaupt Container oder müsste ich die sonst selber bauen, aber supporten die das dann auch? Wie ist das Betriebsmodell? Also bei solchen Themen muss man natürlich immer sehr genau hingucken und schauen, was supportet da. Dann auch die Stärken von Kubernetes kann es natürlich am besten ausspielen, wenn ich wirklich ja Microservice Architekturen habe oder zumindest Applikationen habe, die

dem 12-Factor-App-Paradigma folgen. Und je weiter ich davon weg bin und je monolithischer das Ganze dann wird, ist eben die Frage, okay, wie weit macht das Ganze eigentlich Sinn, das in Container zu packen? Oder wenn ich weiß, in ein, zwei Jahren entwickle ich sowieso was komplett Neues, lasse ich das dann nicht einfach noch weiter einfach in WMs laufen, bevor ich hier ein riesen Migrationsprojekt starte.

und mir ganz viele Probleme einhole. Wie viel Wissen habe ich eigentlich für diese ganze Applikation noch? Kann ich da überhaupt migrieren? Macht es da Sinn, das zu migrieren oder habe ich gar nicht mehr das ganze Wissen für diese Applikation? Und Never Touch the Running System, ich lasse einfach weiter laufen und ich weiß davon, ich habe viel weniger Aufwand und Probleme wahrscheinlich damit.

Also es kommt auf den Use Case drauf an, kann man nicht so pauschal sagen. Ich habe irgendwann mal gehört, Datenbanken sollte man nicht in die Container stecken. es immer noch so oder hat sich das mittlerweile erledigt?

Ich glaube, das kommt sehr stark darauf an, du fragst. Auch da natürlich habe ich mit Datenbanken ein anderes Laufzeitverhalten, vielmehr stateful. Ich will nicht, dass es relativ schnell moved einem auf das andere. Aber da würde ich eher sagen, es kommt ein bisschen auf die Datenbank drauf an. Und Kubernetes ist im Endeffekt ein Orchestrierungstool, ⁓ meine Datenbanken zu beschreiben.

insbesondere mit irgendwelchen Operatoren und so, kann ich damit natürlich auch viel mehr automatisieren, als wenn ich das jetzt irgendwie rein auf eine VM installiere. gerade wenn ich eine Datenbank HA betreiben will und muss und die über mehrere Server verteilen muss. Weiß ich nicht, ob es andersrum viel einfacher ist. Ich glaube, da kann man sehr schwierig sagen pauschal, ja, mache es oder mache es nicht, sondern es hängt sehr stark von der Datenbank ab, es hängt sehr stark von Use cases an und auch...

Mmh.

Wie häufig mache ich das? Brauche ich eine Datenbank? Ja gut, dann würde ich wahrscheinlich wirklich nicht machen. Insbesondere wenn ich irgendwie auf dem Cloud Provider bin, würde ich auch ganz klar sagen, gerne nutze das, Managed Service vom Cloud Provider. Aber muss ich sehr viele Datenbanken verwalten? Habe ich ein komplettes Datenbankteam? Mit irgendeinem Tool müssen sie es ja machen. Und ich wüsste jetzt nicht ein Tool, unbedingt dann

X besser ist, wo man sagt, ja, obvious Choice ist, das Tool für Datenbanken zu managen. Ich glaube, es liegt in der Natur der Datenbank, dass das nicht immer, dass das stateful ist und sehr schmerzvoll ist, wenn man die Daten verliert, dass es mit allen Tools ein bisschen schwieriger ist. Und dasselbe sieht man an Kubernetes auch. Kubernetes kann da keine Wunder vollbringen und sagen, okay, hurra, jetzt sind Datenbanken einfach. Es hängt sehr stark von der Datenbank ab.

Ja,

wie du sagst, Kubernetes macht ja eigentlich nichts, ist nur eine Orchestrier. Und ich glaube, wenn man das passende Fach-KnowHow hat und die Experten mit dabei hat, die schauen sich dann den Use Case an und finden dann entweder einen Weg oder sagen großes No-No. Ihr seid bei Kubermatic all in in Open Source. Ich glaube, ich habe mal geschaut auf GitHub, eure Top Repos. haben 1400 und 1200 Stars, also wirklich auch eine große

in der Community. Ihr seid selbst unter den Top-Kontributern oder ihr habt Kollegen in der Firma, die eine Top-Kontributern sind von Kubernetes selbst. Was bedeutet für dich Open Source und wie ist es ein Unternehmen rund Open Source aufzubauen?

Ja, also ich denke der Hauptpunkt ist insbesondere ohne Open Source wären wir nicht da, wo wir heute sind. Also hätten wir das alles selber entwickeln müssen, da ist ja erstmal schon mal die Frage, wo fange ich an? Also muss ich wirklich, wenn wir gar keine Open Source hätten, müsste ich ja quasi auf OS-Level anfangen, aber auch auf Orchestrierungslevel und und und und wären viele, wären wir glaube ich alle nicht da und wir hätten viel mehr Insellösungen, das Ganze zu managen. Also von daher

sind wir und waren wir immer starker Verfechter von Open Source, ich glaube, gerade so im Infrastrukturbereich sind die Probleme, die wir alle haben, relativ vergleichbar. Natürlich gibt es verschiedene Use Cases, dass man sagt, okay, ich habe, ich betreibe das in der Cloud, ich betreibe das On-Premise, ich betreibe das irgendwie am Edge, ich betreibe Web Server, ich betreibe Datenbanken, aber

Ich glaube, das ist eher technisch und problemstellungsbezogen, als dass es sehr irgendwie industrie-spezifisch ist. auch der Edge-Use-Case, ja, natürlich haben nur einige Industrien dieses Problemen, aber der Use-Case ist dann zum Beispiel, wenn ich mir Retail angucke und wenn ich mir Manufacturing angucke, nicht so groß unterschiedlich, aber natürlich ist es was ganz anderes, als wenn ich irgendwie im Supermarkt unterwegs bin, als ich in der Fabrikhalle unterwegs bin, rein von der Workload, die hinterher auch da drauf läuft.

Aber ich glaube, da sind eben viele Synergien, die alle mitbringen und alle unterstützen. Und ich glaube, allein aus dem Grund kann Open Source da sehr viel Mehrwert bringen, insbesondere wenn es über eine große Community und Foundations im Großteil passiert.

Aber es bedeutet natürlich auch, braucht ein gewisses Mindset, sich da zu öffnen. Also das alles irgendwie offen zu legen, in der Öffentlichkeit auch zu diskutieren, ist für viele erstmal ein Hindernis. War das für euch klar von Anfang an, wir gehen Open Source?

Dass wir komplett open source sind, nee, war nicht von Anfang an klar. Wir hatten erst, wir haben viele an Kubernetes gemacht, aber die Sachen, die wir erst selber entwickelt haben, waren nicht open source. Ich glaube, das würde ich beim nächsten Mal sofort anders machen, zu sagen, wir gehen von vorne rein, open source oder mit dem Open Core Model an das Ganze ran. Aber ich glaube, das zeigt sich dann auch erst immer in der Zeit, was sind da die besseren Modelle?

Aber von der Sache her glauben wir sehr extrem stark an Open Source, weil wir darüber auch einen extrem guten Erfahrungsaustausch haben mit anderen Unternehmen und man sich auch eben entsprechend gegenseitig helfen kann und auch viel mehr Wissen aufbauen kann in der gesamten IT. ich glaube keiner in dem ganzen Cloud-Native-Ekosystem wäre alleine so weit gekommen, auch vom Wissen her, dass es so viele Leute gibt, die sich

mit Kubernetes auskennen und und und und.

Du hast das Open Core Modell gerade angesprochen. Kannst du das kurz noch mal erläutern? Das ist ja ein Business Modell, wie man Open Source betreiben kann sozusagen oder wie eine Company außen rum baut.

Genau, also natürlich arbeiten wir alle, meine Entwickler, nicht für Luft und Liebe. Also am Ende des Monats erwartet hier jeder einen Gehaltscheck und Geld auf so einem Konto. irgendwie müssen wir das Ganze auch bezahlen. ja, den Weg, den wir aktuell gehen, eben zu sagen, auf der einen Seite entwickeln wir sehr stark in Foundations, also sei es der Linux Foundation, CNCF.

an Open Source mit, aber auch unser Code für die Produkte liegen als Open Source, oder sind Open Source verfügbar mit Features, die on top kommen, wo wir wissen, das ist typischerweise was, die Enterprises nutzen oder größere Unternehmen nutzen oder die das Ganze schon mehr advanced nutzen und dort in einem Bezahlmodell dann, dass man dafür eine Lizenz braucht.

⁓ das entsprechend auch zu kommunizieren. Wir sehen aber eben auch, dass diese Nutzer oftmals sowieso auch Support brauchen, konventionell in Support und oftmals auch gar nicht in vielen Fällen das Okay haben, rein Legal- oder Risk-Management nur die Open Source-Version zu nutzen. ⁓ da eben die Synergien auf beiden Seiten zu nutzen und zu sagen, wir glauben stark an die Community, wir geben viel an die Community, aber auch...

oftmals, dass Leute aus der Community zu unserem Code beitragen und sagen, hey, ich habe einen Feature Request. Ich glaube, das macht es auch einfacher für unsere Kunden, weil wenn sie sagen, hey, ich habe da was, ich habe so eine gute Idee und es selber entwickeln, weil wir vielleicht gerade nicht die Priorität dafür haben oder die Zeit dafür haben, können sie es ganz einfach bei uns zusteuern. Es wird öffentlich dann diskutiert, ob es Sinn macht oder nicht Sinn macht, am besten frühzeitig.

auf uns zukommen und eine Diskussion anstoßen, also einen riesen PR und bitte mergen. Aber man kann eben dann auch wirklich Einfluss auf das Produkt nehmen, nicht nur über irgendwelche Meetings im Produktmanagement, sondern auch wirklich selber sagen, das würde ich ganz gerne, das Feature sehe ich. Und wenn wir sehen, okay, das ist jetzt irgendwie nicht ein spezielles Feature, was nur für diesen einen Use-Case und diesen einen Kunden funktioniert.

Wir immer sehr daran interessiert, sowas auch in unserem Code aufzunehmen. Der Vorteil für den Kunden ist, dass wir auch hinter die Maintenance für das ganze Übernehmen gucken, das automatisch testen, was natürlich auch dazu gehört.

Ja, das ist spannend. Also nicht nur Tickets schreiben, sondern wirklich auch im Code schauen, wie funktioniert es, eventuell Vorschläge mit einreichen in Form von PRs. Wie, also wenn du das teilen möchtest, wie triffst du denn diese Entscheidung, was kommt in den offenen Core? Was ist dann Enterprise? Wie ist denn da für dich die Balance? Und wann merkst du, das ist ein Feature, das brauche ich in der Richtung oder das machen wir offen? Oder gibt es Features, die waren mal eine Zeit lang Enterprise und wann dann dann in Open Core? ist so dein

oder euer Mindset dahinter, wie ihr das organisiert.

Also, erstmal prinzipiell, erstmal alles, was lauffähig ist, das Produkt erstmal so zu nutzen und lauffähig zu haben. was dann oftmals noch hinzukommt, sind so Sachen wie, ja, sag mal klassische Enterprises, Policy

Wir haben zum Beispiel die Load Balancer Integration in QB. Die kann ich auch manuell machen, aber wenn ich natürlich Seamless Integration habe, ist das nur in der Enterprise. Und wirklich, wo ich sage, okay, da muss ich was skalierend betreiben und da will ich das auch Support haben. Solche Sachen packen wir dann typischerweise in die Enterprise Edition oder auch in der Community Edition. Keil ich das Ganze immer nur auf einem Cloud-Proval oder auf einem

Providers betreiben. Das heißt, ich den überliegenden Blick über alle Providers und ich habe viele Installationen und diese sind Umbrella, den Schirm, der mir das Ganze in einem Tool gibt, das haben wir dann in der Enterprise Edition. Das heißt aber nicht, dass ich die nicht unabhängig verwalten kann und managen kann. Habe da nun ein bisschen mehr Aufwand, das zu verwalten und zu managen und ja, versuche dann ein gutes Bundle, gerade so, ich insbesondere, dass ich

mit der Community Edition erstmal gut starten kann. Aber wenn es dann hinterher vielleicht an die Skalierung geht und ich brauche da mehr Automatisierte Features, ich kann das alles auch manuell, aber habe da natürlich mehr Zeitaufwand und so weiter und da gucken wir dann schon, dass wir dann sagen, das geht dann vielleicht in die Enterprise Edition anstatt, dass wir das noch weiter in die Community Edition machen, da eben auch den Mehrwert zu zeigen und zu sagen, hey, da helfen wir.

Und da können wir auch helfen.

Ja, das ist dann spannend am Anfang schnell starten zu können, vielleicht auch im Unternehmen launchen zu können und später ab einer gewissen Skalierung geht man ja auch davon aus, dass das Produkt Geld verdient. Und dann kann man natürlich auch bisschen Automatisierung auslagern und dann in ein bezahltes Produkt reingehen und quasi eure Dienstleistung auch mit in Anspruch nehmen.

Genau,

also insbesondere muss man sich ja auch immer vor Augen führen, wenn ich Open Source nutze. Natürlich machen einige Leute das in ihrer Freizeit, aber das Gro an Software, was gebaut wird, die Leute werden von den Unternehmen bezahlt und in irgendeiner Weise müssen diese Unternehmen natürlich auch dann damit Geld verdienen. Natürlich mit unterschiedlichsten Business Modellen, aber schon

gewisserweise Geld verdienen, sei es über irgendwie einen SaaS Service oder sie verkaufen Hardware und die Software ist on top oder oder oder und ich glaube da muss jedes Unternehmen gucken, was ist der beste Weg da für sich. Für uns ist aktuell eben dieses Open Core Model, dass wir sagen, okay der Core ist open source und wir haben die Enterprise Edition on top und ja, man sieht es ja auch, es gibt ja auch immer wieder Diskussionen generell auch

wenn andere Unternehmen ihre Lizenz ändern, weil natürlich auch jeder gewisse Ziel erreichen muss.

Ja, wäre dann auch so Thema. Wir haben das von Docker gesehen, HashiCorp, Elastic, die haben irgendwann dann angefangen, die Lizenz zu ändern, haben das geändert, die haben aber ein so gutes Produkt rausgebracht und was natürlich in unserer Industrie ist, das sind ja auch fähige Leute, die dann quasi mit dem Kernprodukt schon einiges anfangen können und ja, am Ende des Tages muss Geld verdient werden. Siehst du da einen generellen Trend oder waren das jetzt einzelne Vorkommnisse von

Börsennotierten Unternehmen, vielleicht einfach mehr Revenue ausweisen müssten oder was siehst du da aktuell?

Ich glaube, das kommt immer so bisschen drauf Was ist der Treiber des Ganzen? Warum ändern Sie die Lizenz? ich nicht jeder ändert ja auch die Lizenz. Es gibt ja auch unterschiedliche Lizenzen, die dann hinter genutzt werden. Also viele kommen irgendwie von Apache oder MIT. Einige gehen dann in die Business Server License, die sehr

die nicht mehr wirklich Open Source ist. Andere aber gehen dann in AGPL. Das heißt, ich kann es trotzdem weiter nutzen, muss aber den Code eventuell offenlegen, wenn ich da Erweiterungen baue oder, oder, Und ich glaube, da muss man immer auch bisschen gucken, okay, welche Richtung hat sich das Projekt entwickelt, entwickelt sich es, was sind eigentlich die Gründe dafür und wie viel Impact hat das auch als Nutzer von diesem Produktprojekt.

Aber ja, du hast gesagt, im Endeffekt müssen wir oder müssen die auch alle Geld verdienen, weil irgendwie müssen auch die Entwickler bezahlt werden und muss da jeder ein vernünftiges Businessmodell finden, was sowohl die Kunden zufrieden stellt, weil das ist ja die Konsequenz, wenn ich diese Lizenzänderung mache und mir laufen alle Kunden weg, habe ich natürlich auch ein gewisses Risiko. Es ist jetzt nicht so, dass das Gott gegeben ist, nur weil ich die Lizenz ändere, dass ich da auf einmal viel mehr Geld mit mache, sondern

Was stellt meine Kunden zufrieden? Und auf der anderen Seite, je nachdem ob ich Börsen oder Investoren getrieben oder, was stellt meine Stakeholders, andere Stakeholders da Und ich das ist immer noch schwierig da eine gute Balance zu treffen, aber was man auf der anderen Seite sieht ist, es wird ja immer mehr Software, die früher auch nur proprietär zur Verfügung stand, gibt es heutzutage Open Source Alternativen.

zu sagen, okay, das Open Source Modell ist tot, ist, glaube ich, auch total der falsche Ansatz, weil da zeigen die Sachen eher in die andere Richtung, dass man guckt, mehr und mehr Software davon wird heutzutage Open Source bereitgestellt, insbesondere auch so Business Software, die es früher nur als proprietary oder SaaS-Lösungen gibt, wo es heute auch SaaS-Lösungen gibt, die auf Open Source-Basis basieren oder komplett Open Source-Lösungen.

Also ich glaube, das Spannendste dass da passieren viele Experimente im Moment. Also einige von diesen Firmen haben das ja auch wieder zurückgedreht und sind dann wieder in eine andere Richtung gegangen. meine Interpretation ist, dass oft sind die einfach mit der coolen Lösung erstmal an den Markt gegangen und wollten die offen stellen. Und das Ding hat dann so viel Traction bekommen, sozusagen, dass man einfach sagt, okay, hier ist es groß geworden, jetzt muss man ein Businessmodell nachbauen oder außen rum bauen.

Und das ist das, was dann oft schwierig ist, das Rad dann dreimal zurückzudrehen. Eine andere Möglichkeit, wie man zur Open Source beisteuern kann, ohne zu bezahlen, ist, dass man Entwickler nimmt und sie entwickeln lässt für das Open Source Produkt. Das macht ihr auch. Ihr commited Upstream zu Kubernetes zum Beispiel oder seid sehr involviert in KCP. Wie organisiert ihr denn die Arbeit? Also ihr bekommt auf der einen Seite Rückmeldung von der Community. Dann habt ihr Leute, die...

selbst an ganz anderen Projekten tagtäglich arbeiten und wie steuerst du das, wie priorisierst du diese Themen oder machen die Entwickler das selbstständig bei euch? Wie läuft das?

Ja, so oftmals sind da unsere Entwickler schon mal sehr selbstständig. Wir gucken natürlich die Themen, die wir selber treiben, sei es in unserem Open Source, aber auch irgendwie im Open Source, in Foundation liegt, dass es Mehrwert für uns generiert, also dass wir jetzt nicht an irgendwelchen Features arbeiten, wir sagen,

Das brauchen wir überhaupt nicht, sondern das sind Themen, wo wir sagen, das hilft uns auch. Entweder in unserem Daily Business bei der Entwicklung oder das hilft unseren Und unterstützen in solchen Projekten, wo wir auch ganz klar einen Mehrwert Oftmals ist es eben die Entwickler bei uns, ich sag mal jetzt, source arbeiten, was in der Foundation liegt.

Da ist keiner bei, irgendwie 100 % nur da drauf arbeitet, sondern auch immer nah am Produkt arbeitet. Es gibt natürlich welche, die arbeiten mehr am Open Source Foundation als am Produkt, vice versa. Versuchen da aber schon, jedem bisschen Zeit einzuräumen. Aber natürlich müssen wir gucken, dass es auch Mehrwert für uns generiert. Aber das bringt es ja, wie am Anfang auch ohne Open Source,

und und und und. Wenn wir glaube ich, wenn viele von uns nicht hier sondern allein schon Produkt oder Projekt her, es vielleicht überhaupt nicht geben oder man müsste viel mehr selber bauen.

Auf jeden Fall. Wenn ich jetzt jemand bin, der hat ein Open Source Produkt selbst schon gelauncht oder maintainten Repo oder findet ein Produkt sehr gut und möchte ein Business starten rund ⁓ dieses Open Source Produkt, hast du ein paar Tipps für den, wie man da am besten starten kann, auf was man achten muss? so eine gute, also ist es eher machen oder lass lieber die Finger davon und wenn machen, das wären dann so paar Tipps, du hier oder

ein, zwei Tipps, du gerade aus der Hand mitgeben kannst.

Natürlich erstmal auf jeden Fall machen, also ausprobieren, weil sonst weißt du nie, ob es hinterher erfolgreich war oder nicht. Ich glaube, hängt so bisschen, was genau, hängt so ein bisschen davon ab, was das Open Source Projekt ist. Ist es eher für Entwickler oder wer ist eigentlich die Target Persona, die dieses Ganze nutzt.

Aber wenn man es dann eben auch kommerzialisieren oder sagen will, ich will ein Business drumherum bauen, zu überlegen, was ist eigentlich ein gutes Businessmodell? Kann ich das Ganze als irgendwie Saas-Offering anbieten oder mache ich so ein Open-Core-Modell, habe Enterprise-Features, die da drin, die in der Enterprise-Version nur drin sind? Ich glaube, da wirklich auch zu überlegen, wie ist da mein Modell?

Natürlich kann man nie garantieren, dass das erste Modell das Richtige oder das Beste ist. Aber natürlich, je weniger Änderungen ich da habe, insbesondere wenn es dann irgendwie an Lizenzen oder so gehe, je weniger, ich sag mal, mehr Open Source machen, ist immer einfach, restriktiver hinterzuwerden. Sei es bei Lizenzen oder bei Sachen, irgendwie früher mal im Open Source Code sind, ist immer schwieriger und man muss mehr argumentieren, weil natürlich dann die Erwartungshaltung, das war ja mal frei.

Probleme gibt in der Community, da muss ich natürlich dann ganz gut gucken, wie argumentiere ich das. Aber auch da haben, glaube ich, schon mehrere Beispiele gezeigt, selbst wenn man gesehen hat, okay, ich muss das irgendwie besser konvertieren oder kommerzieller machen, dass es da auch andere Wege gibt. Aber ich glaube, da ist wirklich einer der Punkte, frühzeitig zu überlegen, wie kann ich das gut kommerzialisieren und dann hoffentlich am Anfang schon einen guten Weg gefunden zu haben.

Das heißt, Anfang an die Businessbrille mit aufsetzen. Aber wenn es den meisten Techies dann erstmal ein bisschen schwerer fällt, schon zu überlegen, wen adressiere ich hier und wie kann ich mit dem Produkt oder dem Projekt dann auch Geld verdienen. Ja, sehr spannend. Danke für deine Einschätzung. Jetzt mal ein kleiner Schwenk. bist ein Boardmember der CNCF. Was macht ein Boardmember der CNCF? Die Cloud Native Computing Foundation ist ein Subset von der Linux Foundation.

Was machst du da?

Genau, also ich bin im CNCF Governing Board. Im Endeffekt, wir sind Silvermember und repräsentiere mit drei weiteren, alle Silvermember, was quasi die Mehrheit der CNCF Mitglieder ist. Was für mich da wichtig ist, auf der einen Seite diesen eine Stimme zu geben, insbesondere auch den europäischen und kleinen Unternehmen eine Stimme zu geben, weil

Was wird in dem governing board gesprochen? Grobe Richtungsentscheidungen, in welche Richtung der CNCEF in Zukunft geht. Und das ist natürlich auch immer wichtig, dass da nicht nur die ganz Großen mitreden, sondern dass man da auch zumindest versucht, das Gehör zu verschaffen und zu sagen, geht in, aber habt ihr bedacht für die kleinen und oder mittleren Unternehmen? Wir sehen das aber anders, weil wenn man sich guckt, ja.

Wo vielleicht nicht die Mehrzahl, aber wo sie viele Leute auch beschäftigt, ist es doch trotzdem auch noch bei vielen kleineren, mittleren Häusern und nicht nur bei den großen, die da contributen und auch das Ganze hinterher einsetzen, mitentwickeln und und und und und genau, denen allen auch eine Stimme zu geben und zu sagen, hey, es gibt uns und es sind nicht nur die Großen, sondern

Wir wollen da tatkräftig mitarbeiten und wir arbeiten auch mit, aber wir wollen entsprechende Sichtbarkeit auch haben.

Ja, spannend. CNCF ist mittlerweile schon ziemlich groß geworden. die Landscape, da gibt es ja so ein Bild, die alle Produkte dort mit umfasst. Wie navigierst du da durch oder wie navigiere ich da am besten durch? Wie überhältst du den Überblick dort? Weil wenn du da mit einer Governance ausführst, ist ja schon eine Menge, dort tagtäglich wieder dazukommt und im Lifecycle sich verändert.

Ja, absolut. da ändert sich natürlich relativ viel oder die Landscape ist jetzt natürlich eine ganz andere als vor fünf Jahren oder so. Ich glaube, es kommt immer so bisschen auf die Problemstellung an und ich glaube auch da, dass zum Beispiel wo kommerzielle Hersteller eben helfen können, zu gucken, okay, wie packe ich das Ganze entsprechend zusammen, weil ja, es ist schwierig, da immer den Überblick zu behalten bei den ganzen neuen Projekten, aber auch nicht jedes Projekt wird erfolgreich.

Ich glaube, da muss man sich immer auch bisschen überlegen, was sind eigentlich gerade die Problemstellungen, die ich habe? Wie weit, was mache ich da? Gibt es da schon Projekte? Starte ich vielleicht auch ein komplett neues Projekt, um das Ganze nach vorne zu treiben? ja, regelmäßig, ich meine, die CNC informiert auch, regelmäßig auf den Seiten unterwegs sein, gucken, welche neue Projekte gibt es, um einfach up to date zu bleiben?

und zu gucken, was für neue Projekte gibt es da, welche sind aktiv und und und und. Aber da muss ich auch eingestehen, es gibt immer auch wieder Projekte, wo ich drüber stoppe und denke, ach guck mal an. Das ist im CNC für immer noch nie gehört. Also von daher, ich glaube, ist auch unrealistisch zu sagen, man kennt jetzt alle Projekte, die da drin sind, sondern wirklich die, die einem weiterhelfen. Und dafür ist ja eben auch diese

Landscape da, dass man da relativ einfach durch navigieren kann und sagen kann, okay, was gibt mir denn jetzt eigentlich einen groben Überblick? Was sind denn so die fünf, zehn Projekte in dem Scope, wo ich gerade unterwegs bin? Und welche sollte ich mir vielleicht mal angucken? Oder welche habe ich auch schon gehört und welche habe ich noch nie gehört, wo ich mal drauf gucke, okay, wo stehen die, was machen die? Sind die nah an dem Problem dran, was ich eigentlich lösen will oder?

Hört sich dann die Überschrift in die Richtung an, aber wenn ich mir den Text ein bisschen durchlese, denke ich, weiß ich sofort, okay, nee, vergleitbare Problemstellung, aber komplett anderer Lösungswege und es passt nicht.

Ja, also mit Sicherheit Landscapes riesen gewachsen, auch wenn man bei der QCon ist. Man sieht diese, ihr habt da Riesenhallen, die ihr füllt und es wird immer größer und größer. Wie stellt ihr denn von der Governance-Seite oder aus der Boardsicht, dass sicher, dass die Kommerzialisierung euch da nicht irgendwie auffrisst, dass ihr euch treu bleibt und dass ihr dann doch noch das weiterhin spiegelt, womit ihr gestartet seid?

Die Foundation ist natürlich sehr wichtig und sehr nützlich für viele, haben echt schon eine gute Grundlage gebracht. Wie habt ihr das so auf dem Schirm oder ist das überhaupt ein Thema für euch?

Das Wichtigste ist, glaube ich, erstmal schon mal, dass die Foundation neutral ist. Also es gibt da keinen Kingmaker, wie sollte man so schön sagen. Also auch bei Projekten ist es nicht die Linux Foundation oder die CNCF, die final entscheidet, okay, das ist das Projekt, was quasi für diesen Bereich gewinnen soll, sondern es müssen schon die Projekte selber zeigen, welcher Use-Case oder warum sie vielleicht besser sind, gegen bei anderen Projekten.

Das Ganze erzeugt natürlich auch gewisse Wachstumsschmerzen. Aber man sieht eben auch, ich glaube, das ist ganz gut ausbalanciert. Natürlich gibt es auf der einen Seite, wenn man sich die KubeCon anguckt, die riesen Hallen mit den kommerziellen Ausstellern. Aber auf der anderen Seite sind die Talks sehr neutral und die Talks beziehen sich rein auf Open Source Projekte. Also ist jetzt nicht so, dass da...

in den Talks zum Beispiel ein Hersteller nach dem anderen ihre Produkte pitchen, sondern wirklich neutral. Aber wenn ich mir dann sage, okay, hey, ich will mir jetzt auch einen Überblick machen, wenn ich Support brauche oder wer kann mich denn da kommerziell unterstützen, gibt es natürlich den Sponsorbereich, wo dann wieder die Experten sind, an die ich mich wenden kann und sagen kann, okay, hey, ihr habt doch da schon mal was gemacht, wie kann das bei mir aussehen, sei es über Consulting oder aber auch Produkte.

Und am Ende des Tages muss auch dort Geld verdient werden. Also wir brauchen dann die Sponsoren dort auch, das Thema mit voran treiben und das ermöglichen. Ja, was spannend war, gerade auf der letzten KubeCon hat man gesehen, dass Europa sehr stark auch im Contribution-Bereich vertreten ist. Also dass wir eine starke Präsenz haben dort, wo wir mit beisteuern zu den Projekten. Was manchmal so bisschen untergeht, man denkt immer, es passiert alles in Amerika.

Aber Europa ist dort stark vertreten. Hilft das uns so ein bisschen jetzt in dem Zeitalter der digitalen Souveränität dort auch stärker zu sein? Müssten wir da eigentlich noch bisschen stärker Marketing betreiben, einen Buzz draus machen?

Genau, also ich glaube, was uns hier insbesondere fehlt, ist unser Vertrauen in unsere eigenen Fähigkeiten, weil von der Entwicklung her haben wir das Wissen, glaube ich, oder haben wir vergleichbares Wissen. Was in den USA einfach mehr gibt, ist Risikokapital. Die gehen auch an Themen ganz anders ran, so etwas hoch zu skalieren. Aber auch im Open Source Umfeld schaffen sie einfach mehr Sichtbarkeit, wo wir, glaube ich, hier in Europa

mehr in die Details arbeiten und gar nicht so sehr gucken, wie machen wir das Ganze sichtbar. Ist jetzt plakativ gesagt und trifft sicherlich nicht auf alle und für jeden. Aber ich glaube, da müssen wir auch einfach alle noch mehr lernen zu sagen, okay, wir haben das Wissen, wir kennen uns da aus und wir sind jetzt nicht nur von den großen Herstellern abhängig, die aus Amerika kommen, auch wenn die es Open Source entwickeln, sondern

Es ja auch viele hier in Europa, die sowas machen und aber auch viele große amerikanische Hersteller haben ja hier in Europa große Entwicklungszentren, weil sie eben auch sehen, dass hier doch relativ viel Talent in dem Bereich gibt.

Also, wie gesagt, wo die Leute die Experten sind, einfach die Technologie vielleicht den Mittelpunkt stehen und nicht so sehr die Länder und die Grenzen und die Community stärken. Sprichwort Community. bist in der CNCF quasi da schon mit im Board richtig tief drin. Aber du hast auch sehr viel für die deutsche Community getan. Ihr habt ein

Event sozusagen, alles im Leben gerufen, die Container Days, wo ihr gar nicht so sehr als Kubermatic auftretet, was so eins der zentralen Container- und Kubernetes-Events ist. Wie kam es dazu? Was war die Idee?

Genau, also relativ am Anfang haben Julian und ich mich eben gefragt, okay, wo sind eigentlich die ganzen Leute, diese Container und Kubernetes machen? Weil wenn wir in unserem Netzwerk herumgefragt haben, haben da viele gesagt, machen wir nicht, wir machen gerade VMs oder wir gehen gerade in die Cloud, aber mit Containern und Kubernetes beschäftigen wir uns gar nicht und sind erst angefangen, Meetups zu machen, haben dann aber gesehen, ja, die lokalen Communities.

die kennen sich hinterher noch ganz gut, also die Hamburger kennen die Hamburger, die Berliner die Berliner, aber auch dass zum Beispiel Hamburg und Berlin nur anderthalb Stunden im Zug auseinander sind, findet der Austausch quasi nie statt und haben uns dann eben überlegt, wie kann wir denn hier den Austausch besser stattfinden und sind dann eben auf die Idee gekommen, können wir nicht da eine Konferenz so machen und wollten

immer so bisschen, ja nicht so eine klassische Konferenz im Hotel machen, sondern eher oder im Konferenzcenter, sondern haben damals dann gesagt, okay, lass uns coole Location finden, waren dann jahrelang im Hafen unterwegs in verschiedensten Locationen, sind jetzt auf dem Kampnagel in Hamburg, was eigentlich ja normalerweise ein Theater ist, aber was früher mal eine

Produktionshalle war, wo unter anderem Schiffsmotoren produziert wurden und gucken eben auch immer, dass so das Gesamtbild interessant ist für alle und nicht einfach nur noch eine neue Konferenz, sondern wirklich auch da die Community Gedanken im Zentrum zu stellen, also deswegen auch nicht irgendwie Kubermatic Days oder irgendwie sowas, sondern wirklich zu sagen, hey, wir wollen da die Community zusammenbringen.

⁓ sich da einfach auszutauschen, sich da hier in Deutschland und auch so bisschen darüber herum auszutauschen und zu sagen, neben der KubeCon hat man noch einen zweiten Anlaufspunkt hier in Europa, wo man hingehen kann und sagen kann, ja, lass uns mal austauschen, lass uns mal sprechen, weil ich glaube, das das Wichtige, dass man auch mal Erfahrungsberichte von anderen hört, sei es auf den Talk selber, aber eben auch die Gespräche.

Ja, die Nebengespräche nehmen bei, dass man andere trifft, die sagen, hey, wir haben das gleiche Problem. Wie habt ihr das denn gelöst? Weil alles, gut geht, man ja relativ oft dann, aber dass man eben auch mal herausfindet, was für, was hat nicht so gut funktioniert, ⁓ aus diesen Fehlern von anderen auch bisschen zu lernen.

Ja und der Netzwerkauspekt sollte nicht zu kurz kommen dort. Raus aus den Discords, trefft euch persönlich. Also ich finde die Idee sehr gut. Ich finde es auch persönlich immer sehr spannend, sich in Konferenzen da auszutauschen. Ihr habt ja wirklich geschafft auch dort richtige Größen aus der Szene zu bekommen. Ihr habt Kelsey Hightower für eine Keynote gehabt. Ich persönlich höre ja Kelsey Hightower sehr gerne. Ich habe auch sehr viel von seinen Talks verfolgt.

hat ja, ist ja einer der Pfade sozusagen dort gerade auch im Automatisierungsthema für uns bereitgestellt hat. Wie ist es denn so mit Kelsey, sich auszutauschen? Was ist das denn für ein Typ, wenn mit ihm spricht?

Das ist natürlich schon sehr interessant. meine, kennen, dadurch dass wir in diesem ganzen Cloud-Native-Kybernesium- Umfeld schon sehr lange unterwegs sind, kennen Kelsey schon relativ Aber was ich an ihm absolut schätze, auf der einen Seite sein breites Wissen. Ich glaube, den kannst du heute auf der Bühne stellen und sagen, hier ist das Thema und er fängt ja darüber an zu sprechen. Das ist schon interessant, was er da alles...

für ein Wissen aufgebaut hat, auch wie schnell er solche Sachen umsetzen kann. Aber auf der anderen Seite ist er ein ganz normaler Techie wie du und ich. Es ist auch immer schön, irgendwo an der Seite zu treffen und er nimmt sich auch die Zeit, sich mit jedem zu unterhalten. Ich glaube, das macht ihn auch so nahbar, sodass die Leute ihn auch lieben. Er kann, glaube ich, ganz gut erklären, diese Themen. Hat ein ganz gutes Talent für ...

sodass die Leute auch wirklich gerne zuhören, was er da erzählt und wie er das Ganze rüberbringt.

Ja, also das finde ich auch so sein Hands-on-Mentalität. Also dem hört man gerne zu und der bringt es wirklich praxisnah bei. Wenn du jetzt Zugriff auf solche Leute in der CNCF auch hast, die quasi auch teilweise Advisor sind für andere Firmen, sprecht ihr da auch über das Business? Holst du dir auch mal hier und da oder tauscht ihr euch da auch auf einer anderen Ebene aus? Oder sind das jetzt rein einfach solche Sachen, komm, mach mal einen Talk hier, mal einen Impuls oder gehst du da auch ein bisschen tiefer?

Man unterhält sich sicherlich, also zum Beispiel, was sind neue interessante Trends, Tools und und und und. Einfach mal, auch zu hören, okay, was sehen denn die anderen, also was treibt die anderen, glauben sie, wo die Reise hingeht? Dieselben Fragen kriege ich zurück, einfach auch mal zu sehen, okay, was sind deren Sicht darauf? Ich glaube, da merkt jeder auch so bisschen, okay, passt meine Sicht auch mit den Sichten, die andere auf das Thema haben oder?

gibt es vielleicht auch Themenbereiche, die man noch gar nicht so auf dem Schirm hatte, wo man sagt, ja, guter Punkt, habe ich noch nie gehört oder ja, habe ich vielleicht schon mal gehört, aber in dem Kontext sollte ich mir vielleicht mal näher angucken und dann Entscheidungen zu treffen, okay, macht das Sinn, sowas zum Beispiel in Produkt zu integrieren oder wie steht man zu dem Thema oder, oder, oder, also von daher, ja, ich glaube generell ist das eins der wichtigsten Themen.

für mich immer auf der CubeCon, sich mit Leuten auszutauschen, gar nicht so sehr die Talks zu Die Talks sind interessant, aber wirklich auch zu sehen, im direkten Gespräch, was sagen andere, wie sehen sie Themen, was für Herausforderungen sehen sie, auf den Markt zu kommen, auf das Thema zu kommen oder auch welche neuen Lösungsansätze gibt's.

Spannend. Die Videos kann man oft im Recording dann schauen. Und das Netzwerk oder den Zugang zu den Persönlichkeiten, dann mal gegenseitig auszutauschen. Mal die Industrie ein bisschen zu fühlen, wie die gerade so tickt. Das macht auf jeden Fall Sinn. Wie würdest du das denn persönlich einschätzen, wenn jemand jetzt in einem Unternehmen ist oder irgendwie gerade ein Open-Source-Projekt hat? Wie wichtig ist es denn, solchen Konferenzen teilzunehmen und auch einen Talk zu geben? Oder sagst du, okay, ich

würde jetzt meine eigenen Mitarbeiter rausschicken, ... macht mal einen Talk oder zeigt euch, ... oder ist das hier so eine Sache, ... ... die du heutzutage nicht mehr als Wichtiger kennst.

Ich glaube, es ist extrem wichtig, weil auf der einen Seite lernen ja viele über den Talk und ich glaube, seinen Erfahrungsbericht zu erzählen, was man damit gemacht hat, ist immer sehr interessant. Ich glaube, es so bisschen darauf an, welchen Ruder man aufkommt. Man eher von der Herstellerseite oder End-Userseite. Aber ich glaube, beide können da wirklich Mehrwert bringen und auch interessante Themen.

erzählen. Ich glaube, bei Endusern insbesondere so das Thema, okay, wie setze ich das ganze Thema ein? Was sind die Vorteile? Was hat nicht funktioniert? Was funktioniert gut? Damit andere davon auch lernen können, einfach auch diesen Erfahrungsaustausch zu machen und zu sehen, okay, guck mal, Company ABC, die machen das. dann vielleicht auch hinterher zu dieser Position hinzugehen und zu sagen, hey, lass mal reden, wie macht ihr das? Kann man da vielleicht auch

bei der Konferenz, aber vielleicht auch im Nachgang eine kleinere Community, größere Community das Thema herumbringen und sagen, hey, lass uns das Thema noch mal weiter nach vorne bringen oder einfach einen Erfahrungsaustausch zu machen. Also von daher glaube ich, ist das Ganze aus vieler seiner Hinsicht interessant, sei es auch aus Recruiting Perspektiven. Ich glaube, viele gucken eben auch, okay, was macht man da? Welche Informationen geben die schon von sich preis? Und ich glaube, es ist

Gerade der Infrastrukturlayer, der ist jetzt nicht so spannend, dass ich sagen kann, okay, da kann ich nicht drüber reden, weil da ist eben viel, was doch viele vergleichbar machen, dass man da sagt, okay, Secret, Secret, Secret, sind meine Cronjuwelen. Ich glaube, das ist bei den wenigsten, weil sonst dürften so Companies wie eine Google oder so auch über teilweise solche Themen nicht reden, weil die natürlich da...

Hm.

das eine der Kernbusiness Cases ist und ich glaube da kann man nur von Partizipieren in mehrererlei Hinsicht und sei es seine Mitarbeiter zu motivieren, weil sie Lust haben auf eine Konferenz zu gehen und zu sagen, ich möchte gerne Talks machen und ihnen die Möglichkeit zu bieten und dadurch ja Motivation zu schaffen.

Also ich sehe es genauso. Die Sichtbarkeit ist wichtig. Man bekommt auch ein interessantes Feedback. Also oft sind es eher sehr willkommen, dass man merkt, okay, ich bin nicht der Einzige, jetzt in diesem Thema interessiert ist oder der Einzige, der das Problem hat. Man respektiert sich auch untereinander, gerade in unserer Szene sehr. Und ich glaube auch, dass es ganz wichtiges Instrument ist, auch zu zeigen, an was man gerade arbeitet und das zu teilen. Apropos teilen.

Ja,

genau, also ich glaube, was da nochmal wichtig ist, natürlich wenn ich versuche, irgendwie auf der CubeCon und so einen Talk unterzubringen, die Konferenz ist so überlaufen, ich weiß gar nicht, zehn-, zwanzigfach mehr Talks, als dass sie eigentlich Plätze haben, also massiv. Aber eben auch gucken, was gibt es neben den großen Konferenzen, also es gibt ja auch viele Meetups von das Thema und so weiter, aber eben auch für Leute, die sagen, hey,

Ich weiß nicht, ob ich sofort auf so einer riesen Bühne stehen will. sind glaube ich kleinere Konferenzen und am Mittag ist ein ganz guter Startpunkt, zu sagen, hey, guck mal, da fange ich erst vor 30, 50 oder 100 Leuten an und kann erstmal Erfahrungen sammeln und sagen, okay, ist das was für mich, mache ich das gerne oder stelle ich dann fest, okay, nee, über das Thema sprechen, das soll man lieber andere machen, das mache ich nichts für mich.

Sehr guter Hinweis noch mal. Also erst mal antesten in kleinen Bereichen und gucken, ob das was Fein ist, weil nicht jeder ist dafür gemacht, auf der Bühne zu stehen. Ja, super, danke dir. Stichwort Container Days. Wann finden die nächsten Container Days statt?

Genau, im September und zwar 9. bis 11. September in Hamburg auf dem Kankennagel. das Agenda ist schon raus. Dieses Jahr ist auch Kelsey wieder dabei, aber auch viele andere interessante Speaker. Ja, wir freuen uns, von euch da zu treffen. Ich glaube, es wieder eine ganz interessante Konferenz.

sehr schönen Link werden wir in die Show Notes mit aufnehmen, auch die Agenda. Sebastian, wir haben jetzt über eine Stunde gesprochen zusammen. Es war sehr interessant, sehr spannend. Vielen Dank, dass du dein Wissen mit uns geteilt hast, gerade auch in dem Thema, wie baut man eine Company auf im Open Source Umfeld. Sehr interessante Kenntnisse auch, wie sucht man das Business Modell aus. Wenn jemand mehr von dir sehen, hören will, sich mit dir austauschen will, wo findet man dich, in welchen sozialen Medien.

Oder wie kann man dich am besten kontaktieren?

Besten auflingen, Sebastian Scheele suchen und Kubermatic, da findet ihr mich und einfach eine Anfrage stellen und dann gerne da austauschen. Das ist glaube ich der einfachste und schnellste Weg.

Alles klar. Werden wir auf jeden Fall in den Show Notes mit verlinken. Ich danke dir noch mal recht herzlich. Es hat mir super Spaß gemacht, dass du dabei warst. Es war sehr interessant und an alle anderen auch danke, dass ihr zugehört habt. Und schreibt gerne in den Kommentaren, wie ihr das fand. Wollt ihr mehr aus der Infrastrukturebene, mehr über Open Source und Cloud Native Foundation hören? Lasst es mich wissen, gebt mir Rückmeldungen. Und ansonsten Dankeschön, dass ihr dabei wart und bis zum nächsten Mal. Ciao.

Tschüss!