Willkommen zu allesnurgecloud.com – Ausgabe #211
In der heutigen Ausgabe findest du an erster Stelle einen Artikel eines Fractional CTO aus den USA, der in vielen Beispielen erklärt, warum Tech-Mitarbeitende kündigen oder zumindest ihren Input reduzieren. Bei vielen der genannten Vorgänge konnte ich nur noch nicken – lies ihn dir daher auch unbedingt im Original zu und schicke mir gerne Feedback zum Artikel und ob du ähnliches erlebt hast.
Ansonsten scheint sich Vodafone der Enshittification der Telekom anzuschließen und steigt aus diversen öffentlichen Peerings aus. Die Netzbremse lässt schön grüßen und ich werde anhand von 2 Vodafone Messpunkten mal im Auge behalten, was da passiert und ob sich die Latenzen ähnlich verschlechtern wie bei der Telekom (heise: Vodafone verlässt öffentliche Internnetknoten, LinkedIn Artikel zur Netzbremse)
Happy Bootstrapping Podcast
In der aktuellen Folge 146 spreche ich zum zweiten mal mit Johannes Lutz vom Stuttgarter Startup Duschbrocken. Die Aufnahme war was ganz b besonderes, denn wir haben in einem Audi E-Tron Hoonitron auf der Heilbronn Slush’d aufgenommen (Fotos bei LinkedIn). Wir sprechen über das Produkt Highlight des Jahres, den Adventskalender, Bootstrapping, seitliches Wachstum und viele Challenges – aber auch die Einbindung der Community in das Design neuer Produkte – hör gerne mal in Folge 146 rein (Spotify / Apple).
Wenn dir die Podcast Folgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).
Support the Newsletter
Ü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 oder mir einfach ne E-Mail als Antwort auf den NL schicken.
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:
Wertschätzung und warum deine besten Engineers kündigen
Selten hat mich ein Artikel so häufig nicken lassen, wie der heutige Artikel zum Thema „Wertschätzung“, würde ich es fast in einem Wort zusammenfassen wollen. Der Autor ist Lloyd, ein Fractional CTO, den Startps in den USA auf Projektbasis einstellen, wenn es brennt.
Er hat im Artikel sehr viele Beispiele zu seinen Thesen drin und ich empfehle unbedingt, den Original Artikel komplett zu lesen.
Ich versuche mich trotzdem an einer Zusammenfassung der wichtigsten Punkte…
In einem Beispiel warten ein Senior Engineer 2018 sechs Monate lang davor, dass die geplante Datenbankarchitektur nicht skalieren würde. Das Engineering Leadership stimmte ihm zwar zu – pushte aber nicht zurück gegen Product & Features. Die Entscheidung fiel: Ship now, refactor later. Er begann in derselben Woche mit Interviews für einen neuen Job. Nicht wegen der technischen Entscheidung, sondern weil sein Urteil nicht zählte.
Acht Monate später: tägliche Performance-Probleme. 18 Monate später: fünf Senior Engineers verloren, 1,4 Millionen Dollar Kosten für Recruiting, verlorene Produktivität und Knowledge Drain.
Hierarchien filtern schlechte Nachrichten heraus
Organizations create hierarchies to manage complexity. The unintended consequence is that information gets filtered at each layer….
Each layer removes detail and urgency. By the time something reaches executive level, it is either a crisis or it has been filtered out entirely.
Der Mechanismus ist simpel: Junior Engineer erwähnen ein Problem → Senior Engineer sagt’s dem Manager → Manager filtert → VP hört „we are handling it“ → CEO hört „everything on track“. Beispiel: Frontend-Team identifiziert Performance-Probleme im März. Im August beschwert sich der größte Kunde. Engineers wussten es seit fünf Monaten.
„A CTO who talks directly to junior engineers hears what is actually happening. A CTO who relies on filtered reports hears what management wants them to hear.“
Die drei wahren Kündigungsgründe (Exit Interviews nennen fast immer fälschlich „Compensation“, da man ja schon abgeschlossen hat):
1. Loss of Agency – Engineers werden um ihr Expertenurteil gebeten, das dann aus nicht-technischen Gründen ignoriert wird. Sie sagen „das wird scheitern“, werden überstimmt mit „baue es trotzdem“, und wenn es dann wie vorhergesagt scheitert, werden sie gefragt „warum hast du das nicht verhindert?“ Fintech-Beispiel: Company baute eigenes Auth-System statt etablierte Lösung zu nutzen. Senior Engineers warnten vergeblich. System shippte mit drei Security Vulnerabilities. Kosten: $580K im ersten Jahr ($180K Build + $400K entgangener ARR vom verlorenen Engineer).
2. Technical Debt wird unbezahlbar – Ein E-Commerce Unternehmen verschob die neue Datenbank Infrastruktur 18 Monate. Response Times stiegen mit der zeit von 200ms auf 4 Sekunden. Kosten: $240K Emergency Fixes + $1,2M Revenue Loss. Die beiden Engineers, die es vorhergesagt hatten, waren allerdings bereits weg.
3. Smart People, dumb work – Senior Engineer ($190K/Jahr) verbrachte 60% Zeit mit Maintenance eines Systems, welches $80K Umsatz im Jahr brachte. DieCompany zahlte effektiv $114K/Jahr um $80K zu supporten. Replacement kostete $220K. Migration aller Kunden: $40K.
Wie bekommt man solche Dinge mit – aka Frühwarnsystem
6-12 Monate vorher (Junior Engineers sehen Probleme): Seniors hören auf zu kämpfen, Architecture Reviews werden durchgewunken, „we tried that, leadership said no“ wird Standard-Antwort.
4-8 Monate vorher (Senior Engineers erleben): Sie hören auf zu argumentieren, winken alle Decisions durch, reduzieren Code Reviews auf „LGTM“. Das sieht für Executives wie Reife aus – es ist tatsächlich innerliche Kündigung.
2-4 Monate vorher (Manager sehen): LinkedIn-Updates bei Mitarbeitenden, es werden mehr Konferenzen besucht, gründliche Dokumentation entsteht (= Schuldgefühl wegen Knowledge Gap), Training von Juniors. Manager eskalieren oft nicht, weil das Thema schlecht auf sie reflektiert.
0-1 Monat vorher (Executives erfahren): „Sarah gave notice.“ Complete surprise – alle sind überrascht
Und wie aus einer Kündigung 5 werden: Eine Cloud Infrastruktur Firma verlor zwei Engineers in drei Wochen. Über drei Monate gingen fünf weitere. Domino-Effekt kostete: $2,2 Millionen + acht Monate Verzögerung bei drei Major Initiatives.
Was kann man dagegen tun?
Ein CTO allokierte vier Stunden/Woche für Skip-Level Conversations – direkte Gespräche mit Engineers mehrere Hierarchieebenen tiefer, unter Umgehung der Manager. Die freiwillige Kündigungsrate sank in einem Beispiel von 18% auf 7% jährlich. „I hear about issues when they are small and fixable. Previously, I heard about them when they were resignation letters.“
Ein Developer erwähnte eine 45-Minuten-Test-Suite Laufzeit als Blocker. Ein CTO allokierte daraufhin sofort Budget für zwei Wochen Optimierung. Die Runtime der Test-Suite sank auf acht Minuten. Investment: $12K. Signal: Your input produces action. Der Wert fürs Halten dieser Person übersteigt die $12K bei weitem.
Die Rechnung: Skip-Level Conversations (CTOs sprechen direkt mit Engineers statt über gefilterte Manager-Reports) kosten ca. $50K/Jahr in Executive Time. Verhindert das eine Senior Engineer Departure ($275-395K), zahlt es sich fünffach aus. Die Alternative – über Resignation Letters lernen – ist katastrophal teurer per Outcome.
„Engineers are expensive and competitive is easier than admitting our decision-making processes systematically ignore technical expertise.“
Der einfache Mechanismus: Executives fragen direkt bei Engineers nach – und hören die ungefilterte Wahrheit, bevor Probleme zu Kündigungen werden.
Als Engineer jeden Levels möchte man gehört werden, und man möchte auch Feedback zu einer Meinung – das ist die mindeste Erwartungshaltung und eine wichtige Wertschätzung. Stellt euch einfach eine Mitarbeiterumfrage vor, die man dann schön präsentiert – jeder zieht die gleichen Schlüsse und was man nun eigentlich ändern müsste , es passiert aber – nichts. Dann hätte man lieber keine Umfrage gemacht und die Erwartungshaltung geschürt, das schützt einen wenigstens vor den enttäuschten Menschen.
Wenn du also Skip-Level Conversations einführen möchtest, dann unbedingt auch was mit dem Input anfangen. Und bei Exit Interviews 2 mal nachfragen, ob es wirklich an der Bezahlung lag.
So, ich habe fertig – wie siehst du das Thema? Hast du schon ähnliches erlebt?
Why Your Best Engineers Are Interviewing Elsewhere
Hyperscaler Earnings im Vergleich
Die Big Tech Earnings offenbaren ein spannendes Rennen im Cloud-Geschäft. Während AWS weiterhin die Nummer 1 bleibt, wächst Microsoft Azure mit 40% am schnellsten – und überrascht damit selbst die optimistischen Analysten.
Microsoft Azure: 40% Wachstum – der schnellste der drei Hyperscaler
Microsofts Cloud-Sparte Azure wuchs um 40% Year-over-Year nach 39%, 33% und 31% in den Vorquartalen. Eine klare Beschleunigung – und damit deutlich schneller als AWS (20%) und Google Cloud (34%). Analysten hatten sich trotzdem noch mehr erhofft. Microsoft plant dieses Jahr 85 Milliarden Dollar CapEx und ist auf gutem Kurs dorthin. Die letzten zwölf Monate investierten sie 68 Milliarden in Data Center, während der Operating Cashflow bei 147 Milliarden lag.
Ein überraschender Fund in den SEC-Filings: Die 3,1 Milliarden Dollar „Other Expenses“ lassen sich auf OpenAI zurückführen. Da Microsoft etwa ein Viertel besitzt, bedeutet das: OpenAI machte 11-13 Milliarden Dollar Verlust allein in diesem Quartal.
Amazon AWS: Die Beschleunigung ist zurück – erstmals seit 2022 über 20%
AWS überraschte positiv mit 20% Wachstum nach 17,5% und 17% – das erste Mal seit 2022 wieder über der 20%-Marke. Bei einer Run-Rate von über 120 Milliarden Dollar Jahresumsatz ist das bemerkenswert, auch wenn AWS deutlich langsamer wächst als die Konkurrenz. Die operative Marge liegt stabil bei 35% – die höchste der drei Hyperscaler. Allein in diesem Quartal schuf Amazon annualisiert 22 Milliarden Dollar zusätzlichen ARR.
Amazon investiert mit 125 Milliarden Dollar geplanten CapEx für 2025 am aggressivsten – allein dieses Quartal waren es 35 Milliarden. Interessant: Im Vorquartal waren es 32 Milliarden (83% YoY-Steigerung), jetzt „nur noch“ 55% YoY – eine leichte Verflachung der Investitionskurve.
Google Cloud: Solides 34% Wachstum mit Margenverbesserung
Google Cloud lieferte 34% Wachstum nach 28% und 32% – eine Beschleunigung, aber langsamer als Azure. Von 11,4 auf 15,1 Milliarden Umsatz gestiegen, sind das annualisiert 15 Milliarden neuer Revenue. Besonders beeindruckend: Die operative Marge verbesserte sich von 17% auf 24% – klare Skaleneffekte. Das Operating Income stieg annualisiert um 6 Milliarden.
Google investiert 24 Milliarden dieses Quartal (83% YoY-Steigerung) und läuft auf eine 100 Milliarden Run-Rate zu. Bei einem Operating Cashflow von 150 Milliarden in den letzten zwölf Monaten hat Google die Mittel dafür.
Der Vergleich: Wachstum vs. Profitabilität
- Azure (40%): Wächst am schnellsten und holt auf AWS auf – dank OpenAI-Integration und KI-Euphorie
- Google Cloud (34%): Starke Margenverbesserung von 17% auf 24% zeigt Skaleneffekte
- AWS (20%): Wächst am langsamsten, aber mit 35% Marge am profitabelsten und auf höchster Umsatzbasis
Mit 40% Wachstum powert Azure an der Konkurrenz vorbei. Während AWS weiterhin Marktführer bleibt, scheint eine Wachablösung an der Spitze wahrscheinlich: Bis Ende 2026 könnte Azure AWS tatsächlich einholen. Google liefert solide Zahlen mit der besten Margenentwicklung, kann aber beim Wachstum nicht mit Microsoft mithalten.
Die CapEx-Schlacht geht weiter: Amazon (125 Mrd.), Microsoft (85 Mrd.) und Google (100 Mrd. Run-Rate) investieren zusammen über 300 Milliarden Dollar in Data Center – hauptsächlich für KI-Workloads – mal schauen ob sich der Trend im nächsten Jahr fortsetzt oder ob die Blase tatsächlich platzt.
OpenAI For-Profit | Tech Earnings: Microsoft, Amazon, Google, Meta, Apple, Cloudflare #506
Anzeige
Buchtipp: „Phoenix Project: A Novel About It, Devops, And Helping Your Business“
Und nach dem Tipp von letzter Woche geht es diese Woche weiter mit einem Klassiker: „The Phoenix Project“ von Gene Kim, Kevin Behr und George Spafford. Das Buch ist als Roman geschrieben und erzählt die Geschichte von Bill, der plötzlich VP of IT Operations wird – mitten im totalen Chaos. Ein gescheitertes Projekt, frustrierte Entwickler, wütende Kunden und ein Vorstand, der kurz davor ist, die gesamte IT outzusourcen.
Was das Buch für mich so so genial macht, ist die einfache Lesbarkeit und, dass man sich darin wiederkennt. Die endlosen Hotfixes, die Ticket-Flut, die ständigen Notfall-Meetings. Und während Bill lernt, wie man DevOps-Prinzipien in der Praxux anwendet, lernt man als Leser nebenbei, warum manche IT-Abteilungen immer im Feuerlöschen-Modus sind – und wie man da rauskommt.
Ich musste beim Lesen oft schmunzeln (und manchmal auch zusammenzucken), weil so vieles einfach verdammt nah an der Realität ist. Das Buch ist perfekt für alle, die verstehen wollen, warum DevOps mehr als nur ein Buzzword ist.
Verlinkt ist die englische Variante – das Buch gibt es aber auch auf Deutsch. Klare Leseempfehlung – vor allem für alle, die in oder mit IT-Teams arbeiten.
Buchtipp: „Phoenix Project: A Novel About It, Devops, And Helping Your Business“
„Schick das deinem Freund, der glaubt, Cloud sei eine gute Idee“
Artikel Autor Rameerez hat alle seine Projekte aus der Cloud geholt und spart nun 10x bei den monatlichen AWS-Kosten – bei 2x Performance-Speedup. Sein viraler Tweet löste eine heftige Debatte aus, die mehr über die Tech-Industrie verrät als über Server-Management.
Ein Bare-Metal-Server mit 80 Cores bei Hetzner: $190/Monat. Vergleichbare AWS C5-C6 Instanzen: $2.500-3.500/Monat – also 13-18x teurer. Selbst Reserved Instances kosten noch $1.300/Monat (7x teurer) plus $46K Upfront bei 3-Jahres-Lock-in.
Wer keine 80 Cores braucht: 48-vCPU VPS für $300/Monat ohne Setup-Fees, ohne Contracts. Oder eine 8-Core-Maschine mit 32GB RAM für $50/Monat, die locker alle deine Projekte gleichzeitig bedienen kann – solange du nicht Millionen Requests täglich hast.
„You’ve been scammed, likely not out of your own money, but your employer’s money – and that’s why you don’t give a crap.“
Warum der Pushback? Rameerez stellt fest: Die meisten Kritiker haben „DevOps“, „Cloud Engineer“ oder „AWS Certified“ im Lebenslauf – und kein Skin in the Game. Sie zahlen keine Cloud-Bills, profitieren von der Komplexität (job security) und haben null Incentive für effiziente Entscheidungen. Mit dem Geld anderer Leute sei jeder mutig.
Die Gaslighting-Strategie der Cloud-Evangelisten
„You’re using the cloud wrong“, „It’s expensive because you’re doing it poorly“, „You just need to know how to use the cloud.“ Rameerez kennt diese Mantras – er hat AWS Certs studiert, seine Infra war nicht overprovisioned, er hatte bereits seine monatliche Bill von $5K auf unter die Hälfte gedrückt. Seine Meinung: Die Cloud ist einfach zu teuer, Punkt.
Der Trick der Cloud-Anbieter: Extrem günstig (kostenlos!) für Startups, dann extrem teuer sobald sie wachsen. AWS machte die Runde durch Startup-Accelerators, verteilte Credits – klassisches Vendor Lock-in.
Die Realität für 99,9% der Businesses ist aber: die meisten Firmen sind klein (Power Law Distribution). Nur ein winziger Bruchteil braucht High Availability, Multi-Zone Replication, Distributed Kubernetes Clusters. Rameerez bedient Millionen Requests täglich mit zwei Servern. Indie Hacker Pieter Levels (@levelsio) macht es sogar auf einem einzigen Server.
Die Angst vor „Servern“ sei unbegründet – Hardware-Failures sind heute selten. Ein Server läuft nach Initial Setup oft jahrelang problemlos ohne viel Intervention (Na gut, Patchen und als mal rebooten wäre schon gut. Man brauche kein 5-Person-DevOps-Team. Claude und ChatGPT verstehen Linux perfekt – nie sei Server-Management einfacher gewesen. Da würde ich jetzt widersprechen – einfach alles kopieren was Claude und Chattie so von sich geben, ist keine gute Idee – und das Hirn schrumpft dann ja auch zusammen.
In vielen Punkten hat er aber recht – häufig skalieren wir, bevor Kunden und Wachstum skalieren. Macht keinen Sinn und es geht eine ganze Weile auch „klassisch“ ohne Probleme und mit geringen Kosten. Den initialen Artikel zu seiner Migration hatte ich in Ausgabe 162 schon drin – dieser hier ist nun auch aus dem Oktober 2024, jetzt aber nochmal auf HackerNews viral gegangen und daher auch erwähnenswert hier.
Send this article to your friend who still thinks the cloud is a good idea
Netflix verarbeitet 5 Petabyte Logs täglich mit ClickHouse
Netflix betreibt eines der größten ClickHouse-Deployments weltweit: 5 Petabyte Logs pro Tag bei 10,6 Millionen Events pro Sekunde – mit Sub-Sekunden-Queries.
Die Herausforderung: 40.000 Microservices, 300 Millionen Nutzer
„At Netflix, scale drives everything“, sagt Engineer Daniel Muino. Das Logging-System verarbeitet durchschnittlich 10,6 Millionen Events/Sekunde, mit Peaks bei 12,5 Millionen. Trotz extremer Write-Last: 500-1.000 Queries pro Sekunde für das Debugging von über 40.000 Microservices.
Logs sind innerhalb von 20 Sekunden durchsuchbar (SLA: 5 Minuten), teilweise mit 2 Sekunden Latency im Live-Stream.
Netflix nutzt ClickHouse für aktuelle Daten und Apache Iceberg für Langzeitspeicherung. Logs fließen über Sidecars in Ingestion-Cluster, landen in Amazon S3 und triggern via Kinesis die Verarbeitung. Eine Query-API abstrahiert darüber und gibt Engineers eine unified View.
Optimierung #1: Fingerprinting mit generierten Lexern (8-10x schneller)
Um Millionen ähnlicher Log-Messages zu gruppieren, nutzt Netflix „Fingerprinting“. ML-Modelle waren zu ressourcenhungrig, Regex skalierte nicht auf 10M Events/Sekunde.
Die Lösung: Generated Lexer mit JFlex – wie Compiler Text tokenisieren. Statt Runtime-Regex wird Code optimiert compiliert.
Ergebnis: 8-10x höherer Durchsatz, Fingerprinting-Zeit sank von 216 auf 23 Mikrosekunden.
Optimierung #2: Custom Native Protocol Serialization
JDBC Batch Inserts waren ineffizient, RowBinary Format besser, aber nicht optimal. Nach Lektüre eines ClickHouse-Blogposts stellte Daniel fest: Native Protocol ist am schnellsten – aber nur der Go-Client unterstützte es.
Daniel’s Lösung: Reverse-Engineering des Go-Clients und Bau eines eigenen Encoders mit LZ4-komprimierten Blocks. Resultat: niedrigerer CPU-Verbrauch, bessere Memory-Effizienz.
Optimierung #3: Sharded Tag Maps (Query-Zeit von 3s auf 700ms)
Custom Tags als Map(String, String) erforderten linearen Scan bei jedem Lookup. Bei 25.000 unique Tag-Keys pro Stunde war das nicht skalierbar.
Die Lösung: Map in 31 kleinere Maps sharden via Key-Hashing.
Ergebnis dramatisch:
- Filter-Query: von 3 Sekunden auf 1,3 Sekunden
- Filter + Projection: von 3 Sekunden auf unter 700ms
- Gescannte Datenmenge: 5-8x reduziert
„At Netflix’s scale, that’s a big, big win.“
Daniel’s Fazit: „The key is more about how you simplify things in order to do the least amount of work.“ Diszipliniertes Engineering und konsequentes Eliminieren von Bottlenecks machten Netflix’s Logging-System zu einem der größten ClickHouse-Deployments.
Das System fühlt sich selbst bei Netflixs „otherworldly scale“ leichtgewichtig an – der Unterschied zwischen „scrambling to chase outages“ und smooth service für hunderte Millionen Zuschauer.
How Netflix optimized its petabyte-scale logging system with ClickHouse
Observability mit SigNoz, ClickHouse und OpenTelemetry
Dream11 hat eine In-House Observability Platform gebaut, die >10.000 EC2 und Datastore-Instanzen überwacht – und dabei Millionen Dollar an kommerziellen SaaS-Lösungen spart. Das Setup verarbeitet ~100M unique Metrics at Peak und ~1M Rows/Sekunde und wird über 9 ClickHouse-Nodes repliziert. SigNoz hatte ich in Ausgabe 42 mal vorgestellt und dann aus den Augen verloren, muss ich mal wieder anschauen.
Die Architektur: OTEL → Kafka → ClickHouse → SigNoz
Telemetrie-Daten (Metrics & Traces) von Apps und Systemen fließen via OpenTelemetry Collectors zu Kafka (6 Broker, Replication Factor 3, 3-Tage-Retention). Von dort schreiben SigNoz Collectors in ClickHouse (3 Shards, 3 Replicas). Daten, die älter als 90 Tage sind werden automatisch nach S3 „archiviert“, sind aber noch abrufbar.
Scale in Zahlen:
- ~200 Mbps Ingestion Rate
- 357 TB ingested Spans/Monat
- ClickHouse Insert Query Time: 25μs
- 8xlarge Instances mit 250GB SSD bei nur ~8% CPU-Auslastung
Warum nicht Prometheus? Dessen Pull-Model skaliere nicht für distributed, high-cardinality Workloads. OTELs Push-Design mit konfigurierbaren Processors gibt feinere Kontrolle und Resilienz. Plus: Export zu multiple Backends (ClickHouse + S3 + Kafka) möglich.
Observing the Observability Stack: Statt hunderte Prometheus Scrape Targets pflegen zu müssen, zieht Prometheus Metrics von einem einzigen OTEL Collector, der via Kafka alle Pipeline-Components konsumiert. Topology-agnostic – Scale Kafka/ClickHouse/OTEL up/down ohne Prometheus YAML zu touchen.
Beim Tracing arbeiten sie mit „1% Sample Rate“ und reduzieren damit die Ingestion Load, können aber weiterhin glaubwürdig Daten analysieren. 1 % ist bei großen Systemen sicherlich sinnvoll, bei kleineren sollte man eher 5-10% wählen, je nachdem, wie die Anwendung aussieht..
In Teil 2 soll es dann um den SigNoz Server, die Collectoren und die ClickHouse Schemas gehen – ich bleib natürlich dran.
„You Don’t Need Kafka, Just Use Postgres“ ist Unsinn
Nach dem Postgres-vs.-Kafka-Artikel letzte Woche die Gegenstimme: Gunnar Morling (Debezium-Lead, jetzt Confluent) erklärt, warum „Just use Postgres“ statt Kafka problematisch ist und am Ende mehr Komplexität schafft als löst.
Der Strohmann mit der Job Queue: Die meisten „You Don’t Need Kafka“-Posts zeigen SELECT ... FOR UPDATE SKIP LOCKED für Job Queues. Das Problem: Queuing war nie ein typischer Kafka-Anwendungsfall. Kafka unterstützte historisch kein Message-Level Consumer Parallelism. Die Argumentation läuft also auf „Nutze Kafka nicht für etwas, wofür es nicht designed wurde“ hinaus. Außerdem sind robuste Queues auf Postgres schwieriger als gedacht – Long-Running Transactions verursachen MVCC Bloat und WAL Pile-up bei anhaltender Last.
Was Kafka wirklich auszeichnet: Kafka ist für Event Streaming gebaut – Microservices-Kommunikation, IoT-Daten, Data Pipelines, Realtime Stream Processing wie Fraud Detection. Die Kernfrage ist nicht Scale, sondern ob man diese Capabilities benötigt:
Log Semantics: Kafka ist ein persistenter, geordneter Event-Log mit Replay-Möglichkeit und Exactly-once-Semantik. Auf Postgres nachzubauen: erheblicher Aufwand.
High Availability: Kafka-Cluster replizieren auf mehrere Nodes mit automatischem Failover. Postgres: alle Writes zu einem Node, manuelles Failover nötig.
Consumer Groups: Verteilung der Last auf mehrere Clients, automatisches Rebalancing. Bei Postgres müsstest du das Rebalance-Protokoll selbst nachbauen.
Connector-Ökosystem: Kafka Connect bietet fertige Connectoren für praktisch jedes System. Postgres hat kein vergleichbares Ökosystem – du musst alles selbst bauen.
Das eigentliche Problem: Was als „Keep it simple“ startet, wird zur komplexen Eigenentwicklung. Du baust am Ende dein eigenes Kafka auf Postgres nach – Arbeit von hunderten Contributors über Jahre. Die richtige Architektur nutzt oft beides: Postgres für internen State, Kafka für Event-Austausch zwischen Services, synchronisiert via Change Data Capture wie Debezium. Mit KRaft-Mode und Managed Services ist Kafka-Betrieb heute einfacher denn je. Nutze das richtige Werkzeug für den Job.
„You Don’t Need Kafka, Just Use Postgres“ Considered Harmful
KI-Rechenzentren im Weltraum: Google, Bezos und Lumen Orbit
Der AI-Boom treibt verrückte Ideen: Sowohl Google als auch Jeff Bezos schlagen Rechenzentren im Orbit vor – betrieben mit 24/7-Solarenergie. Doch können die technischen und wirtschaftlichen Hürden gemeistert werden?
Google’s „Project Suncatcher“: Konkrete Pläne für 2027
Google will 2027 zwei Test-Satelliten mit je vier TPUs launchen (Partner: Planet Labs). Die Satelliten fliegen in konstantem Sonnenkontakt – 8x mehr Solarenergie als auf der Erde. TPUs werden als Konstellation (hunderte Meter auseinander) verbunden via optische Wireless-Verbindung mit ~1,6 Tbit/s.
Radiation-Test bestanden: TPUs überlebten UC Davis Particle Accelerator – 5-6 Jahre Mission seinen daher möglich. Die ökonomische Wette: Aktuell ~$1.500/kg Launch-Kosten, Google kalkuliert bis 2035 auf $200/kg – dann wäre Space-DC cost-per-kilowatt on par mit terrestrisch.
Jeff Bezos‘ Vision: Gigawatt-starke DCs via Blue Origin’s New Glenn Rakete. Vage Vision ohne Timeline – klassischer „Moonshot“, bisher.
Starcloud: Das Y Combinator Startup rechnet vor
Starcloud (ehemals Lumen Orbit – Y Combinator Startup) will’s konkret angehen: Mai 2025 Satellit-Test, 2026 Micro DC. Ihr Pitch: 24/7 Solar + passive Kühlung via Weltraum (-270°C) mit kleinem Radiator. Ein 40 MW Cluster über 10 Jahre – im All: $8,2 Mio., auf der Erde: $167 Mio. Twitter kritisiert das „Schön-Rechnen“, aber das White Paper und die schicke Website zeigen: Sie meinen es ernst.
Die Hürden: Wärmeabfuhr im Vakuum (nur Infrarot), Latenz (LEO: 20-40ms = OK für Training, KO für Echtzeit), Strahlungsschutz, autonome Wartung. Eine EU-Studie dämpft: Net-Positive nur wenn der Raketen Launcher <370 kgCO2/kg emittiert. Google ist Engineering-driven pragmatisch, Bezos visionär-vage, Lumen Orbit startup-optimistisch. Bis 2035 wird klar, ob aus Science Fiction Fact wird.
Google wants to build solar-powered data centers — in space
2 Milliarden E-Mail-Adressen im bisher größten HIBP-Datensatz
Troy Hunt hat den bisher umfangreichsten Datensatz in Have I Been Pwned (HIBP) indexiert: 1,96 Milliarden unique E-Mail-Adressen und 1,3 Milliarden Passwörter – davon 625 Millionen völlig neue. Die Daten stammen von Synthient’s Threat Intelligence Platform und enthalten hauptsächlich Credential Stuffing Lists aus diversen Data Breaches.
Die Verifikation: „Yes, that’s my password from 10 years ago“
Hunt verifizierte die Daten zunächst mit sich selbst – fand ein uraltes Passwort aus den 90ern. Bei Subscriber-Befragungen kam wiederholt: „Yes, familiar, last used 10 years ago.“ Ein Subscriber nutzte sein Passwort noch aktiv – nur zwei Ausrufezeichen mehr als die alte Version. Exakt der Grund, warum Hunt den Aufwand betreibt: Diese Credential-Paare werden durch die Veröffentlichung unbrauchbar.
Kein Gmail-Breach! Von 32 Millionen Domains sind 394 Millionen Adressen Gmail (20%) – 80% haben nichts mit Gmail zu tun. Und die 20% Gmail-Adressen haben nichts mit einer Security-Vulnerability bei Google zu tun.
Die technische Herausforderung
Fast 3x größer als der bisherige größte Breach (Collection #1, 2019). HIBP läuft auf Azure SQL Hyperscale, maxed out bei 80 Cores für fast zwei Wochen. Einfache Updates crashten komplett – mussten in 1M-Record-Batches verarbeitet werden, teilweise über Tage.
2,9 Millionen der 5,9 Millionen HIBP-Subscriber sind betroffen. Problem: So viele E-Mails auf einmal versenden, ohne auf Reputation-Blacklists zu landen. Lösung: Graduelle Delivery mit +1,5% pro Stunde, +45% pro Tag über eine Woche verteilt.
Pwned Passwords Response-Größen stiegen durchschnittlich um 50% (26kb → 40kb brotli-compressed). Services, die Pwned Passwords integriert haben, sollten Compression nutzen.
Die Daten sind jetzt als „Synthient Credential Stuffing Threat Data“ durchsuchbar – komplett getrennt vom vorherigen Synthient-Dataset.
Hunt’s Appell: Statt nach kompletten Datenrows zu fragen oder HIBP zu stressen, lieber Password Manager nutzen, MFA aktivieren und wo möglich auf Passkeys umsteigen.
2 Billion Email Addresses Were Exposed, and We Indexed Them All in Have I Been Pwned
Linux-Gamer auf Steam knacken erstmals die 3%-Marke
Nach Jahren des stetigen Wachstums ist es passiert: Linux erreichte im Oktober 2025 erstmals 3,05% auf Steam (+0,41 Prozentpunkte). Windows fiel auf 94,84% (-0,75%), macOS stieg auf 2,11% (+0,34%).
3% klingt wenig, bedeutet aber über 4 Millionen monatlich aktive Linux-User – basierend auf Valves letzter offizieller Zahl von 2022. Mit Steam Deck-Verkäufen in Millionenhöhe und Steams Wachstum seitdem dürfte die tatsächliche Zahl deutlich höher liegen.
Distribution-Breakdown: SteamOS Holo (Steam Deck) führt mit 27,18%, gefolgt von Arch Linux 10,32%, Linux Mint 22.2 mit 6,65%, CachyOS 6,01% und Bazzite 4,24%. Überraschend: CachyOS und Arch schlagen das user-friendly Bazzite – Linux-Gamer sind offenbar tech-savvier als gedacht.
Der Timing-Faktor
Das Wachstum kommt nicht zufällig: Windows 10 Support endet, mehr Menschen probieren Linux. Der Trend ist seit Monaten klar erkennbar. Mit den Gerüchten um „Steam Frame“ (angeblich SteamOS-betriebenes VR-Kit) könnte die Kurve weiter steigen.
Auch macOS profitiert: Erstmals seit langem wieder Wachstum, liegt knapp hinter Non-Deck-Linux. Die gesamte Non-Windows-Share über 5% – zum ersten Mal seit 2013.
Zockst du mit Steam unter Linux? klappt gut?
Ich finde die Auswahl auf dem Mac schon sehr eingeschränkt
Linux gamers on Steam finally cross over the 3% mark
Schmunzelecke
Dass das Passwort für die Videoüberwachnung im Louvre einfach nur „LOUVRE“ war, hast du bestimmt mitbekommen. Heute morgen kam das sogar bei uns im Radio – abenteuerlich. Haben bestimmt eine ISO und sonstige Zertifizierungen, aber sowas wird da halt nicht beachtet. Verrückt, was man in der Praxis so antrifft.
Zum Thema Software Release on Friday noch ein einigermaßen lustiger Short auf YouTube.
💡 Link Tipps aus der Open Source Welt
pg_lake – Postgres für Iceberg und Data Lakes
pg_lake ist eine von Snowflake open-sourcte PostgreSQL-Extension, die Postgres nahtlos mit Data Lakehouses integriert. Ursprünglich von Crunchy Data entwickelt, ermöglicht pg_lake die direkte Arbeit mit Iceberg-Tabellen und Dateien in Object Storage direkt aus Postgres heraus.
Features:
- Native Iceberg-Tabellen: Erstelle und verwalte Iceberg-Tabellen direkt in Postgres mit voller Transaktionsgarantie
- Direkte File-Queries: Abfrage von Parquet, CSV, JSON und Delta-Dateien in S3/Azure ohne Import
- Flexibler Datenimport: COPY-Befehl funktioniert direkt mit S3-URLs und HTTP(S)-Links
- Datenexport: Schreibe Query-Ergebnisse zurück nach S3 in Parquet, CSV oder JSON
- Geospatial-Support: Lese GeoJSON, Shapefiles und andere GDAL-Formate
- Map-Datentyp: Eingebauter Typ für semi-strukturierte Key-Value-Daten
- DuckDB Engine: Nutzt DuckDB unter der Haube für schnelle Analytics-Queries
- Auto-Schema-Detection: Erkennt automatisch Spalten und Typen aus externen Dateien
pg_lake verbindet also die transaktionale Stärke von Postgres mit der Skalierbarkeit von Data Lakehouses – alles mit vertrauter SQL-Syntax.
Und irgendwie auch cool, dass Snowflake das nun Open Source veröffentlicht – natürlich haben sie auch ein Interesse daran, dass die Menschen da draußen ihre PG Daten nach Snowflake schicken.
Hier findest du das Announcement zum Tool bei Snowflake und hier eine 4 Minuten Demo auf YouTube.
https://github.com/snowflake-labs/pg_lake
kubesafe – Safety Net für Kubernetes Cluster Management
kubesafe ist ein Open-Source CLI-Wrapper, der versehentliche Ausführung gefährlicher Befehle auf den falschen Kubernetes-Clustern verhindert. Das Tool fungiert als Sicherheitsschicht zwischen dir und deinen Kubernetes-Tools.
Features:
- Universal Wrapper: Funktioniert mit jedem K8s-Tool (kubectl, helm, kubecolor, etc.)
- Context Protection: Markiere bestimmte Contexts als „safe“ und schütze sie
- Custom Commands: Definiere eigene Listen von Commands, die Bestätigung erfordern
- Regex Support: Nutze Regular Expressions für Context-Matching (z.B.
prod-.*) - Non-Interactive Mode: Skip Prompts automatisch für CI/CD-Umgebungen
- VSCode Integration: Nahtlose Integration mit der Kubernetes VSCode Extension
- Usage Statistics: Zeigt an, wie oft gefährliche Commands blockiert wurden
- Alias-Ready: Einfache Shell-Aliase für transparente Nutzung
kubesafe löst ein alltägliches Problem: Die Angst, versehentlich Production-Ressourcen zu löschen, wenn man im falschen Context arbeitet. Aber das passiert in der Praxis ja nicht, oder doch? 🙂
https://github.com/Telemaco019/kubesafe
❓ 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: