Willkommen zu allesnurgecloud.com – Ausgabe #166
Besuch und Vortrag auf der OSMC in Nürnberg
Mittwoch und Donnerstag war ich endlich mal wieder auf der tollen Open Source Monitoring Conference in Nürnberg. Falls du die Konferenz nicht kennst, auf der OSMC gibt es viele Talks zu verschiedenen Themen rund um Monitoring, Observability, Logging und Metriken. Es werden diverse Tools vorgestellt inklusive vieler Beispiele aus der Praxis. Abgerundet wird die Konferenz von einem tollen Abend Event am ersten Tag und der Möglichkeit, sich mit vielen Menschen von diversen Firmen zu unterhalten. Ich mag die Konferenz sehr, da man einen guten Überblick über eine Vielzahl von Themen bekommt und man sich eben nicht auf ein Projekt konzentriert.
Ich war nun ein paar Jahre nicht mehr da und durfte einen kleinen Vortrag zum Thema „Customer Centric Monitoring“ vorstellen – ansonsten hab ich viele inspirierende Talks gesehen. Zusammenfassung kommt, sobald die Talks auf YouTube sind. Bis dahin findest du eine Zusammenfassung des Events bei Claudio Kuenzler im Blog oder bei Netways, dem Veranstalter der OSMC (Day 1, Day 2, Day 3).
BlueSky musste die letzten Wochen fleissig Server nachschieben – und irgendwie finde ich das cool – zum Anfang waren zu wenig Techies von Twitter rübergekommen, nun wechseln aber auch größere Accounts. Bluesky läuft noch immer On-Premise, die Migration von AWS hatte ich im April diesen Jahres vorgestellt – mich findest du übrigens hier.
Happy Bootstrapping Podcast
Im Podcast hab ich in dieser Woche den Flo Sailer von KnowledgeHero interviewed – direkt zur Folge 97. KnowledgeHero ist ein EdTech SaaS und bietet Tools zum Auswendiglernen von Abkürzungen. Größter Kunde ist aktuell Lidl und hier werden die PLU Codes gelernt – die „Price lookup-code), das sind die Nummern für Obst & Gemüse ohne Barcode. Damit es schnell geht, braucht man die im Kopf.
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:
Cloud-Exit mit 25 Millionen Usern bei SofaScore
In einem spannenden Vortrag auf der OSMC gab SofaScore CTO Josep Stuhli Einblicke in die Infrastruktur der beliebten Sport-Plattform. Mit über 25 Millionen monatlich aktiven Nutzern ist SofaScore eine der größten Anlaufstellen für Live-Sportdaten und Analysen. Die Daten und Tools der Plattform werden auch von deutschen Anbietern über APIs und Einblendungen genutzt.
Interessant ist bei SofaScore aus Infra-Sicht vor allem der komplette Verzicht auf klassische Cloud-Provider zugunsten von Dedicated Servern.
Die wichtigsten Punkte im Überblick:
- Die Infrastruktur-Kosten betragen nur 0,6% des Umsatzes – bei einem Cloud-Setup wären es geschätzte 5-10%
- Durch Varnish als Caching-Layer und Fastly als CDN erreicht man eine Cache-Hit-Rate von 99,4%
- Das Monitoring-Stack basiert auf Telegraf, InfluxDB und Grafana
- Die Skalierung erfolgt automatisiert über virtuelle Maschinen zur Lastverteilung
- Auch bei Peak-Traffic-Events läuft die Plattform stabil und performant
Der Erfolg gibt dem Ansatz recht: SofaScore kann durch die Kombination aus Dedicated Servern und ausgeklügeltem Caching nicht nur enorme Kosten sparen, sondern auch eine hohe Performance garantieren. SofaScore hat auf AWS angefangen und dann schnell festgestellt, dass die Kosten bei steigender Nutzerzahl explodieren werden.
Im Bild im Artikel siehst du in blauer Farbe die AWS Kosten, Grün ist die Anzahl der User, Gelb ist CloudFlare und Rot ist der Housing Provider Serverloft. Ganz linkst siehst du die hohen Kosten bei AWS bei noch kleiner User-Anzahl. Ganz rechts siehst du dann eine Vervielfachung der User bei gleichbleibenden Infrastruktur-Kosten.
Das Auto-Scaling funktioniert übrigens ganz einfach über eine Grafana Metrik, die einen Webhook triggert, welcher dann neue VMs provisioniert und diese in die Loadbalancer aufnimmt. Die Maschinen werden dann nach 4 Stunden automatisch gelöscht, da die Fußball Spiele in der Reel vorbei sind. So einfach und pragmatisch kann man ein auto-scaling bauen und das finde ich dann schon wieder sehr cool.
Ein spannendes Beispiel dafür, dass die Public Cloud nicht immer alternativlos ist – vor allem wenn man seine Workloads gut kennt und entsprechend optimieren kann. An den Varnish habe ich auch noch tolle Erinnerungen – da haben wir mit 2 VMs ganz schön Traffic gecached.
Josip hat vor kurzem über den Case im „All Things ops“ Podcast berichtet und im verlinkten Artikel findest du eine Zusammenfassung des Vortrages auf der OSMC im Blog von Claudio Kuenzler.
Jedenfalls zahlen sich die technischen Entscheidungen von SofaScore sich auch beim Team-Setup aus: Die eingesparten Cloud-Kosten ermöglichen höhere Investitionen in die Produktentwicklung und mittlerweile arbeiten über 100 Entwickler an der Plattform.
Reviewing the OSMC Monitoring Conference 2024
140x günstiger als Datadog: On-Premise Monitoring mit Coroot
Ein spannender Artikel im Blog von Coroot zeigt die enormen Kostenunterschiede zwischen Cloud-basierten und On-Premise Monitoring Lösungen auf. Für eine kleine Demo-Umgebung (5 EC2 nodes, 15 Services, 5 Datenbanken) mit voller Observability wurden folgende monatliche Kosten ermittelt:
Monitoring Kosten im Vergleich:
- Datadog: $22.303 (140x teurer als On-Premise)
- Grafana Cloud: $1.855 (11x teurer)
- Coroot Enterprise: $162
- Coroot Community: $142
Die Datenmenge ist dabei durchaus beachtlich:
- 15.000 Metriken (alle 15 Sekunden)
- 1,6 Mrd Log Events (400 GB)
- 7 Mrd Traces (2 TB)
- 500 GB Profile Daten
Der gewaltige Kostenunterschied kommt vor allem durch drei Faktoren zustande:
- Hohe Speicherkosten bei Cloud Anbietern
- Egress Traffic Kosten für die Datenübertragung
- Pay-per-metric Preismodelle
Besonders interessant finde ich, dass die reine AWS Infrastruktur für die Anwendung nur $680 pro Monat kostet – das Monitoring mit Datadog wäre damit über 30x teurer als die eigentliche Anwendung. Kein Wunder, dass viele Teams nur einen Bruchteil ihrer Services monitoren können. Gut, das Beispiel ist vielleicht auch auf einen hohen Kostenunterschied getrimmt.
Der Fall zeigt eindrucksvoll, dass sich ein Blick auf Self-Hosted Alternativen durchaus lohnen kann und man mit einfachen Schritten die Observability des gesamten User-Flows durch die eigene Umgebung deutlich besser verstehen und debuggen kann. Coroot betreibt ein Demo-System – da wird dir sicher schnell klar, welche Möglichkeiten dahinter stecken.
Coroot ist übrigens Open-Source, aber das hast du sicher ja schon gedacht. Auf der OSMC in dieser Woche gab es einen tollen Vortrag zu Coroot von Kris Buytaert – ich werde es mir nun auf jeden Fall genauer anschauen. Sobald das OSMC Video Online ist, verlinke ich es gerne.
140x günstiger als Datadog: On-Premise Monitoring mit Coroot
Sponsored
Kundenzentrisches Monitoring mit Checkly
Checkly ist eine code-first Monitoring-Lösung, die ein kundenzentrisches Monitoring ermöglicht.
Kundenzentrisches Monitoring?
Ja, „Customer Centric Monitoring“ – wie sieht eigentlich der Kunde meine Applikation?
Funktioniert der Login, ist die Suche nach einem Produkt schnell und kann man überhaupt ein Produkt in meinem Shop kaufen?
Das fängt schon beim HTTP Handshake und dem TLS-Zertifikat an und geht durch die ganze Traffic-Kette bis zum Kaufprozess inkl. aller externen APIs, die in deiner Anwendung verwendet werden.
Checkly verwendet hierfür die Open-Source-Browser-Automatisierung Playwright und simuliert damit einen Browser aus über 20 Standorten aus der Welt. Du bekommst damit neben der rein funktionalen Überwachung auch noch einen Einblick in die Performance und Uptime.
Dabei ist Checkly Code-first und bietet wirkliches „Monitoring as Code“ über einen eigenen Terraform Provider, eine Pulumi Integration und die hauseigene CLI an.
Als neues Feature bietet Checkly nun mit Checkly Traces eine nahtlose Integration in vorhandene „Open Telemetry Tracing“ Lösungen an – in einem Webinar vom Ende September kannst du dir hier auf YouTube anschauen, wie das Ganze funktioniert.
Starte jetzt mit dem kostenlosen Checkly Hobby Plan: mit dem Code „Andreas“ bekommst du 15% Rabatt auf die Paid Pläne!
Best Practices für asynchrone Kommunikation in verteilten Teams
Marissa Goldberg vom Remotely Interesting Newsletter hat wieder zugeschlagen. Thema diesmal: Best Practices für Remote Teams mit verschiedenen Zeitzonen.
Die erste Intuition, einfach alle Nachrichten zeitversetzt zu senden, ist dabei oft kontraproduktiv – mist, das mach ich selber eigentlich ganz gerne!
Ihre wichtigsten Learnings für erfolgreiche asynchrone Kommunikation:
- Kein Message Scheduling – erzeugt mehr mentale Last und verlangsamt die Kommunikation
- Klare Response-Erwartungen definieren (z.B. Antwort innerhalb von 24h während Arbeitszeit)
- Nachrichten vollständig formulieren – nicht nur „Hi“ und auf Antwort warten – siehe auch nohello.net
- Wichtigstes zuerst – bei langen Nachrichten mit Summary und konkreter Frage starten
- Persönliche FAQ pflegen für wiederkehrende Themen
Besonders wichtig finde ich den Hinweis auf die Response Policy. Ein einfaches „Antworte innerhalb von 24h während deiner Arbeitszeit“ schafft klare Erwartungen und verhindert Stress durch gefühlten 24/7 Bereitschaftsdruck. Streß haben wir ja schon eh genug.
Was sind deine Erfahrungen mit asynchroner Kommunikation? Welche Praktiken haben sich bei dir bewährt?
Communication Best Practices for Global Teams
Sentry spendet $750.000 an Open Source Maintainer
Sentry hat mal wieder geliefert und $750.000 an Open Souce Maintainer ausgeschüttet. Das ist wieder 50 % mehr als im letzten Jahr, da waren es noch $500.000 Dollar. Man spendet somit $5.813 pro Engineer – bei Sentry arbeiten 129 Engineers.
Man verteilt die Ausschüttungen über viele Projekte, einige davon nutzt man logischerweise selbst in der eigenen Software:
- Django: $30.000
- OSI: $30.000
- Outreachy: $25.000
- Python: $16.500
- OpenJS: $15.000
- Rust: $15.000
und so weiter – in Summe spendet man $218.500 direkt an 29 verschiedene Projekte.
Über die Initiative thanks.dev schüttet man sogar $381.5000 an eine Vielzahl von Projekten aus – über 500 in Summe, die hier öffentlich einsehbar sind. Über GitHub Sponsors schüttet man weitere $75.000 aus und über das Open Source Collective nochmals $75.000.
Auf das neue Projekt von Sentry, Open Source Plegde, hatte ich in Ausgabe 158 schon mal hingewiesen. Hier versucht Sentry die Sammlung und Verteilung von Spenden an die Open Source Community besser zu strukturieren. Hier geht es darum, dass man pro Entwickler $2.000 bezahlt und diese Spenden dann verteilt werden – darüber sind nun stand heute knapp 2 Millionen Dollar an Open Source Projekte ausbezahlt worden.
Mittlerweile sind auch viele kleine Spender dabei – beispielsweise hab ich in der Liste das PHP APM Tideways aus Deutschland entdeckt, welches für 4 Entwickler jeweils $6.046 spendet, wenn ich das richtig verstanden habe – Chapeau!
We Just Gave $750,000 to Open Source Maintainers
AWS Amplify Guide führt zu 1.100$ unerwarteten Kosten
Eine spannende Cloud Horror Story macht aktuell die Runde – ein Entwickler folgte dem offiziellen AWS Amplify OpenSearch Guide und bekam eine Rechnung über 1.100$ präsentiert. Was war passiert?
Die wichtigsten Learnings im Überblick:
- Der Guide nutzt standardmäßig r5.large.search Instanzen (186$/h) statt günstigerer t3.small.search (36$/h)
- Das Beenden der Amplify Sandbox via CTRL-C löscht nicht alle Ressourcen
- Jeder neue Start via
npx ampx sandboxerstellt eine neue OpenSearch Domain - Selbst
npx ampx sandbox deletelöscht die Original-Instanz nicht - AWS hat den Guide erst nach 3 Monaten und der Veröffentlichung des Artikels aktualisiert
AWS hat die unerwarteten Kosten zwar als „one time courtesy“ erstattet und den Entwickler gebeten, AWS Budgets mit Alarmen einzurichten. Das eigentliche Problem mit multiplen OpenSearch Instanzen besteht aber weiterhin.
Der Fall zeigt wieder einmal, wie wichtig es ist, die Cloud Ressourcen und Kosten permanent im Blick zu haben. Selbst wenn man offiziellen Guides folgt, sollte man:
- Die Default-Instanztypen prüfen und anpassen
- Budget Alerts einrichten
- Regelmäßig das AWS Console nach „vergessenen“ Ressourcen durchsuchen
- Bei Sandbox/Preview Umgebungen besonders auf Clean-Up achten
Die Geschichte erinnert mich an den AWS S3 Fall bei prerenderer.io, wo die Traffic-Kosten für Überraschungen sorgten. Cloud ist eben nicht immer „pay as you go“, sondern manchmal auch „pay as you forgot“. Der Guide wurde inzwischen angepasst.
Wie sind deine Erfahrungen mit unerwarteten Cloud Kosten? Welche Maßnahmen hast du implementiert?
I Followed the Official AWS Amplify Guide and was Charged $1,100
Cloudflare migriert Milliarden DNS Einträge im laufenden Betrieb
Eine spannende Story zur Migration der Cloudflare DNS Datenbank wurde diese Woche veröffentlicht. Als einer der größten DNS Provider (14,5% aller Websites nutzen Cloudflare DNS) war dies keine kleine Aufgabe – die größte einzelne Zone enthält dabei 4 Millionen DNS Einträge.
Die wichtigsten Zahlen im Überblick:
- 1,7 Milliarden aktive DNS Einträge (1,5 TB Daten)
- 4,3 Milliarden archivierte Einträge
- 3-5 Millionen INSERT/DELETE Operations pro Tag
- 1 Million UPDATE Operations pro Tag
- Migration mit nur 2 Sekunden Downtime
- DNS nahm 40% der Storage Kapazität in der alten Datenbank ein
Der Grund für die Migration? Die zentrale Postgres Datenbank (cfdb) war zunehmend überlastet und andere Services litten unter Performance Problemen. Die DNS Daten wurden daher in eine eigene Datenbank (dnsdb) ausgelagert.
Besonders spannend finde ich den technischen Ansatz:
- Change Data Capture System für Live-Synchronisation
- Batch-weiser Transfer mit Validierung
- Request Locking System für nahtlosen Übergang
- Foreign Tables als Fallback falls etwas schief geht
Das Ergebnis kann sich sehen lassen – die CPU Auslastung liegt nun unter 10% (vorher deutlich höher) und die API Request Rate hat sich mehr als verdoppelt. Die Latenzzeiten sind ebenfalls gesunken, vor allem in Lastspitzen.
Migrating billions of records: moving our active DNS database while it’s in use
WinAmp Open Source Release endet im Desaster
In der letzten Woche gab es turbulente Nachrichten um den legendären Media Player WinAmp. Die aktuelle Eigentümerin Llama Group hat das komplette GitHub Repository nach nur einem Monat wieder gelöscht – und das aus gutem Grund.
Die wichtigsten Ereignisse im Überblick:
- Im September wurde der Source Code wie angekündigt veröffentlicht
- Die initiale „Winamp Collaborative License“ (WCL) verbot Forking – ein Verstoß gegen GitHub ToS
- Die überarbeitete WCL 1.0.1 erlaubte Forking, aber keine Distribution von Änderungen
- Im Code fanden sich GPL-2 Komponenten, die die restriktive WCL obsolet machen
- Zusätzlich enthielt das Repo nicht-lizenzierte Microsoft und Intel Codecs
- Auch der Shoutcast DNAS Server Code war enthalten – obwohl dieser 2022 an Azerion verkauft wurde
Besonders pikant: Die ursprünglichen WinAmp Entwickler distanzierten sich von der Aktion. Justin Frankel, WinAmp Co-Developer, kommentierte die Lizenz mit „The terms are completely absurd in the way they are written“.
Das Ganze zeigt exemplarisch die Herausforderungen bei der Öffnung von Legacy Code. Nach 20+ Jahren Entwicklung und mehreren Eigentümerwechseln ist es extrem aufwendig, die Rechte aller Code-Komponenten zu klären. Wenn der wirtschaftliche Wert gleichzeitig gegen Null geht, fehlt oft der Anreiz für eine saubere Aufarbeitung.
Tja, und auch wenn das Repository nun gelöscht ist – dank tausender Forks ist der Code natürlich weiter verfügbar. Wie sagte schon Oscar Wilde: „There’s no such thing as bad publicity“. In dem Sinne hat die Aktion zumindest für frisches Interesse an dem 90er Jahre Player gesorgt.
Fun Fact am Rande: Es gibt mittlerweile auch einen WinAmp Web Player und mobile Apps. Nicht schlecht für einen Player, der primär mit Napster und MP3s assoziiert wird
Opening up the WinAmp source to all goes badly as owners delete entire repo
Alert Müdigkeit verhindern (Alert Fatigue)
In einem aktuellen Artikel zeigt Checkly, wie man dem Problem der „Alert Fatigue“ mit besserem Synthetic Monitoring begegnen kann. Eine NIH Studie bestätigt: Nicht die Arbeitslast, sondern die pure Anzahl und Wiederholung von Alerts führt zum Abstumpfen der Teams.
Die wichtigsten Best Practices im Überblick:
- Keine hart-codierten Wartezeiten verwenden (stattdessen automatische Waits in Playwright)
- Fokus auf kritische User Flows statt technischer Tests
- Smarte Retry-Strategien implementieren (Fixed, Linear oder Exponential Backoff)
- Test Steps klar labeln für bessere Nachvollziehbarkeit
- Visuelle Tools für schnellere Interpretation nutzen
- Monitoring as Code für bessere Wartbarkeit
- Monitoring Frequenz und Alert Schwellenwerte am SLA ausrichten
Der Artikel zeigt: Jeder unnötige Alert erhöht das Risiko, dass wichtige Meldungen übersehen werden. Mit den genannten Best Practices und Tools wie Playwright kann man die Alert-Last deutlich reduzieren. Visuelle Regression Tests helfen zusätzlich, schnell zwischen echten Problemen und harmlosen UI Changes zu unterscheiden.
Viele der Themen decken sich mit einem Artikel von DataDog zum gleichen Thema, den ich in einer älteren Ausgabe schon mal vorgestellt hatte.
How to Fight Alert Fatigue with Synthetic Monitoring: 7 Best Practices
Let’s Encrypt wird 10 Jahre alt
Wie schnell doch die Zeit vergeht – Let’s Encrypt ist in dieser Woche schon 10 Jahre alt geworden.
Aus vielen Infrastrukturen ist es nicht mehr wegzudenken – kaum vorzustellen, wie das Internet heute ohne Let’s Encrypt aussehen würde. Der verlinkte Artikel ist übrigens das Announcement vom 18. November 2014 – falls du dich wunders, warum ich sol einen alten Artikel verlinkt habe – das war pure Absicht.
Happy Birthday, Let’s Encrypt!
Let’s Encrypt: Delivering SSL/TLS Everywhere
Schmunzelecke
Das Haus deiner Träume steht vielleicht in Austin, Texas und gehört Kenton Varda und Jade Wang – das lanparty.house.
Man kann dorthin zum Spielen kommen, wenn man die beiden kennt – das geht am schnellsten, in dem man bei Cloudflare arbeitet.
Im Haus gibt es 22 Gaming PCs, die alle miteinander verkabelt sind. Die beiden erklären auch, woher die Kohle für Haus und Equipment kommt.
Ach neben dem ganzen Geek Zeug gibt es auch überall Katzenklappen und die Aussicht ist auch nicht verkehrt.
💡 Link Tipps aus der Open Source Welt
Spliit- Open Source Splitwise Alternative
Spliit ist eine Open-Source Alternative zum beliebten Splitwise. Man kann mit der App Einkäufe mit Freunden und Familien tracken und aufteilen.
Wir nutzen sowas eigentlich immer, wenn wir mit Freunden im Urlaub sind und jeder mal hier und da etwas bezahlt.
Spliit ist komplett Open Source und aktuell in der SaaS Variante kostenlos nutzbar. Entwickler Sebastien Castiel gibt im Blog immer wieder Updates über neue Features, wie beispielsweise hier die AI Erkennung von Belegen oder eine Übersicht über die aktuelle Spenden und Kostenstruktur des Open Source Projekts.
Spliit ist in TypeScript geschrieben und contributen kann man via GitHub.
https://github.com/spliit-app/spliit
YellowLabTools – Open Source Web Performance Testing
YellowLabTools ist eine Open Source Web Performance Suite, die dir einen Score deiner Website Performance und die schlimmsten Schnitzer übersichtlich darstellt. Für die Website von allesnurgecloud.com sieht das ganz ok aus, würde ich sagen.
YellowLabTools kannst du über die Website online nutzen, als Docker image selber betreiben, über die CLI in dein CI/CD integrieren und es gibt auch noch ein NodeJS Package dafür. Ausreden für langsame Websites sollte es nun wirklich nicht mehr geben 🙂
https://github.com/YellowLabTools/YellowLabTools
❓ 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: