Willkommen zu allesnurgecloud.com – Ausgabe #173

nach der ersten Woche Trump gab es zwar viel Getöse, die Welt steht noch und wir können auch noch ohne Probleme amerikanische Services nutzen. Mal schauen, ob das so bleibt. Ein Hammer war jedenfalls das Announcement zum „Stargate Project“ von OpenAI, Oracle, Softbank und MGX. $500 Milliarden Dollar sollen in den nächsten 4 Jahren in neue AI Infrastruktur in den USA investiert werden und „American Leadership“ in AI sichern. Was das für die EU und uns bedeutet, schaue ich mir für die nächste Ausgabe im Detail an.

Übrigens kannst Du meine Arbeit nun auf Patreon supporten, mir ein Bier ausgeben oder mal auf meiner Amazon-Wunschliste vorbeischauen – Danke! Falls du Interesse hast, im Newsletter oder Podcast Werbung zu buchen, kannst du das auf passionfroot machen.

Happy Bootstrapping Podcast

Am Donnerstag hab ich Folge 105 mit Oliver Farr von Colpari.cx veröffentlicht. Colpari ist ein neuer und flexibler Kundenservice, der mit einem fairen pay-per-use Modell und Freelancern arbeitet, um dir Kundenservice in aktuell 17 Sprachen anzubieten. Fand ich an der Stelle interessant, dass du keinen Langzeitvertrag abschließt und Colpari eben auch nen guten Job machen muss, um dauerhaft Umsätze mit dir zu machen – und buchen kann man das schon als „Indie Hackerin“ oder für seinen Side-Hustle, bei dem man telefonisch erreichbar sein möchte.

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:

Ist ChatGPT das Ende von StackOverflow?

Eine ausführliche Analyse von Gergely Orosz zeigt: StackOverflow erlebt gerade den dramatischsten Einbruch seiner Geschichte. Die Anzahl der Fragen ist auf dem niedrigsten Stand seit 2009 – und das hat nicht nur mit KI zu tun.

Die Zahlen sind alarmierend:

• Seitenaufrufe: -28%
• Up & Down Votes: -52%
• Fragen: -56%
• Antworten: -63%

Der Niedergang in drei Phasen:

1. 2014-2020: Stabile Phase mit ~200.000 Fragen/Monat
2. 2020-2022: Gradueller Rückgang
3. Ab Nov 2022 (ChatGPT Launch): Steiler Absturz

Warum der Abstieg schon vor ChatGPT begann:

1. Unfreundliche Moderation: Die strenge Moderation machte es besonders Neulingen schwer, Fragen zu stellen, die nicht sofort geschlossen wurden.
2. Fehlende Innovation: StackOverflow verpasste wichtige Trends:
   • Kein Support für Video-Antworten
   • Keine Anpassung an neue Plattformen wie Discord
   • Kaum Produktverbesserungen seit Jahren
3. Community-Wandel: Entwickler wechselten zu lockereren Plattformen wie Discord oder Telegram, wo Fragen einfacher gestellt werden können.

Was bedeutet das für die Zukunft?

1. Teufelskreis: Weniger neue Fragen → veraltete Antworten → weniger Suchmaschinentraffic → noch weniger Engagement
2. Private Equity Drama: Prosus kaufte StackOverflow 2021 für 1,8 Mrd $ – ein Investment, das sich kaum noch rentieren dürfte
3. KI-Training: Eine spannende Frage bleibt: Woher sollen KI-Modelle in Zukunft ihre Trainingsdaten bekommen, wenn StackOverflow als Wissensquelle versiegt?

Der Fall von StackOverflow ist ein Paradebeispiel dafür, wie disruptiv GenAI für etablierte Plattformen sein kann. Aber er zeigt auch, dass der Abstieg oft schon vor der „Disruption“ beginnt – durch verpasste Innovation und Community-Management-Fehler.

Besonders interessant finde ich die Frage nach den zukünftigen Trainingsdaten für KI-Modelle. Vielleicht sehen wir bald neue Plattformen, die speziell für die KI-Ära konzipiert sind und sowohl Menschen als auch Maschinen beim Lernen helfen. Die Tech-Branche hat sich schon immer angepasst – und wird auch diese Transformation meistern.

Was meint ihr – war ChatGPT wirklich der Sargnagel für StackOverflow, oder hätte die Plattform auch ohne KI an Relevanz verloren?
Nutzt du StackOverflow noch?

Are LLMs making StackOverflow irrelevant?

---

Million Dollar Lines of Code – Wenn Cloud Kosten aus dem Ruder laufen

Der CTO und Gründer von CloudZero, Erik Peterson, zeigt in einem interessanten Artikel aus 2024, wie einzelne Code-Zeilen zu massiven Cloud Kosten führen können. Anhand von konkreten Beispielen macht er deutlich, dass Entwickler heute eine enorme finanzielle Verantwortung tragen – denn jede Engineering-Entscheidung ist auch eine Kaufentscheidung.

Seine Top 5 der teuersten Code-Fehler:

1. Debug-Statements im Produktivcode – Ein simples Debug-Log in einer AWS Lambda Funktion führte zu CloudWatch Kosten von über 1,1 Millionen Dollar pro Jahr
2. API-Calls in Schleifen – Eine MVP-Implementation mit S3 API Calls in einer Schleife verursachte Kosten von 1,3 Millionen Dollar
3. Ineffiziente Datenstrukturen – Das simple Hinzufügen eines Timestamps in DynamoDB verdoppelte die Schreibkosten durch das Überschreiten der 1KB Grenze
4. Infrastructure as Code Fehler – Zwei voneinander getrennte Terraform Konfigurationen führten zu ungelöschten EBS Volumes im Wert von 1,1 Millionen Dollar
5. Ein Zeichen zu viel – Ein einzelner Character Fehler in einem CDN Update Skript hätte beinahe zu Kosten von 39 Millionen Dollar pro Jahr geführt

Peterson empfiehlt, Kosten nicht von Anfang an zu optimieren, sondern eine „Cloud Efficiency Rate“ (CER) als Metrik einzuführen. Diese berechnet sich aus:

CER = (Umsatz – Cloud Kosten) / Umsatz

Für verschiedene Entwicklungsphasen empfiehlt er unterschiedliche CER Ziele:

• R&D Phase: Negativ ist OK
• MVP: 0-25%
• Scale-Up: 25-50%
• Wachstumsphase: 50-70%
• Steady State: 80%

Der Artikel zeigt, wie wichtig es ist, Cloud Kosten als nicht-funktionale Anforderung zu betrachten. Die vorgeschlagene CER Metrik bietet dabei einen pragmatischen Ansatz, um nicht in vorschnelle Optimierung zu verfallen. Besonders spannend finde ich die konkreten Code-Beispiele – sie machen deutlich, dass auch kleine Änderungen große finanzielle Auswirkungen haben können.
In der „Cloud Exit“ Story wurden die Infrastruktur Kosten ja auch als prozentualer Ansatz des Umsatzes genannt (0,6 %) – man sollte sich jedenfalls mal mit dem Thema beschäftigen und seine Kosten berechnen.

Als Entwickler sollten wir uns dieser Verantwortung bewusst sein – ohne dabei den Fokus auf die eigentliche Produktentwicklung zu verlieren. Der Artikel liefert dafür einen guten Kompass.

Million Dollar Lines of Code – an Engineering Perspective on Cloud Cost Optimization

---

---

OKRs in der Tech-Branche: Marketing vs. Engineering

Jessitron hat einen interessanten Artikel über den Einsatz von OKRs (Objectives & Key Results) in verschiedenen Unternehmensbereichen veröffentlicht. Der Hauptfokus liegt dabei auf dem Vergleich zwischen Marketing und Engineering Teams – mit überraschenden Erkenntnissen.

Die Kernfrage ist spannend: Warum funktionieren OKRs im Marketing so viel besser als im Engineering? Die Antwort liegt in der unterschiedlichen Natur der Arbeit:

• Marketing arbeitet überwiegend projektbasiert mit klaren Kampagnen und Zeiträumen
• Engineering dagegen folgt einem kontinuierlichen Produktentwicklungszyklus

Im Engineering führt dies oft zu einer frustrierenden Situation: OKRs werden zum reinen Abklatsch der Produkt-Roadmap („Ship the Roadmap“). Dies ist laut Jessitron ein Warnsignal:

„When a team’s OKRs duplicate the roadmap, I read that as ‚We aren’t trying to improve. This is a quarter for trudging along.‘ Not a good sign.“

Der richtige Einsatz von OKRs sollte sich stattdessen auf folgende Aspekte konzentrieren:

• Was ist besonders an diesem Quartal?
• Was ist neu?
• Wie wollen wir uns verbessern?
• Was wollen wir herausfinden?

Für die normale operative Arbeit gibt es bereits andere Metriken:

• Im Marketing: KPIs wie Lead-Generierung, Website-Traffic, SEO-Rankings
• Im Engineering: SLOs (Service Level Objectives) und Accelerate-Metriken wie Deployment-Frequenz

Diese Perspektive erinnert mich stark an die Diskussionen zum Thema „You build it, you run it“ aus Ausgabe 157. Auch hier geht es um die Balance zwischen operativem Geschäft und kontinuierlicher Verbesserung.

Manchmal sollten wir unsere Management-Werkzeuge kritisch hinterfragen – nicht jedes Tool passt für jeden Bereich gleich gut.

Hitting OKRs vs Doing Your Job

---

State of Email Deliverability 2025: Die wichtigsten Erkenntnisse

Der aktuelle „State of email deliverability Report 2025“ von Mailgun bietet einen umfassenden Einblick in die Entwicklungen der E-Mail-Deliverability (PDF, 70 Seiten). Hier die wichtigsten Takeaways:

Kernzahlen & Trends:

• 78,5% der Befragten bewerten Deliverability als sehr wichtig (8/10 oder höher)
• 48% kämpfen mit Spam-Filterung als Hauptherausforderung
• 53% monitoren ihre Blocklistings nicht
• 39% führen selten oder nie E-Mail-Hygiene durch

Das „Yahoogle“-Update 2024:
Eine der bedeutendsten Entwicklungen war die Zusammenarbeit von Google und Yahoo bei neuen Sender-Anforderungen. Die wichtigsten Änderungen:

Authentifizierung:

• Verpflichtende Implementierung von SPF und DKIM
• DMARC-Konfiguration (mindestens p=none)
• 63% der Sender waren mit den neuen Anforderungen vertraut

Technische Anforderungen:

• One-Click-Unsubscribe nach RFC 8058
• Spam-BeschwerdeRate unter 0,3%
• 49,5% der informierten Sender passten ihre E-Mail-Programme an

Interessante Entwicklung: Die DMARC-Adoption stieg von 42,6% (2023) auf 53,8% (2024). Bei High-Volume-Sendern (>1 Million E-Mails/Monat) liegt die Adoptionsrate sogar bei etwa 70%.

Sicherheitsaspekte: Besonders kritisch: 47,7% der DKIM-Nutzer rotieren ihre Keys nur nach Sicherheitsvorfällen, während 40% unsicher über ihre Key-Rotation-Praktiken sind.

Die E-Mail-Landschaft entwickelt sich in Richtung höherer Sicherheitsstandards und besserer Nutzerfreundlichkeit. Wer als Sender relevant bleiben will, muss technische Standards erfüllen und Qualität in den Vordergrund stellen. E-Mail-Deliverability wird komplexer, aber auch professioneller. Die neuen Standards von Google und Yahoo treiben also die Professionalisierung des E-Mail-Marketings weiter voran.

Dass 53 % ihre Blocklisten nicht monitoren, das überrascht mich jetzt – dabei ist das doch so einfach wie nie?

State of email deliverability 2025

---

5 wichtige Grundlagen für erfolgreiches Remote Work

Ein aktueller Artikel stellt die 5 wichtigsten Voraussetzungen für erfolgreiches Remote Working vor – und argumentiert dabei, dass es weniger um technische Gadgets geht als um nachhaltige Gewohnheiten und Systeme:

Virtuelle Grenzen setzen:

• Klare Trennung von Arbeit und Privatleben durch separate Browser-Profile
• Fokus-Modi nutzen
• Vermeidung von Arbeits-Notifications auf privaten Geräten

Mehrere Arbeitszonen einrichten:

• Nicht das Büro zu Hause nachbauen
• Verschiedene Orte für unterschiedliche Aufgaben nutzen
• Umgebung an persönliche Bedürfnisse anpassen

Morgenroutine etablieren:

• Nicht direkt mit Arbeits-Notifications starten
• Bewussten Übergang zwischen Privatleben und Arbeit schaffen
• Pendelzeit sinnvoll für persönliche Routinen nutzen

Klares Arbeitsende definieren:

• Feste Kriterien für den Feierabend festlegen
• Nicht auf ein „Gefühl“ verlassen
• Konsistente Grenzen setzen um Burnout zu vermeiden

Eigene Arbeitsweise verstehen:

• Persönliche Präferenzen für produktives Arbeiten kennenlernen
• Mit verschiedenen Arbeitszeiten und -orten experimentieren
• Workday an persönliche Stärken anpassen

Der Artikel betont, dass nachhaltige Gewohnheiten wichtiger sind als neue Technologie-Gadgets. Die Investition sollte in erster Linie in die Entwicklung guter Arbeitsroutinen fließen, da diese deutlich länger Bestand haben als technische Ausrüstung.

Top 5 Must-Haves for Remote Workers

---

Datacenter auf dem Mond als Backup Location

Das US-Startup Lonestar plant einen „revolutionären Schritt in der Datenspeicherung: Das erste Rechenzentrum auf dem Mond soll im Februar 2025 per SpaceX Falcon-9 starten.

Kernpunkte:

• Start: Februar 2025 mit SpaceX Falcon-9
• Projekt: „Freedom Data Center“ im Rahmen der Athena-Mission
• Energieversorgung: Solar-betrieben
• Lebensdauer: 15-20 Jahre geplant

Die Daten blieben selbst bei schwerwiegenden Naturkatastrophen auf der Erde sicher und sind auch vor geopolitischen Konflikten sowie Cyberattacken weitgehend geschützt. Das „Freedom Data Center“ positioniert sich damit als ultimative Backup-Lösung für besonders sensible Daten.
Die Kosten für den Transport und Betrieb sind erheblich, während bei technischen Defekten keine direkten Reparaturen möglich sind. Zudem birgt bereits der Raketenstart gewisse Risiken, und die Wartung des Systems gestaltet sich durch die extreme Entfernung besonders komplex.

Lonestar kann bereits auf erfolgreiche Tests (ISS 2021, Mond 2024) zurückblicken und plant für 2026/27 weitere Expansionen. Erste Kunden, darunter Florida und die Isle of Man, sind bereits an Bord.

Na, müssen wir „3-2-1“ nun um ne 2 erweitern, damit wir die Daten auf 2 unterschiedlichen Planeten/Monden speichern?
Irgendwie glaube ich ja, dass wir bei einer „schwerwiegenden Naturkatastrophen auf der Erde“ andere Probleme haben werden…

Erstes Rechenzentrum auf dem Mond soll im Februar starten

---

Quora’s Datenbank-Optimierungen: Von MySQL bis MyRocks

Quora hat im verlinkten Artikel einen Einblick in ihre Datenbank-Optimierungen gewährt. Als Plattform mit über einem Jahrzehnt Geschichte und stetig wachsender Nutzerbasis stehen sie vor interessanten Herausforderungen bei der Skalierung ihrer Datenbanken.

Die drei Hauptbereiche der Optimierung:

1. Lese-Operationen (Reads)
2. Datenvolumen
3. Schreib-Operationen (Writes)

Besonders pragmatisch finde ich die Optimierung der Lese-Zugriffe durch cleveres Caching. Hier ein paar konkrete Beispiele:

• Bei der Abfrage von Benutzersprachen wurde der Cache-Key von (user_id, language_id) auf nur user_id reduziert – das senkte die Datenbankzugriffe um über 90%
• Für die „Ask to Answer“ (A2A) Funktion wurde ein zusätzlicher Cache mit Limit N eingeführt, der die Zugriffe um 50-66% reduzierte
• Bei spärlich besetzten Datensätzen (sparse data) wurde „Range Caching“ eingeführt – statt einzelner Lookups werden ganze Bereiche gecacht

Beim Thema Speicherplatz setzt Quora verstärkt auf MyRocks (MySQL mit RocksDB Storage Engine):

• Über 80% Speicherplatzersparnis bei einigen Tabellen
• 50-60% Einsparung bei anderen Datensätzen
• Schrittweise Migration, beginnend mit älteren, weniger kritischen Daten

Für die Schreib-Optimierung nutzt Quora zwei interessante Ansätze zur Parallelisierung der Replikation:

• slave_parallel_type=LOGICAL_CLOCK – theoretisch möglich seit MySQL 5.7
• slave_parallel_type=DATABASE – Tabellen in verschiedenen logischen Datenbanken

Die beschriebenen Optimierungen zeigen, wie wichtig ein nuancierter Blick auf Datenbankperformance ist. Besonders das clevere Caching und der Einsatz von MyRocks für Speicheroptimierung sind praktische Ansätze, die auch für kleinere Setups relevant sein können. Spannend finde ich auch den vorsichtigen, schrittweisen Ansatz bei der Migration zu neuen Technologien wie MyRocks – das zeigt, wie auch große Plattformen technische Schulden systematisch angehen.

Wer ähnliche Herausforderungen hat, sollte besonders das Range-Caching für spärlich besetzte Datensätze im Auge behalten – das scheint ein echter Game-Changer bei der Query-Optimierung zu sein.

Optimizing the databases at Quora

---

Zed Editor bringt SSH Remote Development

Der beliebte Code Editor Zed hat ein spannendes neues Feature angekündigt: SSH Remote Development. Damit können Entwickler jetzt Projekte auf entfernten Servern bearbeiten, während die UI lokal mit 120 FPS läuft.

Die Funktionsweise ist denkbar einfach:

• Verbindung per SSH-URL: zed ssh://my-host/~/code/zed
• Language Server, Tasks und Terminals laufen remote
• Lokale UI für beste Performance
• Konfigurierbare dauerhafte Verbindungen möglich

Technisch haben die Entwickler einige interessante Lösungen umgesetzt:

• SSH ControlMaster für persistente Verbindungen ohne erneute Authentifizierung
• Remote Server als statisch gelinkter musl Build für maximale Kompatibilität
• Daemon-Modus für unterbrechungsfreien Betrieb
• Lokales Backup von ungespeicherten Änderungen
• Volle Integration mit dem Collaboration Feature

Besonders beeindruckend ist die Unterstützung der Collaboration-Funktion, bei der jetzt bis zu vier Nodes in einer 2-Personen-Kollaboration involviert sein können. Das Team musste dafür das Project Modul neu strukturieren und intensive Tests entwickeln.

Das Feature richtet sich vor allem an Entwickler mit großen Codebasen, die von der zusätzlichen Server-Power profitieren möchten. Eine ausführliche Dokumentation steht bereit.

SSH Remoting is Here!

---

GitLab 17.8: Sicherheit und MLOps im Fokus

Auch diesen Monat bringt GitLab mit Version 17.8 über 60 Verbesserungen. Ein paar spannende Highlights:

Security First

• Neue „Protected Container Repositories“ ermöglichen bessere Zugriffskontrolle für Container Images
• PyPI Packages können nun durch Schutzregeln abgesichert werden
• Verbesserte Secret Detection mit konkreten Handlungsempfehlungen bei Sicherheitsvorfällen

MLOps & KI Erweiterungen

• Machine Learning Experiment Tracking ist jetzt GA – ideal für Data Scientists
• Neuer Python Client für MLOps (Beta) macht die Integration von ML-Workflows deutlich einfacher
• Optimierte Darstellung von ML-Experimenten und Metriken

DevOps & Infrastructure

• Linux Hosted Runners für GitLab Dedicated (Limited Availability)
• Neue M2 Pro macOS Runner (Beta) mit bis zu 6x mehr Performance
• Verbesserte Kubernetes Dashboard-Funktionen inkl. Pod-Suche

Workflow Verbesserungen

• Multiple To-Do Items pro Issue/MR
• Bessere Epic-Verwaltung mit anpassbaren Farben und Health Status
• Zeiterfassung direkt in Epics möglich

GitLab positioniert sich hier immer stärker als zentrale Plattform für ML-Entwickler. Die neuen Security-Features zeigen auch deutlich, dass GitLab weiter stark in Richtung Enterprise-Readiness arbeitet. Passend dazu gibt es übrigens für die 17.8 schon ein Security Release 17.8.1 (und auch für andere Versionen), welches du unbedingt einspielen solltest.

GitLab 17.3 released with GitLab Duo Root Cause Analysis

---

Schmunzelecke

Es gibt nun ein „outdated footer“ as Service – na gut, leider ist die API etwas überlastet und gibt noch 2024 aus. Die $4M Venture Capital helfen sicherlich, dass es bald wieder geht. Immerhin kommt was per curl:

curl https://getfullyear.com/api/year
{"year":2024,"sponsored_by":"Xbox: green gaming box thing","year_string":"2024"}%

---

💡 Link Tipps aus der Open Source Welt

Starlight: Dokumentation leicht gemacht mit Astro

Wer schon einmal eine technische Dokumentation erstellen musste, weiß wie mühsam das sein kann. Mit Starlight gibt es nun ein spannendes Open Source Framework auf Basis von Astro, das diesen Prozess deutlich vereinfacht.

Die wichtigsten Features im Überblick:

• Markdown-basiert: Volle Unterstützung für Markdown-Syntax plus YAML Frontmatter für Metadaten
• Performance: Dank Astro werden statische HTML Seiten generiert – das bedeutet schnelle Ladezeiten
• Barrierefreiheit: Von Haus aus barrierefrei gestaltet
• Flexibilität: Voller Zugriff auf die mächtigen Page-Generation Tools von Astro
• Theme-Support: Anpassbare Themes für ein professionelles Erscheinungsbild

Die Integration in bestehende Astro Projekte ist denkbar einfach. Entwickler können zwischen .md, MDX oder Markdoc Formaten wählen – je nachdem, was am besten zu ihrem Workflow passt.

Starlight ist damit eine interessante Alternative zu etablierten Dokumentations-Tools wie GitBook oder Docusaurus. Die Kombination aus Performance, Flexibilität und einfacher Bedienung macht es besonders für Developer-fokussierte Projekte attraktiv.

Die Starlight Docs sind logischerweise mit Starlight gebaut und daher wohl die beste Demo, die starlight selbst bieten kann.

https://github.com/withastro/starlight

Delta: Die bessere Git Diff Ansicht?

Delta macht Git Diffs endlich lesbar und übersichtlich – ein Open Source Tool, das die Anzeige von Git Diffs, Grep Output und anderen Vergleichen deutlich verbessert.

Die wichtigsten Features im Überblick:

• Syntax Highlighting: Code wird mit den gleichen Themes wie bei „bat“ farblich hervorgehoben
• Word-Level Diffs: Änderungen werden auf Wortebene markiert, nicht nur zeilenweise
• Side-by-Side View: Praktische Nebeneinander-Ansicht mit automatischem Zeilenumbruch
• Navigation: Mit „n“ und „N“ zwischen Dateien und Diffs springen
• Git Integration: Verbesserte Anzeige von Merge Konflikten und git blame
• Hyperlinks: Commit Hashes können als Links zum Git Hosting angezeigt werden

Die Installation ist denkbar einfach – nach dem Setup über den Package Manager muss man nur die Git Config anpassen. Das Tool lässt sich dann umfangreich an die eigenen Bedürfnisse anpassen.

Delta ist damit ein Must-Have für alle, die viel mit Git Diffs arbeiten. Die verbesserte Lesbarkeit und die praktischen Features machen die Code Review deutlich angenehmer.

https://github.com/dandavison/delta

❓ 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: