Der Weg zur heterogenen Cloud-Plattform

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Gil Breth: Herzlich willkommen zu einer neuen Ausgabe unseres Podcasts CTO Need to know. Mein Name ist Gil Breth und ich freue mich heute über zwei kleine Premieren. Die eine Premiere ist, dass wir heute mal auf unserem Gaststuhl einen INNOQ Kollegen sitzen haben. Wer das ist, wird uns gleich verraten. Das zweite ist, dass wir eine sogenannte Impulsfolge mit euch heute vorhaben. Was heißt Impulsfolge? Wir werden ein Thema kurz und knackig beleuchten. Das Thema, um das es heute geht, ist der Weg zur heterogenen Cloud Plattform. Dazu ist im letzten Jahr in unserem Technology Briefing auch ein Artikel erschienen. Der Autor dieses Artikels ist auch heute unser Gast, nämlich Philipp Beyerlein. Lieber Philipp, möchtest du dich mal vorstellen?

Philipp Beyerlein: Ja, genau. Hallo Gil, ich bin seit mittlerweile sieben Jahren bei der Firma INNOQ als Consultant tätig und mache seit Anfang an schwerpunktmäßig AWS und Infrastruktur. Ich beschäftige mich sehr stark mit dem Weg in die Cloud in der Vergangenheit und jetzt seit eigentlich zwei Jahren auch mit Multicloud Ansätzen und der Fortführung davon aus der eigenen Ideenschmiede, der heterogenen Cloud. Genau.

Gil Breth: Ja, sehr gut. Das passt natürlich im Moment sehr gut. Ich würde sagen, letztes Jahr war sehr stark geprägt vom Thema digitale Souveränität. Ich glaube, ich habe es in einer anderen Podcast Folge schon mal gesagt, für mich persönlich zählt es zu den Top 5, wenn nicht sogar zu den Top 3 Themen in der IT, die uns umgetrieben haben. Und ich kann schon sagen, das Thema ist definitiv angekommen und dieses Jahr wird sicherlich auch ein Jahr sein, wo es um Entscheidungen und um das Thema der Umsetzung geht. Wie kann man das jetzt umsetzen? Deswegen freue ich mich, dass wir das heute mal ein bisschen beleuchten werden. Du hast in deinem Artikel geschrieben, und ich glaube, das ist auch nichts Neues, dass viele Unternehmen mittlerweile eine Cloud Strategie haben, aber warum reicht das heute nicht mehr? Warum sollten sich zum Beispiel CTOs mit dem Thema Multicloud Ansätze beschäftigen aus deiner Sicht?

Philipp Beyerlein: In meiner Erfahrung gibt es schon manche, die einen Multicloud-Ansatz fahren, die sagen, manche Themen mache ich auf der eigenen Cloud, zum Beispiel für interne Sachen, manche mache ich auf einer anderen Cloud für externe Sachen. Beim Thema Multicloud ging es eher darum, dass ich in den einen Anbieter oder in den anderen skalieren kann. Der Ansatz hinsichtlich digitaler Souveränität, wenn man den erweitert und sagt, ich trenne mein System oder meine Umgebung nicht anhand von technischen Merkmalen, sondern von Unabhängigkeitsmerkmalen, dann komme ich um mehrere verschiedene Anbieter nicht herum. Und ich muss die ja alle irgendwie zusammenbringen am Ende. Jeder Cloud-Anbieter hat seine eigenen Schnittstellen, seine eigene Infrastruktur als Code, aber sie sind alle ein bisschen ähnlich von ihrem Grundgedanken her, von ihrem Grund-Setup. Zum Beispiel Amazon und Azure, die haben eigentlich die gleichen Dienste in unterschiedlicher Qualität, in unterschiedlicher Ausprägung, aber sie haben die gleichen Sachen. Es gibt aber nicht nur die amerikanischen Anbieter, sondern auch in Deutschland gibt es Anbieter, die nicht das komplette Portfolio eines amerikanischen Anbieters abdecken, aber die Dinge, die man braucht, können sie anbieten, wie Containerbetrieb, Netzwerk, Datenbanken. Manche können auch mittlerweile LLM Support. Also die können eigentlich schon eine ganze Menge. Und wenn ich jetzt sage, ich habe eh schon einen Multicloud Ansatz in meiner Infrastruktur, also eine Vielfältigkeit, dann kann ich auch sagen, ich setze noch einen europäischen Anbieter dazu, integriere den auch in mein Netzwerk, in meine Infrastruktur. Dann sage ich zum Beispiel für bestimmte Anwendungen, die mir wichtig sind, die mein Geschäft schädigen würden, wenn ich den Zugang verlieren würde, dass ich diese Anwendung über diese Netzwerkstruktur auch in einem europäischen Standort und bei einem europäischen Anbieter deployen könnte. Das ist alles State of the Art, VPN oder Direct-Connect-Geschichten, das bietet jeder an. Gerade wenn ich eh schon ein On-Premise Netz mit einer Cloud verbunden habe, fällt es fast nicht mehr auf, wenn ich noch einen weiteren dazu stecke, aber dann kann ich den nahtlos integrieren. Dann bin ich nicht nur bei einer gewöhnlichen Multicloud Strategie, sondern im Bereich der heterogenen Cloud, wo ich explizit sagen kann, die eine Anwendung mache ich europäisch, die andere mache ich im amerikanischen, weil bestimmte Services, bestimmte Features eben im deutschen fehlen. Oder ich kann das auch weiter treiben und sagen, ich habe dann zwei, drei europäische Anbieter, die sich in Summe so viel anbieten, wie ein amerikanischer Anbieter.

Gil Breth: Okay. Und das ist genau für dich dieser entscheidende Unterschied, wenn du von heterogenen Cloud Plattformen sprichst im Vergleich zu in Anführungszeichen einfach nur Multicloud? Oder gibt es da noch weitere Unterschiede?

Philipp Beyerlein: Genau. Man kennt es von bestimmten Software-as-a-Service-Anbietern oder zum Beispiel von Snowflake oder MongoDB. Da kann ich halt, da ist die Multicloud Strategie, okay, ich kann das mit Azure verbinden, ich kann das mit AWS verbinden, ich kann es mit Google Cloud verbinden, aber es ist eher eine Parallelität von Cloud-Anbietern. Der heterogene Ansatz geht dahin, dass ich nicht nur eine reine Parallelität habe, sondern auch eine Verbindung zwischen den Parallelen, um zu sagen, ich mische jetzt wirklich. Ich nehme zum Beispiel ein System, das geschlossen an sich ist, das könnte ich eigenständig in einer europäischen Cloud betreiben, weil es ein Standard-Container mit Standard-Datenbank, Standard-Webservice ist. Das muss ich nicht unbedingt in einer amerikanischen Cloud betreiben. Das kann ich aber von der europäischen Cloud mittlerweile sehr gut betreiben. Klar, ich muss mir über die Integration dann über diese Netzwerkschicht Gedanken machen, ein bisschen fokussieren, weil jeder Netzwerksprung meine Verfügbarkeit automatisch schwächt. Aber da gibt es genug Konzepte, wie man das ausfallsicher genug machen kann.

Es ist halt schon mal eine bewusste Vielfältigkeit im System. Das ist der grundlegende Unterschied, dass ich eben nicht einfach nur parallel sage, ich mache jetzt den Cloud-Anbieter und den Cloud-Anbieter, dass wenn einer ausfällt oder ich habe Kunden, die wollen gerne etwas mit Azure haben, ich habe Kunden, die wollen gerne etwas mit AWS haben und so. Eher aus dem SaaS-Bereich kommt eigentlich eher Multicloud, aber eben jetzt für die eigene Systemlandschaft intern eine heterogene Cloud Strategie zu haben, ist heute, glaube ich, eher so der erste Schritt Richtung Souveränität.

Gil Breth: Ja. Du hast gerade für mich drei zentrale Dinge gesagt. Das eine ist eine ganz bewusste Entscheidung, also nicht einfach dieses klassische ‘andere machen das so, also machen wir das genauso’ oder ‘das macht man heute so’, was immer das auch bedeuten kann. Und das bedeutet für mich aber auch, es ist ab diesem Moment eine wirklich strategische Entscheidung, die ich sehr bewusst treffen muss, weil es dann auch sicherlich irgendwelche Trade-offs gibt oder auch mittel- bis langfristige Implikationen für das, was ich da mache. Und das dritte, was du gerade angesprochen hast, und das würde ich gerne noch mal ein bisschen beleuchten, aber nicht unbedingt auf dieser Netzwerkebene, ist das Thema der Integration. Du hast auch in deinem Artikel über das Thema API-only versus Data-only Integration gesprochen. Vielleicht kannst du noch mal ganz kurz die beiden Ansätze voneinander abheben, also, was macht da den Unterschied? Was kann man darunter verstehen, wenn wir über das Thema Integration an der Stelle sprechen?

Philipp Beyerlein: Die zwei Ansätze fokussieren sich ein bisschen auf das, was das Wichtigste in meiner Anwendung ist. Durch Containerisierung und so weiter ist es weniger der Ablaufcode, der entscheidend ist. Den kann ich beliebig oft deployen, wo ich will, Hauptsache irgendwo. Das ist sehr einfach gelöst. Was viel schwieriger und viel wichtiger am Ende sind, sind die Daten, weil das natürlich der eigentliche Schatz im System ist. Und wenn ich den Zugang zu meinen Daten verliere, dann bringt mir der beste Container oder die beste Software nichts, wenn die Daten weg sind, sind sie weg. Deswegen gibt es eben den Ansatz zu sagen, okay, ich kann jetzt aufgrund von Feature-Abhängigkeit oder Login-Abhängigkeit, die man mal eingegangen ist, es gab Entscheidungen in der Vergangenheit dafür, aber zum Beispiel kann ich ohne Probleme meine Daten in ein europäisches System replizieren oder ich kann sogar eine europäische gehostete Datenbank benutzen. Hängt ein bisschen von Abhängigkeit und interner Architektur ab, ob das funktioniert und wie man es macht. Aber dann hätte man erstmal, ohne jetzt das ganze System zu reorganisieren, schon mal ein Stück im sicheren Hafen, ein Stück weniger Risiko. Und es lässt sich vielleicht zum Beispiel so ein S3, also so ein Storage, bietet jeder mittlerweile an, auch in Europa ganz viel. Und wenn ich nicht einfach nur einmal in der Woche einen Datenbank-Dump auf diesen europäischen Bucket schiebe, dann habe ich ja schon mal einen Grundstein der Heterogenität in meiner ganzen Architektur gelegt, um zu sagen, ich könnte dann einfach, wenn ich es brauche. Und wenn mir das aber nicht reicht und ich sage zum Beispiel, ich habe jetzt eh ein gut geschnittenes System mit schönen horizontalen, die unabhängig sind über APIs oder Events oder irgendeine Art und Weise integriert sind, dann könnte ich auch hergehen und sagen, ich ziehe einfach meine gesamte Vertikale einfach in eine andere Cloud, um dann eben, wie es eben in einem verteilten System ist, über APIs zu integrieren, zu agieren.

Gil Breth: Du hast jetzt schon ein bisschen über das Thema der Umsetzung gesprochen, wie ich das machen kann. Jetzt sagen wir mal, ich bin noch einen Schritt davor, ich muss überhaupt erstmal die Entscheidung treffen, vielleicht auch als CTO an der Stelle. Gibt es da Ansätze, wie ich die richtige Entscheidung für mein Unternehmen treffen kann? Hast du da vielleicht ein paar Ansätze oder Ideen dazu?

Philipp Beyerlein: Es hängt sehr stark von der bisherigen Architekturstrategie ab. Wenn ich intern eine, sage ich mal, früher klassische horizontale Architektur habe, also ich habe mehrere Schichten, irgendwo ein Frontend-Dialog, dann irgendwas Verarbeitendes hinten und ganz hinten die Daten, dann tue ich mir schwerer, zum Beispiel einen API-Ansatz zu fahren, weil ich eben meine Fachlichkeit über mehrere Horizontale verteilt habe, und dann wird es viel schwieriger. Da wäre dann eher ein datenorientierter Ansatz zu sagen: „Okay, ich sehe jetzt erstmal meine Daten, um einfach nicht noch mehr Komplexität ins System reinzubringen.“ Einfach eine Datenbankspiegelung, das kann ich über technische Komponenten lösen, da muss ich nicht viel anpassen in meiner Software an sich. Das wäre für den Fall, wenn ich aber schon über die Jahre mit Hilfe von DDD oder so in einen Domänenschnitt investiert habe, in eine saubere Vertikalisierung, dann tue ich mir wiederum einfacher zu sagen: „Okay, ich schiebe jetzt eine Vertikale in ein anderes System.“ Also das ist so die, vielleicht sind auch manche momentan im Umbau. Es gibt ja schon seit Jahren einen Weggang von der horizontalen in die vertikale Architektur, und klar, man darf jetzt da nicht noch mehr und noch mehr aufladen in solche Transformationsprojekte, aber einfach so zu berücksichtigen: „Okay, wenn ich jetzt in die Vertikale investiere, dann könnte ich auch eben einfacher sozusagen in die Heterogenität gehen, weil ich dann eben meine gekapselten Einheiten habe, die unabhängig sind, die sauber mit anderen Einheiten integriert sind.“ Dann tue ich mir da viel, viel leichter. Also, wenn ich eben diese klassische Horizontalisierung habe, wo eben alles breit ist, alles groß ist, ist es viel, viel schwieriger, dann noch ein Level draufzupacken.

Gil Breth: Ja, das ist ein guter Punkt. Ich meine auch, du hast in deinem Artikel vom Thema der künstlichen Systemaufteilung gesprochen und auch davor ganz klar gewarnt. Worauf sollte ich denn da achten, oder was können die Folgen davon sein, wenn ich nicht darauf achte?

Philipp Beyerlein: Wenn ich da nicht drauf achte, ist es das Gleiche, was damals mit der Einführung der Microservices passiert ist, dass plötzlich jeder hergegangen ist und einfach wild in seiner Domäne rumgehackt hat, mehr oder weniger. Und dann aber es übertrieben hat. Und ich sage mal so, eine technische Begebenheit sollte nicht eine Domäne auseinanderreißen. Das sollte niemals der Grund dafür sein, seine Domäne zu teilen oder sein System künstlich zu schwächen, weil am Ende ist eine Teilung immer eine gewisse Schwächung des Systems. Und man hat sich ja vielleicht irgendwann mal über Domänenschnitte und so weiter Gedanken gemacht, viel lang und breit, und da jetzt zu sagen, jetzt nur, weil ich jetzt noch heterogen sein will, jetzt künstlich zu sagen: „Ja, jetzt packen wir um eine Datenbank-Layer noch mal eine Schnittstelle, die das abstrahiert oder so.“ Das ist halt dann noch mehr, immer noch mehr Komplexität, die wir da einfach reinladen. Und deswegen immer noch die klassischen Leitlinien, hohe Kohäsion in der Anwendung zu schaffen und in seiner Anwendungslandschaft zu schaffen und dann eben das gesamtheitlich zu verbessern und zu optimieren.

Gil Breth: Ja, ich glaube, diese Bedenken bezüglich Komplexität, das teilen viele. Aber jetzt mal unter uns, wie viel Overhead entsteht aus deiner Sicht wirklich, und ab wann rentiert sich dieser Aufwand an der Stelle dann?

Philipp Beyerlein: Das ist ein knallharter Kosten-Nutzen-Faktor. Also, nicht Nutzen, eher eine Risikobewertung. Das hängt natürlich davon ab, wie stark mein Geschäftsmodell von dem jeweiligen Anbieter abhängig ist. Das muss man individuell bewerten. Das gehört, finde ich, mittlerweile zu einer klassischen Threat-Analyse: Was passiert tatsächlich, wenn mir der Zugang zu dieser Cloud-Plattform in irgendeiner Weise erschwert wird? Es muss jetzt gar nicht sein, dass man keinen Zugriff hat, aber zum Beispiel einfach die Kosten werden künstlich nach oben getrieben, und das beschädigt ja mein Geschäft am Ende. Und das muss natürlich den Mehraufwand, den man mit der Heterogenität hat, der ist definitiv da. Also, ich muss mehr Netzwerk, mehr Verträge, mehr Struktur bereitstellen und so weiter. Auch die Leute müssen sich mit mehreren Cloud-Anbietern beschäftigen. Also, es ist schon ein Investment, aber da muss natürlich das Risiko gewährt sein. Wenn ich sage: „Okay, ich habe die Cloud ist nur eine Spiegelung von Daten, die sowieso On-Premise vorhanden sind und ist eigentlich gar nicht so abhängig.“ Klar, momentan ein wichtiger Einfallstor oder für die Webseite oder so was wichtig, aber ich könnte es theoretisch bei einem X-beliebigen anderen in überschaubarer Zeit auch hochfahren, dann würde es ausreichen, wenn man sagt: „Okay, ich beleuchte den Fall einfach, dokumentiere das, bin mir der Gefahren bewusst und entscheide mich dafür, der Aufwand rechtfertigt das Risiko momentan nicht.“ Aber wenn ich natürlich andersrum bin und sage: „Okay, wenn jetzt der Cloud-Anbieter, wenn ich nicht mehr hinkomme, sind meine Kunden weg. Habe ich keinen Umsatz mehr.“ Dann ist es natürlich, wenn ich dann ist so eine Investition, ich habe einmal irgendwo einen Job, der die Datenbank irgendwo hinsichert und ich sage: „Okay, jetzt habe ich zumindest schon mal kein grundsätzliches Problem mehr, dass die Daten dann weg sind.“ Dann ist ja schon mal eine Entspannung da. Und dann kann ich sagen: „Okay, jetzt steige ich da mehr ein.“ Und je tiefer ich mich vielleicht mit einem deutschen oder europäischen Anbieter beschäftige, vielleicht stelle ich auch fest, die Dienste, die der anbietet, reichen mir vollkommen aus. Ich brauche gar nicht so diese Hyperscaler-Funktionalität. Ich habe kein X-beliebig skalierendes Kundschaft, ich muss keine absolute Hochverfügbarkeit anbieten und so weiter. Da kommt dann vielleicht klar, die Cloud-Anbieter, die bieten so einen Full Service an, das machen sie bequem und da fühlt man sich dann wohl, wenn man automatisch ganz viel kriegt, aber vielleicht kriegt man auch einfach ein bisschen zu viel und da ist dann auch und da ist eben die gar nicht bewusst: „Okay, ich könnte eigentlich auch mit ein bisschen weniger das Gleiche erreichen.“

Gil Breth: Ja, ich stelle mir auch manchmal die Frage, befindet man sich da als Unternehmen in der Komfortzone oder in der Angstzone, man könnte vielleicht was verpassen oder weil andere es eben genauso machen. Kann ich bestätigen aus vielen Gesprächen, die ich so führe. Du hast aber eben diese Kombination aus europäischen Cloud-Anbietern als Alternative zur US-Hyperscalern skizziert. Und was ich auch so aus den Gesprächen mit anderen im Markt feststelle, ist immer dieses: „Ja, ist das wirklich realistisch oder ist das nur Wunschdenken?“ Also, wie siehst du das? Oder gibt es noch echte Lücken?

Philipp Beyerlein: Die größte Lücke ist eigentlich, dass es niemand, also, ich habe bisher keinen gefunden, der wirklich das, was die Großen können, komplett anbietet. Es gibt zwar schon so eine Grundlinie, die alle irgendwie hinkriegen, aber es gibt dann in den Nuancen schon Unterschiede. Die einen haben zum Beispiel, gerade was Datenbanken angeht, nur normale relationale Datenbanken als Service, und dann gibt es manche, die haben auch noch MongoDB als Betrieb. Also da tun sich so ein bisschen so an den Feinheiten unterscheiden, oder gerade was jetzt eben mit KI, mit Inferenzbetrieb und so weiter, da unterscheiden sie sich stärker. Aber ich sage jetzt mal so, bei den großen europäischen wie Telekom Cloud, Ionos und Co, da kriegt man eigentlich immer eine S3, immer eine Datenbank, immer eine Container-Orchestrierung, also Kubernetes oder zum Teil auch schon höherwertig, dass ich kein Cluster mehr brauche. Also das bieten die im Grunde alle irgendwie an. Dann noch ein bisschen Management drumherum, eine Terraform-Schnittstelle, und dann kann ich die eigentlich, wenn ich zum Beispiel jetzt eh schon Terraform habe, kann ich die halt einfach parallel mit verwalten.

Gil Breth: Ja, ich hatte es eingangs schon gesagt, das heute wird eine kurze, knackige Folge, eine Impulsfolge, so haben wir es genannt, und ich würde dich jetzt gerne gegen Abschluss dieser Folge um einen Blick nach vorne mal bitten. Also, was glaubst du, wohin geht die Reise? Wird das Thema Multicloud der neue Standard oder ist das vielleicht nur eine Nischenlösung, also zum Beispiel für regulierte Branchen? Gib mal bitte eine Einschätzung ab.

Philipp Beyerlein: Ich persönlich glaube, dass die heterogene oder Multicloud-Strategie ein Übergang ist, weil je mehr Firmen sich sozusagen multi- oder heterogen aufstellen, desto eher kommt irgendwie der Wunsch, ein System zu haben, was einen dabei unterstützt.

Um langfristig zum Beispiel, eben wenn ich jetzt zwei, drei Anbieter habe, muss ich ja eben Verträge mit denen managen, muss ich mich um die API-Integration kümmern, die Netzwerkintegration kümmern. Es wird halt, also da kann ich dann eine ganze Mannschaft beschäftigen und es müssen halt mehrere parallel beschäftigt werden, und dann wäre natürlich der nächste Schritt zu sagen: „Okay, wieso gibt es nicht einen, der die koordiniert, der mir unterstützt?“ Weil die Technologien an sich, die sind ja da, sage ich immer so. Autorisierung dezentralisiert, auch Container-Orchestrierung und so weiter, das sind alles Technologien, die sind schon da und die werden auch schon genutzt, und zwar von den großen amerikanischen Herstellern. Die sind ja an sich so groß geworden, weil die intern eine sehr starke Standardisierung haben und eine Entkopplung von dem sozusagen der eigentliche Betrieb, das macht zum Beispiel eine Telekom oder so weiter, die stellen halt einen gewissen Grundstock bereit und dann gibt es den nächsten, der macht das obendrauf und dann noch weiter obendrauf, und die haben das alles über die Jahre standardisiert, so dass ich einfach eben eigentlich eine interne sehr heterogene Masse habe, die ich dann über eine Schnittstelle synchronisiert bekomme und bespielt bekomme. Und da wird meiner Meinung nach die Reise hingehen, weil wenn ich jetzt das Spiel weitertreibe, ich stelle jetzt fest: „Okay, ein europäischer Anbieter passt für mich und ich ziehe da um von dem amerikanischen zu einem europäischen.“ Dann bin ich aber trotzdem wieder nur von einem abhängig. Das heißt, die Souveränität an sich hat sich vielleicht auf internationalem Level vielleicht verbessert, aber für mein Geschäftsmodell an sich eigentlich gar nicht. Ich bin jetzt halt von dem anderen abhängig.

Gil Breth: Ja, ich habe die eine Abhängigkeit gegen die andere getauscht.

Philipp Beyerlein: Genau. Und jetzt ist natürlich die Frage, was können wir als Europäer oder als Gesellschaft dagegenhalten? Es ist schon fast die Frage, was wir als Gesellschaft tun können. Und da gibt es ein gutes altes Konzept, das kennt vielleicht jeder aus seinem eigenen Ort: die Genossenschaft zum Beispiel, oder eher demokratisch organisierte Systeme, wo sich nicht einer über Kapitalmacht mehr Rechte sichert als die anderen, sondern man schließt sich zusammen, man hat einen gemeinsamen Bedarf und versucht, diesen lösungsorientiert und gemeinschaftlich umzusetzen, ohne dass sich eine Monopolisierung herausstellt. Deswegen ist es langfristig so, dass ich glaube, dass wir von diesen ganzen Plattformgedanken, was eine Cloud bietet, nicht wegwollen. Niemand will wieder daheim Serverfarmen hochziehen, das ist einfach nicht mehr Stand der Technik. Aber die Plattformökonomie muss meiner Meinung nach geändert werden. Weg von der Einzelzentralisierung hin zu einer föderalen Form, wo verschiedene Teilnehmer gleichwertig mitspielen können. Und das ist eben die Stärke von Europa. Wir haben, weil wir eben so viele zwar kleinere, aber sehr spezialisierte Firmen haben, die sich gut in ihren Themen auskennen. Wir haben viele gute VM-Betreiber, wir haben viele, die sich mittlerweile gut mit Container-Orchestrierung auskennen, mit Datenbankbetrieb, und die müssen wir nur zusammenbringen. Und da brauchen wir vielleicht gar nicht die Telekom zum nächsten Hyperscaler machen oder Ionos zum nächsten Hyperscaler machen, sondern wir sind schon der Hyperscaler in Europa. Wir sind es schon, wir müssen uns nur zusammentun. Und eben eine gemeinsame, gleichwertige Lösung bauen oder definieren, denn die Technologien sind da. Wir müssen sie nur kombinieren und umsetzen.

Gil Breth: Ja, die Gedanken, die mich da manchmal umtreiben, sind: Es klingt manchmal so, als wäre es alter Wein in neuen Schläuchen, wenn man schon länger dabei ist. Aber es mangelt manchmal am Umsetzungswillen, und oft wird dann immer auf die politische Ebene verwiesen, aber ich sehe das auch manchmal bei Unternehmen. Es muss dieser Wille da sein, und das Beispiel mit der Genossenschaft finde ich auch deswegen so schön, weil es eigentlich dem Grundgedanken des Internets, auf dem das ja alles fußt, gerecht wird, und zwar Dezentralität beziehungsweise auch eine hohe Auswahl und nicht diese reinen Monokulturen, wo man vielleicht über fünf, sechs große Lösungen oder Anbieter spricht. Deswegen finde ich den Gedanken schön. Ich würde auch dann an dieser Stelle hiermit die Folge heute abschließen und diesen Gedanken mal bei unseren Zuhörerinnen und Zuhörern lassen und mal die Einladung aussprechen: Wer Lust hat, da mal mit uns in den Dialog zu treten oder diesen Gedanken auch weiterzuspinnen, soll sich einfach mal bei uns melden. In den Shownotes werden wir dazu auch zu den Themen Links und Quellen verlinken, und wir freuen uns natürlich aber auch über Feedback zur Folge. Ich habe es eingangs schon mal gesagt, ich glaube, es ist das dritte Mal, dass ich es erwähne: Es soll eine Impulsfolge sein, wir wollen an der Stelle zum Nachdenken anregen, vielleicht haben wir den ein oder anderen Impuls setzen können. Und wenn das so gewesen sein sollte, freuen wir uns natürlich auch darüber, wenn jemand oder wenn ihr da draußen unseren Podcast abonniert. Philipp, vielen lieben Dank für deine Einsicht, für dein Wissen, das du hier heute mit uns geteilt hast. Und ich freue mich darauf, wenn wir den Dialog vielleicht auch noch in anderen Formen fortführen können, und verabschiede mich an der Stelle und sage: Bis zum nächsten Mal, habt eine gute Zeit.

Philipp Beyerlein: Vielen Dank, Gil, und wünsche den Zuhörern eine gute Zeit.

Gil Breth: Ja, danke sehr.

This summary was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Multicloud vs. heterogene Cloud – wo liegt der Unterschied?

Multi-Cloud bedeutet oft nur eine parallele Nutzung mehrerer Anbieter, etwa AWS für externe, Azure für interne Systeme. Die heterogene Cloud geht einen Schritt weiter: Anwendungen und Daten werden bewusst nach Unabhängigkeitskriterien verteilt, und verschiedene Anbieter werden aktiv miteinander vernetzt - nicht nur nebeneinandergestellt. Das schafft echte Flexibilität und vermeidet neue Monodependenzen.

Digitale Souveränität als strategischer Treiber

Der Haupttreiber hinter dem heterogenen Ansatz ist die digitale Souveränität. Unternehmen, die ausschließlich auf einen US-Hyperscaler setzen, sind politischen, regulatorischen und wirtschaftlichen Risiken ausgesetzt – etwa durch künstliche Preiserhöhungen oder eingeschränkten Zugang. Ein heterogener Ansatz ist keine Panikreaktion, sondern eine bewusste Risikoabwägung.

Zwei Integrationswege: API-First vs. Data-First

Die Wahl des Integrationsansatzes hängt von der bestehenden Architektur ab. Wer bereits vertikal geschnittene Systeme (z. B. nach DDD) betreibt, kann ganze Domänen in andere Clouds verschieben und über APIs integrieren. Wer noch horizontal aufgestellt ist, profitiert zunächst vom einfacheren Data-First-Ansatz: Datenbankspiegelungen oder regelmäßige Backups auf europäischen Storage-Diensten schaffen erste Souveränität ohne große Systemeingriffe.

Warnung vor künstlicher Systemaufteilung

Ein häufiger Fehler: Systeme werden aus technischen Gründen aufgesplittet, obwohl fachliche Domänen intakt bleiben sollten. Wie bei der Einführung von Microservices kann ein unkontrolliertes Aufteilen die Systemkomplexität unnötig erhöhen. Philipp empfiehlt: Domänengrenzen dürfen nicht aus Cloud-Strategie-Gründen aufgebrochen werden.

Risikobasierte Entscheidung – Threats-Analyse für CTOs

Ob und wie weit ein Unternehmen in Heterogenität investiert, sollte auf einer klaren Risikoabwägung basieren. Fragen wie „Was passiert, wenn ich den Zugang zu diesem Anbieter verliere?" oder „Wie stark hängt mein Umsatz daran?" helfen bei der Priorisierung. Der Mehraufwand – mehr Verträge, mehr Know-how, mehr Infrastruktur – ist real, muss aber dem konkreten Risiko gegenübergestellt werden.

Europäische Anbieter: Lücken und Potenziale

Kein einzelner europäischer Anbieter deckt aktuell das Gesamtportfolio eines US-Hyperscalers ab. Aber: Grundlegende Services wie Container-Orchestrierung (Kubernetes), relationale Datenbanken, S3-kompatibler Storage und Terraform-Schnittstellen bieten viele europäische Anbieter wie Telekom Cloud oder Ionos bereits an. Für viele Workloads reicht das aus.

Der Ausblick: Heterogenität als Übergang zu einer föderalen Cloud-Infrastruktur

Langfristig könnte die heterogene Cloud ein Übergang zu einer föderalen, genossenschaftlich organisierten europäischen Cloud-Infrastruktur sein. Europa hat viele spezialisierte Anbieter – von Netzwerkbetrieb über Datenbankhosting bis Containerorchestrierung. Die Technologien sind vorhanden. Was fehlt, ist die Koordination: ein gemeinsames, standardisiertes Ökosystem, das die Stärken der Einzelanbieter zusammenbringt, ohne neue Monopole zu schaffen.

Zitat-Highlight:

„Wir sind schon der Hyperscaler in Europa. Wir müssen uns nur zusammentun und eine gemeinsame, gleichwertige Lösung bauen."

Fazit:

Heterogene Cloud-Strategie ist kein Trend, sondern eine strategische Notwendigkeit für Unternehmen, die echte Unabhängigkeit anstreben. Der erste Schritt muss nicht groß sein – ein Datenbank-Backup auf einem europäischen Bucket reicht als Einstieg. Entscheidend ist, bewusst zu handeln statt einfach den Marktstandard zu kopieren.