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:
Ärger bei Red Hat geht weiter
In der letzten Woche hatte ich dich zu den aktuellen Änderungen bezüglich des Red Hat Source Codes informiert.
Die ausführlichen Hintergründe , die Mike McGrath (VP Core Platforms Engineering, Red Hat) im Red Hat Blog dazu dargelegt hat, konnten hier nicht beruhigen – im Gegenteil.
Der bekannte Buch-Autor und Code-Autor diverser, populärer Ansible Rollen, Jeff „geerlingguy“ Geerling, kündigt in „I’m done with Red Hat (Enterprise Linux)“ an, den Support seiner veröffentlichten Software für RHEL einzustellen. Er erklärt im Artikel, dass Red Hat zwar rechtlich auf der sicheren Seite sei, sich aber absolut unmöglich gegenüber der Community verhalte, auf deren Füße Red hat aufgebaut worden sei. Er habe auch keine Zeit, seine Developer Tools auf die geänderten Umstände anzupassen, daher sei für ihn nun klar, dass es für ihn hier nicht weitergehe.:
Who wants to build around an ecosystem where the open source users are called freeloaders and where massive disruptions are implemented in the middle of a release cycle, two times in a row, with no warning?
I don’t see this helping Red Hat in any way in the long term.
Jedenfalls hat Jeff den RHEL Support in seinen Repos schon teilweise entfernt, beispielsweise in ansible-role-php oder ansible-role-docker.
Ironischerweise muss Jeff sich dann vorwerfen lassen, als „Tech-Influencer“ ebenfalls Geld mit Red Hat Produkten zu verdienen, beispielsweise in seinem YouTube Video zu AWX – schaut man sich dann aber die Fakten an, so sieht man, dass Jeff initial den Code für den AWX-Operator geschrieben hat, den Red Hat (und andere) heute verwenden und pushen.
Bei its-foss.com gibt es einen weiteren Kommentar zum Thema, der das Thema im Detail und ausführlich mit der ganzen Red Hat und CentOS/CentOS Streams Historie erklärt.
Der Vater von Ansible, Michael DeHaan, hat der IT zwar inzwischen den Rücken gekehrt, beschreibt seine Gedanken zur „CentOS Controversy“ in seinem Blog:
To me, the value of Ansible to modern day Red Hat — that came in turn from that experience from primarily “non-paying” CentOS users — is likely, what, billions? I’m not just talking about Ansible sales but also they are using it in training and to automate lots of cloud internals.
Ja, „Red Hat“ hat die Community nicht nur unterstützt, sondern auch massiv von ihr und der massiven User-Anzahl profitiert. Der Zugang zur Technologie und die Hemmschwelle, sie zu nutzen, ist aufgrund der Vielzahl an YouTube-Videos, StackOverflow Artikel und Blog Beiträgen einfach extrem gering.
Und Jeff Geerling? Der nimmt ein Video im „Rocky Linux“ Shirt auf und macht sein E-Book „Ansible for DevOps“ kostenlos für alle.
I’m done with Red Hat (Enterprise Linux)
Tipps für Manager eines Remote-Teams
In einer zunehmend digitalisierten Welt ist die Fähigkeit, Teams aus der Ferne effektiv zu leiten, zu einer entscheidenden Kompetenz für Manager geworden. Der verlinkte Artikel auf infoq.com beleuchtet wichtige Fähigkeiten, die Manager entwickeln sollten, um Remote-Teams erfolgreich zu führen.
Als Erstes ist eine klare Kommunikation wichtig. Bei der Arbeit in virtuellen Umgebungen ist es unerlässlich, dass Führungskräfte ihre Erwartungen, Ziele und Anweisungen klar und präzise kommunizieren. Eine klare Kommunikation trägt dazu bei, Missverständnisse zu vermeiden und sicherzustellen, dass alle Teammitglieder auf dem gleichen Wissensstand sind. Meiner Meinung nach sollte ein Teil dieser Kommunikation asynchron sein, sodass die Information auch nachträglich verarbeitet werden kann.
Ein weiterer Schlüsselfaktor für den Erfolg von Remote-Teams sei das Vertrauen zwischen dem Manager und den Teammitgliedern. Vertrauen bildet das Fundament einer effektiven Zusammenarbeit. Führungskräfte sollten daher darauf achten, Vertrauen aufzubauen, indem sie transparente Kommunikation fördern, erreichbare Ziele setzen und die individuellen Stärken und Fähigkeiten jedes Teammitglieds erkennen und diese „Wertschätzen“.
Da physische Interaktionen begrenzt sind, müssten Manager kreative Wege finden, um Teamzusammengehörigkeit zu schaffen. Dies kann durch virtuelle Team-Meetings, regelmäßiges Feedback und Anerkennung der Leistungen einzelner Teammitglieder erreicht werden. Dabei sollte dann auch der Spaß nicht zu kurz kommen bzw. es Termine geben, die sonst an der Kaffeemaschine stattfinden – also „Coffee-Chats“, bei denen man sich über private Themen austauscht. Auch dies schafft Vertrauen und festigt das Verhältnis.
Die meisten Themen im Artikel kennst du sicher schon, vermutlich muss man diese sich einfach regelmäßig vor Augen halten.
Respect. Support. Connect. The Manager’s Role in Building a Great Remote Team
Sponsored
DevOps & SRE as a Service mit „We Manage“
Wir helfen Dir beim 24×7 Betrieb, bei Performance Problemen, bei Kostenoptimierung oder einfach beim Betrieb Deiner Web-Applikationen.
Betreibst Du Services wie Elasticsearch, GitLab, Zammad und Matomo selbst – hierbei unterstützten wir ebenfalls gerne – schau Dir einfach mal unsere Leistungen an.
Unsere Kunden kommen in unseren Case Studies zu Wort – wie beispielsweise KRUU.com – ein Premium-Event-Dienstleister rund ums Thema Hochzeit.
Interessiert? Lerne uns in einem 15 Minuten Video-Call kennen.
Figma: DB-Sharding mal anders
Im verlinkten Artikel erklärt Tim Lang, Software Engineer beim UI/UX SaaS Anbieter Figma, welche Schmerzen mit wachsender DB Größe verbunden sind und was man dagegen tun kann.
Laut dem Artikel verdreifacht sich die Last der Figma Systeme seit 2020 jedes Jahr. Man habe die PostgreSQL RDS Instanz bei AWS ausgereizt und sieht aufgrund von 65 % CPU Peaks keine Möglichkeiten mehr, vertikal zu skalieren. Eine andere Lösung musste also her.
Um Zeit zu gewinnen, hat man ein paar Workarounds etabliert:
- Umstieg auf die derzeit größte AWS RDS Instanz (r5.24xlarge mit 48 Cores/96 VCPU und 768 GB RAM)
- Hinzufügen weiterer Read-Replicas zum Verteilen der Leselast
- Neue Use-Cases wurden in neuen Datenbanken abgelegt, um die aktuelle nicht weiter zu belasten
- Einführung von PgBouncer zum Connection-Pooling
Man hat sich verschiedene Möglichkeiten angeschaut und verworfen, beispielsweise:
- Ein Umstieg auf eine NoSQL DB war parallel zum Betrieb nicht realisierbar
- Migration zu Vitess (MySQL mit Sharding) hätte ebenfalls viele Applikation Rewrites benötigt und wurde verworfen
- Self-Hosting auf eigener HW – wollte man nicht machen, da man damit keine Erfahrung hatte
Schlussendlich hat man sich für das „Vertical Sharding“ entschieden – aber nicht wie man es üblicherweise kennt. In der Regel verteilt man hier die User auf X-Systeme, beispielsweise nach der User-ID, nach Landeszuordnung oder nach anderen Merkmalen.
Bei Figma hat man Tabellen, die zusammengehören, auf Systeme verteilt – die Datenbank quasi in „Self-Contained“ DB Instanzen verschoben.
Natürlich musste man Tabellen auswählen, die wenig oder keine Fremdbeziehungen zu „entfernten“ Tabellen hatten und die auch für eine ordentliche Entlastung der Haupt-DB sorgten.
Spannend an der Migration: Man hat die Applikation so umgeschrieben, dass das Ganze „online“ funktioniert hat.
Dank guter Vorbereitung konnte man erst 2 größere Tabellen, dann 50 weitere mit kurzen Downtimes migrieren:
Our first operation involved moving two high-traffic tables, while our final operation in October 2022 involved 50.
During each operation, we observed a ~30 second period of partial availability impact (~2% of requests dropped.)
Nun hat man Platz und CPU übrig, um weiterzuwachsen – die aktuell größte DB läuft auf 10 % Last.
The growing pains of database architecture
Google: Anwesenheit im Büro positiv beim Review
Zum „Remote Work“ Artikel von oben passt die Nachricht, dass Google in Zukunft eine Anwesenheit im Büro im jährlichen Performance Review „positiv“ bewerten möchte.
Sprich, Mitarbeiter, die die geforderten 3 Tage (oder mehr) im Büro verbringen, können dadurch einen positiven Impact in ihrem Review bekommen:
We’ve heard from Googlers that those who spend at least three days a week in the office feel more connected to other Googlers, and that this effect is magnified when teammates work from the same location
So wurde zumindest bei Ars Technica Google Chief People Officer Fiona Cicconi zitiert. Und sind wir mal ehrlich, eine höhere Bindung lässt sich durch Büro-Anwesenheit schon erreichen, aber das sollte auch anders gehen, oder? Zumindest halte ich es nicht für mehr zeitgemäß, von einer Anwesenheitszeit auf eine Performance zu schließen – hier sollte das Ergebnis zählen. Das „Wall Street Journal“ hat ebenfalls über das Thema berichtet (Paywall hier).
Google makes office attendance part of performance reviews
Fly.io sammelt weitere $ 70 Millionen ein
Über fly.io und deren Use-Cases hatte ich schon ein paar mal berichtet.
Nachdem die Gründer im letzten Juli bereits 25 Millionen Dollar von Andreessen Horowitz (A16Z) eingesammelt haben, haben sie ein Jahr später nochmals 70 Millionen Dollar nachgelegt. Die Runde wurde von EQT Ventures angeführt und soll fly.io helfen, weiterzuwachsen:
- Fly.io läuft weltweit verteilt auf eigener Hardware, an der Stelle möchte man nun nachlegen, denn 10 Jahre in die Zukunft gedacht, mache eigene Hardware das alles erst möglich „Hardware is what makes the margins work“.
- Gestartet ist man mit 19 Regionen, nun sind es 33 – und man möchte diese weiter ausbauen
- Support und Verfügbarkeit möchte man weltweit verbessern
Man verspricht aber auch, dass fly.io weiterhin so einfach zu nutzen sei, wie bisher.
Habe man schon einen Docker Container, so bekomme man diesen weiterhin mittels flyctl in unter 10 Minuten ans Laufen.
Landingpage zur Uptime Berechnung
In der Vergangenheit hatte ich zur Uptime Berechnung gerne auf das Pingdom Uptime Cheat Sheet verwiesen, das gehört nun der Vergangenheit an.
Du musst dir nur noch „uptime.is“ merken, da hängst du einfach die gewünschte SLA an
- 99,9 % = https://uptime.is/99.9
- 99,99 % = https://uptime.is/99.99
- 99,999 % = https://uptime.is/99.999
oder auch SEO freundlich: https://uptime.is/three-nines
Auf der Landingpage sieht man dann auf einen Blick, was das auf den Tag, die Woche, den Monat und das Jahr bedeutet.
Bei 99,999 % sind die folgenden möglichen Downtimes:
- Daily: 1m 26s
- Weekly: 10m 4.8s
- Monthly: 43m 28s
- Yearly: 8h 41m 38s
Cool, oder?
Gesehen bei Hannes – danke!
Uptime and downtime with 99.9 % SLA
1994: Jeff Bezos auf Job-Suche
Tja, das hier kannte ich noch nicht, aber im verlinkten Artikel findest du die erste Job-Anzeige von Jeff Bezos für Amazon.
Er sucht darin „extremely talented C/C++/Unix developers“, die „experience designing and building large and complex (yet maintainable) systems“ haben.
Echt interessant, Kenntnisse in Webservern und HTML wären zwar nett, seinen aber nicht zwingend erforderlich.
Well-capitalized Seattle start-up seeks Unix developers
Schmunzelecke
Passend zur Red hat News, ein lustiges Video zu „Red Hat’s first blog post …. and the second one“ von Jeff Geerling.
Anmerkung: Ich weiß, das Video ist älter und geht aktuell wieder rum – und ich hoffe, es wurde dabei niemand ernsthaft verletzt.
💡 Link Tipps aus der Open Source Welt
dub.sh – Moderner Link Shortener
Dub ist ein moderner Open-Source Link-Shortener und eine Alternative zu bit.ly.
Im Gegensatz zur hier schon vorgestellten Alternative shlink.io benötigt dub jedoch einen anderen Stack:
In der Regel genügen hier überall die „Free“ Angebote – und falls man diesen Stack nicht kennt, ist es ein tolles Projekt, um das Ganze mal in einer Kette und einem Use Case auszuprobieren.
Dub kommt ansonsten mit einem Analytics Feature, Custom-Domains-Support, QR-Code Generator und OG Image Proxy.
https://github.com/steven-tey/dub
xeol – EOL Paket Scanner
xeol ist ein in Go geschriebener EOL Scanner, welcher Container oder Filesysteme nach Paketen von endoflife.date abgleicht und entsprechend informiert.
Man kann den Scanner beispielsweise in GitHub Actions einbauen oder anderweitig automatisieren.xeol speichert seine Metadaten lokal in einer SQLite DB ab. Eine kurze Video-Demo findest du hier.
Ich denke nicht, dass es Sinn macht, sich nur auf xeol zu verlassen, aber ein Baustein kann es schon sein.
https://github.com/xeol-io/xeol
❓ 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: