Hier ist eine Übersicht der Tools, die ich nutze, das Geld, das ich spare, und die wenigen Hürden, über die ich noch (immer) stolpere.

Übrigens: Dieser Beitrag richtet sich an persönliche Setups, nicht an Unternehmen. Die meisten Tools lassen sich aber auch für Teams und Firmen nutzen.

Das Rückgrat: Das Proton-Ökosystem

Den größten Einfluss auf diese Migration hatte Proton. Das Unternehmen hat sich von einem einfachen Anbieter verschlüsselter E-Mails zu einem (fast) vollständigen Produktivitäts-Komplettpaket entwickelt.

Kurze Anmerkung vorab: Ja, Proton ist nicht in der EU ansässig, aber der Schweizer Datenschutz ist mit den EU-Anforderungen abgestimmt und in manchen Bereichen sogar strenger, in anderen wiederum flexibler für Nutzer und Anbieter.

Mein Abonnement umfasst jetzt:

• Mail & Kalender: Verschlüsselt und aufgeräumt.

• Drive: Sicherer Cloud-Speicher, seit einer Weile mit Docs, und jetzt auch mit Tables.

• Proton Pass: Ein solider Passwortmanager mit 2FA-Integration.

• VPN: Schnell und zuverlässig.

• Meet: Recht neu, brauch ich nicht wirklich oft aber funktioniert auch sauber

• Lumo AI: Eine datenschutzorientierte KI, ich nutze sie noch nicht regelmäßig, hab kein Abo dazu. aber dazu gleich mehr.

Außerdem benutze ich Standard Notes: Mein bevorzugtes Notiztool, unterstützt vom Proton-Team. (ABER, es ist ein US Unternehmen. Warum nutze ich es trotzdem? a) Sourcecode ist offen, ich kann jederzeit davon Weg b) ich kann es selber hosten c) starke Verschlüsselung ((ja, ja, kann man immer knacken etc…))).

Zurück zu Proton: Alles ist integriert und die Nutzererfahrung ist Gut. Proton Drive ist auf dem Smartphone viel zu langsam. Nutze es dort aber auch selten.

Dieses Setup ersetzt für mich Google Drive und das Gmail-Ökosystem plus NordVPN, Notion, 1Password und einen Authenticator.

Neugierig? Ich hinterlasse hier meinen Empfehlungslink.

Meine gemischte KI-Strategie

KI ist das Schwierigste, von Big Tech zu lösen.

Für sehr sensible KI-Aufgaben in meinem Workflow nutze ich Lumo AI. Es eignet sich gut für schnelle, private Anfragen, ohne großes Reasoning, Research etc., jedoch habe ich kein Abo, der Free Tier reicht mir aus.

Manchmal braucht man aber rohe Rechenleistung. Dafür habe ich angefangen, Mammouth zu nutzen, weniger aus Datenschutzgründen, sondern wegen des unschlagbaren Preis-Leistungs-Verhältnisses. Für 10€ Zugang zu allen gängigen KI-Modellen (einschließlich Bildgenerierung) ist einfach unglaublich.

Meine Standardauswahl bei Mammouth sieht so aus, man kann die Modelle nach Priorität sortieren, das ganz linke ist der Standard:

Die zwei Modelle, die ich am häufigsten nutze, sind Mistral Medium 3.1 und Flux 2 Pro oder Flux Fast. Für einfache Coding-Aufgaben verwende ich ebenfalls Mistral, bei größeren Codebasen gebe ich aber zu, dass ich auf Claude Code mit Opus zurückgreife.

Für Recherchen erledigt Mistral seinen Job. Bei komplexeren Themen liefert Gemini oft die besten Ergebnisse.

Und Flux für Bilder ist fantastisch, hat aber meiner Meinung nach einen großen Nachteil: Man muss sehr präzise Anweisungen geben. Während ein „Nano Banana” auch aus kurzen, einfachen Eingaben kreativ wird, braucht Flux genaue Vorgaben.

Was sich noch stark geändert hat: Ich nutze lokal in AnythingLLM Whisper um quasi Sprachnotizen zu machen oder aber auch Meetings aufzuzeichnen. Whisper ist hier imo 100 mal besser als Copilot (muss/darf ich an der Arbeit verwenden), weil es Multi-Lingual kann, was Copilot nicht beherrscht. Meeting Summaries etc. kann es auch und das alles lokal.

Browser, Suche und Sprache

• Browser: Ich bin zu Vivaldi gewechselt. Hochgradig anpassbar und respektiert die Nutzerdaten. Und nutze als Backup wenns mal auf ner Webseite klemmt Brave.

• Suche: Mein Standard ist Ecosia. Es funktioniert gut und Bäume beim Suchen zu pflanzen gibt dem gedankenlosen Scrollen eine nette Bedeutung. Manchmal muss ich aber doch auf Google zurückgreifen.

• Übersetzung: DeepL nutze ich schon ewig. Es ist nach meiner Einschätzung Google Translate in Sachen Nuancen und Qualität noch immer weit voraus.

• Rechtschreibprüfung: … Hier habe ich noch keine gute Alternative gefunden und bleibe bei Grammarly.

Infrastruktur: Hosting & Domains

Für meine Website und Domains habe ich alles zu Scaleway umgezogen.

Wer technisch versiert ist, wird diesen Wechsel zu schätzen wissen. Der Dienst ist schlank, einfach und bietet alles, was man als Cloud-Anbieter braucht ohne den Overhead von AWS oder Azure. Und günstiger ist er auch.

Kreativität & Aufgabenverwaltung

Canva… was soll ich sagen.

Dank einer Diskussion auf LinkedIn habe ich Superlist entdeckt, zu dem ich von Todoist gewechselt bin. Zwischendurch hatte ich auch kurz MeisterTask ausprobiert, aber das war reine Zeitverschwendung.

MeisterTask fühlt sich an wie ein Kindergartenspielplatz: zu viel buntes Design und zu wenig echte Funktionalität. Es ist zu 100% nicht intuitiv für irgendeinen Workflow.

Ich bin jetzt bei Superlist und sehr zufrieden.

Die Wirtschaftlichkeit: Datenschutz ist tatsächlich günstiger

Wir nehmen oft an, dass „Boutique”-Datenschutztools einen Aufpreis kosten. Meine Migration hat mir das Gegenteil bewiesen. Anfangs hatte ich nur von einer kleinen Ersparnis geschrieben, hatte aber die Kosten für Notion, Todoist, 1Password, Claude und Canva übersehen, da ich mich auf die „Office”-Suite konzentriert hatte.

• Alter Stack: ca. 83€/Monat

• Neuer EU-Stack: ca. 39€/Monat

Ich spare über 528€ im Jahr und besitze dabei den Großteil meiner Daten.

Was man dazu sagen muss:

Sovereignty ist kein An/Aus Schalter, sonder ergibt sich immer aus der Frage wie Souverän kann ich werden ohne das ich Autark bin und damit aber wiederum die Anknüpfung ans Weltgeschehen verliere. Denn…

Open Source und Autarkie oder wie man es in 2026 schafft wie im Mittelalter zu leben

Auf meinen original Post in Englisch hab ich sehr viel Feedback bekommen, positiv wie auch sämtliche Schwurbler, Weltverschwörer und “An jeder Ecke gibts nen Spion”. (Um die gehts mir aber nicht hierbei).

Denn wer sich auch sehr oft bemüht ist die Ecke “Souveränität gibts nicht”, “alles muss Open Source sein, koste es was es wolle”, “Du musst alles selbst hosten” usw.

Ganz ehrlich, das ist der größte Blödsinn. 99% der Menschen ist nicht in der Lage etwas selbst zu Hosten. Und das müssen sie auch nicht. Mir geht es darum einen Ansatz zu zeigen der für Jedermann/frau funktionieren kann.

Und natürlich gibt es Tools die noch losgelöster sind und noch mehr Autarkie versprechen. Viele dieser Lösungen sind aber er nicht Benutzerfreundlich oder Esthetisch in der Nutzung und Bedarfen sehr viel Pflege und Aufwand.

Wo Licht ist, ist auch Schatten

Ich möchte aber auch transparent sein: Nicht alles lässt sich vermeiden, und manches ist einfach umständlicher.

• Das „schlechte Gewissen”: Als Technikbegeisterter macht es mir zu viel Spaß mit Claude Code zu arbeiten. Das ist ein Luxus, den ich mir gönne. Ich schalte das Abo daher gelegentlich ein. Bin wieder im dauer Abo Modus, “Code” aber quasi täglich. Wer diesen Anwendungsfall nicht hat: → Mistral, Lumo

• Das soziale Netz: LinkedIn, GitHub, YouTube, Medium, Substack und Co. lassen sich einfach nicht umgehen, wenn man vernetzt bleiben will.

• Komfort: Google SSO fehlt mir. Es ist überall, und der Verlust dieses „Ein-Klick-Logins” macht das Leben ein kleines bisschen umständlicher. Ich habe alle Logins auf Proton Pass mit MFA und Passkey migriert, wo immer möglich. Aber man ist immer sehr in Versuchung den Google Knopf zu drücken.

• Office-Suite: Ich tue mich schwer, mich an LibreOffice und Collabora Online zu gewöhnen. Sie fühlen sich ähnlich wie MS Office an, aber eben „nicht ganz”. Da ich für den persönlichen Gebrauch nicht täglich Dokumente oder Tabellen erstelle, fühlt sich die Lernkurve steiler an als nötig. Egal → Proton Docs und Sheets erledigen das. Im schlimmsten Fall nehme ich für Präsentationen Canva, das zahle ich sowieso.

• Bloggen, Newsletter & Co.: Wie man sieht, schreibe ich auf Substack. Alternativen gibt es kaum, außer alles selbst zu hosten, aber das macht für mich gerade keinen Sinn.

Die unerwarteten Entdeckungen

Es gab auch einige positive Nebeneffekte. Die Proton-Plattform selbst bietet alles für den täglichen Bedarf.

Außerdem bin ich mit meiner Frau auf einen Duo-Plan umgestiegen. Gemeinsam haben wir 2TB Speicher für Mails, Dateien usw. Vorher hatten wir 30GB bei Gmail für etwas mehr Geld.

Proton Pass erstellt anonyme E-Mail-Adressen, falls man die echte Adresse nicht verwenden möchte, das spielt voll auf Protons Datenschutzphilosophie ein.

Superlist ist kostenlos für dieselben Funktionen, für die ich bei Todoist ein kleines Abo bezahlt habe.

Und schließlich kämpfe ich immer wieder mit Notizen. Ich habe alles getestet und angefangen, etwas Komplexes in Notion aufzubauen. Ich bin froh, dass ich es löschen und einfach Standard Notes jetzt nutze. Einfach gesagt: Es ist wie Notizen von Apple, aber Ende-zu-Ende-verschlüsselt und offline sicherbar. Am hilfreichsten war aber, dass ich endlich einen effizienten Umgang mit Notizen gefunden habe, schlank, sauber und funktional.

Fazit

Mit Proton, Scaleway, Mammouth, Vivaldi, Superlist und DeepL habe ich ein nützliches Werkzeugset aufgebaut, das meiner Meinung nach das übertrifft, was ich vorher hatte.

Die Apps sind übersichtlicher, die Benutzeroberflächen oft benutzerfreundlicher, und die Migration war überraschend einfach. Und das Beste: Ich kann mit meinem Tech-Stack mehr tun für weniger Geld.

Wer noch zögert, zu EU-gehosteten Lösungen zu wechseln: Wagt den Schritt. Es lohnt sich.

Aber die Antwort darauf ist nicht der Monolith. Das Problem ist nicht die Komplexität.
Was oft fehlt ist einfach ehrlich zu sein.

Was am Monolith-Argument stimmt

Ein Monolith ist im ersten Schritt einfacher. Ein Repository, ein Deployment, ein Logfile. Man braucht keinen großen CI/CD und GitOps Maschinerien, keine verteilte Tracing-Lösung, keine drei verschiedenen Datenbanken, die irgendwie konsistent bleiben müssen. Ein Entwickler kann das System lokal starten und verstehen, was passiert. Das kann ein riesen Vorteil sein. Und ja, für viele Unternehmen ist das genau die richtige Antwort. Nicht jedes Startup braucht die Architektur von Netflix.

So weit, so unstrittig.

Was gerne unter den Tisch fällt

Wenn der Monolith ausfällt, ist alles weg. Nicht ein Teilbereich, nicht “die Suche funktioniert gerade nicht, aber Checkout läuft”, sondern alles. Für viele Produkte ist das akzeptabel. Für andere existenzbedrohend. In einem meiner vorherigen Berufsleben wurde die Kernentwickler aus dem Urlaub zurück geflogen wenn unsere zentrale Anwendung stehengeblieben ist. Diese Abwägung wird in der aktuellen Debatte praktisch nie gemacht. Es geht immer um Entwicklungsgeschwindigkeit, Kosten, Komplexität und nie um operative Resilienz.

Klar, wenn ich nur 400 User habe ist der Schaden vermutlich gering. Hab ich aber ein Produkt/Service der viel genutzt wird, steigen Kunden auch schnell um. Kunden zahlen für Verfügbarkeit.

Dazu kommt: Monolithen skalieren in einer Dimension miserabel und zwar in der Dimension, die sich am wenigsten messen lässt. Sobald mehr als ein Team daran arbeitet, wird jeder Merge zur Verhandlung, jedes Deployment zum Risiko, jede Datenbankänderung zur Migration mit Eskalationspotenzial. Das passiert nicht ab Tag eins. Aber es passiert verlässlich ab einer bestimmten Größe.

Interessanterweiße werden diese Argumente oft auch gegen Mircroservices herangezogen. Meine Antwort darauf: Wenn dass die Gründe sind warums bei euch nicht läuft, dann ist es kein Microservice, dann ist es ein Micro-Monolith. Schlecht gebaut, vermutlich fehlendes Wissen und Kompetenz.

Der eigentliche Punkt

Wir reden so, als wäre die Wahl zwischen “Monolith” und “Microservices” eine reine Architekturfrage. Das ist sie nicht. Sie ist zu einem nicht unerheblichen Teil eine Frage, was die Organisation und deren Engineers eigentlich kann.

Und da sehe ich ein Problem, das größer ist als jede Architekturdiskussion: Die Skill-Lücke in vielen Unternehmen wird breiter, nicht schmaler. Die Generation, die noch wusste, wie ein Betriebssystem funktioniert, wie TCP eigentlich tickt, was eine Datenbank tut, wenn niemand hinguckt, die geht in Rente. Und in den Pipelines dahinter steht oft erschreckend wenig. Nicht weil die jungen Leute dumm wären. Sie sind es nicht. Sondern weil unser Ausbildungs- und Anreizsystem darauf optimiert ist, schnell produktiv zu sein, nicht tief zu verstehen. Wer ein Framework bedienen kann, gilt als Senior, bevor er je einen Production-Incident debuggt hat.

“Früher” (jaaaa früher), konnte man von einer Senior stelle träumen wenn man ein absoluter Experte ist auf seinem gebiet und darüber hinaus. Wenn man sehr viel gesehen hat, sehr viel gemacht hat, sehr viel erlebt hat. Heute, erwartet man das mit 1-2 Jahren Arbeitserfahrung und nem Master, man auch automatisch Senior ist. Außerdem fehlt es bei vielen Menschen an dem Antrieb sich ständig weiter zu entwickeln, sich neuen Schwierigkeiten zu stellen, an Themen zu arbeiten die man noch nicht gemacht hat.

Diese Zurückhaltung ist ein Problem. Sehr oft ist es sogar Angst. Weil die Kompetenzen und Erfahrungen fehlen. Diese werden unterschätzt, auch weil sich viele “Junge Talente” ins internet Stellen und über ihre Erfolge sprechen, ohne das die jemals jemand hinterfragt hat. Dies vermittelt ein Vollkommen falsches Bild.

Wenn jetzt also Unternehmen reflexartig zum Monolithen zurückkehren, dann passiert oft etwas, das niemand offen ausspricht: Es ist nicht primär eine technische Entscheidung. Es ist eine Anpassung an die verfügbare Kompetenz. Wir bauen die Systeme einfacher, weil wir die Leute nicht mehr haben, die komplexere Systeme betreiben können. Das ist auf kurze Sicht klug. Auf lange Sicht ist es eine Spirale: Einfachere Systeme produzieren auch einfachere Anforderungen an Entwickler. Anforderungen formen Kompetenzen. In zehn Jahren ist das Wissen, wie man verteilte Systeme baut, nicht nur knapp, es ist weg. (etwas überzogen gesprochen)

(Monolithen hier als einfach zu bezeichnen ist etwas übergriffig, als Enterprise Architekt hatte ich oft mit System zu tun die zwischen 1-2 Millionen Codezeilen hatten, und die alles andere als einfach waren.)

Die unbequeme Position

Meine These ist deshalb: Komplexität ist kein Bug der modernen IT, den wir wegoptimieren können. Sie ist die natürliche Folge davon, dass wir global verfügbare, hochintegrierte, datenintensive Produkte bauen wollen. Wer die nicht bauen will, kann mit einem Monolithen glücklich werden. Wer sie bauen will und das werden viele müssen, ob sie wollen oder nicht, muss die Komplexität tragen können. Und das bedeutet: Skill, nicht Architektur, ist die eigentliche Engstelle.

Die Frage ist also nicht “Monolith oder Microservices?”. Die Frage ist: Bauen wir Unternehmen, die in der Lage sind, anspruchsvolle Systeme zu betreiben oder akzeptieren wir leise, dass wir das nicht mehr können, und richten unsere Technik daran aus?

Beides ist legitim. Aber wir sollten ehrlich sein, welche Entscheidung wir gerade treffen. Der Monolith-Hype auf LinkedIn klingt nach Pragmatismus. Manchmal ist er aber auch nur Kapitulation in hübscher Verpackung. Manchmal ist er das laute Plappern von den offensichtliche Fakten, aber ohne dem Verständnis was dahinter steht.

Was denkt ihr? Sind Architekturentscheidung in eurem Umfeld noch eine technische Diskussion, oder längst eine ehrliche Bestandsaufnahme der eigenen Kompetenz?

Es gibt diesen Moment in fast jedem Budgetmeeting, in dem die Cloud‑Rechnung auf dem Tisch landet und niemand mehr weiß, warum sie schon wieder gestiegen ist. Wer als IT‑Entscheider die letzten zehn Jahre mitgegangen ist, hat den Erzählbogen verinnerlicht: „Cloud‑First” galt als Vernunftgebot und wer sich verweigerte, war Bedenkenträger. Aber es lohnt sich, diese Erzählung kühl zu prüfen.

Die Datenlage und ein wachsender Chor prominenter Praktiker legt eine andere These nahe: Cloud‑Provider und Managed Services werden systematisch überbewertet, ihre Vorteile stehen für viele Workloads in einem schlechten Preis‑Leistungs‑Verhältnis und der Preis dafür ist nicht nur monetär, sondern auch ein Verlust an betrieblicher Fähigkeit und Substanz.

27 Prozent Verschwendung sind kein Betriebsunfall

Die Zahlen aus dem Flexera State of the Cloud 2025/2026 sind ernüchternd: 27 bis 29 Prozent aller Cloud‑Ausgaben gelten als verschwendet, 84 Prozent der Unternehmen nennen das Cloud‑Kostenmanagement als ihre größte IT‑Herausforderung, und Budgets werden im Schnitt um 17 Prozent überschritten. Die FinOps Foundation, eigentlich eine Lobby‑Organisation der Cloud‑Optimierung, kommt zu ähnlichen Werten: Seit fünf Jahren stagniert die Quote zwischen 27 und 32 Prozent.

Stagnation ist hier das Signal. Diese Verschwendung ist strukturell, nicht zyklisch. Die IDC schätzt das globale Public‑Cloud‑Volumen 2024 auf 805 Milliarden Dollar mit Verdopplung bis 2028. Das hochgerechnete Verschwendungsvolumen liegt damit weltweit oberhalb von mindestens 200 Milliarden Dollar pro Jahr, Geld, das eben nicht in Innovation, Mitarbeiter oder Wettbewerbsfähigkeit fließt.

Wer glaubt, das sei ein Lückenproblem, das sich mit „etwas mehr FinOps” lösen lässt, sollte einen Blick auf die Margen werfen. Hyperscaler operieren mit operativen Margen von 30 bis 40 Prozent. Anders formuliert: Für jeden Euro Infrastruktur, den Sie konsumieren, zahlen Sie 30 bis 40 Cent Marge an Ihren Vermieter. Das ist ein legitimes Geschäftsmodell, aber es als „kosteneffizient” zu verkaufen, ist Marketing.

Die Repatriation‑Welle ist real aber differenziert

Fast jedem ist das Beispiel von 37signals bekannt. Diese senkten ihre Infrastrukturkosten von 3,2 Millionen auf 1,3 Millionen Dollar im Jahr, bei etwa 700 000 Dollar Einmalinvestition in eigene Server, die sich binnen eines Jahres amortisierte. Oft werden hier von Skeptikern Migrations- und Personalkosten noch ins Feld geführt. Ein offizielles Statement gibt es dazu nicht, jedoch Kommentare, dass dasselbe Team für Cloud und Applikation die Migration durchgeführt hat und weiterhin den Betrieb gewährleistet hat.

Dropbox sparte mit seiner Eigenbau‑Initiative „Magic Pocket” laut S‑1‑Filing rund 75 Millionen Dollar in zwei Jahren. GEICO stand 2021 bei über 300 Millionen Dollar Cloud‑Spend pro Jahr, einem 2,5‑fachen Budget‑Overrun, und reduziert seither über offene Hardware‑Standards die Compute‑Kosten pro Core um 50 Prozent.

Der Barclays CIO Survey Q4 2024 zeigt, dass 83 Prozent der CIOs zumindest einige Public‑Cloud‑Workloads zurück on‑prem oder in Private Clouds verlagern wollen. IDC beziffert für 2024 den Anteil der Unternehmen mit Repatriation‑Plänen auf rund 80 Prozent.

Wichtig für die Einordnung: Es geht nicht um den theatralischen Cloud‑Exit. Nur 8 bis 9 Prozent der Unternehmen planen Voll‑Repatriationen. Die Bewegung ist selektiv und ökonomisch motiviert, aber die Ergebnisse sprechen für sich.

Der unterschätzte Schaden: Verlust an Betriebskompetenz

Aber es wird noch unbequemer. Die Linux Foundation berichtet, dass 92 Prozent der Organisationen Schwierigkeiten haben, qualifizierte Cloud‑Talente zu finden. Mehr als 75 Prozent haben Projekte wegen Skill‑Lücken abgebrochen. Das Problem dahinter ist eines, über das in Vorstandsetagen ungern gesprochen wird: Eine ganze Engineering‑Generation hat schlicht nie ein Storage‑Tier dimensioniert, ein Netzwerk segmentiert oder eine Datenbank auf Bare‑Metal getunt. Wer „Cloud‑Native” gelernt hat, kann oft Terraform schreiben, aber keine echte Kapazitätsplanung machen. Und AI wird uns noch nicht davor retten.

Cloud‑Veteran David Linthicum bringt es auf den Punkt: Die durchschnittliche IT‑Abteilung habe gar nicht mehr das Engineering‑Talent, um größere Cloud‑Workloads zu repatriieren. Das ist die eigentliche Lock‑in‑Falle, nicht die proprietären APIs, sondern das organisationale Vergessen.

Verschärft wird das durch Outsourcing und Offshoring. Studien zeigen, dass 22 Prozent der Outsourcing‑Beziehungen binnen zwei Jahren scheitern, 48 Prozent spätestens in fünf, vorrangig wegen Qualitäts‑ und Kommunikationsproblemen. Was als Effizienzhebel verkauft wird, ist häufig ein systematischer Kompetenztransfer aus dem eigenen Haus und im schlimmsten Fall eine Erosion der Fähigkeit, Architekturentscheidungen überhaupt noch zu beurteilen. Offshore‑Modelle multiplizieren diesen Effekt durch Zeitzonen‑, Sprach‑ und Kulturfriktion und durch fluktuationsbedingten Wissensabfluss.

Meiner Meinung nach ist es eine absolute Vollkatastrophe, die von den meisten Unternehmen bewusst ignoriert wird.

Der Multi‑Cloud‑Sumpf

Wer geglaubt hat, Multi‑Cloud sei die Antwort auf Vendor‑Lock‑in, ist meist enttäuscht: 99 Prozent der Unternehmen berichten von Schwierigkeiten beim Multi‑Cloud‑Management; im Schnitt nutzen sie 2,4 Public‑Cloud‑Provider, 73 Prozent sagen, Cloud habe ihre Operations komplexer gemacht. Egress‑ und Inter‑Region‑Gebühren machen laut Gartner 10 bis 15 Prozent der Gesamtkosten aus und wirken als ökonomische Mauer zwischen den Anbietern. Multi‑Cloud ohne übergreifende Steuerung ist nicht Freiheit, sondern multiplizierte Komplexität.

Übrigens sind hier europäische Anbieter in der Regel praktikabler, da sie selten Egress-Kosten verrechnen.

Die Lösung: Provider zur API degradieren

Die strategische Antwort liegt nicht im Schwarz‑Weiß‑Denken („alles raus” vs. „alles rein”), sondern in einer eigenen Plattform‑Schicht über den Cloud‑Providern. Konzeptionell bedeutet das:

• Provider = austauschbarer Infrastruktur‑Lieferant. Compute, Storage, Netzwerk und GPUs werden konsumiert wie Strom, in der Region, beim Anbieter und zur Tageszeit, an dem sie am günstigsten oder geeignetsten sind. Die Preisspreizung macht das ökonomisch zwingend: Bei aktuellen GPU‑Pricing‑Vergleichen liegen H100‑Stundenraten je nach Provider zwischen rund 0,47 und über 14 US‑Dollar pro GPU‑Stunde. Wer hier statisch einkauft, verschenkt Faktoren, nicht Prozente.

• Eine Abstraktionsschicht. Konzeptionell ein „Supercloud”‑ oder Plattform‑Engineering‑Layer, kapselt provider‑spezifische APIs, vereinheitlicht Identity, Policies, Observability und Deployment‑Pipelines. Gartner prognostiziert, dass bis 2026 80 Prozent der großen Engineering‑Organisationen eigene Plattform‑Teams aufbauen werden. Das ist kein Hype, sondern eine Konsequenz aus der gelebten Komplexität.

• Agentenbasierte Architektur‑Empfehlungen sind das nächste “künstliche” Glied: Multi‑Agent‑Systeme, die fortlaufend Kosten‑, Performance‑, Latenz‑ und Compliance‑Daten konsolidieren und Vorschläge machen, welcher Workload wohin gehört, idealerweise mit nachvollziehbarer Begründung statt Black‑Box‑Empfehlung.

Was IT‑Entscheider in Betracht ziehen sollten

Drei Konsequenzen, die sich aus der Datenlage ableiten:

Erstens: Operations‑Kompetenz wieder ins Haus holen. Ein eigener Plattform‑Layer braucht echte Engineers, die Hardware, Netzwerk, Storage und Workload‑Ökonomie verstehen. Das ist teuer, aber 27 Prozent verschwendete Cloud‑Ausgaben sind teurer.

Zweitens: Cloud strategisch nutzen, nicht religiös. Cloud bleibt brillant für Lastspitzen, schnelle Experimente und Greenfield‑Projekte, in denen Time‑to‑Market regiert. Sie ist aber typischerweise das schlechteste Modell für vorhersehbare, datenintensive, dauerlaufende Workloads. Kostentechnisch. Und Enterprises reitzen regelmäßig die Standardservices von Providern aus, sodass diese selbst gebaut werden müssen. Genau dort liegen die Repatriation‑Cases.

Drittens: In eine Abstraktionsschicht investieren. Wer seine Workloads so kapselt, dass sie ohne Architektur‑Rewrite zwischen Providern aber auch zu eigener Hardware wandern können, gewinnt sowohl Verhandlungsmacht als auch Resilienz. Das ist die einzig nachhaltige Antwort auf Egress‑Fees, Vendor‑Lock‑in und unkontrollierte Margen. Und vermutlich einer der wenigen Schritte in Richtung Souveränität.

Ich muss aber auch betonen, dass “die Cloud” nicht das Problem ist. Wer sie als das behandelt, was sie wirklich ist, ein Infrastruktur‑Lieferant unter mehreren, baut eine IT, die wieder beweglich, kompetent und wirtschaftlich gesund ist. Genau das ist heute der eigentliche Wettbewerbsvorteil.

Caveats zur Quellenlage

• Die 83‑%‑Repatriation‑Zahl (Barclays CIO Survey) wird von Channelnomics u. a. relativiert: Sie misst Unternehmen, die irgendeinen Workload zurückholen, nicht das Volumen. Die Aussagekraft ist eingeschränkt; richtig ist aber, dass Repatriation ein Trend, kein Massenexodus ist (IDC: nur 8–9 % Voll‑Repatriation).

• Einige der Repatriation‑Erfolgszahlen (37signals, Dropbox) stammen aus Selbstauskünften der Unternehmen bzw. SEC‑Filings. Sie sind plausibel, aber nicht unabhängig auditiert. 37signals selbst weist darauf hin, dass die Rechnung nicht 100 % apples‑to‑apples ist (Hardware‑Refresh, Power, Cooling werden je nach Berechnung mit/ohne berücksichtigt).

• Andrew Tanenbaum ist nicht primär ein Cloud‑Kritiker; seine Bekanntheit stammt aus der Linux‑Microkernel‑Debatte 1992. Im Artikel wurde er bewusst nicht als Cloud‑Kritiker zitiert. Wer eine akademisch fundierte Cloud‑Skepsis sucht, findet sie eher bei Bryan Ford (Yale, „Icebergs in the Clouds”).

• Die GPU‑Preise sind volatil; insbesondere H100‑Spot‑/Marketplace‑Preise schwanken stark. Der Punkt, mehrfache Preisspreizung zwischen Anbietern, bleibt aber stabil.

• Der „Supercloud”-Begriff ist konzeptionell, nicht standardisiert. Manche nennen es auch Sky Computing. Im Artikel wurde er deshalb umschrieben und nicht als Produktkategorie verwendet. Ich persönlich würde eher für eigens gebaute Platform-of-Platforms Ansätze plädieren.

• Cloud‑Waste‑Quoten variieren je nach Studie zwischen 21 % (Harness, eng definiert) und bis zu 47 % (manche Surveys, weit definiert). Die genannte Spanne 27–32 % ist der robuste Median über Flexera, FinOps Foundation und Datadog hinweg.

Daher steht dieser Blog/Newsletter/Brain Dump ganz im Sinne von:

Warum ich?

Mein persönlicher Anspruch ist es, realistische Perspektiven zu gewinnen. Wirklich zu verstehen, was möglich ist, welche Auswirkungen das hat und diese entsprechend einzusortieren. Hypes betrachten, aber nicht selbst süchtig werden.

Seit über elf Jahren bin ich in der Technologie-Beratung unterwegs. Angefangen als Enterprise Architect im Office of the CIO bei ProSiebenSat.1, später als Management Consultant und Senior Cloud Native Architect, und heute als Gründer und Chief Technology Advisor von Liquid Reply. Diese Jahre haben mir eines sehr deutlich gezeigt: Zwischen dem, was auf Konferenzen versprochen wird, dem, was in Architektur-Boards beschlossen wird, und dem, was am Ende tatsächlich in Produktion läuft, liegen oft Welten. Genau in diesen Lücken bewege ich mich beruflich und genau darüber will ich hier schreiben.

Als Enterprise Architect habe ich gelernt, Technologieentscheidungen nicht isoliert zu betrachten, sondern im Kontext von Geschäftsmodellen, Organisationsstrukturen und langfristigen Auswirkungen. Als Berater habe ich gesehen, wie unterschiedlich die gleiche Technologie in einem DAX-Konzern, einem Mittelständler oder einem Scale-up wirkt und warum eine “Best Practice” selten überall passt. Und als Gründer habe ich am eigenen Leib erfahren, wie sich strategische Entscheidungen anfühlen, wenn man selbst die Verantwortung trägt.

Dazu kommen drei Welten, die sich selten in einem Raum treffen: der Maschinenraum von Engineering-Teams, die Vorstandsetagen, in denen über Strategie und Budget entschieden wird, und die internationale Open-Source-Community, in der die Technologien entstehen, über die der Rest der Welt erst Jahre später diskutiert.

Mein Open-Source-Hintergrund verankert das Ganze:

• knapp 3 Jahre im Kubernetes Release Team gearbeitet

• sitze im Advisory Board der Linux Foundation Europe

• bin Cloud Native Computing Foundation (CNCF) Ambassador und Governance Board Member

• organisiere Community Events/Meetups/Events wie den Cloud Native Summit Munich

• Als Speaker (zu Deutsch Vortragsredner), mit über 70 Vorträgen in den letzten Jahren, komme/kam ich in sehr intensive Austauschen mit Menschen aus aller Welt, Branchen und Profilen

Mein persönlicher Anspruch ist es, realistische Perspektiven zu gewinnen. Wirklich zu verstehen, was möglich ist, welche Auswirkungen das hat und diese entsprechend einzusortieren. Hypes betrachten, aber nicht selbst süchtig werden. Mein Ziel ist es, dass du danach besser entscheiden kannst, egal ob du Engineer, Architect, Founder oder Führungskraft bist.

Welche Themen erwarten dich hier?

Grob gesagt: alles, was an der Schnittstelle zwischen moderner IT, Geschäftsrealität und gesellschaftlicher Wirkung liegt. Konkret werden wiederkehrende Themen sein:

• (Cloud) Sovereignty & digitale Souveränität 👉 was sie wirklich bedeutet jenseits des politischen Schlagworts, und was sie für Unternehmen in Deutschland und Europa praktisch heißt.

• AI Engineering 🧠 wie (Gen)AI tatsächlich in Produktion landet, was funktioniert, was scheitert, und welche Architekturen sich gerade herauskristallisieren, und was bedeutet das für den Homo Sapiens.

• Platform Engineering 🧪 vom Internal Developer Platform zur AI-Developer Platform: Menschen, Prozesse und Kultur; ab und an etwas Technik.

• Open Source als strategischer Hebel 🏗️ wie Communities, Governance und Projekte das gesamte Spielfeld definieren und verschieben.

• Leadership & Entrepreneurship in der Tech-Welt 🧙 was es heißt, Engineering-Organisationen zu führen, ohne den Bezug zur Technik oder den Menschen zu verlieren.

• Soziotechnologische Beobachtungen 🪡 der eigentliche rote Faden: wie all das oben genannte unsere Arbeitsweise, unsere Unternehmen und letztlich unsere Gesellschaft formt.

Mal werden es kurze Brain Dumps sein, mal ausführlichere Analysen, mal einfach ein O-Ton aus einem Gespräch, der hängengeblieben ist. Versprochen ist nur eines: keine Pressemitteilungen, kein verkapptes Marketing, sondern das, was ich tatsächlich denke.

Mehr gibt’s hier

Normalerweise schreibe ich auf Englisch 👇

Zeitgeist of Bytes

Cloud sovereignty, AI, and the architecture of digital power. One byte at a time 📩

By Max

Zusätzlich können wir auf LinkedIn diskutieren. Ich komme mit regelmäßigem Input zu (Cloud) Sovereignty, AI Engineering, Platform Engineering, Leadership, und Entrepreneurship.

Sag Hallo ➡️ https://www.linkedin.com/in/maxkoerbaecher/