Willkommen zu allesnurgecloud.com – Ausgabe #154
Vermutlich bist du schon im Urlaub – bei mir ist es in einer Woche so weit – Ausgabe 155 bekommst du noch, dann ist hier 2 Wochen Pause für den Postfach angesagt.
Hast du zwischen dem 19 und 21. November schon was vor?
Falls nicht – schau doch mal in Nürnberg auf der Open Source Monitoring Conference 2024 vorbei. Ich halte dort einen Vortrag zum Thema „Customer Centric Monitoring“ und sammle schon Themen und Cases dafür.
Was verstehst du unter „Customer Centric Monitoring“?
Schicke mir doch gerne deine Erwartungshaltung zu – schreib mir auch gerne, falls wir uns in Nürnberg sehen.
Happy Bootstrapping Podcast
Im Podcast hatte ich diese Woche mal wieder einen E-Commerce Case, der nicht nur für die Bart-Träger unter euch interessant ist. Mit Martin Picard, dem Gründer von Störtebekker.com, habe ich darüber gesprochen, wie man das Barbershop-Feeling im eigenen Badezimmer schafft.
Störtebekker ist 7 Jahre alt und erwirtschaftet mit 11 Mitarbeitenden einen Umsatz von 8 Millionen €. Wir sprachen über Produktentwicklung, Sourcing aus China, Amazon FBA, virale TikTok Videos und Adventskalender.
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:
Data Lake Skalierung bei Notion
Der verlinkte Artikel ist zwar schon von Anfang Juli diesen Jahres, trotzdem einen Blick wert. Die „Alleskönner Workspace Plattform“ Notion teilt im Artikel die Learnings aus 3 Jahren Daten Infrastruktur Wachstum – eine Verzehnfachung der Daten mit einer Verdopplung alle 6-12 Monate ist nicht so einfach in den Griff zu bekommen, speziell wenn man parallel neue Features hinzufügt oder eine AI auf die Daten trainieren möchte.
Speicherte man 2021 noch „nur“ etwas mehr als 20 Milliarden „Block Rows“ in Postgres, so sind es aktuell über 200 Milliarden solcher Blocks. Anfangs versuchte man dem Problem mit Sharding in Postgres zu begegnen und erhöhte die physischen Instanzen in 2021 auf 32 Stück (mit jeweils 15 logischen Shards), gefolgt von einer weiteren Erhöhung auf 96 Instanzen (mit je 5 Shards). Insgesamt muss man also 480 logische DB Shards verwalten, sichern, migrieren – spannend, oder?
Im ursprünglichen Setup hat Notion dann über diverse Fivetran Instanzen Snowflake betankt. Über die Zeit war der Prozess dann nicht nur langsamer, sondern auch extrem teuer geworden. Auch die 480 Fivetran Instanzen zollten ihren Tribut – bei Updates, Migration und so weiter war dies ein ordentlicher Aufwand an Day-2 Operations für das gesamte Team.
Für die neue Data Lake Infrastruktur entschied man sich daher, für die Massendaten auf Standard S3 als Speicher zurückzugreifen – in AWS RDS, der verwendeten PostgreSQL DB bei Notion , gibt es einen einfachen Exporter für S3 zu Postgres. Mit Spark als Open Source Processing Engine konnte man eine flexible, zukunftssichere und performante Processing Engine für sämtliche Daten etablieren, die auch mit den Datenmengen von Notion keine Probleme hat.
Auch interessant – man entschied sich aus diversen Gründen, immer die rohen RAW Daten von PostgreSQL nach S3 zu schieben, und die Daten im Nachgang und nicht on-thy-fly zu verändern. Das minimierte Debugging und Day2 Operations Aufwände enorm, und man konnte im Fehlerfall den ganzen Prozess einfach nochmal abspulen.
Eine Kernkomponente im Notion Setup kannte ich noch gar nicht – der Apache Hudi Deltastreamer konsumiert Kafka Nachrichten und repliziert PostgreSQL Tabellen inkrementel nach S3. Nach anfänglichen Performance Herausforderungen konnte das Notion Team die Verzögerung der Daten auf einige wenige Minuten reduzieren – Chapeau!
Für Notion hat sich das Ganze mehr als gelohnt, man spart sich nicht nur einige große PostgreSQL Datenbanken ein (und spart Millionen beim Hosting – Hallo AWS), sondern hat weitere Kosten bei Snowflake reduziert und ist in Summe trotz ordentlichen Datenwachstums deutlich schneller mit dem Prozess als früher.
Building and scaling Notion’s data lake
Erfolge feiern als Remote Team
Cool, Marissa Goldberg scheint mit ihrem Newsletter „Remotely Interesting“ weiterzumachen. In der aktuellen Ausgabe geht es darum, wie man als verteiltes Remote Team in unterschiedlichen Zeitzonen Erfolge feiern kann. Natürlich kann man die Empfehlungen auch für Teams anwenden, die nur Remote und in der gleichen Zeitzone arbeiten.
Marissa empfiehlt, bereits am ersten Tag herauszufinden, welche Art der Wertschätzung ein Mitarbeitender haben möchte. Häufig machen Teamleads laut ihr den Fehler, die eigene Vorlieben auf andere zu übertragen. Manche freuen sich über anerkennende Worte, andere über kleine Gefallen und wieder andere Arbeitnehmer stehen eher auf materielle Dinge oder kleine Geschenke.
Bei wertschätzenden Worten ist auch zu unterscheiden, dass manche diese eher privat haben möchten und andere eher public – kompliziert, diese Menschen, oder?
Passend dazu empfiehlt Marissa 2 Public Channels im Chat (bsp. Slack) – einen für Shoutouts und einen für Wins. „Shoutouts“ – für Lob und Anerkennung von einzelnen für andere oder ganze Teams. Und „Wins“ für Erfolge von Teams oder ganzen Gruppen/Bereichen oder auch der ganzen Firma.
Bei monetären Geschenken ist Vorsicht geboten:
If their efforts just saved the company thousands and then they receive stickers in the mail, you can imagine how poorly that comes across
Schnitzel und Bier ist also nicht genug, wenn man nen ordentlichen Gewinn erzielt oder eine gravierende Einsparung erzielt.
Eine sehr coole Idee finde ich den „Adventure Bonus“ – man kann lokal Ausflüge mit der Familie als Dankeschön unternehmen, sei es Kletterpark, Hochseilgarten oder andere Outdoor-Aktivitäten und diese Erfahrungen dann teilen und andere motivieren.
Marissa schließt damit ab:
These efforts may feel like small things, but they end up being the difference makers in teams with great retention and morale.
Und das kann ich dann wiederum zu 100 % unterschreiben.
How to celebrate wins with a distributed team
Sponsored
Checkly sucht Engineers – Full Remote!
In der letzten Ausgabe hatte ich bereits über die 20 Millionen Finanzierungsrunde von Checkly berichtet.
Das Team von Checkly sucht nun folgende neue Kolleg:innen zur Unterstützung:
- Senior Backend Engineer (remote)
- Senior Frontend Engineer (remote)
- Senior Full Stack Engineer (remote)
- Staff Platform Engineer (remote)
Bei Checkly arbeitest du remote-first, flexibel und asynchron – Meetings werden so gut es geht vermieden. Mit der Kultur ist Checkly sehr transparent – viele Infos dazu findest du auf dieser Notion Page. Passend dazu ist das „Employee Handbook“ für alle verfügbar – inklusive Informationen zur Bezahlung der Mitarbeitenden.
Falls du Checkly nicht kennst – Checkly bietet eine synthetische Monitoring Lösung an, die eure APIs und Applikationen von der ganzen Welt aus überwacht. Das besondere? Checkly ist Code-first und bietet wirkliches „Monitoring as Code“ über einen eigenen Terraform Provider, eine Pulumi Integration und die hauseigene CLI an.
Hetzner Cloud nun auch Singapur
In der Hetzner Cloud kannst du nun Cloud Server auch in der Location Singapur betreiben. Bisher waren die Hetzner Cloud Services zum gleichen Preis in Deutschland (Nürnberg, Falkenstein), in Finnland (Helsinki) und in den USA (Hilsboro, Ashburn) verfügbar.
In Singapur gibt es zum Start erst einmal nur eingeschränkte IaaS Services – und zum ersten Mal unterscheiden sich die Preise vom bisherigen Angebot.
In Singapur gibt es erstmal nur Shared und Dedicated AMD Server zu XXX höheren Kosten – ein paar Beispiele:
- CPX11: 2 CPUs (Shared vCPU, AMD), 2 GB RAM und 40 GB NVMe SSD – 9,40 €/Monat (andere Locations: 5,18 €/Monat)
- CPX51: 16 CPUs (Shared vCPU, AMD), 32 GB RAM und 360 GB NVMe SSD – 92,11 €/Monat (andere Locations: 65, 33 €/Monat)
- CCX43: 16 CPUs (Dedicated CPU, AMD), 64 GB RAM und 360 GB NVMe SSD – 162,63 €/Monat (andere Locations: 114,82 €/Monat)
- CCX63: 48 CPUs (Dedicated CPU, AMD), 192 GB RAM und 960 GB NVMe SSD – 574,18 €/Monat (andere Locations: 343,30 €/Monat)
Wie man sieht, sind die Preise deutlich übe den normalen Hetzner Preisen angesiedelt – teilweise über 50 % sind die AMD CPUs in Singapur teurer, je nachdem, für welches Modell man sich interessiert.
Hetzner schreibt selbst zur Location:
Wir betreiben Hetzner Cloud-Produkte in Singapur auf Hetzner-eigenen Servern in Datacentern von Drittanbietern.
Datensicherheit hat bei uns oberste Priorität. Daher werden die Hetzner-eigenen Server in Singapur ausschließlich von uns genutzt.
Dass der asiatische Raum hier teurer ist, sollte bekannt sein – dennoch überrascht der Preis, da Hetzner beispielsweise in Finnland auch die gleichen Preise anbietet wie in Deutschland, obwohl die Stromkosten dort deutlich niedriger sind. Vermutlich tritt der Skalierungseffekt, wie man ihn in Deutschland in den eigenen RZs hat, einfach nicht so stark ein.
Hetzner Cloud jetzt auch in Singapur
SQLite ist 35 % schneller als das Dateisystem
SQLite ist eine File-basierte Datenbank, die zunehmend wieder populärer wird (Siehe auch den Open Source Tooltip Turso weiter unten).
In einem Performance-Test konnte das Team nun zeigen, dass Lese-Vorgänge in SQLite um bis zu 35 % schneller sind, als wenn du aus einem normalen File Blob liest. Natürlich kann es bei dir noch viel schneller, oder auch langsamer sein – je nachdem, welche Hardware verwendet wird.
Der Autor des Artikels versteht aber selbst nicht genau, warum SQLite schneller sein kann, als der Vergleich mit einem normalen Blob-File. Es wird vermutet, dass der Overhead von open() und close() eine ordentliche Wirkung auf die Performance habe – bei der Verwendung von SQLite wird dies nur einmal gemacht, bei einem normalen File-Zugriff für jedes einzelne File.
Den Performance-Gewinn gibt es nur beim Lesevorgang – der Schreibvorgang selbst ist mit SQLite dann 5- bis 15-mal langsamer als ein Lesevorgang. In einem Test unter Windows stellt sich heraus, dass das Schreiben bei per Default aktiviertem Virenscanner furchtbar langsam ist.
Alle Schlussfolgerungen der Tests findest du unter „General Findings“ im verlinkten Artikel.
Na, hast du SQLite produktiv laufen?
35% Faster Than The Filesystem
Volltext Suche in Postgres mit ParadeDB
In den vergangenen Jahren ist vor allem Elasticsearch die erste Anlaufstelle für eine schnelle Volltextsuche gewesen. Über Meilisearch als leichtgewichtige Alternative hatte ich schon paar mal berichtet, über typesense auch – ParadeDB kannte ich bisher noch nicht.
ParadeDB ist eine in PostgreSQL integrierbare Volltextsuche, die die Standard Postgres Suche um für viele fehlende Features erweitert. Beispielsweise fehlen in der Postgres FTS ein paar Features, wie etwa BM25 Scoring, Facettierung oder auch das individuelle Tuning der Ergebnisse über Relevanz-Einstellungen.
ParadeDB bietet mit der pg_search Extension ein auf Lucene basierte Suche direkt in PostgreSQL integriert. Vor allem bei großen Datensets soll pg_search seine Stärken ausspielen und verspricht eine bis zu 20-mal schnellere Performance bei einem Vergleich der nativen Postgres Suche mit pg_search und 1 Million Datensätze (zum Vergleich).
Du bekommst ParadeDB direkt bei GitHub – ParadeDB ist aktuell in private Beta und in Version 0.9 verfügbar.
Der große Vorteil gegenüber anderen Lösungen ist natürlich, dass du keine zusätzliche Infrastruktur, Server für die Suche oder Expertise für den Betrieb benötigst. Wenn man sowieso schon auf PostgreSQL unterwegs ist, gerne mal testen.
Full Text Search over Postgres: Elasticsearch vs. Alternatives
Supermarkt Preis-Tracking mit Playwright
Passend zum heutigen Episoden Sponsor hab ich hier eine interessante Story. Ein Entwickler aus Griechenland beschreibt, wie er im Jahr 2022 eine Seite zum Tracking von Supermarkt Preisen (pricewatcer.gr) mit Hilfe von Playwright gebaut hat.
Falls du Playwright nicht kennst, das ist eine OpenSource API zur Fernsteuerung und Simulation von Browser Aktivitäten. Playwright kommt aus dem Hause Microsoft und unterstützt die gängigen Rendering Engines Webkit, Firefox und natürlich Chromium.
Playwright kann man nicht nur für das End2End Testing von Kundenaktivitäten nutzen, sondern auch für das Scraping von Websites.
Nach ersten Versuchen mit einem alten Laptop entschied er sich für eine VM bei Hetzner, die um Faktor 7 günstiger war als bei AWS. Witzigerweise kommt der Laptop nun doch als Steuerung mittels Concourse CI zum Einsatz.
Nach diversen Optimierungen waren noch 2 Themen übrig – die „lange“ Scraping Duration und zu viele übertragene Daten. Da der Server nur für die Dauer des Scrapings läuft und dann gelöscht wird – erzeugt er nur in der Laufzeit kosten. Daher konnte in Summe eine schnellere, aber in Summe dann doch günstigere Version mit einem größeren Server realisiert werden.
Und um nur die Preise zu scrapen, kann man in Playwright auch einfach das Laden der Bilder abbrechen – spart Geld und Zeit – Geld dann auf beiden Seiten, da der Bilder-Traffic ausbleibt.
Ach und die Supermarkt Websites haben ein Akamai CDN zur Protection, das umgeht er einfach, in dem er über Tailscale seine eigene, lokale IP des Internet Providers für das Scraping nutzt.
Tracking supermarket prices with playwright
Reliability Investment Playbook
Im Artikel „My Availability Investment Playbook“ geht es darum, wie man ein Team, Manager oder eine Firma davon überzeugt, nachhaltig in Availability bzw. Reliability zu investieren. Das ist nämlich gar nicht so einfach, wie es sich anhört. Ein neues Feature zu bauen kann viel einfacher sein, da man den Mehrwert direkt sieht.
Autor Ross Brodbeck schlägt folgende Roadmap vor:
- Gather concrete metrics on the problem : Um eine Investition zu rechtfertigen, sind konkrete Zahlen notwendig, da sonst die Diskussion in subjektive Meinungen abdriftet. Um Überzeugungskraft zu erlangen, sollte man den Impact auf Kunden messen, insbesondere bei großen Enterprise Accounts, die Anzahl der Support-Tickets betrachten und analysieren, wie sich das Problem auf die Reaktionsfähigkeit bei Incidents auswirkt.
- Measure the benefits of fixing the problem – Welchen Nutzen bringt die Behebung des Problems? Dazu gehört die Frage, wie sich dadurch das Kundenerlebnis verbessert und wie viel Zeit die Entwicklerteams einsparen könnten. Auch wenn es keine direkten Auswirkungen auf die Kunden gibt, kann das Problem erhebliche Auswirkungen auf das Entwicklerteam haben, beispielsweise durch häufige Alarmierungen oder lange Reaktionszeiten bei Vorfällen.
- Propose a solution with alternatives – Nachdem du Daten gesammelt und die Vorteile einer Lösung ermittelt hast, ist es wichtig, verschiedene Lösungen zu analysieren, Alternativen zu prüfen und sicherzustellen, dass du nicht voreilig eine bestimmte Lösung favorisierst, da dies oft zu einseitigem Denken führen kann.
- Present a conclusion supported by data – Erarbeite einen Vorschlag auf Basis deiner Daten und bereite das überzeugend und einfach zu konsumieren auf.
- Review your solution with a trusted group – Nimm dir ein bis zwei Tage Zeit, um kritisches Feedback von vertrauenswürdigen Personen einzuholen, da ein unklarer oder unzureichend belegter Vorschlag eine Idee für Monate oder sogar Jahre scheitern lassen kann.
- Take your proposal on a road show – Oft reicht es nicht aus, deine Idee nur deinem direkten Vorgesetzten oder deiner Abteilung vorzustellen, da viele Verfügbarkeitsprojekte mehrere Teams erfordern. In solchen Fällen solltest du deine Idee an möglichst vielen Stellen verbreiten. Das kann durch lokale Präsentationen für interessierte Teams, Firmen-Lichtblitzvorträge oder Planungsmeetings geschehen, oder indem du den Vorschlag einflussreichen Personen schickst und 1:1-Gespräche mit ihnen planst.
Dieser Ansatz hat sich für Autor Bob in den letzten Jahren bewährt, und er empfiehlt daher, etwas Ähnliches zu übernehmen, besonders für erfahrene Engineers.
Meiner Erfahrung nach ist der Aufbau einer Lobby für das Thema Reliability gar nicht so einfach und häufig im Management nur präsent, wenn es zu gravierenden Ausfällen kommt – präventiv wäre das aber schöner und für alle weniger Streß, erfordert aber mindestens die oben beschriebene Vorgehensweise in einen kontinuierlichen Prozess.
My Availability Investment Playbook
Skaliarungs Challenge mit 1 Million Checkboxen
Kennst du das Projekt onemillioncheckboxes.com?
Das war eigentlich ein Spaß Projekt eines Entwicklers, das er Ende Juni mal kurz zusammengeschraubt hatte.
Das besondere daran?
Checkst du eine der der Boxen, so ist diese bei mir auch gecheckt – und bei allen anderen auch, die die Page nutzen.
Mittlerweile wurde das Ziel erreicht und die Page ist nur noch „für dich“ alleine spielbar.
Im Juni/Juli rumpelte es ordentlich an Traffic, denn nicht nur Twitter und HackerNews spielten etwas verrückt, sondern das Projekt wurde auch von der Washington Post und anderen Medien aufgegriffen.
Im verlinkten Artikel findest du die Story des Entwicklers und was er alles an Skalierungsmaßnahmen ergriffen hat, damit die Seite am laufen blieb. Teilweise lieferte die Page 250 MB/s aus (also nur mit den Checkboxen und dem Traffic), wurde mehrfach mit DDoS Attacken angegriffen und hatte mehrere 10.000 Tausend Besucher pro Stunde, die im Schnitt 3-4000 Checkboxen die Stunde gecheckt haben.
Klingt alles etwas bescheuert – bei solchen Projekten lernt man aber sehr viel über die gesamte Traffic-Chain einer Web-Applikation und das Zusammenspiel der verschiedenen Komponenten.
SCALING ONE MILLION CHECKBOXES TO 650,000,000 CHECKS
.internal TLD nun ICANN approved
Ich dachte ja, das Thema sei im Februar 2024 (Ausgabe 135) schon durch gewesen, aber nun hat die ICANN am 29.7.2024 in ihrer Sitzung ..internal nun final approved:
Resolved (2024.07.29.06), the Board reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications. The Board recommends that efforts be undertaken to raise awareness of its reservation for this purpose through the organization’s technical outreach.
Somit ist das Thema nun also endgültig bestätigt, nach 4 Jahren Empfehlungen, Beratungen und verschiedenen Alternativen wie .private geprüft und verworfen wurden. Du kannst nun also endgültig sicher sein, dass .INTERNAL eben für interne Zwecke genutzt werden kann – Chapeau!
Full Text Search over Postgres: Elasticsearch vs. Alternatives
Schmunzelecke
Der „Force Push Gin“ ist ein Gin Schäppchen ($ 95) aus dem Hause „Friday Deployment Spirits“ und den gibt es wohl tatsächlich:
Force Push is distilled from scratch grain in Denver, Colorado and has notes of citrus, coriander and a touch of mountain juniper
💡 Link Tipps aus der Open Source Welt
postgresqltuner – Tuning Advisor für PostgreSQL
Das Perl Script postgresqltuner ist ein Open Source Tuning Advisor für PostgreSQL Datenbanken. Es arbeitet ähnlich wie pgbadger, schaut sich aber neben den Logs auch die Config, den Memory Verbrauch und andere wichtigen Metriken an. Es gibt etwa Hinweise, wenn du vm.overcommit_memory gesetzt hast, oder wenn du in der DB mehr Speicher konfiguriert hast, als das System überhaupt zur Verfügung hat.
Einen Beispiel Output siehst du beispielsweise hier. Für mich ähnlicher Fall wie bei myqsltuner: ein Muss auf jedem DB-System.
https://github.com/jfcoz/postgresqltuner
E-Mail Server Maddy
Maddy ist ein E-Mail Server, der sowohl als MTA (Mail Transfer Agent) und als MX für eingehende Mails genutzt werden kann. Nachrichten speichert er per IMAP ab – der Mail Versand kann mit den üblichen Mechanismen abgesichert und authentifiziert werden (DKIM, SPF, DMARC, DANE, MTA-STS). Alle Infos zu Maddy findest du auf der Maddy Homepage.
Maddy kannte ich bis heute noch nicht – habe ich im Healthchecks.io Blog hier entdeckt und Healtchecks Founder Pēteris erklärt im Artikel, warum er sich für Maddy entschieden hat – er hatte diverse SaaS Tools wie SE und Brevo, aber auch andere self-hosted Lösungen wie Postal, Haraka und ZoneMTA geteset (alle hatte ich hier schon mal erwähnt).
❓ 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: