Willkommen zu allesnurgecloud.com – Ausgabe #163

Na, haben sich all deine Uhren und Wecker automatisch umgestellt? Am Backofen muss bei uns noch der „Manuel“ ran, sonst hat es gepasst.
Ansonsten war ich diese Woche auf 2 Konferenzen mit vielen tollen Inspirationen und Gesprächen – sowas ist anstrengend, aber super, um aus der Komfortzone herauszukommen.
Auf der Heilbronn Slush’d durfte ich einen kleinen Workshop zum Thema „Boostrapping“ beisteuern – und dann kurzfristig sogar noch einen „Live-Podcast“ aufnehmen (Infos und Details bei LinkedIn).

Happy Bootstrapping Podcast

Ebenfalls inspirierend ist die Story von Celina Goette zur Gründungsstory von JuniorJob.de, einer Job Plattform für Ausbildung, Studium oder Schülerpraktikum. Celina und Bersa, die beiden Gründerinnen, sind selbst noch sehr jung und waren bei der Suche nach einem solchen Job damals nicht mit dem vorhandenen Angebot zufrieden und haben dann selbst in dem Bereich gegründet – cool. Alle Links und die Podcast Folge selbst findest du hier auf der Website zum Podcast (Folge 93).

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:

Uber aktualisiert 2000 MySQL Cluster auf MySQL 8.0

Uber ist bekanntlich ein Heavy User von MySQL – bisher in Version 5.7. Seit 2023 arbeitete man am Upgrade auf 8.0.
Die beeindruckende Infrastruktur von Uber in Zahlen:

• 2.100 MySQL Cluster in 19 Zonen und 3 Regionen
• über 16.000 Nodes in den Clustern
• „Multiple Petabytes of Data“
• 3 Millionen Queries pro Sekunde

Uber ist ebenfalls Heavy User der Replikation von MySQL – für die Migration war entscheidend, dass zwar ein MySQL 5.7 Primary an eine MySQL 8.0 Replika angeschlossen werden kann, umgekehrt funktioniert das aber nicht. D.h. ein MySQL 8 Primary kann nicht mit einer 5.7 Replika kommunizieren.

Beim Upgrade-Pfad hat man sich für einen „side-by-side“ Upgrade entschieden – d.h. man hat nicht in-place auf 8.0 aktualisiert, sondern parallel Nodes mit 8.0 bereitgestellt, diese konfiguriert und in den Replika Verbund aufgenommen, und dann final den Primary auf einen 8.0 Node geswitched. Das ist natürlich mehr Aufwand beim Upgrade, bietet aber eine kürzere Downtime sowie zusätzliche Sicherheit, da die 5.7 Nodes als Fallback noch bis zur Dekommissionierung bereitstehen.

Vorab hatte man sich noch eine Rollback-Strategie überlegt und diese auch mit den Stakeholdern abgestimmt. Einige Schwierigkeiten fand man schnell heraus, oder waren vorher bekannt – etwa Änderungen bei den „STRICT_TRANS_TABLES“ oder dem neuen Default SQL Mode, der eben ein „ONLY_FULL_GROUP_BY“ erforderte.

Auf andere Issues konnte man sich nicht so gut vorbereiten – dass für einige Queries der Execution Plan sich mit gewisser Last änderte und zu längeren Laufzeiten führte – das ist im Testsystem nur mit großem Aufwand nachzustellen. Hier konnte Percona unterstützen und einen Patch für 8.0 liefern, der die alte und gewohnte Performance bei den betroffenen Queries wiederherstellte.

Interessant ist außerdem, dass man ordentliche Performanceverbesserungen erreicht hat:

• 29 % Performance Verbesserung bei 1 Million Inserts bei 1024 Threads (Connections)
• 33 % Performancesteigerung bei 1 Million Reads und 1024 Threads (Connections)
• Updates konnten um 47 % schneller verarbeitet werden – ebenfalls bei 1 Million Updates und 1024 Threads

Clientseitig konnte man die „Locking Time“ um 94 % reduzieren und manche Queries liefen sogar um 78 % schneller als mit MySQL 5.7. Man sollte einfach nicht zu lange mit so Major Upgrades warten – auch interessant – die ganze Aktion hat man innerhalb eines Jahres geschafft – für die Größenordnung der Uber Landschaft finde ich das beeindruckend.

Upgrading Uber’s MySQL Fleet to version 8.0

---

80% AWS Kosten gespart bei Prerender.io

Eine ältere Story zum Thema Cloud-Kosten Reduzierung hat mir Eugen bzw. Tim in den LinkedIn Feed gespült (ich schreib dazu auch mal noch ausführlicher was).

Im konkreten Fall geht es um eine von Tims Portfolio Firma Prerender.io, welche Javascript Pages serverseitig rendered, so dass diese schnell ausgeliefert werden können und vor allem für Maschinen einfacher zu lesen sind – Suchmaschinen, Crawler, etc. Prerender ist quaso der Vorgänger von Diensten wie Vercel und Netlify (ja, nur sehr grob).

Jedenfalls sind die Berechnungen CPU intensiv und benötigen planbar viel Rechenpower. Prerender ist heute noch größer als zum Zeitpunkt des Interviews im verlinkten Blog-Artikel – man liefert heute 2,7 Milliarden Webseiten von über 65.000 Firmen aus.

In 2022 zahlte man jährlich 1 Million Dollar an AWS – diese Kosten konnte man auf 200.000 $ im Jahr reduzieren, in dem man in mehreren Phasen auf eigene Infrastruktur umgezogen ist:

Testing Phase

Als ersten Test hat man eigene Server mit KVM provisioniert und 1 % des Traffics umgezogen. Mit ein wenig Code-Optimierung und Monitoring Anpassungen konnte man nach einem Monat bereits schon signifikant Rendering Workload auf eigene Infra umziehen und kosten sparen. Das war nach 4-6 Wochen erledigt und man konnte in Phase 2 übergehen.

Scale up Phase

In der zweiten Phase zog man die umfangreiche Caching Infrastruktur auf die eigenen Server um. Als S3 Alternative setzte man auf eigene Server mit der AWS S3 kompatiblen Open Source Lösung von Minio. Caching wurde auf eine selbst betriebene Cassandra Lösung umgezogen. Während des Umzugs ist man natürlich auf einen großen Nachteil von AWS gestoßen – „innerhalb“ von AWS ist alles recht human, was den Traffic betrifft – möchte man AWS in Kombination mit anderen Diensten nutzen oder Daten exportieren, so ist das erstmal teuer:

„The true hidden price for AWS is coming from the traffic cost, they sell a reasonably priced storage, and it’s even free to upload it. But when you get it out, you pay an enormous cost.“

Prerender zahlte für den ausgehenden Traffic allein 30-50.000 $ pro Monat – schon verrückt, aber klar – man zahlt ja hier auch alle am Traffic beteiligten Komponenten, hier rechnet halt AWS für jeden Switch, Firewall, Router und jedes RZ Kabel einen Teil mit ab.

Skalierung und Finale

In der finalen Phase änderte man auch Teile der Infrastruktur – man nutze Cloudflare Loadbalancer, um den Traffic zwischen der alten und neuen Welt zu verteilen. Zusätzlich migrierte man diverse Tabellen in Cassandra und arbeitete parallel mit Lasttests, um sicherzustellen, dass die neue Infra auch wirklich schnell genug ist.

Fazit

Cooles Projekt, man sieht, wenn man es ernsthaft betreibt, kann man so einen „Hyperscaler-Exit“ dann doch auch relativ schnell durchziehen – das hat nun von Mai bis August für die Migration gedauert, und man hat sehr schnell deutliche Einsparungen erzielt.
Die Ziel-Cloud ist übrigens Digital Ocean, also auch kein kleiner Player am Markt.

How we reduced our annual server costs by 80% — from $1M to $200k — by moving away from AWS

---

---

Smoke Testing bei Incident.io

Im Blog von Incident.io findet sich aktuell dieser Artikel zum Thema Smoke Tests. Das Incident.io Team hat ein neues „On-Call“ Feature gelaunched. Da sich Kunden auf ein solches Feature zu 100% verlassen, musste einen dauerhafter End-to-End Test her.
Ob sie dafür Checkly nutzen? Man weiß es nicht.

Jedenfalls testet der „Smoke Test“, alle Funktionen, Zusammenhänge und 3rd Party Integrationen einmal in der Minute:

Every minute, we run this full suite of tests in production and staging environments. These run end-to-end in actual environments, so they exercise our infrastructure and third party integrations.

Das nenne ich „kundenzentrisches Monitoring“ – einmal die Minute ist aus diversen Gesichtspunkten beachtlich – wie kann man solche Features so schnell testen? Das so parallel abfeuern, obwohl die Daten ja bestimmt auf einander aufbauen?

Im Blog Artikel gibt es 4 Tipps, wie man sinnvoll mit dem Aufbau einer solchen Smoke-Test Infrastruktur starten kann

1. Sauberer Ausgangszustand: Es ist wichtig, dass jeder Test mit einem „sauberen“ Zustand beginnt. Wenn Tests ihre Daten nicht vollständig aufräumen, können fehlerhafte Testläufe Reste hinterlassen, was spätere Tests behindert. Die beste Lösung besteht darin, vor jedem Test alles zu löschen, was aus vorherigen Läufen noch übrig ist, um Fehlerquellen durch unerwartete Zustände zu vermeiden.
2. Standardabstraktionen: Tests sollten nur auf die Datenbank zugreifen, indem sie dieselben Abstraktionen nutzen wie der eigentliche Code/API. Dies vermeidet inkonsistente Datenbankzustände und nutzt vorhandene Sicherheitsvorkehrungen.
3. Erwartungen der Nutzer: Tests sollten die Perspektive der Nutzer einnehmen und darauf achten, dass das System den Erwartungen der Nutzer entspricht – nicht nur technisch korrekt funktioniert. Ein Beispiel ist die Reaktionszeit: Wenn ein System eine Eskalation oder Benachrichtigung verzögert, wirkt es auf Nutzer möglicherweise „fehlerhaft“. Tests sollten also auch auf Faktoren wie Zeit basieren, um eine realistische Nutzererfahrung zu simulieren.
4. Vorbereitung auf das Unerwartete: Systeme basieren oft auf Annahmen, die sich bei wachsender Nutzung als unzutreffend erweisen. Durch kontinuierliches Testen werden Schwächen früh erkannt, bevor sie dann echte Kunden betreffen. Ein ausgereiftes Testsystem hilft dabei, versteckte Annahmen zu identifizieren und das gesamte Team auf mögliche zukünftige Herausforderungen vorzubereiten. Man könnte beispielsweise sehen, wann „Response Times“ kippen, da sich DB Execution Plans aufgrund der Datenmenge ändern.

So, längerer Text geworden – er zeigt aber, wie sinnvoll die Investition in eine solche Maßnahme sein kann, damit man einen robusten und verlässlichen Release Prozess am Start hat.

Building On-call: Continually testing with smoke tests

---

Zukunft der .io Domain in Gefahr

Seit einigen Wochen berichten diverse Portale über eine drohende Abschaltung der populären .io Domain durch die ICANN – warum?

Bereits im Jahr 2019 hatte der internationale Gerichtshof in Den Haag entschieden, dass die Chagos-Inseln wieder an Mauritius zurückgehen sollen. Großbritannien hatte diese im Jahr 1965 abgespalten und als „British Indian Ocean Territory“ geführt. Diesem Namen verdankt man auch die .io Domain, denn die TLD Vergabe ist in der ICANN wie folgt geregelt:

„Your territory has to be on the ISO 3166 list and the ccTLD has to match the code ISO gives you.“

Das würde dann hier nicht mehr zutreffen und die knapp 3.500 Einwohner könnten ihre tolle und hippe Landesdomain abgeben müssen. Dies war in der Vergangenheit schon mehrmals von der ICANN durchgezogen worden:

• .zr war die TLD von Zaire, das seit 1997 die „Republic of Congo“ mit der TLD .cd ist
• .an – Netherlands Antilles – gibt es so auch nicht mehr seit 2010
• .tp – Portuguese Timor – wurde 2002 unabhängig und hat nun .tl als TLD
• .yu – Yugoslavia – gibt es seit 1992 nicht mehr, die Domain wurde aber erst 2010 final entfernt

Ob die ICANN das hier nun wirklich durchzieht ist aktuell unklar – Mauritius könnte die Inseln auch einfach in „Mauritius Indian Ocean Territory“ umbenennen und so offizielle Sicherheit für die TLD sichern.

Laut InterNetX gibt es über 1 Million .io Domains, deutlich mehr als die 500k .ai Domains – eigentlich sind ja beide mittlerweile mehr oder weniger klassische „Infrastruktur“ Domains wie .net und .com geworden und müssen daher vielleicht gar keinem Land mehr zugeordnet werden?

What Is the Future of the .io Domain?

---

Bitwarden nicht mehr Open Source?

Der bekannte Passwort Manager Bitwarden scheint sich vom früheren Open Source Gedanken zu verabschieden.

Ein Pull Request auf GitHub möchte ein neues Bitwarden/sdk-internal mergen, welches folgenden Hinweis enthält:

You may not use this SDK to develop applications for use with software other than Bitwarden (including non-compatible implementations of Bitwarden) or to develop another SDK.

Rückfragen und Feedback wurden von Bitwarden CTO Kyle Spearrin heruntergespielt und das Issue dann auf GitHub „locked“ und weitere Kommentare auf „Collaborators“ eingeschränkt.

Ob und wie der Server dann in Zukunft so geändert werden wird, dass „inoffizielle“ Server wie der bisherige Community Favorit Vaultwarden weiterhin 1:1 mit den Bitwarden Clients funktionieren, ist aktuell nicht klar.

Zuletzt hatte das BSI neben KeePass auch Vaultwarden einer Sicherheitsprüfung unterzogen und diverse Sicherheitslücken entdeckt, die die Projekte dann direkt gefixed hatten.

Im Bitwarden Community Forum wird das Thema ebenfalls diskutiert und man verspricht, dass sich für den User keine Änderungen ergeben werden. Die Clients seinen mit der GPL 3.0 lizensiert, der Server mit AGPL 3.0 – daran soll sich nichts ändern. Das GitHub Issue sei eher ein Packaging Bug, um den man sich noch kümmern möchte:

It seems like a packaging bug was misunderstood as something more, and the team plans to resolve it. Bitwarden remains committed to the open source licensing model in place for years, along with retaining a fully featured free version for individual users.

Mal abwarten, was hier nun noch passiert.

Desktop version 2024.10.0 is no longer free software

---

Wie überbringt man schlechte Nachrichten?

Da es in der „Remote Ecke“ etwas ruhiger ist, mal wieder etwas aus dem Bereich Management, was mir früher sicher das ein oder andere Mal geholfen hätte – wie überbringt man schlechte Nachrichten, deren Auslöser jemand oder etwas anderes ist?

Vermeide negative Wörter
Wörter wie „leider“ oder „jedoch“ erzeugen oft unnötige Dramatik und lassen die Situation schlimmer erscheinen, als sie eigentlich ist. Stattdessen sollte eine positive und bildhafte Sprache genutzt werden, um unnötige negative Emotionen zu vermeiden.

Gib nicht zu viele Details
Zu viele Erklärungen bei negativen Nachrichten lenken vom Wesentlichen ab und können den Empfänger verwirren. Direkte und klare Kommunikation ermöglicht eine offene Dialogbasis, falls der Empfänger mehr wissen möchte, ohne ihn zu überfordern.

Vermeide unabsichtliche Schuldübernahme
Auch wenn man Empathie zeigen sollte, sollte man darauf achten, dass dies nicht als Eingeständnis von Schuld interpretiert wird, wenn man nicht verantwortlich ist. Andernfalls könnten andere eine ungerechtfertigte Schuldzuweisung vornehmen, was das Vertrauen und die eigene Glaubwürdigkeit schwächen könnte – nicht gut für die „Trust Battery“.

Komme schnell zum Punkt
Zu lange Einleitungen erhöhen die Anspannung, und die Empfänger neigen dazu, sich das Schlimmste vorzustellen. Indem man schnell auf das Wesentliche eingeht, vermeidet man, dass der Empfänger in negative Gedanken abschweift und unnötige Angst empfindet.

Den letzten Punkt im Artikel kann ich jetzt so nicht unterschreiben – da geht es darum, den Empfänger daran zu erinnern, dass er ebenfalls eine Verantwortung an der Situation hat. Aus den eigenen Erfahrungen in größeren Firmen ist das eher sehr selten der Fall.

Für den Sprachgebrauch fand ich die Tipps aber dennoch hilfreich, daher hab ich sie mal hier erwähnt – was hilft dir in solchen Fällen?

How to deliver bad news when it’s not your fault

---

Latenzen von AWS Cloud Regionen im Vergleich

Auf der Site von Benjamin Dicken findest du eine einfache Visualisierung von typischen Latenzen zwischen AWS Regionen.

Man kann den Globus zoomen und drehen und sieht an den Farben die typische Latenzen zwischen den Standorten:

• grün unter 100ms
• gelb von 100ms bis 200ms
• rot über 200ms

Die Daten beruhen auf dieser CloudPing Tabelle, in der man dann alle Regionen ebenfalls genau unter die Lupe nehmen kann. Man kann grundsätzlich sagen, dass in der EU alles recht schnell verbunden ist. Von Frankfurt an die Ostküste ist man noch bei knapp unter 100ms, an die West-Küste dann schon bei 150ms, nach Asien dann über 200ms und Australien (Sydney) hat von uns aus mit 250ms die höchste Latenz.

Hilft vielleicht dem ein oder anderen, wenn er sich bei der Entwicklung oder Architektur für eine asynchrone Lösung interessiert.

AWS data center latencies

---

Schmunzelecke

Tja, vermutlich hast du das schon gelesen: Die AI Company Anthropic hat ein neues Claude Modell vorgestellt, welches einen Desktop Computer steuern kann. Mit der Electron App Agent.exe kannst du das ganze auf deinem Rechner mal ausprobieren.
Agent.exe ist eine Node Application und keine wirkliche .exe, aber irgendwie ja dann doch – viel Spaß damit.

---

💡 Link Tipps aus der Open Source Welt

Kubernetes bei Hetzner mit „Cluster API Provider“

Ok, für das Marketing wäre ein hipper Name mit Logo sicherlich cooler gewesen, aber vielleicht wollte man auch einfach mit Features überzeugen. Die Firma syself hat die Version 1.0 ihres Cluster API Provider Hetzner (CAPH) veröffentlicht. CAPH ist ein Möglichkeit, die eigene Hetzner Infrastruktur deklarativ zu steuern inklusive Features wie Self-healing und co.

Vorab installiert haben sollte man eine Container Runtime, kubeadm und kubelet – dann kann man damit auch schon loslegen. Ein Tutorial wie das Ganze funktioniert findet sich in der Hetzner Community oder auch in der Online Hilfe bei Syself.

Finanziert wird das Ganze über Pläne mit mehr Features, bei denen man „nur“ die Control Plane + ein Featureset nach Paket bezahlt, und seine Worker Nodes dann nach Usage bezahlt.

https://github.com/syself/cluster-api-provider-hetzner

Benchmarking Tool YABS – Yet Another Bench Script

Auf diesem Twitter habe ich einen interessanten Performance Vergleich zwischen einer Hetzner und OVH VM gesehen. Der Performance Test wurde mit „Yet Another Bench Script“ ausgeführt – kannte ich bisher nicht.

yabs.sh nutzt bestehende Tools wie fio, iperf3 und Geekbench und erstellt damit einen Benchmark zum Vergleichen verschiedener Provider hinsichtlich Netzwerk Bandbreite und Latenz, IOPS und CPU Benchmark mittels Geekbench.

Man könnte damit auch automatisierte Benchmarks laufen lassen und ein Ergebnis via JSON auf einen verarbeitenden Service hochladen.

https://github.com/masonr/yet-another-bench-script

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