Willkommen zu allesnurgecloud.com – Ausgabe #201
Vielen dank für die vielen Glückwünsche und Weiterempfehlungen zu Ausgabe #200 in der letzten Woche. Ohne Feedback, Fragen, Vorschläge und Kritik würde ich das hier gar nicht mehr machen – vielen Dank daher an alle, die im Laufe der Jahre den Newsletter weiterempfohlen oder mir News geschickt haben.
So, wenn du diesen Newsletter liest bin ich schon im Urlaub, d.h. hier ist erstmal 2-3 Wochen Pause – dafür hast du hier nochmal einen prall gefüllten Newsletter mit vielen interessanten Nachrichten. Du hörst dann im September wieder von mir. Bis bald!
Happy Bootstrapping Podcast
In dieser Woche habe ich mit Andreas Mühe von ivy.Mayhem gesprochen. Andreas baut nicht 1, nicht 2, nicht 3 – sondern gleich 8 verschiedene SaaS Apps. Die Folge heisst deshalb auch „Zwischen AppSumo Erfolg und Support Wahnsinn“ – wir sprechen ausführlich über seine Produktstrategie, den Sales Channel AppSumo, Höhen und Tiefen und warum er eben 8 Tools baut und sich nicht nur auf eines konzentriert – Folge 134 von „Happy Bootstrapping“ (Spotify/Apple Podcasts).
allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:
AWS EU-Bürger-Pflicht für Sovereign Cloud
Das About Amazon Team berichtet, dass AWS für seine European Sovereign Cloud künftig ausschließlich EU-Bürger als Mitarbeiter einstellen will. Die Ankündigung kommt nur wenige Monate vor dem geplanten Start Ende 2025 und wirft Fragen zur tatsächlichen Souveränität auf.
Die neuen Anforderungen im Detail
AWS verschärft die Einstellungskriterien und will damit den Ansprüchen hochregulierter Branchen gerecht werden. Nur noch EU-Bürger mit Wohnsitz in der EU sollen operative Kontrolle über die Infrastruktur haben – vom Rechenzentrum über den technischen Support bis zum Kundenservice. Die Maßnahme repliziere eine „etablierte Praxis“ von EU-Institutionen und Regierungen.
Oracle war schneller
Interessant dabei: AWS ist hier Nachzügler. Bereits im Sommer 2023 kündigte Oracle eine ähnliche „EU Sovereign Cloud“ an, die isoliert von EU-Mitarbeitern betrieben, aktualisiert und supportet wird. Die Oracle-Rechenzentren in Deutschland und Spanien sind laut eigenen Angaben komplett vom restlichen Cloud-Angebot getrennt. Wie in Newsletter #122 berichtet, kritisierte NextCloud-CEO Frank Karlitschek schon damals das AWS-Konzept als „Etikettenschwindel“.
Coreys beißende Kritik
Cloud-Experte Corey Quinn zeigt sich wenig beeindruckt von der Ankündigung: Ein Blick in den Pass sage nichts über Immunität gegen staatlichen Druck aus. Seine Beobachtung: Als Doppelbürger existiere er offenbar in einem „Quantenzustand der Loyalitäten“. Quinn weist auf den Elefanten im Raum hin – AWS bleibe ein US-Unternehmen, das rechtlich verpflichtet sei, US-Regierungsanfragen nachzukommen. Die EU-Mitarbeiter-Show lenke nur davon ab.
Was bedeutet das wirklich?
Die 7,8 Milliarden Euro Investition in Brandenburg zeigt zwar Commitment, aber die grundlegende Abhängigkeit von US-Rechtsprechung bleibt bestehen. Wie schon bei Oracles souveräner EU-Cloud und Microsofts Sovereign Cloud in #193: Technisch beeindruckend, rechtlich fragwürdig.
Man kann sich eher Fragen, ob die Schaffung eines solchen Angebots nicht ein Eingeständnis ist, dass die bisherigen Lösungen „Wir haben doch deutsche Datacenter“, etc. nicht so ganz compliant sind. AWS lässt sich den Spaß auf jeden Fall ne Stange Geld kosten.
Ich frag mich ja, ob es dann auch ein Migrationstool geben wird, denn als bisheriger eu-central-1 Kunde (Frankfurt) muss man seine komplette Infrastruktur ja dann auch wirklich umziehen, damit man „souverän“ in Anführungszeichen ist.
AWS European Sovereign Cloud to be operated by EU citizens
STACKIT: Cloud-Offensive gegen die US-Dominanz
Die ZEIT berichtet über die ambitionierten Cloud-Pläne der Schwarz Gruppe. Mit STACKIT baut die Schwarz Gruppe (Lidl, Kaufland) eine komplett souveräne deutsche Cloud-Infrastruktur auf – und treffe damit einen Nerv: 87% der deutschen Unternehmen hängen laut Bitkom von US-Technologien ab.
Christian Müller, Co-CEO von Schwarz Digits, führt zum Interview durch die Serverfarm in Neckarsulm: tausende Server in klimatisierten Reihe, Stickstoff-Löschanlage, mehrfache Stromversorgung, biometrische Zugangskontrollen – die Sicherheitsvorkehrungen erinnern an Fort Knox. „Heute sind wir beim Thema souveräne, deutsche Cloud zu 100% unabhängig„, erklärt Müller stolz.
Müllers Beispiel zeigt die Komplexität mit „US-Clouds“: Eine in Deutschland gehostete E-Mail über einen US-Cloud-Anbieter kann beim Abruf über ein iPhone plötzlich amerikanische Server passieren. Ein paar Bits US-Code reichen – schon greift der Cloud Act. Die Konsequenz bei STACKIT: Daten werden nicht nur in der EU gespeichert, sondern auch komplett dort prozessiert.
Die Kommentare zur ZEIT-Berichterstattung zeigen interessante Perspektiven:
- „Amerikafreie IT gibt es nicht“ – User mkollig weist darauf hin, dass selbst souveräne Clouds auf Nvidia, Intel, EMC, NetApp und Cisco angewiesen sind. Geschätzte Kosten für EU-Chip-Unabhängigkeit: Ein halbes EU-BIP
- Open-Source-Abhängigkeit – Reimi63 fragt provokant: Wer pflegt die 50-60% Open-Source-Produkte bei STACKIT? Oft seien es Oracle, Microsoft, Google und Red Hat – Disclaimer – Nein, in dem Fall nicht.
- Praxis-Check – Virtual_ berichtet vom Umstieg seines Kleinunternehmens: IONOS NextCloud statt Google Drive, Mailfence statt Gmail. Ein Jahr Übergangszeit für komplette Linux-Migration
Die Händler-Paradoxie
User last-unicorn bringt es auf den Punkt: „Das Schaf bezahlt dem Metzger noch das Messer“ – wenn Händler ihre Systeme auf AWS hosten und damit Amazons Kriegskasse füllen. Die Ironie ist bitter.
Gregor Schumacher vom Thinktank Cloud Ahead sieht 12 Millionen relevante Softwareprogramme weltweit – die meisten aus den USA. Seine Empfehlung: Bestandsaufnahme der eigenen IT und konkrete Risikoszenarien durchspielen.
Die Wahrheit liegt irgendwo dazwischen: Komplette US-Unabhängigkeit ist illusorisch, aber Wahlfreiheit und Verhandlungsspielraum sind machbar. Wie schon bei AWS‘ EU-Bürger-Pflicht und Oracles Sovereign Cloud diskutiert: Technische Souveränität allein reicht nicht – es braucht auch rechtliche und wirtschaftliche Unabhängigkeit.
STACKIT zeigt: Deutsche Cloud-Alternativen sind möglich, aber kein Allheilmittel. Die Abhängigkeit von US-Hardware und Open-Source-Projekten bleibt. Trotzdem – jeder Schritt Richtung digitaler Souveränität zählt, besonders wenn 50% der Unternehmen ihre Lieferketten wegen Trump überdenken.
Dagegen ist keine Cloud gewachsen, oder?
Anzeige
Hier könnte Deine Werbung stehen
Du möchtest Deine Firma, angebotene Dienstleistungen & Services oder Dein SaaS Produkt hier im Newsletter vorstellen?
Du suchst neue Mitarbeiter und möchtest diese direkt erreichen?
Erreiche über 1400 Cloud und Open-Source Enthusiasten direkt per E-Mail und im RSS Feed. Dazu kommen 1000+ Impressions im LinkedIn Artikel des Newsletters.
Die Preise beginnen ab 150€ pro Ausgabe – bei Interesse antworte mir direkt auf den Newsletter oder kontaktiere mich über LinkedIn ich schreib dann auch ganz schnell zurück.
Jetzt Werbung anfragen (und Freitags deployen)
Dropbox zeigt 7. Generation Hardware mit GPU-Power
Eric Shobe und Jared Mednick berichten über Dropbox‘ beeindruckende siebte Hardware-Generation. Nach 14 Jahren Eigenbau-Infrastruktur präsentiert das Unternehmen seine bisher leistungsfähigste Architektur – inklusive dedizierter GPU-Server für KI-Workloads.
Die neue Hardware-Flotte im Detail
Dropbox setzt auf spezialisierte Plattformen für unterschiedliche Workloads. Crush übernimmt traditionelle Compute-Aufgaben mit 84-Core AMD EPYC 9634 Prozessoren – satte 75% mehr Cores als die Vorgängergeneration. Die Datenbank-Plattform Dexter glänzt mit 30% höherer IPC und reduziert Replikations-Lag um den Faktor 3,57x. Bei Storage setzt Sonic neue Maßstäbe mit 32TB SMR-Drives und über 200Gbps Durchsatz.
Power-Management als neue Herausforderung
Die Leistungssteigerung hat ihren Preis: Dropbox musste von zwei auf vier PDUs pro Rack umstellen, um die 16kW Leistungsaufnahme zu bewältigen. Besonders knifflig: Die hochdichten SMR-Drives reagieren extrem empfindlich auf Vibrationen der 10.000 RPM schnellen Lüfter. Die Lösung? Ein komplett neu entwickeltes Chassis mit akustischer Isolation. Bilder der Racks findest du hier und hier – vom Gehäuse gibt es nur eine grafische Darstellung.
KI-Beschleunigung mit Gumby und Godzilla
Für Dropbox Dash führt das Unternehmen zwei GPU-Tiers ein: Gumby für leichte Inference-Tasks und Video-Transcoding, Godzilla mit bis zu 8 vernetzten GPUs für LLM-Training. Dropbox zeigt hier eindrucksvoll, wie man Infrastructure-as-Code auf die Spitze treibt.
Die drei wichtigsten Learnings:
- Thermals & Power sind die neuen Bottlenecks: Höhere Leistung bedeutet mehr Stromhunger – die Umstellung auf vier PDUs war unvermeidlich
- Supplier-Kollaboration beschleunigt Innovation: Frühe Zusammenarbeit mit Hardware-Partnern ermöglichte maßgeschneiderte Lösungen wie vibrations-optimierte Storage-Gehäuse
- Product-First Approach zahlt sich aus: Hardware folgt Software-Anforderungen – die GPU-Tiers entstanden direkt aus den Bedürfnissen von Dash und ML-Teams
Interessant, was man für so einen Datenablage und Sync Service dann doch alles an hardware braucht. Gut, die ganzen KI Features kenne ich alle gar nicht, da ich dropbox kaum mehr nutze – du?
Seventh-generation server hardware at Dropbox: our most efficient and capable architecture yet
Von Todo-Apps zurück zur .txt-Datei
Der Entwickler Alireza Bashiri berichtet über seine Odyssee durch die Welt der Produktivitäts-Apps – von Notion über Todoist bis zu OmniFocus. Nach Jahren des App-Hoppings landet er wieder beim Ausgangspunkt: einer simplen todo.txt auf dem Desktop.
Die App-Graveyard-Tour
Seine Erfahrungen lesen sich wie ein Who-is-Who gescheiterter Produktivitätssysteme:
- Notion: Drei Wochen am „Life Operating System“ gebaut, zwei Tage genutzt
- Todoist: Gamification führte zu sinnlosen Tasks („Wasser trinken“ 8x täglich)
- Things 3: Schön, teuer, vergessen zu checken
- OmniFocus: So komplex, dass man ein Manual braucht
Der Durchbruch: Radikal einfach
Als sein Handy ausfiel, kritzelte er vier Tasks auf einen Zettel – und erledigte alle. Die Erkenntnis: Keine Tags, keine Prioritäten, keine Due-Dates – nur eine Liste. Sein System heute:
2025-08-11
10am review pull requests
- check the auth changes specifically
write blog post about todo apps
2pm meeting with team
3:30pm call with client
fix that annoying bug in the navbarWarum es funktioniert
- Immer da: Die Datei starrt ihn vom Desktop an – kein App-Launch nötig
- Instant: Ein Keyboard-Shortcut öffnet die Datei im Floating Window
- KI-unterstützt: Claude/Cursor ergänzt Sätze, merkt sich Schreibstil – aber das System funktioniert auch ohne
- Zukunftssicher: Textdateien funktionieren in 20 Jahren noch – Notion-Workspaces eher nicht
Das erinnert an Jeff Geerlings Ansatz aus Newsletter #136, der ebenfalls auf eine simple Markdown-Datei setzt. Geerling nutzt allerdings iCloud-Sync und trennt zwischen „Today“ (max. 3 Items) und „Soon“. Produktivität bedeutet nicht, die perfekte App zu finden. Es geht um drei simple Schritte: Aufschreiben, regelmäßig checken, ausführen. Alles andere ist Prokrastination im Produktivitäts-Gewand.
Ich nutze bisher noch mein agiles Notizbuch – allerdings fehlt mir hier die Möglichkeit, Themen einfach an Tage zu gruppieren/kopieren oder an längerfristigen Themen zu arbeiten. Was funktioniert hier für dich?
I Tried Every Todo App and Ended Up With a .txt File
Nach Claude-Limits: KI-Alternativen im self-hosting
Peter Steinberger berichtet über seine Odyssee durch die Welt selbst-gehosteter KI-Modelle, nachdem Anthropic die Nutzungslimits für Claude Max verschärft hat. Mit 6.000 Dollar monatlichen Anthropic-Kosten war er definitiv Teil der Power-User, die das neue Limit hart trifft.
Die Alternativen-Landschaft
Nach intensiven Tests kristallisieren sich einige Favoriten heraus:
- opencode: Der vielversprechendste Kandidat – unterstützt alle Provider und hat optimierte Prompts für Qwen 3 Coder
- charm crush: Optisch ansprechend, aber noch zu buggy – keine funktionierende Textauswahl ist ein Deal-Breaker
- Gemini CLI: Extrem schnell, aber Tool-Calling noch sehr kaputt („I’m just a file“)
- amp: Nutzt Claude Sonnet direkt, aber ohne Subscription-Support uninteressant
Das Hardware-Abenteuer
Steinberger ging all-in: Ein Mac Studio mit 512GB RAM reichte nicht, also mietete er 8x H200 GPUs für 15 Dollar pro Stunde. Die Specs sind beeindruckend:
- 1.128 GB GPU VRAM insgesamt
- Läuft Qwen3 Coder 480B mit 400k Token Context
- Performance: Vergleichbar mit Alibabas Cloud-Angebot
Die noch neueren B200 GPUs für 4 Dollar/Stunde sind ein guter Deal – wenn man sie zum Laufen bekommt. Hardware im Wert von 2 Millionen Dollar zu mieten und trotzdem an Software-Problemen zu scheitern, zeigt die aktuelle Realität. Wenn man hier mal das Ausschalten vergisst oder 3 Wochen in Urlaub fährt – Gute Nacht 😉
Die ernüchternde Kostenrechnung
Bei 360 Dollar täglich (24/7 Betrieb) oder 11.000 Dollar monatlich ist die Rechnung klar: Self-Hosting lohne sich nicht. Alibabas Qwen 3 Coder kostet 1-6 Dollar pro Million Input-Tokens – man müsste schon extrem viel verbrauchen, damit sich eigene Hardware rechnet. Zum Vergleich: An intensiven Tagen verbraucht Steinberger 500 Millionen Tokens – das wären bei Opus 1.000 Dollar, bei Sonnet 200 Dollar.
Open-Source-Modelle sind nur 6-12 Monate hinter kommerziellen Modellen – aber ökonomisch macht Token-basierte Bezahlung mehr Sinn. Steinbergers Strategie:
- Claude Code für Terminal und Coding
- opencode + Qwen auf Alibaba als günstige Alternative
- Gemini für Debugging mit großem Context
Interessant dazu: Arvid Kahl spart mit Hetzner RTX4000 GPUs über 8.000 Dollar monatlich bei seinem Podcast-Transkriptions-Service. Der Trick: Consumer-GPUs statt Enterprise-Hardware – bei seinem Use-Case erreicht die RTX4000 10.100 transkribierte Minuten pro Dollar, während die H100 nur 1.438 schafft. Für kleinere Modelle wie Whisper reichen die 20GB VRAM völlig aus. Ein Kunde von mir nutzt Qwen auf einem solchen Hetzner Server – klar, ist nicht so schnell wie Claude Code – dafür gibt es keine Rate Limits.
Self-Hosting AI Models After Claude’s Usage Limits
monday.com verwandelt Datenbank-Chaos in Ordnung
Mateusz Wojciechowski erklärt, wie monday.com den Sprung von einem einzelnen Datenbank-Server zu hunderten Datenbanken gemeistert hat. Das Unternehmen entwickelte mit „Shepherd“ eine elegante Lösung für ein Problem, das viele schnell wachsende Tech-Firmen kennen: Wie manage ich Datenbanken im großen Stil?
Von Monolith zu Microservice-Chaos
Die Geschichte beginnt klassisch: 2014 startete monday.com mit einer monolithischen Anwendung und einer einzigen Datenbank. Sechs Jahre später, bei über 100.000 Kunden, explodierten die Datenmengen. Der Umstieg auf Microservices brachte dann die eigentliche Herausforderung: Aus wenigen Datenbanken wurden hunderte. Das DBA-Team musste sich neu erfinden und wurde zum DBRE-Team (Database Reliability Engineers) – ein Paradigmenwechsel von „Haustiere“ zu „Viehherden“.
Die Shepherd-Lösung im Detail
monday.com setzt auf Temporal als Workflow-Engine und kombiniert diese mit einer eigenen Konfigurations-Datenbank. Das System arbeitet nach dem GitOps-Prinzip: Desired State vs. Actual State, automatische Synchronisation bei Abweichungen. Clever: Die Integration in das interne Developer-Portal „Sphera“ ermöglicht Self-Service für Entwickler – sie können Backups erstellen, Storage erhöhen oder Replikas hinzufügen, ohne das DBRE-Team zu involvieren.
Tier-System für unterschiedliche Anforderungen
Besonders durchdacht ist die Tier-Klassifizierung: Tier 1 für kritische Services mit Zero-Downtime-Anforderung, Tier 3 für periphere Dienste mit lockereren Standards. Automatische Minor-Version-Updates? Bei Tier 3 kein Problem, bei Tier 1 undenkbar.
Die vier DBRE-Prinzipien:
- Standards: Einheitliche Konfiguration pro Tier statt individueller Snowflakes
- Automation: Jede Aktion muss skriptbar sein – mit Tests, CI/CD und graduellen Rollouts
- Self-Service: Entwickler verwalten ihre eigenen Datenbanken über definierte Interfaces
- Observability: Automatisiertes Monitoring mit intelligenten Alerts direkt an die richtigen Teams
Das Tier Prinzip gefällt mir irgendwie, auch die Idee, ein „Database Reliability Engineering Team“ zu etablieren. Cloud hin oder her, man braucht immer jemanden, der sich mit Datenbanken auskennt.
Guarding the herd – managing database servers at scale
AWS Account von letzter Woche gerettet
In der letzten Woche berichtete ich von einem gelöschten AWS Account eines Open Source Entwicklers, nach über 10 Jahren Arbeit. Einige Tage nach Veröffentlichung des Blog-Posts kam die Wende: Tarus Balog, ein AWS-Mitarbeiter mit 20 Jahren Open-Source-Erfahrung, meldete sich. „Ich bin erschüttert über die Löschung Ihrer AWS-Daten“, schrieb er – die erste menschliche Reaktion in der ganzen Saga.
Balog eskalierte bis zur VP-Ebene und löste ein Severity-2-Ticket aus – „die höchste Priorität, die normale Sterbliche je sehen werden“. Über 50 interne E-Mails flogen umher, CEO Matt Garman wurde informiert.
Als Boudihs Konto wiederhergestellt wurde, kam Licht ins Dunkel: Die Instanzen waren nur gestoppt, nicht terminiert. Der RDS-Snapshot stammte vom 19. Juli – vier Tage NACHDEM Support behauptete, alles sei „terminiert“. Das System hatte still weiter Backups erstellt, während Boudih um Read-Only-Zugriff bettelte.
Die technische Ursache: Boudihs Account war mit einem Payer-Account verknüpft. Als dieser die Zahlung einstellte (angeblich wegen 200 Dollar), wurde alles kaskadierend gelöscht. Boudih vergleicht es treffend: „Wenn das Leben nach AWS-Prinzipien funktionierte, würdet ihr mit euren Großeltern kaskadiert werden.“
Die systemischen Probleme
- AWS MENA operiert anders: Die Region ist bekannt für „zufällige“ Account-Terminierungen
- Kritische E-Mails von [email protected]: Vermischt mit Black-Friday-Promotions
- AWS besitzt die .aws TLD seit 2016 – nutzt sie aber nicht für wichtige Benachrichtigungen
- „Terminated“ bedeutet nicht wirklich terminated: Offenbar gibt es undokumentierte Restore-Möglichkeiten
Was lernen wir?
Die Hacker-News-Community brachte es auf den Punkt: „Backups von Backups sind wichtiger als eure N-Tier Web-3 Enterprise-Architektur„. Die Cloud war nie magische Regentropfen – es waren immer die Computer anderer Leute.
Boudihs Kunden – 400.000 Dollar monatliches AWS-Billing – migrieren bereits zu Oracle OCI, Azure und Google Cloud. Er entwickelt ein kostenloses Tool für den AWS-Exodus.
AWS führt jetzt einen „Correction of Error“-Prozess durch. Aber die Botschaft ist klar: Ohne öffentlichen Druck und einen einzelnen Menschen, der sich traute zu helfen, wären 10 Jahre Arbeit für immer verloren gewesen.
Diese no-reply E-Mails werde ich ja nicht mehr verstehen – wir haben 2025 und AWS hat einen eigenen E-Mail Dienst, bei dem man dies doch schön konfigurieren kann.
AWS Restored My Account: The Human Who Made the Difference
Claude Code: Der AI-Copilot erobert das Terminal
Der Entwickler Gareth Dwyer berichtet über seine Erfahrungen mit Claude Code, Anthropics Terminal-Tool, das zum Game-Changer für seine Arbeitsweise wurde. Nach nur wenigen Tagen wechselte er vom $20 GPT-Abo zum $100/Monat Anthropic MAX Plan – und bereut es nicht.
Vibe-Coding als neue Realität
Der Autor prägt den Begriff „Vibe-Coding“: Software entwickeln, ohne Code zu schreiben oder anzuschauen. Sein Experiment mit einem SplitWise-Klon zeigt die Möglichkeiten: Mit einer 500-Wörter-Spezifikation generierte Claude Code eine voll funktionsfähige CRUD-App in 900 Zeilen PHP. Der Clou: Die gleiche Spec ohne technische Vorgaben produzierte eine kaputte NodeJS-App mit 500MB Dependencies.
Die autonome Startup-Maschine
Das wildeste Experiment: Claude Code bekam einen Root-VPS und die Anweisung, autonom ein Startup zu bauen. Das Ergebnis nach 100 Commits: Eine funktionierende Server-Monitoring-App mit Nginx, SSL-Zertifikaten und GitHub-Integration. Zwar verwechselte die KI ihr eigenes Produkt (sie dachte, es sei ein SaaS-Tool, obwohl es nur den eigenen Server überwachen konnte), aber die technische Umsetzung war beeindruckend.
Produktions-Migration in Rekordzeit
Bei der Migration einer Laravel/MySQL-App auf einen neuen Server sparte Claude Code dem Autor geschätzte 16-32 Stunden. Die KI analysierte Dependencies, setzte Worker-Queues auf und debuggte Cloudflare Turnstyle-Fehler. Kleiner Schreck: Sie droppte einmal die Produktions-Datenbank – „Have faith“ ist das Motto des Autors.
Die wichtigsten Learnings:
- Immer mit
--dangerously-skip-permissionslaufen – auch auf Produktionsservern (InfoSec-Teams hassen diesen Trick) - Viel Input geben: Je mehr Kontext, desto besser das Ergebnis – tausende Wörter Input sind keine Seltenheit
- UI-Design überrascht: Trotz Text-Model generiert Claude Code ansprechende Interfaces
Gareth nutzt Claude Code mittlerweile sogar als Text-Editor für seine Blog-Artikel. Das erinnert an die in Newsletter #196 diskutierten KI-Experimente, wo Anthropic Claude einen Mini-Shop führen ließ – auch dort zeigte sich die beeindruckende Autonomie der KI, wenn auch mit ähnlich chaotischen Ergebnissen.
Kann mir sehr gut vorstellen, dass die Ergebnisse hier schon gut sind und immer besser werden. Trotzdem muss man immer verstehen, was für ein Code generiert wird – sonst kann man nötige Korrekturen nicht einsteuern.
TikTok spart 300.000 Dollar durch Rust-Rewrite
Ein Praktikant bei TikTok berichtet über ein beeindruckendes Optimierungsprojekt: Durch das gezielte Umschreiben von CPU-intensiven Endpoints eines Payment-Services von Go nach Rust konnte die Performance verdoppelt und dabei jährlich fast 300.000 Dollar eingespart werden.
Das Problem: Wenn Erfolg zur Last wird
Der ursprünglich in Go geschriebene Payment-Service war ein zuverlässiges Arbeitspferd – bis das Wachstum von TikTok LIVE die CPU-Last in kritische Bereiche trieb. Die Flame-Graphs zeigten eindeutig: Einige wenige API-Endpoints für User-Balance und Statistiken fraßen den Großteil der CPU-Zeit. Weitere Optimierungen des Go-Codes hätten nur marginale Verbesserungen gebracht.
Die Lösung: Chirurgische Präzision statt Kahlschlag
Statt das gesamte System neu zu schreiben, wählte das Team einen polyglotten Ansatz: Nur die problematischen Endpoints wurden in Rust neu implementiert, der Rest blieb in Go. Die Umsetzung erfolgte in drei Phasen:
1. Shadow-Mode für Korrektheit: Wochenlang lief der neue Rust-Service parallel und erhielt eine Kopie des Live-Traffics. Erst nach 100% Datenübereinstimmung ging es weiter.
2. Stress-Tests bis zum Breaking Point: Identische Cluster mit realen (anonymisierten) Daten wurden bis zum Versagen belastet.
Die beeindruckenden Ergebnisse bei 80.000 QPS:
- CPU-Nutzung: 78,3% (Go) → 52,0% (Rust) = 33,6% weniger
- Memory: 7,4% → 2,07% = 72% weniger
- p99 Latency: 19,87ms → 4,79ms = 76% schneller
- Max Throughput: Kritische Endpoints schafften 150.000-210.000 QPS statt 85.000-105.000
Das Projekt sei kein „Rust ist besser als Go“-Statement. Es zeige vielmehr Engineering-Reife: Go bleibe die erste Wahl für 95% der Services – seine Developer-Produktivität ist unschlagbar. Aber für die seltenen, hyper-kritischen CPU-Bottlenecks hat TikTok jetzt ein bewährtes Playbook.
2x Performance, $300k Savings: A Case Study in Rewriting a Critical Service in Rust
OpenFreeMap übersteht 100.000 Requests pro Sekunde
Zsolt Ero berichtet über einen unerwarteten Stresstest für OpenFreeMap. Was als ruhiger Tag begann, endete mit 3 Milliarden Requests in 24 Stunden – ein Traffic-Volumen, das bei kommerziellen Anbietern über 6 Millionen Dollar monatlich kosten würde.
Der Auslöser: Eine virale Pixel-Art-Seite
Die Ursache des Traffic-Tsunamis: wplace.live, eine kollaborative Zeichen-Website im Stil von r/place. Innerhalb weniger Tage explodierte die Nutzerzahl auf 2 Millionen User. Das Problem: Viele nutzten Scripts, um die 30-Sekunden-Limitierung pro Pixel zu umgehen. Statt manuell zu zeichnen, starteten Bots permanent neue Browser-Sessions, klickten einen Pixel und schlossen den Browser wieder – 1.500 Requests pro User im Schnitt.
Bei 100.000 Requests pro Sekunde zeigte sich die Robustheit der Architektur:
- 96% Success Rate trotz der extremen Last
- Nur vereinzelte „Too many open files“ Fehler in nginx
- 99,4% CDN Cache-Hit-Rate bei Cloudflare
- Die eigenen Server bewältigten die verbleibenden 1.000 Requests/Sekunde
Cloudflare als Lebensretter
Besonders cool: Cloudflare sponsort die Bandbreite für OpenFreeMap. Die 215 TB Traffic in 24 Stunden wären sonst unbezahlbar gewesen. Ero lobt die Agilität des Konzerns – die Sponsoring-Zusage kam innerhalb von 48 Stunden über ein Wochenende.
Die Lessons Learned:
- Bandwidth-Limiting per Referer wird implementiert – maximal 100 Millionen Requests pro 24h pro Domain
- Native Apps müssen künftig einen Custom Header zur Identifikation senden
- Server-Konfiguration wird optimiert, um „empty tiles“ bei extremer Last zu vermeiden
Manchmal zeigen erst extreme Belastungen, wo die wahren Grenzen eines Systems liegen. OpenFreeMap hat den Test bestanden – und dabei bewiesen, dass Open-Source-Alternativen zu MapTiler und Mapbox nicht nur möglich, sondern auch robust sind.
in der wpsace.live Karte einfach mal rauszoomen, manche Leute haben wir nun wirklich zu viel Zeit.
OpenFreeMap survived 100,000 requests per second
„Die Kochen auch nur mit Wasser“
Man kann Google Home Devices dank Google Gemini Integration über einen Calendar Invite hacken, der prompts zur Steuerung des Smart Home enthält.:
The adversary needs only to send a meeting invitation or an email containing an indirect prompt injection to the victim’s Google account. Once the invitation is added to the victim’s Google Calendar, the attack is set to be triggered either automatically or in the next user interaction.
Unter dem Titel „Invitation is all you Need“ gibt es eine Demo auf YouTube zum Thema.
Interessant wird es dann hier:
The researchers told Google what they’d found in February and Google has tried to patch around it. Google says it’s put in “mitigations”.
Google has not fixed the root cause, because the root cause is prompt injection, and fixing that would mean not using Gemini. And we can’t have that!
Dadurch dass die Gemini Integration nun überall eingebaut wird oder schon ist, wird das noch an ganz anderen Stellen passieren. Wenn deine Banking App ne AI Integration hat, dann ist es vielleicht Zeit, die Bank zu wechseln.
Schmunzelecke
„I asked you to write Tests only, so why did you touch Business Logic?“ – Instagram Video bei @developertimeline
💡 Link Tipps aus der Open Source Welt
Omnara – Mission Control für deine AI-Agenten
Vibe-Coding – nun auch aus dem Pool: Omnara verwandelt KI-Agenten wie Claude Code, Cursor oder GitHub Copilot von stillen Arbeitern in kommunikative Teamkollegen. Als Teil des Y Combinator S25 Batches bietet Omnara Echtzeit-Monitoring und Interaktion mit AI-Agenten – direkt vom Smartphone aus.
Features:
- Real-Time Monitoring aller Agent-Aktivitäten
- Push-Notifications bei wichtigen Entscheidungen
- Instant Q&A – beantworte Agent-Fragen von überall
- Universal Dashboard für alle AI-Tools
- Mobile-First Design (iOS App + Web)
- Model Context Protocol (MCP) Integration
- Remote Launch – starte Agenten vom Strand aus
- Git Diff Tracking für Code-Änderungen
- FastAPI Backend mit Read/Write Server-Trennung
- Dual JWT Auth (Supabase + Custom)
Endlich müssen wir nicht mehr stundenlang warten, um festzustellen, dass unser AI-Agent bei einer simplen Frage hängt! Omnara macht aus autonomen Agenten echte Teamplayer – perfekt für die mobile AI-Arbeitswelt und das Vibe-Coding vom Strand aus.
https://github.com/omnara-ai/omnara
Gitleaks – Der Secrets-Scanner für Git und mehr
Gitleaks ist ein Security-Tool, das Passwörter, API-Keys und andere Secrets in Git-Repos, Dateien und sogar stdin aufspürt. Mit seinem ausgeklügelten Regex-Engine und umfangreichen Regelwerk findet es selbst gut versteckte Geheimnisse – und das alles mit einem fancy ASCII-Logo beim Start.
Features:
- Scannt Git-Repos, Verzeichnisse und stdin nach Secrets
- 150+ vordefinierte Regeln für gängige API-Keys und Tokens
- Entropy-Analyse zur Erkennung hochzufälliger Strings
- Baseline-Support zum Ignorieren bekannter Findings
- Dekodierung von Base64, Hex und Percent-encoded Secrets
- Archive-Scanning (ZIP, TAR etc.) mit rekursiver Tiefe
- Composite Rules für mehrteilige Secrets
- GitHub Action und Pre-Commit Hook Integration
- Multiple Report-Formate: JSON, CSV, SARIF, JUnit
- Anpassbare Regeln mit TOML-Konfiguration
Ein Must-Have für Security-bewusste Teams! Die Integration in CI/CD-Pipelines verhindert, dass Secrets versehentlich committed werden. Der gitleaks:allow Kommentar ermöglicht kontrollierte Ausnahmen.
https://github.com/gitleaks/gitleaks
❓ Feedback & Newsletter Abo
Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.
Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: