Willkommen zu allesnurgecloud.com – Ausgabe #213
Tja, nach AWS und Azure hat es in dieser Woche Cloudflare erwischt – und wie. Viele Seiten und APIs wurden mit 500ern ausgeliefert und aufgrund der Spezialität des Incidents sind die Pages mehrfach hin- und her geflapped. Kunden hier waren teilweise 3 Stunden offline – selbst wenn die Pages selbst über andere CDNs ausgeliefert wurden (bsp. Bunny), dann war das Kundenerlebnis trotzdem gestört, weil vielleicht die Payment API oder der Captcha Dienst nicht funktioniert haben. Crazy jedenfalls, was den Vorfall verursacht hat und wie schnell man dann mit dem Postmortem war.
Klar ist, sowas darf eigentlich nicht passieren und dennoch ist es völlig normal, dass es passiert. Jedenfalls nimmt das Thema aufgrund der Brisanz in der aktuellen Ausgabe ein wenig mehr Raum ein als üblich – Viel Spaß mit der Ausgabe!
Happy Bootstrapping Podcast
Besonders gefreut hab ich mich über Podcast Folge 148, da ich selber Clockodo.com Kunde bin. Mit Co-Founder Moritz Hofmann. hab ich daher ausführlich über die Story der Zeit-und Projekterfassung gesprochen. Clockodo enstand aus dem eigenen Bedarf in der Agentur heraus und seit 2017 arbeitet das Team Vollzeit an der SaaS Anwendung. Mittlerweile mit 35 Menschen im Team. Das hab ich so nicht erwartet, aber das passiert, wenn man einfach in Ruhe und Vernab vom Hype an seinem Produkt baut – cool! Hör gerne mal in Folge 148 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).
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:
Cloudflare-Ausfall: Wie ein .unwrap() das halbe Internet lahmlegte
Am 18. November 2025 erlebte Cloudflare den schlimmsten Ausfall seit 2019, als CEO Matthew Prince in einem bemerkenswert transparenten Postmortem noch am selben Tag die Details offenlegte. Kernfunktionen waren 3 Stunden, weitere Services dann 6 Stunden lang gestört und Services von ChatGPT über X bis hin zu Uber – nicht oder nur eingeschränkt erreichbar. Die Ursache: Eine scheinbar harmlose Datenbankberechtigungs-Änderung in ClickHouse löste eine Kettenreaktion aus, die in einem simplen .unwrap() in Rust endete.
Die technische Ursache im Detail
Cloudflare wollte die Sicherheit verbessern und änderte Datenbankberechtigungen von einem gemeinsamen System-Account zu individuellen Nutzer-Accounts. Eine Abfrage, die zuvor 60 Features aus der „default“-Datenbank holte, lieferte plötzlich auch Daten aus der „r0“-Datenbank – das Feature-File verdoppelte sich auf über 120 Einträge. Das Bot Management Modul hatte jedoch ein hart kodiertes Limit von 200 Features mit vorallokiertem Speicher. Als das überdimensionierte File propagiert wurde, crashte die Software durch einen unbehandelten Error in der append_with_names() Funktion – ausgelöst durch ein .unwrap(), das nicht mit einem Error-Fall rechnete.
Der Debugging-Marathon
Besonders tückisch: Das Feature-File wurde alle 5 Minuten neu generiert und nach und nach auf die Edge-Nodes verteilt. Manchmal war das File korrekt, manchmal fehlerhaft – die Systeme erholten sich kurzzeitig, um dann wieder zu crashen. Das Cloudflare-Team vermutete zunächst einen DDoS-Angriff, da zeitgleich ihre Status-Page ausfiel (eine nicht-zusammenhängende Koinzidenz). Erst nach 2,5 Stunden identifizierten sie das fehlerhafte Configuration-File als Ursache. Die vollständige Wiederherstellung dauerte bis 17:06 UTC – insgesamt knapp 6 Stunden.
Betroffene Dienste und Kaskadeneffekte
Der Ausfall zog einen massiven Blast Radius: Core CDN lieferte HTTP 5xx-Errors, Workers KV hatte eine stark erhöhte Fehlerrate, das Dashboard war wegen Captcha-Ausfällen (Turnstile) nicht erreichbar, und Access sowie Email Security waren teilweise ausgefallen. Wie Gergely Orosz im Pragmatic Engineer hervorhebt, kam das Postmortem innerhalb von 24 Stunden – Matthew Prince schrieb einen ersten Entwurf zu Hause, das Team füllte die offenen Fragen in einem Google Doc und nach Review durch das SF-Team wurde es veröffentlicht. Diese Geschwindigkeit ist bei einem börsennotierten Unternehmen bemerkenswert (Matthew schreibt auf HackerNews etwas dazu).
Cloudflare CTO Dane Knecht hatte auf LinkedIn recht schnell Informationen geteilt und sich bei allen Kunden entschuldigt.
Parallelen zu früheren Vorfällen
Cloudflare hat eine Historie von Ausfällen – vom BGP-Selbstaussperrung im Juni 2022 bis zum Stromausfall in Portland 2023. Was Cloudflare jedoch auszeichnet: Die konsequente Transparenz. Während andere Provider Wochen für ein oberflächliches Postmortem brauchen, dieses später offline nehmen liefert Cloudflare detaillierte technische Analysen binnen Stunden, übersetzt es in X Sprachen und lässt es für immer und ewig im Internet stehen. Davor kann man nur den Hut ziehen, mehrfach. Auf der anderen Seite ist es vermutlich die beste Chance, verlorenes Vertrauen wieder zurückzugewinnen.
Drei Dinge fallen trotzdem auf: Erstens zeigt der Incident, wie globale Datenbank-Änderungen hochriskant sind – selbst harmlos wirkende Permission-Updates können unerwartete Query-Resultate produzieren. Zweitens: Explizites Error-Logging vor dem Werfen von Exceptions hätte die Root-Cause-Analyse drastisch beschleunigt. Drittens: CDNs sind kritische Infrastruktur, aber echte Multi-CDN-Strategien sind teuer und komplex. Die meisten Unternehmen werden auch weiterhin diese Single Points of Failure akzeptieren müssen – die Frage ist nur, wie gut sie für solche Szenarien vorbereitet sind. Beispielsweise. konnte man sich nicht in Cloudflare einloggen, um den Service zu deaktivieren, da der Captcha Services Turnstile ja nicht funktioniert hat.
Ein paar Fragen, die man sich nach dem Ausfall stellen sollte:
- Hast du ein Service Token zur Hand gehabt und hättest Cloudflare für deine Page per API abschalten können?
- Hat du den Prozess irgendwo dokumentiert und ein Runbook dafür?
- Kannst du zur Not DNS Einträge per API ändern / Terraform, etc.?
- Wärst du darauf vorbereitet gewesen, die Zertifikate auszutauschen? Reicht die Security dann aber aus?
- Wenn deine Hauptpräsenz über Cloudflare ausgeliefert wird und nicht funktioniert – funktioniert deine Statuspage noch, da diese dann mit absicht kein Cloudflare verwendet?
- ….
Auf HackerNews gab es über 1500 Kommentare zum Thema, aber eben auch Beispiele, wie man per API hätte agieren können. Ein paar Auszüge:
„How did we get to a place where either Cloudflare or AWS having an outage means a large part of the web going down? This centralization is very worrying.“
Ja, irgendwie war das internet mal dezentraler gedacht. Wir haben aber Resilienz gegen Bequemlichkeit getauscht. Ich selber nutze auch gerne Cloudflare, da DNS dort einfach funktioniert und man DNS mit Rollen/Rechten zusammen mit Kunden machen kann.
Auch interessant:
„Oddly this centralization allows a complete deferral of blame without you even doing anything: if you’re down, that’s bad. But if you’re down, Spotify is down, social media is down… then ‚the internet is broken‘ and you don’t look so bad.“
Man ist selber nicht schuld und alle haben ja auch dann Verständnis für so eine Outage, da man selber nichts dafür kann.
HackerNews läuft übrigens nicht über Cloudflare, da hat man sich also rumtreiben können.
Ansonsten sollte man sich immer Fragen, ob die eigene Page einen Service wie Cloudflare überhaupt braucht. In Deutschland vergrault man dank der Telekom Netzbremse sowieso viele User, da sollte man sich eh Alternativen anschauen.
Cloudflare outage on November 18, 2025
GDPR-Abschwächung in der EU während US-Abhängigkeit offensichtlich wird
Die EU rudert bei ihrer Tech-Regulierung zurück. The Verge berichtet, wie die Europäische Kommission unter Druck von Big Tech und der Trump-Administration zentrale GDPR-Elemente aufweicht. AI-Unternehmen dürfen künftig personenbezogene Daten für Training nutzen, sofern andere GDPR-Anforderungen eingehalten werden. Unternehmen können einfacher anonymisierte und pseudonymisierte Datensätze teilen. Hochrisiko-KI-Regeln des AI Act werden verschoben, bis „benötigte Standards verfügbar sind“. Cookie-Banner werden vereinfacht – über deren unnötige Komplexität hatte ich bereits in Newsletter 140 berichtet – jetzt schauen wir mal, wie es dann wirklich implementiert werden soll.
Bürgerrechtsgruppen protestieren heftig, sehen fundamentale Schutzrechte gefährdet. Selbst Ex-Premierminister Mario Draghi drängte auf Lockerungen – Europa fürchtet im KI-Wettrennen gegen USA und China abgehängt zu werden.
Die bittere Ironie dieser Abschwächung
Zeitgleich zeigt ein Fall aus Frankreich die dramatischen Folgen US-Abhängigkeit. ICC-Richter Nicolas Guillou wurde von den USA sanktioniert – heise berichtet über die drastischen Konsequenzen: Alle Konten bei Amazon, Airbnb, PayPal geschlossen. Online-Buchungen werden storniert, Transaktionen in US-Dollar verboten. Visa, Mastercard und American Express kontrollieren faktisch Europas Zahlungsinfrastruktur – selbst nicht-amerikanische Banken schlossen Konten.
Guillou fordert die Aktivierung einer EU-Blocking-Regelung (EG Nr. 2271/96) gegen US-Sanktionen. Irgendwie kann ich mir nicht vorstellen, dass wir so unterschwellig erpressbar werden wollen.
Europe is scaling back its landmark privacy and AI laws
Anzeige
Buchtipp: „Remote: Office Not Required“
Heute geht’s um „Remote: Office Not Required“ von Jason Fried und David Heinemeier Hansson – den gleichen Typen, die auch „It Doesn’t Have to Be Crazy at Work“ geschrieben haben. Und wieder liefern die Basecamp-Gründer ab.
Das Buch räumt mit dem Mythos auf, dass produktive Arbeit nur im Büro stattfinden kann. Die beiden zeigen, warum das „alle unter einem Dach“-Modell aus der Industriellen Revolution endlich ausgedient hat. Remote Work ist nicht die Ausnahme, sondern macht einfach Sinn – wenn man es richtig macht.
In kurzen, knackigen Kapiteln geht’s um alles: Von „Talent ist nicht an Hubs gebunden“ über „Wann tippen, wann reden“ bis zu „Hör auf, Stühle zu managen“. Die Autoren erklären, wie man Remote Work als Manager organisiert, wie Teams zusammenarbeiten ohne sich ständig über die Schulter zu schauen, und wie man die virtuelle Kaffeemaschine ersetzt.
Das Buch ist mittlerweile fast schon prophetisch – geschrieben lange bevor Corona uns alle ins Home Office gezwungen hat. Klare Leseempfehlung für alle, die Remote Work verstehen oder besser machen wollen!
Buchtipp: „Remote: Office Not Required“
Schwierige Entscheidungen ohne Vertrauensverlust kommunizieren
Karin Hurt und David Dye von Let’s Grow Leaders erklären im verlinkten Artikel, wie Manager unpopuläre Entscheidungen kommunizieren, ohne das Vertrauen ihres Teams zu verlieren. Die größte Falle: Upper Management unter den Bus werfen.
Phrasen wie „Das war nicht meine Entscheidung“ oder „Ich verstehe auch nicht, warum die das so entschieden haben“ zerstören die eigene Glaubwürdigkeit. Wer sich von Entscheidungen distanziert, wird vom Leader zum machtlosen Messenger.
Das 4-Schritte-Framework
- Connection: Die emotionale Realität anerkennen – „Ich weiß, das ist nicht die Entscheidung, die wir als Team getroffen hätten.“
- Clarity: Das „Warum“ erklären, notfalls beim eigenen Manager nachfragen.
- Curiosity: Das Team ins „Wie“ einbeziehen – „Wie können wir das so umsetzen, dass wir stolz darauf sein können?“
- Commitment: Konkrete nächste Schritte definieren und Termine setzen.
Menschen akzeptieren Entscheidungen eher, wenn sie die Begründung verstehen und mitgestalten können, wie sie umgesetzt werden. Das Re-Empowerment durch Mitgestaltung verwandle Frustration in Ownership.
Soweit die Theorie – in der Praxis wissen wir sicher auch, dass Einbeziehung auch immer einen Spagat darstellt und man es nicht jedem Recht machen kann. Das „Warum“ erklären finde ich aber super wichtig – „Start with the why“ ist glaub deshalb auch ein beliebter TED Talk und es gibt ja sogar das passende Buch von Simon Sinek dazu.
How to Communicate Difficult Decisions at Work without Losing Your Team
Cloud Native DC Teil 2: Warum On-Prem Kubernetes so schwer ist
Matthias Winzeler von meltcloud erklärt im zweiten Teil seiner Serie zum Cloud Native Data Center, warum Kubernetes On-Premise deutlich schwieriger zu betreiben ist als in der Cloud (hier ist der erste Teil).
Die Control Plane Herausforderung
Ein produktionsreifes Kubernetes-Cluster benötigt drei Control Plane Nodes (kube-apiserver, scheduler, controller-manager) mit jeweils 4 vCPUs und 16 GB RAM. Hinzu kommen Load Balancer für High Availability und die etcd-Datenbank, deren Betrieb vielleicht eine der größten operativen Herausforderungen darstellt.
Day 2 Operations
Kubernetes veröffentlicht monatlich Patch-Versionen und alle 4 Monate neue Minor-Versionen. Dazu kommen regelmäßige Updates von etcd, OS-Kernel, Container Runtime sowie Certificate und Secret Rotation – alles ohne Disruption der laufenden Workloads.
Cluster Sprawl Problem
Die schwache Multi-Tenancy von Kubernetes führt dazu, dass Unternehmen zwischen 10 und mehreren hundert Clustern betreiben müssen – für Trennung von Non-Prod/Prod, spezielle Workloads oder Größenlimitierungen. Hosted Control Planes können helfen, schaffen aber ein Bootstrapping-Problem für den initialen Management-Cluster.
Winzelers Analyse bestätigt die Beobachtungen von Kelsey Hightower, dass Cloud-Technologien endlich auch On-Premise standardisiert nutzbar werden – die Komplexität bleibt jedoch erheblich. Der Artikel ist Teil einer Serie und nun kommen noch 5 weitere Artikel – ich hoff, dass ich alle hier dann unterbekomme 🙂
Building the Cloud Native Data Center – Part 2: Why On-Prem Kubernetes is Hard
Der 1.000-Dollar-AWS-Fehler: NAT Gateway, mal wieder
Mathias Hansen von Geocodio beschreibt in einem Blog-Post, wie eine vergessene VPC-Konfiguration zu unerwarteten Kosten von über 1.000 Dollar führte. Die Geolocation-Plattform synchronisiert täglich hunderte Gigabytes an Geodaten von Hetzner zu AWS S3 – eigentlich kostenlos innerhalb derselben Region.
Die Falle: Bei VPCs mit NAT Gateway werden S3-Transfers standardmäßig durchs NAT Gateway geroutet – trotz gleicher Region. Resultat: 20.167 GB an einem Tag = $907,53 an NAT Gateway Data Processing Fees ($0.045/GB). Die AWS-Regel „EC2 zu S3 ist kostenlos“ gilt nur mit korrekter Routing-Konfiguration.
Die Lösung sind VPC Gateway Endpoints für S3 – komplett kostenlos, keine Hourly Charges, keine Transfer Fees. Der Endpoint erstellt eine direkte Route von der VPC zu S3 und umgeht das NAT Gateway vollständig. Über das teure NAT Gateway und Alternativen wie fck-nat hatte ich bereits in Newsletter 87 berichtet.
Hansen betont: AWS Cost Anomaly Detection erkannte das Problem innerhalb von Tagen – ein essentielles Tool, das man unbedingt so konfigurieren sollte, dass es einen auch alarmiert, wenn sowas passiert.
Immerhin sind die offiziellen NAT Gateways nun regional verfügbar – früher musste man die dann überall buchen. Ansonsten hier nochmal der Hinweis zu den Alternativen fck-nat und alternat.
Datadog: SRE und Security in einer Organisation vereint
Datadog hat seine SRE und Security-Teams zu einer einzigen Organisation zusammengeführt, wie Bianca Lankford im Datadog Monitor Blog erklärt. Der Ansatz breche Silos auf und wendet bewährte SRE-Praktiken auf Security-Herausforderungen an – und umgekehrt.
Die neue „Security and Reliability Organization“ arbeitee in drei Bereichen: Das Product Team sichert das Feature-Design durch Code-Scanning und Supply-Chain-Kontrollen. Das Internal Cloud Infrastructure Team bettet Security über Infrastructure-as-Code in Deployments ein. Das Security Operations Team nutzt Datadogs Observability für Security-SLOs und behandelt Vulnerabilities wie Reliability-Issues.
Praktische Vorteile
Die Verschmelzung ermöglicht proaktives Risikomanagement durch Integration in Core Observability Workflows und verbessert Log-Governance sowie Auditing. Statt isolierter Security Incident Response Teams gibt es einen einheitlichen Incident-Prozess mit Security-Playbooks und standardisierten Engineering-Praktiken. Security-Teams profitieren zudem von regelmäßiger Incident-Erfahrung.
Der Ansatz erinnert an Googles SRE-Implementierungsmodelle, geht aber einen Schritt weiter durch die vollständige organisatorische Integration beider Disziplinen. Das finde ich ja nicht verkehrt, wenn alle einfach in einem Boot sitzen und man nachts um 3 gemeinsam entscheidet, ob ein CVE einen sofortiges Eingreifen und Deployment benötigt oder nicht.
Security and SRE: How Datadog’s combined approach aims to tackle security and reliability challenges
Österreich: Ministerium migriert 1.200 MA in 4 Monaten zu Nextcloud
Das österreichische Bundesministerium für Wirtschaft, Energie und Tourismus (BMWET) hat 1.200 Mitarbeiter in nur vier Monaten von Microsoft zu Nextcloud migriert, wie Sourav Rudra auf It’s FOSS berichtet. Die Entscheidung fiel nach einer Risikoanalyse, die zeigte, dass ausländische Cloud-Dienste die DSGVO-Anforderungen und NIS2-Richtlinie nicht erfüllen.
Hybrides Setup statt Komplettumstieg
Das Ministerium wählte einen pragmatischen Ansatz: Nextcloud übernimmt die gesamte interne Kollaboration und sichere Datenspeicherung, während Microsoft Teams ausschließlich für externe Meetings verfügbar bleibt. Die Implementierung erfolgte gemeinsam mit Atos Austria und dem Nextcloud-Partner Sendent, der eine Outlook-Integration bereitstellte.
Gründliche Vorbereitung als Erfolgsfaktor
Der schnelle Rollout gelang durch eine umfassende Informationskampagne mit Trainings, Videos und einem detaillierten internen Wiki. CISO Florian Zinnagl betont: „Wir tragen Verantwortung für eine große Menge sensibler Daten. Deshalb sehen wir es kritisch, uns auf Cloud-Lösungen von nicht-europäischen Konzernen zu verlassen.“
Die Migration reiht sich ein in den Trend zu souveränen Cloud-Lösungen wie dem Nextcloud Workspace von Ionos, der mittlerweile gestartet ist. Interessant dabei – die Preise skalieren nicht mit der Anzahl der User – 1 Anwender ist für 9€/Monat dabei, für 20€/Monat dann schon 5 User und 25 Anwender gibt es ab 75€.
Falls du das schon getestet hast, schreib mir gerne, wie das für dich funktioniert oder gerne auch welche anderen Alternativen du dir anschaust.
Good News! Austrian Ministry Kicks Out Microsoft in Favor of Nextcloud
11 Milliarden Euro: Schwarz-Gruppe baut Rechenzentrum in Lübbenau
Die Schwarz-Gruppe, bekannt durch Lidl und Kaufland, investiert 11 Milliarden Euro in ein Rechenzentrum in Lübbenau – die größte Einzelinvestition ihrer Unternehmensgeschichte, wie Co-Chef Christian Müller beim Spatenstich am 17. November bestätigte.
Vom Dampfkoloss zur KI-Fabrik
Der Standort hat Symbolkraft: Bis 1996 stand hier Europas größtes Dampfkraftwerk mit 1,3 Gigawatt Leistung. Was blieb, ist die entscheidende 200 Megawatt Energieinfrastruktur – Hochspannungsleitungen und Umspannwerke, die andernorts Jahre Bauzeit erfordern würden – oder schnell gebaut sind und dann der Anschluß auf sich warten lässt…. Zur Historie des Standorts gibt es hier eine interessante Zusammenfassung mit vielen ausgehenden Links und Artikeln.
Die technischen Dimensionen
Bis Ende 2027 entstehen auf 13 Hektar sechs Gebäude für bis zu 100.000 KI-GPUs – das entspricht den fünf geplanten EU AI-Gigafactories zusammen. Zum Vergleich: Das neue Telekom/Nvidia-Rechenzentrum in München soll mit 10.000 GPUs laufen. Ob das ein kleiner Seitenhieb ist? Bei der Telekom war Nvidia CEP Jensen Huang sogar vor Ort, den Weg nach Lübbenau hat er scheinbar nicht gefunden.
Hauptnutzer des Standorts soll die Cloud-Plattform der Schwarz Gruppe, STACKIT, werden. STACKIT hat bereits dreistellige Kundenzahlen (Bundesagentur für Arbeit, Polizei Baden-Württemberg, FC Bayern München). Co-CEO Rolf Schumann nennt den Bau des Rechenzentrums eine „Blaupause für Souveränität“. Die Abwärme fließt übrigens ins Fernwärmenetz und der Strom kommt aus erneuerbaren Energien.
Das Projekt zeigt: Private Investoren treiben Deutschlands KI-Infrastruktur voran – mit oder ohne EU-Förderung. Die erste Ankündigung erfolgte bereits im Dezember 2024 – hatte ich in Ausgabe 191 schon erwähnt.
Schwarz-Gruppe baut Rechenzentrum für elf Milliarden Euro
Tines: Zero-Downtime Migration zwischen AWS Regions
Anna Dowling vom Automation-Plattform-Anbieter Tines beschreibt im Tines Engineering Blog die komplexe Migration eines Kundentenants zwischen AWS Regions ohne Downtime. Die Herausforderung: Millionen kritischer Workloads täglich bei 100% System-Verfügbarkeit umziehen.
Technische Architektur
Die Migration kombinierte mehrere Technologien: Lambda@Edge für intelligentes Request-Routing mit automatischem Failover, pg_easy_replicate für PostgreSQL Logical Replication und VPC Peering für sichere Cross-Region-Konnektivität. Besonders knifflig war die Handhabung von gzippten Inhalten und CloudFront-Header-Restriktionen.
BLOB-Problematik und Reliability-Verbesserungen
Da PostgreSQL 14.10 keine BLOB-Replikation unterstützt, entwickelte das Team einen eigenen Ruby Sidekiq Job für die Synchronisation von Kunden eigenen Attachments. Gleichzeitig verlagerte man die Throttle- und Delay-Logik von Redis auf datenbankbasierte Persistenz – um während der Migration keine Events zu verlieren. Interessant, dass man ne Architektur Änderung macht, um eine Migration zu machen – kann man danach ja zurückbauen.
Die gesamte Migration lief über eine Tines Story mit vier Phasen: Setup, Replication, Switchover und Post-Migration – inklusive Slack-Monitoring. Beim Switchover wurde die Source-DB auf READ ONLY gesetzt, Lambda@Edge erkannte die 5xx-Fehler und routete automatisch zur neuen Region.
Das Projekt ähnelt den Zero-Downtime PostgreSQL-Upgrades von Knock.app, zeigt aber die zusätzliche Komplexität bei Cross-Region-Migrationen. So Live / Online Migrationen im größeren Stil sind ja immer beeindruckend – aber sicherlich auch gut vorbereitet und das muss nicht immer so laufen, könnte ich mir vorstellen.
Zero downtime database migrations: Lessons from moving a live production database
Schmunzelecke
Auf chronodivide.com kannst du Command & Conquer Red Alert 2 im Browser spielen – also auch auf dem Handy oder Tablet – mir wäre ja Warcraft 2 lieber gewesen, aber kommt vielleicht ja noch.
Zu den Laptop Preisen von 1989 gibt es hier ein Video auf Instagram, 286er, 12 MhZ und so. Waren natürlich alles Schnäppchen.
💡 Link Tipps aus der Open Source Welt
OpenObserve – Modern Observability Platform
OpenObserve (O2) ist eine cloud-native Open-Source Observability-Plattform für Logs, Metrics, Traces, Analytics und Frontend-Monitoring. Das in Rust geschriebene Tool verspricht 140x niedrigere Storage-Kosten als Elasticsearch bei besserer Performance.
Features:
- All-in-One Platform: Logs, Metrics, Traces, RUM in einem einzigen Binary
- 140x Kostenersparnis: Durch Parquet-Format, Kompression und S3-native Architektur
- OpenTelemetry Support: Native OTLP-Ingestion für alle Telemetriedaten
- SQL & PromQL: Flexible Query-Languages ohne proprietäre Syntax
- Real User Monitoring: Performance-Tracking, Error-Logging und Session Replay
- Pipelines: Daten-Enrichment, Redaction und Stream Processing beim Ingest
- 19+ Chart-Typen: Umfangreiche Visualisierungsmöglichkeiten inkl. 3D
- Multi-Tenancy: Native Unterstützung mit kompletter Daten-Isolation
- Skalierbarkeit: Single Binary bis TB, HA-Mode bis PB (2 PB/Tag in Production)
Die Enterprise Edition bietet zusätzlich SSO, Advanced RBAC, Sensitive Data Redaction und Federated Search. Die Open-Source-Version unter AGPL ist feature-complete und production-ready.
OpenObserve ist SOC 2 Type II und ISO 27001 zertifiziert und läuft laut eigenen Angaben bei tausenden Deployments weltweit in Production.
Klingt irgendwie fast zu schön, um wahr zu sein – ich hatte es nicht gekannt, du?
So eine .ai TLD schreckt mich ja immer etwas ab, (openobserve.ai) aber sieht ja schon interessant aus. Ohne die letzte Newsletter Ausgabe hätte ich es nicht entdeckt, daher wäre ich interessiert, falls du es am Start hast oder kennst.
https://github.com/openobserve/openobserve
Octelium – Unified Zero Trust Secure Access Platform
Oder auch Gesundheit – „Unified Zero Trust Secure Access Platform“ klingt zumindest mal danach, als hab ich ein Bingo in einem Satz.
Jedenfalls ist Octelium eine Open-Source, self-hosted Zero-Trust-Plattform, die als modernes Remote-Access-VPN, ZTNA/BeyondCorp-System, API/AI-Gateway, PaaS-Plattform oder Homelab-Infrastruktur fungieren kann. Entwickelt von George Badawi als Ein-Mann-Projekt.
Features:
- Zero Trust Architecture: Identity-basierte L7-aware Proxies mit dynamischer Policy-as-Code (CEL/OPA)
- Dual Access Modes: Client-basiert über WireGuard/QUIC und clientless BeyondCorp-Access
- Secretless Access: Zugriff auf APIs, SSH, Databases ohne Credentials zu teilen
- Dynamic Routing: Context-aware Routing basierend auf Identity und Policies
- Container Deployment: PaaS-ähnliche Capabilities für containerisierte Apps
- MCP/A2A Support: Infrastruktur für Model Context Protocol und Agent2Agent Architekturen
- OpenTelemetry Native: Vollständiges Auditing und Visibility
- Kubernetes-basiert: Läuft auf Single-Node oder Multi-Node K8s Clustern
Lizenzierung: Client-Components unter Apache 2.0, Cluster-Components unter AGPLv3 (kommerzielle Lizenz verfügbar). Das Projekt ist aktuell in Public Beta (v1.0 mit Bugs) und nicht offen für externe Contributions.
Octelium positioniert sich als vielseitige Alternative zu Tailscale, Cloudflare Access, ngrok und klassischen VPNs.
https://github.com/octelium/octelium
❓ 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: