Transcript
Torsten:
[0:37] Hallo und herzlich willkommen zur 129. Ausgabe des e-Government Podcast.
Ich bin Thorsten Frenzel und heute habe ich das Thema Server and Cloud Stack mir ins Studio geholt und da ich das nicht alleine kann, habe ich mir natürlich da Experten eingekauft.
Hallo Alex.
Alexander:
[0:57] Hallo Thorsten.
Torsten:
[0:59] Alex, vielleicht stöß ich mal ganz kurz vor, wer du bist und was du mit dem Server and Cloud Stack zu tun hast.
Alexander:
[1:05] Ja, sehr gerne. Ich fange mal an, erstmal wer ich bin und was mein Werdegang ist und wie ich zu SCS gekommen bin.
Ich habe viele Jahre in der Softwarebranche gearbeitet an vielen verschiedenen Stellen, in vielen verschiedenen Rollen.
Ich habe ein bisschen entwickelt, ich war im Support, ich habe Consulting gemacht, ich habe ein Produktmanagement gemacht, ich habe Handbücher geschrieben.
Also im Grunde genommen, das Ganze, was eine Software Lifecycle angeht oder das Software Geschäft angeht, habe ich irgendwo mal beschäftigt.
Ich habe auch zwischendurch mal ein Start-up gehabt für ein Jahr.
Ich habe immer versucht, mit meinem Bruder eine Digitalisierungslösung in in den Mobilitätsbereich zu entwickeln und an den Markt zu bringen.
Und war dann bei verschiedenen anderen Softwarefirmen beschäftigt, unter anderem für DevOps-Lösungen, für E-Commerce-Lösungen, für Datenanalyse-Lösungen.
Und jetzt bin ich seit einem halben Jahr beim Souverän Cloud Stack in dem Projektteam da drin und dort zuständig und verantwortlich für das Thema Ökosystem und Zertifizierung. Genau.
Torsten:
[2:26] Schön, dass du da bist und schön, dass wir darüber sprechen können.
Und jetzt würde ich sagen, wir steigen mal direkt ein.
Jetzt haben wir schon ungefähr fünfmal Severin Cloud Stack gesagt.
Wir werden das jetzt zukünftig mit SCS abkürzen. Aber jetzt müssen wir erst mal erklären, was überhaupt Severin Cloud Stack oder SCS überhaupt, was das bedeutet und was es ist.
Alexander:
[2:43] Genau. Ich habe es ja schon vorher gesagt, ich habe keinen Elevator-Pitch.
Ich habe in im halben Jahr mir auch keinen zurechtgelegt und ich bekomme die Frage natürlich öfter oder bin öfter im Gespräch damit und wenn wir mit potenziellen Partnern oder mit Kunden sprechen.
Der Souverän Cloud Stack ist, wie der Name sagt, ein Cloud Stack.
Jetzt normalerweise würde ich anfangen, erstmal auszubreiten, was Cloud Computing ist, weil ich glaube, dass das ein wichtiges Thema ist, um das zu verstehen und dass das häufig missverstanden wird gleich zu Anfang.
Aber wir kommen da sicherlich später nochmal drauf zu sprechen.
Daher erstmal, es ist ein Cloud Computing Stack. Das bedeutet eine Software, mit der man Infrastruktur, also Computerressourcen.
[3:36] So virtualisieren kann, dass sie eine Cloud-Umgebung bilden, ganz profan in einem Satz.
Jetzt ist es allerdings nicht so einfach.
Einfach ist das Thema sowieso nicht, aber das Souverän Cloud Stack Projekt ist noch mehr.
Es ist einmal diese modulare Software, mit der man dieses Cloud Computing aufsetzen, deployen und betreiben kann.
Es ist allerdings, und das ist der noch wichtigere Punkt, es ist ein Standard, mit dem man, wenn man diesen Standard erfüllt, Interoperabilität erreichen kann.
Das bedeutet, eine Infrastruktur, die auf einem Souverän Cloud Stack kompatibel betrieben wird, auf einer Seite in einem Rechenzentrum und in einem anderen Rechenzentrum, das ist interoperabel.
Beide sollten sich oder werden sich gleich verhalten, wenn man Software darauf anwendet und laufen lässt.
Torsten:
[4:41] Das heißt, nochmal ganz kurz für mich, ein Stack ist quasi ein modular zusammengebautes Software.
Alexander:
[4:47] Also genau, richtig. Ein Stack ist nicht eine Software, sondern es ist eine Reihe von Software.
Man braucht eine ganze Reihe von Softwarepaketen, um diese Möglichkeit oder um die Fähigkeit, was ein Cloud Computing Stack leisten muss.
Dafür braucht man mehrere. Man braucht Authentifizierungsmöglichkeit, man braucht ein rechter Management, man braucht ein Monitoring Management, man braucht diverse Virtualisierungsstufen, man braucht Netzwerkmanagement Software.
Und diese Software zusammen bildet dann diesen Stack, der die Möglichkeit für Cloud Computing bildet.
Torsten:
[5:24] Und ihr habt da einmal genau die richtigen Komponenten Open Source zusammengebaut und Das nutze ich jetzt quasi als Standard, damit...
Und dass damit Rechenzentren untereinander kompatibel sind und austauschbar.
Alexander:
[5:41] Ja, richtig, genau. Es gibt einen Open Source Stack, der ist auch weit verbreitet und wird sehr professionell entwickelt und gewartet.
Wie heißt der? Der heißt Open Stack und der hat diese Komponenten, diese Module bereits, die werden in dieser Community entwickelt.
Das läuft auf Linux-Basis. Linux selbst ist auch ein Open Source Projekt und es gibt noch mindestens ein weiteres CNCF.
Und aus diesen Modulen bauen wir einen Stack zusammen. Jetzt könnte man das auch selber tun.
Also man braucht jetzt nicht erst CS dafür. Man könnte sich diese Dinge, diese einzelnen Module auch aus dem Internet herunterladen und versuchen, sie zum Laufen zu bekommen. Das ist allerdings, ich sag's mal vorsichtig, eine Expertenaufgabe.
Und was wir tun wollen ist, Wir konfigurieren das so vor, dass es verhältnismäßig einfach zu installieren, zu deployen und zu betreiben ist.
Das ist das Ziel. Es bleibt open source. Die Komponenten werden weiterhin in den jeweiligen Foundations entwickelt und gewartet. Aber wir bauen es so, dass es standardisiert und einfach zu bedienen ist.
Torsten:
[6:55] Verhältnismäßig einfach. Ok, jetzt muss ich mal eine ganz bösartige Frage stellen.
Warum muss ich das machen? Es gibt doch Amazon und Co.
Alexander:
[7:02] Ja, jetzt sind wir schon in der Mitte des Was ist Cloud Computing?
Also wenn wir jetzt Amazon zum Beispiel damit damit damit vergleichen.
AWS als als als Cloud Angebot ist jetzt erst mal keine.
Also es ist zwar eine Software, aber die Software kann man nirgendwo runterladen oder selbst betreiben, sondern die Software wird von der Firma Amazon betrieben Und man kann die Dienste, die diese Software zur Verfügung stellt, von Amazon mieten.
Auf Rechnern, die ebenfalls von Amazon betrieben werden. Wir betreiben überhaupt gar nichts, sondern wir stellen nur einen Software-Stack zur Verfügung.
Torsten:
[7:44] Das heißt, ihr sorgt dafür, dass ich nicht abhängig werde von Amazon, Google und Co.
Das heißt, ich kann das in meinem Rechenzentrum so betreiben, wie ich das will und kann auch so skalieren, wie ich das möchte.
Alexander:
[7:55] Richtig, absolut. Also der Souverän Cloud Stack für sich genommen, wenn man jetzt als unmittelbarer Nutzer davon profitieren möchte, dann bräuchte man erst mal ein Rechenzentrum.
Genau, und das ist auch genau das Ziel. Also von AWS oder Google kann man keine Cloud Computing Stack Software benutzen, jedenfalls nicht kommerziell, soweit ich das weiß.
Das gibt es nicht. Man kann sie nur dann kann ich zu die dienste nur mieten und und wir haben die möglichkeit oder es ist einfach ein ganz anderes ganz anderes modell.
Torsten:
[8:29] Ja immerhin google nennt ja seine cloud jetzt schon sagen laut aber das ist ein anderes thema warum wir.
Auf digitale Souveränität achten sollten und achten müssen.
Das habe ich schon mal in einer Episode zur digitalen Souveränität besprochen.
Ich glaube, da gehen wir jetzt nicht nochmal im Detail drauf ein.
Aber vielleicht kannst du mir nochmal ganz kurz abreißen, was digitale Souveränität heißt.
Alexander:
[8:53] Naja, es gibt da verschiedene Definitionen und Begrifflichkeiten.
Das ist ja auch ein, ich sag's mal vorsichtig, ein Modewort, was in sehr vielen Mund geführt wird.
Für mich ist digitale Souveränität, dass ich als Nutzer, wer jetzt auch immer der Nutzer ist, weil es in einem Cloud-Computing-File-Use-Case auch nicht so einfach zu diskriminieren ist, die Souveränität habe, sowohl über den Prozess, den ich mit dieser Software abbilde, als auch über die Daten, die ich damit erzeuge bzw.
Die ich damit benutze. Und mit dem Prozess meine ich, dass wenn ich eine Software benutze, dann tue ich damit ja irgendeinen, dann bilde ich irgendeinen Geschäftsprozess ab. Und wenn die Software weg ist, kann ich meinen Geschäftsprozess auch weg sein.
Torsten:
[9:50] Dafür schafft ihr Abhilfe mit dem Sovereign Cloud Stack, dass ich die Abhängigkeit eben nicht mehr habe.
Okay, wir haben uns hier so ein bisschen groben Fahrplan aufgemalt, wie wir durch das Thema Surround Cloud Stack durchführen möchten.
Und da habe ich als nächstes die drei Dimensionen der Komplexität des Projektes.
Du hattest ja vorhin schon eingangs gesagt, dass es ziemlich komplex ist und ziemlich umfangreich aufgrund der vielen beteiligten Komponenten.
Kannst du vielleicht noch mal drauf eingehen?
Alexander:
[10:21] Genau, was ich, was mir...
Was mir aufgefallen ist, oder zuvor, als ich, bevor ich zum Servering Cloud Stack, zu dem Projektteam gestoßen bin, dachte ich, ich wüsste, was Cloud Computing ist und dann musste ich es nochmal lernen.
Ja, und allein das, obwohl ich denke, dass ich zumindest gute technische Grundkenntnisse besitze, hat mich dann doch überrascht, in welchen Erkenntnisprozessen ich dann nochmal durchgegangen bin, obwohl ich bereits Cloud Computing benutzt habe und zwar seit mehreren Jahren.
Und dann habe ich auch die Beobachtung gemacht, dass dieses gerade in dem öffentlichen Kontext, in dem sich ja auch dieser Podcast so überwiegend bewegt, dass dieses Thema Cloud gerade jetzt mit der deutschen Verwaltungscloud-Strategie und vielen anderen Aktivitäten, das wird in vielen Kontexten verwendet.
Aber die passen nicht unbedingt oder die passen eigentlich überhaupt gar nicht miteinander zusammen.
Und mein Eindruck ist, dass es eigentlich wie bei so vielen Buzzwords da häufig keinen Common Sense gibt. Und deswegen würde ich damit anfangen, dass wir vielleicht noch mal einen Moment darüber reden, was Cloud Computing ist und was damit gemeint sein kann.
Torsten:
[11:33] Also sehr gern, bisher dachte ich immer, Cloud heißt der Computer von jemand anderes. Aber du kannst das vielleicht noch etwas ausdifferenzieren.
Alexander:
[11:40] Ja, genau. Tatsächlich ist auch das kein geschützter Begriff, aber vielleicht können wir uns dem mal ein bisschen annähern.
Ich habe ja schon vorher reingeschrieben und in der Linksammlung auch nochmal das gepostet. Es gibt eine Definition vom NIST. Ich habe gesagt, ich soll sagen, was das NIST ist, ist das National Institute of Standards and Technology.
Das ist also das amerikanische Normungsinstitut, was ein staatliches Institut ist. die haben eine Definition dafür entwickelt.
Und um ganz kurz zu sagen, das mag sich jeder selber angucken, das würde ich auch jedem mal empfehlen, das einmal durchzulesen, das ist nur eine halbe Seite, ist, dass ein Cloud Computing bedeutet, dass Computing-Ressourcen, also das sind im Kern, was sind Computing-Ressourcen?
Das ist der Prozessor, das ist Netzwerk, das ist Storage und das ist Speicher.
Das Cloud Computing ist, wenn diese Ressourcen on-demand und self-serviced verfügbar sind.
Das heißt, jeder, der die haben möchte, kann sie sich zu jeder Zeit besorgen, dass das ein Ressourcen-Pulling ist. Das heißt, man bekommt nicht eine Maschine, sondern es gibt eine Millionen Maschinen und 10 Millionen Anwender.
Und die Ressource wird dann dynamisch zu dem alloziert, der sie gerade benötigt.
Das ist auch das Thema Elastizität, was dort auch ein Aspekt ist.
[13:05] Und der fünfte Punkt ist, dass das auch gemonitert wird. Das heißt, die.
Zum beispiel für abrechnung wenn das mit deinem mit einem mietmodell oder mit einem ja mit einem abo modell verbunden ist dass das auch dann dann je nach ressourcenverbrauch abgerechnet werden kann das ist die nist definition von cloud computing das bedeutet jetzt erstmal nicht.
Das das sagt ja nichts darüber wo zum beispiel der computer steht auf jeden fall steht bei jemand anders.
Nicht notwendigerweise.
Ich könnte ja zum Beispiel für einen, also das ist jetzt ein leicht hypothetischer Fall nur um das Wesen von Cloud Computing.
Ich könnte ja in einer Firma, könnte ich ja im Keller ein großes Rechenzentrum machen und dann sagen, für alle Mieter in diesem Bürogebäude biete ich diese Computingressourcen an.
Zum Beispiel, wenn ich SCS in diesem Rechenzentrum deploye, dann könnte ich ja so ein Modell machen. Dann wäre es ja schon mal im selben Gebäude.
Torsten:
[14:04] Da stimmt.
Alexander:
[14:05] Also was bedeutet so anders? Ja.
Torsten:
[14:08] Okay, es war auch eher scherzhaft gemeint. Also das ist ja die, ich habe in meinem Büro einen Poster von der FSFE hängen. Da steht genau das drauf.
Alexander:
[14:18] Was ist die FSFE?
Torsten:
[14:19] Die Free Software Foundation Europe. Ah ja, okay. Genau, die haben genauso was gesagt. Cloud just someone else's computer.
Alexander:
[14:25] Okay. Interessanterweise, auch in dieser NIST-Definition gibt es verschiedene Arten von Clouds, die auch beschrieben werden.
Da ist auch die Private Cloud beschrieben. Private Cloud bedeutet, dass es deine eigenen Rechner sein können. Sie können auch in deinem Gebäude stehen und sogar in deinem Zimmer stehen. Das hat darüber keine Aussage.
Torsten:
[14:45] Cloud ist im Prinzip ein Pool an Rechenpower, den ich ad hoc oder dynamisch buchen kann oder wieder abbestellen kann, im Prinzip.
Alexander:
[14:56] Im Kern ja. Ich würde es sogar noch einfacher sagen.
Eine Cloud ist ein Pool an Computing-Ressourcen, über dem eine Virtualisierungsschicht liegt, die dann diese Ressourcen logisch verteilen kann.
Torsten:
[15:11] Und ich glaube, da beginnt gerade die Komplexität jetzt.
Alexander:
[15:14] Ja, kann sein. Also ich habe in dem letzten halben Jahr mit verschiedenen Gesprächen, ich habe auch andere Podcasts angehört, habe gerade was in der öffentlichen Verwaltung und wenn über Cloud-Strategie geredet und diskutiert wird, habe ich so verschiedene Dinge mal aufgeschnappt, was für einzelne Leute Cloud ist.
Cloud und On-Premise wird einander gegenübergestellt.
Das ist ja so, wie wir jetzt gerade darüber geredet haben. Es ist ja nicht richtig. Es ist kein Gegensatz.
Cloud ist auch zum Beispiel Microsoft 365.
Das stimmt, aber es ist auch nur eine bestimmte Anwendung, die cloudbasiert ist. Also eine SaaS-Anwendung.
Oder Hyperscaler sind Cloud. Ja?
Aber wenn man sich sein eigenes Rechenzentrum irgendwo in Bochum selbst betreibt, dann ist das und man es virtualisiert, sodass die Ressourcen dynamisch und skaliert verteilt werden können, ist das auch Cloud.
Torsten:
[16:21] Soterios Vielleicht kann man es auch noch mehr auf den Punkt kriegen.
Cloud heißt nicht, dass alles auf einem einzigen Gerät funktioniert, der dann massenhaft Speicher und massenhaft Prozessoren hat, sondern es ein ganzer Haufen an Rechnern ist, die dann dynamisch entsprechend nach Last und nach Bedarf zugebucht werden.
Alexander:
[16:45] Richtig, genau. Es ist vielleicht noch mal ein anderes praktisches Beispiel zu machen.
Man kann auf einem Cloud Computing Stack, also in einer Cloud Computing Umgebung, kann man sich einen Computer, also eine virtuelle Maschine zusammenstellen, die, ich sag jetzt 10.000, Prozessoren hat und 10 Terabyte an Arbeitsspeicher.
Und so eine Maschine gibt es physisch überhaupt gar nicht.
Aber ein Cloud Computing Stack kann sie erzeugen, indem er einfach sehr viele zusammenschaltet.
Es ist allerdings nicht so, dass er sagt, okay, diese eine Anwendung, die jetzt so viele Ressourcen braucht, da sind jetzt diese ersten 100 Rechner, die da vorne in dem in dem Rack steht, sondern er verteilt sie andauernd dynamisch über alle, je nachdem, wo die Last am sinnvollsten genutzt werden kann.
Torsten:
[17:34] A. Okay, ich glaube, wir sollten das mit dem Cloud Computing, ich glaube, das haben wir abschließend erklärt, was das bedeutet.
Und ich wette, es gibt trotzdem noch Leute, die bessere und einfache oder andere Ansätze in die Kommentare schreiben, also immer her damit.
Alexander:
[17:50] B.
Torsten:
[17:50] Mit Sicherheit. A. Aber jetzt gehen wir wieder zurück zu dem Thema, die Dimension der Komplexität dieses des Projektes speziell.
Alexander:
[17:58] Richtig, genau. Also wir hatten jetzt dieses Thema Cloud Computing, was sehr erklärungsbedürftig ist. Wir haben jetzt auch gar nicht über Container und Kubernetes geredet und das ist für sich genommen noch eine.
Auch diese Konzepte sind nicht einfach zu verstehen, glaube ich, aber das ist sozusagen der eine Teil. Dazu ist es aber auch noch ein Open Source Projekt und das ist ja ein extrem wichtiger Aspekt dieser Software.
Wenn man jetzt zum Beispiel, ich sag jetzt mal, Microsoft hat ja auch einen Cloud Stack, den man glaube ich in Lizenz betreiben kann, ich bin mir nicht so sicher.
Ja Azure kann man in Lizenz betreiben. Aber Azure ist nicht open source, jedenfalls nicht komplett.
Und das sind ja Dinge, die gegenüberstehen. Und dieses Thema open source ist ein sehr wichtiges Thema, es ist auch ein Herzensthema, auch das ist, wie zumindest meine Beobachtung, nicht so einfach zu verstehen.
Und auch dagegen gibt es viele Missverständnisse.
Das ist kostenlos oder kann ja jeder Bugs reinprogrammieren.
Solche Dinge sind hier bestimmt auch schon untergekommen mit verschiedenen Diskussionen.
Torsten:
[19:08] Genau. Vielleicht grenzen wir hier Open Source von dem Projekt nochmal ganz deutlich ab.
Ihr benutzt nicht nur Open Source Software, um dieses Projekt zu bauen, sondern auch das Das komplette Projekt ist dann letztendlich open source.
Projekte mit Open Source-Projekten zu bauen ist überhaupt kein Thema.
Das macht heutzutage jeder.
Aber dann das Ergebnis, was da rauskommt, auch als Open Source-Projekt zur Verfügung zu stellen, das ist der große Unterschied.
Alexander:
[19:32] Genau, ich hätte es nicht besser sagen können, Thorsten.
Der eine wichtige Aspekt ist, dass die Komponenten selbst alle Open Source sind, aber wir fügen sie ja zusammen und machen sie ja zu einem, Wir veredeln sie sozusagen, machen sie zu einem neuen Produkt, zu einem standardisierten Produkt und auch das ist komplett open source.
Also unsere Gitterpropositoris sind offeneinsehbar, der ganze Code, wie auch das gesamte Projekt, wie auch die Teilnahme an der Community.
Alles das ist offen und kann von jedem eingesehen und jeder kann auch mitmachen und sich einbringen.
Torsten:
[20:11] Genau, dann nennen wir am Ende nochmal die URL oder vielleicht nennst du jetzt gleich schon mal, dann vergessen wir sie nicht und können sie mehrmals nochmal mit nennen, wo euch die Leute finden.
Alexander:
[20:22] Genau, das ist scs.community, ist dann auch in der Linksammlung drin und dort findet man natürlich eine Beschreibung des Projektes, aber man findet eben auch ein Kalender mit all unseren Terminen und auch die die Verweise auf die jeweiligen Repositories, wo das Projekt drin ist.
Torsten:
[20:43] A. Genau. Jetzt versuche ich nochmal wieder, den Faden aufzugreifen mit der Komplexität.
Wir schweifen immer ab. Also das ist überhaupt kein Problem, aber wir sollten trotzdem immer wieder zurückkommen zu dem Thema, worüber wir eigentlich sprechen wollten. Das Thema Komplexität.
Alexander:
[20:57] B. Ja, eins der Probleme, der Herausforderung, wenn ich in meinem Elevator-Pitch arbeite, was SCS ist, ist eben, dass ich diese Komplexitäten, dass die Teil dieses Projektes sind und ich mich immer versucht fühle, erst diese Komplexitäten aufzulösen, damit der Gegenüber das auch einordnen kann, was einfach schlicht und möglich ist.
Und viele Leute wissen ja auch oder haben ein gutes Verständnis von der Open Source, dann braucht man es nicht neu zu erklären. Wir hatten das Thema Open Source, auch das, ich dachte, ich wüsste, was es ist.
Auch das habe ich nochmal besser verstanden jetzt. Das hat ja auch verschiedene Aspekte, zum Beispiel lizenzrechtliche Fragestellungen.
Das ist ja erstmal ein Kernelement von Open Source, aber auch das, was du gerade gesagt hast, der Community-Gedanken, dass jeder mitmachen kann, aber auch wie so ein Projekt strukturiert ist, dass es nicht einfach jeder kann mitmachen und jeder kann etwas tun, sondern dass es auch kontrolliert ist, dass es einen strukturierten Plan gibt, dass es Maintainer gibt, die diesen auch auch reviewen.
[22:01] Und all diese Dinge sind, glaube ich, wichtig zu verstehen, um es einordnen zu können, was der Unterschied ist zu einem proprietären Stack oder zu einer proprietären Software, dass es nicht qualitativ, nicht notwendigerweise oder gar nicht schlechter ist, dass es entsteht oder entwickelt wird, nur anders entwickelt.
Was mir dabei ganz wichtig ist, und das ist etwas, was ich zumindest Leute, die da neu in diesem Thema denken, Open Source Software, das sind Hobbyprojekte und die proprietieren Software, das sind die Profis.
Das stimmt natürlich nicht. Der entscheidende Punkt dabei ist, glaube ich, zu verstehen, dass eine Open Source Software, die professionell betrieben wird, dahinter steht immer eine Firma.
Vielleicht fühle ich das noch mal ganz kurz aus was ich damit meine.
Linux ist eine freie und kostenlose Software.
Trotzdem würde eine Firma, die einen Linux Stack betreibt oder ihre Computer oder auch nur Server auf Linux betreibt, einen Vertrag machen mit einer Firma, die diese Linux-Distribution zur Verfügung stellt und vor allem den Support und die Gewährleistung mitliefert.
Das ist eine Lieferantenbeziehung.
Und diese Lieferantenbeziehung ist eigentlich das Entscheidende.
Torsten:
[23:24] Genau. Also, weil du gerade Linux sagst, da gibt es Distributionen.
SUSE Linux, Ubuntu Linux, Red Hat Linux, da hängen überall Unternehmen dahinter.
Alexander:
[23:33] Richtig, genau. Und das ist das Entscheidende bei der Beziehung.
Und wie diese Software, die im Netz steht oder wo dieser Code herkommt, ist dann zweitrangig, weil es die Beziehung mit der Firma ist.
Und das ist eine sehr, sehr ähnliche Beziehung wie zu der Firma Microsoft oder Oracle oder viele, viele andere.
Torsten:
[23:52] Sjoerd Genau. Was bringt uns das bei dem Thema Souverän Cloud Stack?
Der ist ja genau dafür gebaut, dass ich nicht abhängig bin von der Firma.
Alexander:
[24:01] Daniela Na ja, das stimmt so nicht. Der Souverän Cloud Stack stellt nur diesen Code zur Verfügung.
Linux baut auch nicht den Linux-Körner, sondern der Linux-Körner ist ein Community-Projekt.
Der SUSE Linux veredelt diesen Körner zu einer Distribution und steht dann als Firma zur Verfügung, um eine Lieferantenbeziehung einzugehen.
Wir sind das Community-Projekt, das, wenn wir jetzt das Äquivalent mal nehmen wollen, den Linux-Körner.
Wir sind keine Firma, wir können auch keine Gewährleistung und wir können noch nichts verkaufen.
Torsten:
[24:35] Ich arbeite ja bei der bei der bei dem IT Dienstleister für den öffentlichen Bereich bei der akb und wir könnten jetzt jetzt sozusagen den Sammler Cloud Stack nehmen und vertreiben den als akdb Cloud Stack.
Den könnten wir im eigenen Rechenzentrum betreiben oder wenn ein anderes Rechenzentrum auf uns zukommt und sagt, oh euer AKDB Cloud Stack, den finden wir ziemlich cool, dann könnten wir sagen, ok installieren wir bei euch.
Alexander:
[24:55] Genau, das wäre zum Beispiel ein Geschäftsmodell, was man auf SCS aufbauen könnte.
Und das Überleben dieses Projektes hängt auch davon ab, dass diese Geschäftsmodelle entstehen und sie sind auch am Entstehen.
Es gibt Firmen, die bereits auf SCS-Basis oder SCS-Technologie supporten, wenn man das selbst benutzen möchte.
Und es gibt auch Firmen, die das bereits in Anspruch nehmen.
Und es braucht aber noch mehr davon. Und wir sind aber nicht diejenigen, die diese Geschäfts- oder daraus wird sich jetzt unmittelbar zumindest kein Geschäftsmodell entwickeln, sondern wir sind das Community-Projekt, was darunter liegt.
Torsten:
[25:37] Meine Hörerinnen und Hörer wissen, dass ich auch Projektleiter Open Source in meinem Beruf in der Akademie bin. Da haben wir die große Herausforderung, wir entwickeln Software.
Und wir entwickeln Software natürlich auch mit Open Source Bestandteilen.
Aber wir entwickeln auch Software, die wir dann letztendlich Open Source zur Verfügung stellen. Und wir stellen die zur Verfügung unter eine Lizenz, die heißt EUPL 1.2.
Und jetzt haben wir die Herausforderung, dass alle Module, alle Bibliotheken und ähnliches, was wir verwenden, um unsere Software zu bauen und unseren Teil ringsum zu programmieren, kompatibel sein müssen mit der Lizenz, wie wir dann letztendlich diese Software veröffentlichen.
Wie handhabt ihr das beim sovereign cloud stack?
Weil da gibt es ja wahrscheinlich auch, wenn es so eine komplexe zusammengebaute Stack quasi ist, deswegen ist Stack, da gibt es ja wahrscheinlich auch diverse Lizenzen, die ihr irgendwie beachten müsst.
Alexander:
[26:32] Du sprichst jetzt auf das Thema Software Bill of Material an.
Das ist eine sehr gute Frage, Thorsten. Ich bin dazu nicht sprechfähig.
Dieses Thema Lizenzmanagement ist tatsächlich eines, was natürlich von uns liegt in unserer Verantwortung, dieses Thema zu managen.
Ich Ich weiß es ehrlich gesagt nicht.
Ich nehme aber an, dass die Komponenten, die Module, die wir zusammenbauen aus den jeweiligen Foundations, also aus der Linux Foundation, CNCF und Open Infrastructure, dass die gleich weit offen sind, sodass wir das gewährleisten können.
Torsten:
[27:19] Ein Thema, was bei Open Source ja immer in generell Open Source und auch Schnittstellen, APs und so weiter immer wieder nachgefragt wird, ist das Thema der Referenzimplementierung.
Habt ihr sowas? Macht ihr sowas?
Alexander:
[27:35] Ja, es ist tatsächlich Teil des Produktes, wenn man so will.
Es gibt drei Säulen, vielleicht sollten wir ganz kurz gleich über die dritte Säule reden. Also das erste ist dieser Standard. Das heißt, wir sagen, diese Komponenten in der Konfiguration sind unser Standard.
Den können wir auch zertifizieren.
Das heißt, wir können auch nachweisen oder jemand kann nachweisen, dass dieser Standard eingehalten ist und damit ist diese Infrastruktur interoperabel.
Der zweite Teil ist, dass wir tatsächlich diesen Stack auch einmal so zusammenbauen, dass er deployment-ready zur Verfügung steht.
Das heißt, es ist nicht nur eine Gebrauchsanweisung, nimm dir das, lad dir das runter, schreib das in die Konfig-Datei, dann läuft es hoffentlich, sondern wir haben tatsächlich eine Referenz-Implementierung, wie du richtig sagst, Jan.
Torsten:
[28:27] Okay, du hast vorhin gerade noch gesagt, ihr könnt das zertifizieren.
Das heißt, wenn ich jetzt unsere Produktmanager überzeugt kriege und sage, wir machen mal also ein AKDB Cloud Stack, den könntet ihr euch anschauen und sagen, der ist SCS-kompatibel.
Alexander:
[28:40] Richtig, genau. Das ist möglich.
Dieses Thema Zertifizierung ist das große Thema für 2023.
Wir haben bereits ein Zertifizierungstool noch nicht gelauncht, noch nicht öffentlich, das kommt sehr bald.
Ohne dass ich die Komplexität hier zu sehr stressen möchte, nur so viel, dass wir, wir haben zwei verschiedene Zertifizierungsstufen.
Das eine auf der Infrastructure as a Service Ebene und das andere auf der Kubernetes Ebene.
Das heißt, und das ist doch das Einzige, was ich dazu sage, es sei denn, du möchtest mehr hören, dass du auf der Kubernetes-Ebene SCS zertifiziert sein kannst, ohne dass die unterliegende Infrastruktur überhaupt etwas mit SCS zu tun hat.
Also im Extremfall könnte man auf AWS ein Kubernetes Cluster so...
Installieren, deployen und konfigurieren, dass er SCS-kompatibel ist.
Und dann hättest du eine SCS-kompatible Umgebung in AWS laufen.
Torsten:
[29:53] Sagt nicht so laut, sonst weiß ich genau, was passieren wird demnächst.
Alexander:
[29:59] Das ist jetzt ein Extremfall und ob das wirklich jemals jemand tut, ist fraglich.
Aber um diese Deutung des Standards klarzumachen, Das Wichtigste ist, dass dieser standard, dieser zertifizierbare, nachprüfbare Standard eingehalten wird.
Und das bedeutet für sich genommen schon Souveränität.
Torsten:
[30:21] A.S. Okay, jetzt musst du nochmal ganz kurz, du hast Kubernetes gesagt, ich hatte das heute auch schon mal gesagt. Kannst du noch ganz kurz sagen, was Kubernetes ist?
Alexander:
[30:27] B. Ja, obwohl ich mir sicher bin, dass es in deinem Podcast schon öfter mal erklärt und auch diskutiert wurde.
Aber ich meine, wenn man über Kubernetes redet, muss man erst mal über Container reden. Ganz kurz, Container sind, ist auch eine Artvirtualisierung.
Einer meiner Accountmanager hat mal gesagt, das ist wie eine virtuelle Maschine nur viel kleiner.
Ich finde, das für einen Line ist keine schlechte Erklärung.
Und ein Kubernetes ist eine weitere Virtualisierung, die sozusagen ein Cluster emuliert, in dem dann diese Container kontrolliert laufen.
Und Kubernetes für sich genommen als Open Source Projekt ist ja auch ein Standard, aber jedes Kubernetes ist halt auch ein bisschen anders.
Torsten:
[31:27] Das stimmt. Und ihr gebt eine Empfehlung, welches Kubernetes man am besten benutzt?
Alexander:
[31:33] Eine Empfehlung ist ein bisschen zu schwaches Wort. Ich würde es tatsächlich als ein Standard so bezeichnen.
Und wir geben vor, wenn es SCS-kompatibel ist, wie ein Kubernetes-Cluster konfiguriert werden muss, um es jetzt in einem Satz zu sagen, ohne zu sehr in die Technik zu gehen, was ich auch nicht könnte.
Torsten:
[31:56] Mir fällt gerade ein, wir sollten vielleicht nochmal ganz kurz darauf eingehen, warum und wie das ganze Thema mit Kubernetes und Containern und so überhaupt möglich ist.
Also ich versuche mal eine Erklärung, die mir mal jemand erzählt hat.
[32:13] Früher hat man Software entwickelt, das war ein riesengroßer Haufen, ein ganz langes Listing an Code und die hat dann irgendwie noch zusätzliche Code-Bestandteile nachgeladen oder zusätzliche Code-Bestandteile angesprochen.
Auf jeden Fall war das ein riesen Blob mit Code, also ein riesen dickes singuläres Software- Artifakt. Inzwischen ist die Entwicklungstechnologie viel moderner, leichtgewichtiger.
Das heißt, diesen großen Blob, den zerhacke ich jetzt in ganz viele kleine Teile.
Und weil nicht jedes dieser kleinen Teile dauerhaft auch funktionieren und laufen muss, schmeiße ich diese ganzen kleinen Teile in ganz kleine Containerchen.
Das kommt von Docker und das sind die sogenannten Microservices.
Und diese Microservices, die ruft diese Software nur dann auf oder startet diese Software nur dann, wenn es die braucht. Wenn es das drei- oder viermal braucht, statt es auch einfach mal drei oder vier mal die gleiche einzelnen Containerchen.
Und diese ganzen Containerchen, die werden jetzt alle zusammengepackt in einen großen Kuponetes.
Ich stelle das, glaube ich, da mit einem großen Schiff und es wird auch so ein großes Containerschiff getan und das ist meine Kuponetes-Infrastruktur.
Ich fahre mit diesem Riesenschiff durch die Gegend und an jedem Hafen wird nur dieser kleine Container ausgeladen, der auch genau gerade dort benötigt wird.
Alexander:
[33:29] Das ist ein sehr schönes Bild. So habe ich es noch nie gehört.
Torsten:
[33:34] Ich hoffe ich habe jetzt nicht wieder mit meiner Besserwisserei hier Hörer und Hörerinnen verschreckt, aber so ist mir das mal erklärt worden.
Alexander:
[33:42] Okay, ich würde dem noch etwas hinzufügen, wenn ich darf. Ein entscheidender Punkt bei Containern, wie auch bei virtuellen Maschinen, ist ja die die die Isolierung der einzelnen Umgebungen.
Weil früher, also in den alten Zeiten, wenn alles auf einem Rechner gelaufen ist, und das kennt vielleicht viele Leute von ihren Privatrechnern, die Dinge interferieren miteinander, beeinflussen sich gegenseitig, miteinander verschränkt.
Und das ist halt sehr, sehr störanfällig.
Und ein Container für sich, also sozusagen die kontenerisierte, die gekapselte Anwendung, Die Einzelnen, die da zerhacktstückt wurden, wie du richtig sagtest, die wissen nichts voneinander und sie können sich gegenseitig nicht stören.
Und das ist ein ganz wichtiger Punkt für die Stabilität und die Wartbarkeit von solchen Systemen, weil ein größeres System kann ja von Dutzenden oder Hunderten von verschiedenen Containern ja bestehen.
Torsten:
[34:43] S.S. Genau. Und da kommt dann auch dieser Begriff Orchesterieren dazu.
Und das macht nämlich Kubernetes.
Kubernetes sorgt dafür, dass diese Containerchen genau dann laufen, wann sie zu laufen haben und genau mit dem Containerchen kommunizieren, mit dem sie zu kommunizieren haben.
Alexander:
[34:58] Genau. Und wenn ich jetzt nochmal den Bogen zu SCS und dem Standardthema spannen, wenn wir uns jetzt vorstellen, wir haben so eine komplexe Anwendung, die aus sagen wir mal hunderten von Containern bestehen und diese hunderte von Containern in dieser Anwendung sind in einem Kubernetes Cluster zusammengefasst, unser Containerschiff.
Und das haben wir Das können wir ja in einem in einem in einem Skript in einer in einer Konfigurationsdatei können wir das ja können wir das ja beschreiben.
Dann sollte dieses Deployment bei SCS auf einem SCS-zertifizierten System immer, laufen, ohne dass nochmal nachgebessert werden muss. Das ist das Wertversprechen im Kern.
Und im Gegensatz dazu, wenn man, und wir nennen jetzt immer die großen amerikanischen Hyperscaler, diese drei großen Namen, aber es gibt viele andere, also auch viele andere Infrastrukturanbieter, auch Public Cloud-Anbieter, haben alle ihre eigenen Stacks, wo teilweise Open-Stack-Komponenten mit dabei sind, aber auch dann proprietäre Stacks, also das ist dann sozusagen ein Mischmasch.
Da sollte das oder wird es nicht möglich sein. Es wird immer nachgebessert werden müssen, um auf das einzelne System angepasst zu werden. Und das ist das Versprechen von SCS.
Torsten:
[36:19] Okay, das Versprechen ist dann also auch, wenn ich im Rechenzentrum A ein SCS betreibe und da meine Software drauf betreibe auf dem SCS. Weil SCS an sich ist ja erst mal dumm.
Das kann ja noch nix. SCS hat nur, wenn ich SCS irgendwo drauf installiert, dann freuen sich die Rechner, weil ist was drauf, aber passiert mir nichts.
Alexander:
[36:38] Genau.
Torsten:
[36:39] Wenn ich da jetzt meine Software drauf installiere, dann ist das Versprechen, dass wenn ich das im Rechenzentrum A mache und ich plötzlich feststelle, oh mein Rechenzentrum A hat irgendein Problem, kann ich damit eins zu eins umziehen ins Rechenzentrum B, was genauso einen SCS Stack hat, ohne dass ich Einbußen habe und nochmal irgendwas nachkonfigurieren muss.
Im Idealfall sogar on time Rechenzentrum A auf Rechenzentrum B umschalten und dann kann ich Rechenzentrum A abschalten und B läuft einfach weiter.
Alexander:
[37:10] Richtig.
Torsten:
[37:11] Das ist eigentlich genial und das sollten wir in der öffentlichen Verwaltung für unsere Cloud-Infrastruktur auf jeden Fall ins Auge fassen.
Alexander:
[37:18] Richtig. Das ist der Kern und tatsächlich, wie schon gesagt, das ist ja ein tolles Narrativ.
Es ist mir nur bisher nicht gelungen, es ist sozusagen in drei Sätzen, ich meine wir reden jetzt vielleicht eine dreiviertel Stunde darüber und kommen jetzt sozusagen an das Pudelskern. Ich glaube es ist auch ganz gut herausgearbeitet, aber es ist halt sehr schwer in drei Sätzen zu erklären, finde ich.
Torsten:
[37:44] Ja, aber das ist das Schöne in dem Podcast, das ist dieses sogenannte sprechende Denken. Also mir fallen immer Dinge ein, während ich über Dinge spreche.
So, dann müssen wir gleich mal noch ein bisschen ans Eingemachte gehen.
Inwieweit seid ihr bei dieser Verwaltungscloud-Strategie involviert?
Alexander:
[38:03] Ja, spannendes Thema, Verwaltungscloud-Strategie.
Es gab ja mal dieses Dokument vom IT-Planungsrat, in dem diese deutsche Verwaltungscloud-Strategie beschrieben wurde.
Wir sind dort als eine Technologie genannt.
Das bedeutet aber nicht, dass jeder IT-Dienstleister, öffentliche IT-Dienstleister in Deutschland, SCS, benutzen muss. Es steht weiterhin jedem frei.
Das weißt du viel besser als ich. Sondern es ist eine Empfehlung.
Jetzt ist es natürlich unser ureigenes Interesse, dort vorzukommen.
Wir haben vorher darüber geredet, wie unser Interesse oder auch dafür, dass er belebt, ist es wichtig, dass sich auf Basis dieses Projektes und dieser Technologie Geschäftsmodelle entwickeln. Und das kann nur passieren, wenn es auch Leute benutzen.
Und die öffentliche Verwaltung, die öffentliche IT sollte ein Interesse daran haben, in der Kontrolle der Technologie zu bleiben.
Vor allen Dingen der Basistechnologie, auf der alles andere läuft.
Und das ist ein Cloud Computing Stack. Alle Fachanwendungen und idealerweise sogar alle Arbeitsplatzanwendungen sollten darauf laufen und man sollte nicht davon abhängig sein, dass ein irgendein Anbieter sagt, wir machen jetzt mit euch nicht mehr weiter.
Torsten:
[39:30] Vielleicht kannst du nochmal die UAL nennen, wo man euch findet.
Alexander:
[39:33] Ja, sehr gerne. Das ist scs.community, und dort auf dieser Seite... Das war's für heute.
Findet ihr alles weitere.
Torsten:
[39:43] Genau, das kann man sich auch hinwenden, wenn man mitarbeiten will, wenn man Ideen hat, wenn man die Sources finden will. Also das ist quasi so eine Sammelseite für alle Informationen. Ganz genau. Jetzt habe ich hier eine Riesenliste, wo wir noch Themen drauf stehen haben.
Was ist aus deiner Sicht noch wichtig, was wir auf jeden Fall noch ansprechen sollten?
Alexander:
[40:00] Wir haben über diese drei Komplexitäten geredet, Cloud Computing, ich glaube gut herausgearbeitet über das Thema Open Source und über das Thema Standardisierung, was das alles dann ja auch zusammenbringt.
Was mir wichtig ist, und das würde mich tatsächlich auch nochmal interessieren von deiner Seite, wie du das siehst, ist, dass meine Beobachtung ist, wie gesagt, gerade was das Thema Cloud Computing als auch Open Source angeht, wird sehr viel geredet.
Es ist sehr viel Aktionismus dabei. Wir wollen jetzt Open Source, wir wollen unabhängig werden, wir wollen cloudifizieren, wir wollen alles in die Cloud bringen, aber das standardisiert, das läuft auf Kubernetes und so weiter und so fort.
Meine Beobachtung ist, dass darüber viel geredet wird, aber nicht so viel verstanden.
Und ich glaube, dass ein Teil von digitaler Souveränität ist, dass derjenige, der über die Ressourcen entscheidet und sie auch steuert, dass der, die Kompetenz besitzt, auch gute Entscheidungen treffen zu können.
Und da denke ich mir manchmal, das SCS und ich bin natürlich nicht hier, um das Projekt runterzureden, Aber SCS ist nur eine Technologie.
Verstehen muss man sich schon selbst.
Torsten:
[41:12] Ich glaube, das sind mehrere Ebenen. Ja, du hast recht.
Es wird in der öffentlichen Verwaltung sehr viel über Open Source gesprochen.
Es wird auch teilweise nur noch als Open Source Software ausgeschrieben.
Also es gibt Ausschreiben, wo drin steht, es muss mit Open Source gemacht sein.
Da ist immer der Unterschied, es muss mit Open Source Komponenten gebaut werden oder es muss als Open Source gebaut werden. Das ist immer der kleine feine Unterschied.
Haben, glaube ich, in der öffentlichen Verwaltung noch viele nicht verstanden, was das bedeutet, weil mit Open Source Komponenten baut jeder.
Auch in Microsoft Office und in Microsoft Windows sind Open Source Komponenten drin, wenngleich die dann diese Anforderungen der digitalen Souveränität nicht erfüllen würden.
Wo ich nicht ganz bei dir bin, ist bei dem Thema, dass derjenige, der die Entscheidungen trifft, auch bis ins Detail auch das Thema verstehen muss.
Wenn ich mir jetzt vorstelle, ich darf gelegentlich bei der AG Cloud bzw.
Bei der UAG Technik und Betrieb mitzuhören und manchmal auch was sagen, wenn ich mir überlege, dass alle, die in der AG Cloud Entscheidungen treffen, das sind meistens Abteilungsleiter, dass alle, die das ganze Cloud Thema bis ins kleinste technische Detail durchstiegen hätten, dann dann könnten die keine Entscheidungen mehr treffen, wo sie die...
[42:33] Auswirkungen auf den Rest auch noch im Blick haben können.
Ich brauche Leute, die das kennen, die sich von dem ganzen Cloud-Thema und auch das ganze Thema Open Source vollständig verstanden haben, aber die müssen die Entscheider entsprechend beraten.
Die müssen ihren Vorgesetzten sagen, wir müssen das so und so machen, weil, und wir dürfen das und das nicht machen, weil. Und dann können die Entscheider die entsprechenden Argumente vorbringen in den Runden und die richtigen Entscheidungen treffen.
Alexander:
[43:01] Ja, genau.
Da sind wir uns, glaube ich, eigentlich.
Was meine Beobachtung ist, dass das manchmal in diesen bestimmten Runden, in anderen auch nicht.
Und ich bin auch in dieser UAG, Betrieb und Technik, da bin ich auch gelegentlich dabei.
Da wird schon über das Richtige und richtig geredet.
In anderen Runden bin ich mir manchmal unsicher, da werden sehr viele Dinge zusammengeworfen und miteinander verwoben, die inhaltlich nicht zusammengehören.
Das ist so manchmal mein Eindruck, aber das mag auch je nach Runde unterschiedlich sein.
Also da hast du natürlich vollkommen recht, eine Entscheidung musst du nicht bis ins Detail verstehen aber im wesentlichen halt schon aber aber ja das ist so das ist zumindest meine beobachtung jetzt auch aus dem halben jahr heraus in dem ich in zwischen in dieser rolle bin genau deswegen gibt es den podcast um den entscheidern die grundkenntnisse in den verschiedenen bereichen mit auf den weg zu geben genau und das hoffe ich dass haben wir heute ein bisschen so zumindest einen kleinen baustein davon leisten können genau und wenn noch jemand Fragen dazu hat.
Torsten:
[44:25] Ich denke, da seid ihr offen und ich denke, da können sich auch diejenigen direkt an euch wenden. Jetzt musst du nochmal die URL sagen, weil die muss man so oft wiederholen, wie es geht.
Alexander:
[44:34] Das sage ich gerne nochmal und dann sage ich auch zum Schluss nochmal, habe ich noch eine kleine Ankündigung. Also die URL ist scs.community, und ein großes Ereignis, was wir dieses Jahr das erste Mal veranstalten, ist der SCS Summit in Berlin am 23.
Und am 24. Mai. Und dort, die auf der Seite findet, die auch nähere Informationen, wie ihr euch da anmelden könnt.
Und da werden wir das erste Mal auch groß über das Produkt sprechen, über unser Projekt, über unsere Visionen. Es gibt viele interessante externe Reden auch.
Also, wenn ihr den Podcast nach Mai hört, habt ihr Pech gehabt.
Aber bis dahin bitte sehr gerne auf unserer Seite sich informieren und anmelden.
Torsten:
[45:24] A.S. Aber die meisten Podcast-Hörer haben ja den Eventkalender des E-Galament-Podcasts abonniert und da steht genau das Summit-Mittschirm drin.
Alexander:
[45:31] B. Super.
Torsten:
[45:33] Klasse, Torsten. A.S. Dann Alex, vielen Dank, dass du da warst.
Ich denke, wir sehen uns, das ist quasi noch ein Disclaimer hinterher.
Wir sehen uns regelmäßig bei der OSB-A und ich wünsche dir weiter viel Erfolg und bis bald.
Alexander:
[45:48] Ich danke dir für die Einladung, Thorsten, und ich habe mich sehr gefreut, hat viel Spaß gemacht. und ja, bis bald.