Ein Cloud-Stack aus Open-Source Vanilla-Komponenten

Interview mit Kim-Norman Sahm 

 

The cloud report hatte die Gelegenheit, mit Kim-Norman Sahm von Cloudical über die Entwicklung von Cloud Computing, Open Source und Kundenfreiheit zu sprechen. 

 

Hallo, schön, dass Du Dir Zeit nimmst! Stell Dich bitte selbst vor und erzähl uns, was Du machst. 

Sehr gerne. Ich bin Kim und CTO der Cloudical. Cloudical ist, oder war vielmehr, eine Beratungsfirma für Cloud und cloud-native Technologien sowohl auf der Trainingsebene als auch in der Konzeption und technischen Umsetzung. Und ich sage ganz bewusst „war“, wir transformieren gerade die Company von der reinen Beratungsfirma hin zur Product-Company. Wir haben die letzten Monate an Produkten gearbeitet und werden unsere Produktpalette erweitern, sodass wir neben der Beratung und dem Training- und Enablement-Geschäft auch Managed Services und den VanillaStack anbieten. 

Okay… Was ist denn der VanillaStack? 

Der VanillaStack ist eine Sammlung von Vanilla Open Source Produkten, keine durch einen Distributor gebrandeten Versionen von z.B. Kubernetes, OpenStack, Cloud Foundry, die wir in einem einfach zu deployenden Framework zusammenfassen, was dem Anwender auf einfache Weise ermöglicht, komplexe Tools wie eben Kubernetes, eine IaaS-Plattform wie OpenStack und Storage u.s.w. über einen Webinstaller zu deployen. Wir sehen bei unseren Kunden häufig den Wunsch, diese Tools einzusetzen, das Deployment der Tools ist auch eigentlich nicht die Schwierigkeit, es geht eher darum: Ich habe diesen Zoo von diversen Tools für Operation, für Logging, für diese ganzen Second Day Operations Themen, und muss diese händeln. Und das wollen wir dem User möglichst vereinfacht bereitstellen: Eine einfache und nahtlose Integration der vielen Komponenten, sodass man am Ende eine Lösung hat und nicht den Zoo von vielen Tools.  

Das klingt interessant. Gerade weil diese Open Source Tools von verschiedenen Communities, zum Teil auch von Foundations getrieben werden und die eigentlich nicht darauf angelegt sind, so nahtlos miteinander zu funktionieren. Ist das kompliziert? Oder wie funktioniert das? Wie kann man die zusammenbringen? 

Kompliziert ist immer relativ. Die Basis für unseren Stack ist Kubernetes. Wir betrachten Kubernetes als unser Operating System und sagen, was drunter ist interessiert uns eigentlich nicht, da muss ein Linux Kernel vorhanden sein, da muss eine Container Runtime da sein, und dann sind wir in der Lage obendrauf per Ansible unseren Stack auszurollen.   

Basis ist, wie gesagt, Kubernetes, alle unsere Workloads sollen nur noch containerisiert ausgerollt werden. Das macht das ganze Handeling, das Deployment, das Upgraden einfacher. Der Kunde setzt genauso auf Kubernetes auf, er kann entscheiden, welche Funktionen er haben möchte. Reicht ihm eine reine Container-Plattform? Dann kann er noch sein Tool-Set dazu deployen z.B. in Prometheus, Grafana für Monitoring, oder der typische EFK-Stack für Logging, das sind die Sachen, die im Basis-Paket mitkommen. Und dann sind Erweiterungen möglich wie GitLab oder andere CI/CD-Tools, im Bereich Storage binden wir Rook ein. Rook = Ceph auf Kubernetes, da ist Cloudical auch Maintainer von.   

Auf diese Weise kann der Kunde sein Framework zusammenstellen, nach seinem Bedarf. Das Ganze ist vordefiniert, das Ganze ist integriert und wird auf automatischem Weg ausgerollt. 

Wir betrachten aber nicht nur die reine Container-Plattform. Es gibt ja auch Kunden, die einen anderen Anwenderfall haben, denen Container oder CaaS allein nicht reicht. Diese brauchen vielleicht Iaas, vielleicht eine PaaS-Platform.  

Bei PaaS haben wir uns für Cloud Foundry entschieden, da man das auch sehr stark im Markt sieht, gerade durch Pivotal oder die SUSE, die mit CAP gerade in den Markt eingetreten ist. Wir integrieren aber die Vanilla Cloud Foundry Lösung in den Stack.  

Für IaaS-Kunden integrieren wir OpenStack, was meine eigene Home-Base ist. Wir setzen auf dem OpenStack HELM Projekt auf, integrieren den containerisierten OpenStack-Stack in unseren VanillaStack und ermöglichen dem Kunden so, auf Basis der Container-Plattform z.B. auch seine IaaS-Plattform bereitzustellen. Da kommt Ceph mit, da kommt OpenStack.   

Und dann können wir auf diesem Stack wieder mit anderen Workloads aufsetzen. 

Sodass wir einfach fragen, warum musst Du Dich entscheiden, ob es ein Container-Stack oder eine IaaS oder PaaS werden soll? Wir sagen: Hier ist ein Installer für alles. Wähl Dir einfach aus, was Du brauchst und deploy es.  

Und das alles allein basierend auf Open Source Produkten? 

Das alles auf Open Source. Wir setzen bewusst nur auf Open Source Produkte für unseren VanillaStack. Wir contributen auch wieder in die Open Source Projekte zurück. Die Produkte werden von uns auch nicht groß angefasst. Wenn es Anpassungen gibt, dann werden diese den Communities auch zur Verfügung gestellt, sodass die in das Basis-Projekt mit einfließen.  

Das heißt, alles, was Ihr in dem Bereich dann auch entwickelt, wird zurück in die Communities gegeben, sodass da dann auch weiter mitentwickelt werden kann

Genau, das ist alles Open Source. Wir spielen alles zurück in die Communities, unsere Eigenentwicklungen werden als Open Source bereitgestellt. Wir wollen dieses Produkt nicht verkaufen, wir bieten Professional- und Managed Services dafür an. Wir bieten auf Basis dieses Stacks Supportleistungen und Managed Services an, wenn der Kunde das möchte, wie es andere Open Source Projekte auch machen.  

Wahrscheinlich bietet Ihr ggf. auch Anpassungen an, oder? 

Genau. 

Das klingt ein bisschen wie eine Open Source Cloud. Warum glaubt Ihr, dass das der richtige Schritt ist?  

Wir sehen, Open Source ist das, was die Leute wollen, und wir sehen die Zukunft in Open Source, in der Gemeinschaftlichkeit. Und gerade jetzt, wo der Europäische Gerichtshof das Privacy Shield gekappt hat zwischen Europa und den USA.  

Es wird immer wichtiger zu wissen, wo sind meine Daten, wer geht wie mit meinen Daten um und was macht die Software mit meinen Daten? Bei allem, was ich proprietär einkaufe, muss ich auf den Softwarehersteller vertrauen, dass der mir sagt, diese Daten bleiben wirklich in meinem Data-Center und werden nicht durch irgendeinen Vektor am Ende doch in die USA gesynct.  

Bei Open Source kann ich jederzeit den Quellcode einsehen, ich kann selber meine Änderungen integrieren, ich habe die Sicherheit, Gewissheit, was die Software wirklich macht. Das sehen wir als großen Vorteil.  

Es gibt diverse andere Unternehmen, die sich auch Open Source auf die Fahne geschrieben haben, große Distributroren, die Open Source machen und die Ergebnisse auch wirklich zurück in die Communities bringen, da ist dann oft der Fokus darauf, dass man die Open Source Software an seine eigenen Business-Anforderungen anpasst.   

Von daher sagen wir, wir wollen Vanilla bleiben, wir wollen das nutzen, das die Communities liefern, wir wollen den Code nicht groß verändern, um ihn an unsere eigenen Bedürfnisse anzupassen. Wir wollen eigentlich der Community und dem Kunden sagen: Du willst Vanilla? Hier sind die Tools, hier ist ein Framework, das Dir ermöglicht, diese Vanilla-Tools auf einfache Weise zusammen zu deployen. Es ist am Ende aber trotzdem das Vanilla-Produkt. Es ist am Ende Vanilla-Kubernetes, der aus dem Kubernetes-Branch kommt. Es ist am Ende Vanilla-OpenStack, den die OpenStack Gemeinde entwickelt. Wir haben Vanilla-Cloud Foundry dabei und alles andere, was zu dem Zoo gehört.  

Das heißt, letztendlich fallen keine Lizenzgebühren an und man kann sich ggf. auch Hilfe aus den Communities holen? 

Genau. 

Das klingt so, als ob es noch nicht dagewesen ist. Das ist ein spannender Schritt von Euch. 

Uns ist auch wichtig, dass das nicht ein weiteres Tool ist, um Kubernetes auszurollen, es ist nicht ein weiterer Installer, um eine Kubernetes-Distribution auszurollen. Wir wollen das Installations-Framework schaffen, um Open Source auszurollen, die Kombination aus Kubernetes, Cloud Foundry, anderen Open Source Solutions, alles auf Basis von Kubernetes.  

Da bin ich gespannt, was noch kommt. Bisher sind das ja noch Pläne, aber Ihr wollt das launchen. Habt Ihr schon einen Termin, wann Ihr damit rauskommen wollt? 

Es soll am Geburtstag unserer Company im September, am 17. September rauskommen. Und es wird groß, es wird was Großes kommen. Und dadurch, dass es Open Source ist, sind alle herzlich eingeladen, daran mitzuwirken, mitzucontributen, eigene Ideen reinzubringen, was ggf. auf die Roadmap draufkann, was für Funktionen gefordert werden. Es soll ganz explizit keine Cloudical-only Lösung werden. Es ist entwickelt als Open Source Projekt, es ist gestartet als Open Source Projekt und wir wünschen uns das Mitwirken anderer Unternehmen, anderer Contributoren, dass wir das gemeinsam gestalten und gemeinsam groß machen. 

Sehr spannend! Vielen Dank für die ersten Einblicke. 

Sehr gern.      

Cookie Consent mit Real Cookie Banner