Willkommen zu allesnurgecloud.com – Ausgabe #142!
Wie versprochen erscheint Ausgabe 142 fast pünktlich zum Frühstück in deinem Posteingang.
Danke an alle, die mir Feedback zur letzten Ausgabe geschickt haben – immer wieder hilfreich
Happy Bootstrapping Podcast
Im Podcast habe ich diese Woche eine regionale Erfolgsgeschichte besucht – die HEIMAT Distillers aus Schwaigern (bei Heilbronn) stellen den beliebten HEIMAT Gin, eine alkoholfreie Variante davon und den Ramero Rum her. Neben einem kleinen Tasting und vielen Insights habe ich das „grösste Fasslager Süddeutschlands“ bestaunen können (Impressionen hier bei LinkedIn). Die Folge findest du überall, wo es Podcasts gibt unter „Happy Bootstrapping“ oder direkt unter diesem Link.
Als kleines Geschenk hat Co-Gründer und Podcast Gast Marcel Eßlinger noch einen kleinen Gutschein Code für den Heimat Distillers Online-Shop hinterlassen.
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:
Return-to-Office: Verlust der High-Performer droht
In einer Kolumne der renommierten Fachzeitschrift MITSloan Management Review legt Autor und Speaker Brian Elliott dar, warum gerade High-Performer „Return-to-Office“ Mandate für eine Ablenkung halten.
CEOs würden die Produktivität als Grund zur Bürorückkehr nur vorschieben, dabei sei „Management durch Monitoring“ die schwächste Form des Managements:
But in a world of globally distributed teams, falling back on management-through-monitoring is falling back on the weakest form of management — and one that drives down employee engagement
Er geht sogar noch einen Schritt weiter als andere Analysen und fasst zusammen, dass High-Performer den Zwang zur Bürorückkehr sogar negativ interpretieren.
Brian wirbt daher für ein Upgrade der gängigen Management-Philosophie, nicht „Face-time“ sei entscheidend, sondern der Fokus auf das Ergebnis und die Schaffung von Flexibilität und Vertrauen.
Zudem sei es viel wichtiger, nach den Kundenbedürfnissen zu schauen und Ergebnisse mit Mehrwert zu liefern, das zeige auch die Studie von Atlassian, die ich schon mal verlinkt hatte. In einer weiteren Studie von Slack kam ironischerweise heraus, dass 70 % der Führungskräfte „visible activity“ als primäre Quelle von Produktivität heranziehen – im Gegenzug fand die gleiche Studie heraus, dass Mitarbeitende 32 % ihrer Zeit darauf verwenden, Arbeiten durchzuführen, die den Produktiv erscheinen:
70% of executives use visible activity (such as what time people show up and how many hours they log) as a primary measure of productivity. Notably, the same survey found that, on average, employees spend 32% of their time “on performative work that gives the appearance of productivity.”
49 % der Befragten reagieren mit Sorge, wenn es um das Thema „Monitoring der Arbeitsleistung“ geht. Den Begriff „Doom Loop“ kannte ich in dem Zusammenhang bisher nicht, aber er trifft es wohl auf den Punkt. Man möchte eher den „Boom Loop“, also das genaue Gegenteil davon.
Unternehmen, die auf Vertrauen setzen, übertreffen ihre Konkurrenz finanziell. Laut einer weiteren Studie sind Mitarbeiter in leistungsstarken Unternehmen elfmal häufiger der Meinung, dass ihre Führungskräfte ihnen vertrauen. Vertrauen und Leistung entstehen durch die Ausrichtung auf Ergebnisziele und Verantwortung.
Brian Elliott schließt damit, dass ein Gleichgewicht zwischen Vertrauen und Verantwortung dazu führt, dass Menschen und Organisationen aufblühen. Mitarbeiter können ihre Zeit besser nutzen, indem sie von zu Hause arbeiten und auf Ergebnisse anstatt auf Präsenz bewertet werden. Statt sich mit internen Diskussionen über Vorschriften und Überwachung zu beschäftigen, können sich Mitarbeiter auf die Erreichung von Ergebnissen konzentrieren.
Ein ganz klein wenig erinnert mich das an das „Making teams responsible“ Kapitel in „Shape Up“ von Basecamp.
Return-to-Office Mandates: How to Lose Your Best Performers
Redis Geschichte und Valkey Fork
Bei Redis hat es im März ja gerumpelt und unter der Linux Foundation formte sich der neue Fork „Valkey“, welcher von AWS, Google Cloud, Snap, Oracle und vielen anderen unterstützt wird. Als Basis wird die letzte Redis Version unter BSD Lizenz, Redis 7.2.4, verwendet.
Redis selbst hat nun ein neues Logo und Branding, um sich von den Open Source Projekten abzugrenzen. Wie es sich für eine anständige Enterprise Company gehört, gibt es nun sogar einen Branding Guide. Das ursprüngliche Redis Logo ist damit Geschichte – es war 2010 aus einer Community Competition heraus entstanden.
Schaut man sich die Geschichte des Redis Projektes an, so ist die sicherlich so interessant, wie bei fast keinem anderen Open-Source-Projekt. Im Artikel „RIP Redis: How Garantia Data pulled off the biggest heist in open source history“ kannst du die ganze Geschichte lesen.
Zusammengefasst geht sie ungefähr so:
- 2009 – der italienische Entwickler Salvatore „Antirez“ Sanfilippo startet das Redis Projekt
- 2013 – der hosted Redis provider „Garantia Data“ möchte sich in „RedisDB“ renamen – lässt es dann aber nach Intervention von „Antirez“
- 2014 nennt sich Garantia dann doch in „Redis Labs“ um
- 2015 – „Antirez“ wird Teil von „Redis Labs“ und überträgt 2018 die IP Rechte an die Firma
- 2020 – „Antirez“ zieht sich vom Projekt zurück
- 2021 nennt sich „Redis Labs“ dann in „Redis“ um
und irgendwie haben wir das vermutlich vergessen oder die Zusammenhänge waren nicht so ganz klar. Die Autoren des „RIP Redis“ Artikels bieten selbst Redis als Service an und der Titel ist reißerisch geschrieben, allerdings hat das ganze schon ein ordentliches Geschmäckle, wie wir hier im Ländle sagen.
Die ursprüngliche Firma, Garantia, hat also die Arbeit von „Antirez“ gesponsored, selbst, aber nie groß zur Verbreitung der Software oder zur Entwicklung beigetragen. In einem anderen Artikel kann man sehen, dass Firmen wie Tencent, Alibaba, Huawei, Bytedance und Amazon viele Contrbutions zum Projekt beigetragen haben – 34,2 % der Contributions kamen aber von der unabhängigen Community – dem größten Committer in reinen Zahlen.
Und bei Valkey gibt es nun die erste Version 7.2.5, die dann erstmal den Namen Redis überall entfernt und durch „Valkey“ ersetzt.
RIP Redis: How Garantia Data pulled off the biggest heist in open source history
Sponsored
8gears Container Registry
Container Images unterscheiden sich deutlich von anderen Artefakten hinsichtlich ihrer ständigen Verfügbarkeit.
Im Gegensatz zu NPM oder JAR Artefakte müssen Container Images für den operativen Betrieb der Anwendung durchgehend verfügbar sein. Auch sollte die Registry nicht auf den gleichen Clustern laufen wie die Anwendungen, um den MTTR (mean time to recovery) möglichst kurzzuhalten. Selbstverständlich sollte die Registry hochverfügbar ausgelegt werden, mit ansprechenden Datenbanken und Buckets.
Wenn es bloß jemanden gäbe, der das Ganze für einen übernehmen könnte?
Die 8gears Container Registry ist ein Harbor-basierte Container-Registry Service. Angeboten und betrieben von Harbor Projektbetreuern und Mitwirkenden.
Hochverfügbar in verschiedenen EU Datenzentren ganz in deiner Nähe.
Was ist eigentlich „Boring Technology“?
Im Grunde ist „Boring Technology“ für jeden etwas anderes. Ich würde es mit „bewährte Technologie“ im Deutschen übersetzten.
Das „Choose Boring Technology“ Movement geht aber schon einige Jahre zurück und ich hatte es immer mal wieder hier erwähnt, da ich selbst ein großer Fan davon bin.
Häufig sieht man heute „Over-Engineering“ in der Praxis, da man sich mit neuen Technologien beschäftigen möchte, Angst hat, abgehängt zu werden (FOMO im Artikel) oder auch einfach nur dem Hype hinterher hängt.
Im verlinkten Artikel geht es genau darum. Addy Osmani beschreibt Boring Technology so:
Often, “boring” technology – those stable, well-understood, and perhaps previous-generation tools – have a lot to offer. They are usually tried and tested, have proven scalability, and come with extensive documentation and community support.
Kelsey Hightower, ehemaliger Google Principal Engineer, geht sogar noch ein Stück weiter:
Stick to boring architecture for as long as possible, and spend the majority of your time, and resources, building something your customers are willing to pay for.
Ja, am Ende muss es jemand bezahlen, bzw. man sollte sich auf Features konzentrieren, und nicht darauf, Neues kennenzulernen (und diese Learnings dem Kunden dann in Rechnung zu stellen).
Addy beschreibt in einem Satz, was Software eigentlich sein sollte: Software is a vehicle for delivering value to people.
In der Praxis sehe ich häufig, wie dieses Ziel aus den Augen verloren wird. Man verliert sich in Tools und Technologien und benötigt bei der Migration einer Legacy Applikation Jahre, um Feature-Parität mit der „alten“ Variante der Applikation herzustellen. Natürlich hat der Markt sich aber in der Zeit weitergedreht und man hätte schon längst neue Features liefern müssen – ein Teufelskreis.
Der Artikel liefert einen guten Vorschlag – pro Projekt erhält man einen „Innovation Point“, den man für die Evaluierung einer Technologie verwenden könne – aber nur eine neue Technologie, nicht 42 davon. Man muss den Punkt also weise verwenden.
Passend zum Artikel gibt es im subreddit /webdev eine provokante Diskussion: „Majority of web apps could just run on a single server“.
Ein Kommentar beschreibt eine alte ASP.NET App, mit jQuery im Frontend und Hosting bei Rackspace – klar, nicht hip und sexy, aber:
They brought in millions and millions of dollars per year because they just focused on making the software do what the users wanted it to do.
Manchmal muss man halt einfach liefern und sich nicht im Technologie Dschungel verlieren.
Stick to boring architecture for as long as possible.
OpenTofu: Unterlassungserklärung von HashiCorp gefordert
Der Terraform Fork OpenTofu hat eine Unterlassungserklärung von HashiCorp erhalten und diese im eigenen Blog veröffentlich und kommentiert.
Die Unterlassungserklärung selbst wurde in einer geschwärzten Fassung ebenfalls online gestellt (PDF, 33 Seiten).
Konkret werfen die Anwälte bzw. HashiCorp dem OpenTofu Projekt vor, Teile des nun BSL lizenzierten Codes übernommen zu haben.
In der Antwort des OpenTofu Projekts wird diesem Vorwurf vehement widersprochen:
The OpenTofu team vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp’s BSL code. All such statements have zero basis in facts.
In einer ausführlichen Quellcode Analyse legen die OpenTofu Macher dann da, dass OpenTofu Teile eines älteren und unter MPL Lizenz stehenden Codes übernommen bzw. erweitert habe. Man sei sich sicher, dass die Terraform Maintainer ähnlich vorgegangen sind und nun eben zu einem ähnlichen Ergebnis gekommen sind.
OpenTofu reicht hier sogar die Hand und schlägt vor, solche Themen in Zukunft erstmal in einer Arbeitsgruppe zu klären:
Going forward, OpenTofu would be open to establishing developer liaison contacts between OpenTofu and Terraform who would be available to review and address any intellectual property concerns with submitted contributions to OpenTofu or Terraform.
Tja, die Aktion von HashiCorp wird in der Community sicherlich nicht dafür sorgen, dass die „Trust Battery“ mit HashiCorp wieder aufgefüllt wird – im Gegenteil.
OpenTofu hat zum Vorfall kein Update veröffentlicht – dafür aber eine neue Beta Version von OpenTofu 1.7.0 – mit „Provider-defined functions“, „Loopable import blocks“, „State encryption“ und dem „Removed Block“ Feature, welches der Auslöser der Unterlassungserklärung war. Die Version steht hier zum Download bereit – ist für den produktiven Einsatz aber nicht empfohlen.
Our Response to Hashicorp’s Cease and Desist Letter
Image Processing Benchmark
Im Blog von Imgproxy findest du einen aktuellen und interessanten Performance Vergleich zwischen den drei weit verbreiteten Image Prozessoren imgproxy, thumbor und imagor.
Die Tests wurden auf 2 EC2 Hosts durchgeführt: einmal mit Intel CPU und einmal mit eine Graviton3 ARM CPU (c7i.large und c7g.large).
Im Benchmark wurde die Anzahl der „Requests pro Sekunde“ für die Umwandlung von PNG, JPEG, WebP und AVIF Bildern verglichen.
Imgproxy hat überall die Nase vorn und ist teilweise doppelt so schnell als die anderen beiden Tools. Interessant fand ich, dass imgproxy auf den Graviton ARM CPUs um einiges schneller ist als auf den Intel CPUs. Der Unterschied hist hier bei den Bildtypen enorm – ist imgproxy bei JPGs nur 3 % schneller als auf Intel, schafft es bei PNGs 16% mehr Durchsatz auf ARM, bei WebP 19 % mehr und bei AVIF sogar 34 % mehr Requests pro Sekunde als auf den Intel CPUs.
Solltest du den Benchmark selbst durchführen wollen, der Code ist hier auf GitHub verfügbar.
Solltest du imgproxy nicht kennen – hier gibt es einen Artikel, wie wir imgproxy für die Bilder der Kaufland und Lidl Flyer verwenden – alternativ hier bei YouTube den stackconf Vortrag dazu.
Image processing servers benchmark
MITRE: Netzwerk durch Ivanti Lücken kompromittiert
MITRE, die Non-Profit Organisation, die unter anderem die CVE Datenbank verwaltet und Sicherheitsforschung betreibt, wurde im Januar Opfer eines „Nation State Actor“ Angriffs, welcher die in vorigen Ausgaben erwähnten Lücken im Ivanti VPN ausgenutzt hatte (CVE-2023-46805 und CVE-2024-21887).
In einem ausführlichen Blog Artikel beschreibt die MITRE Principal Cybersecurity Engeineer Lex Crumpton, wie der Einbruch von statten ging. Im Januar wurden die Ivanti Systeme über Session Hijacking kompromittiert und dann über einen verwundbaren Administrator Account auf die VMware Infrastruktur zugegriffen. Es wurden diverse „sophisticated backdoors and webshells“ installiert. Zum Zeitpunkt, an dem MITRE die Ivanti Systeme aktualisierte und austauschte, war es schon zu spät.
Man bemerkte die Attacke dann erst im April, schottete das Netzwerk ab und engagierte eine Digital Forensics Firma, die sich den Vorgang zusammen mit den InHouse Experten anschauten. Im Artikel gibt es dann noch zusätzliche Tipps, zum Netzwerk Monitoring und Hardening, der solch einen Vorfall dann offensichtlich auch nicht verhindern konnte.
Ein Statement im Artikel sticht für mich dann doch hervor:
At the time we believed we took all the necessary actions to mitigate the vulnerability, but these actions were clearly insufficient.
Es gibt bestimmt viele, die das glauben. Allerdings sind „Zero Day“ Lücken bei Bekanntgabe ja ggf. schon länger im Umlauf, vor allem wenn staatliche Interessen dahinter stecken.
Google hat im Rahmen einer ausführlichen Analyse einen „anonymen“ Ivanti Breach vorgestellt und analysiert – MITRE hat auf den Artikel verlinkt, bisher aber nicht bestätigt, dass sie genau der betroffene Fall sind.
Die Analyse bei MITRE selbst ist aktuell noch „Work in Progress“ und es soll in naher Zukunft noch weitere Beiträge zu den Findings aus der Analyse geben.
MITRE was breached through Ivanti zero-day vulnerabilities
Zero-Day auch bei Palo Alto Networks
Die vermutlich „state-sponsored hackers“ machen auch vor Palo Alto keinen Halt. Seit dem März soll eine als CVE-2024-3400 markierte Lücke im Firewall Betriebssystem „PAN-OS“ aktiv ausgenutzt worden sein. Patches für die Software sind seit dem 14. April verfügbar. Der CVE hat eine Base Score von 10.0 – High Score.
Sicherheitsforscher von Volexity hatten am 10. April entdeckt, dass die Lücke ausgenutzt wurde. Im analysierten Fall wurde ein auf Golang basierter Tunnel namens GOST installiert. Laut der weiteren Analyse wurde der Exploit seit dem 26. März verwendet, die Payloads dann aber erst ab dem 10. April installiert.
Bei den ganzen Berichten fragt man sich, was es da draußen noch alles gibt, das bisher nicht entdeckt wurde.
Palo Alto Networks zero-day exploited since March to backdoor firewalls
PiVPN – Finale Version veröffentlicht
Der populäre Raspberry VPN Server „PiVPN“ wurde in Version 4.6.0 veröffentlicht und soll die letzte, finale Version von PiVPN sein. Der Maintainer habe nicht mehr die Zeit, sich darum zu kümmern, und zudem sei die ursprüngliche Mission des Projekts erfüllt worden
There are so many tools out there that do the job much better than PiVPN does, and I genuinely believe PiVPN’s mission in life was accomplished and is no longer relevant. Just as everything in nature has a start, there’s also an end, and this is how PiVPN ends its journey.
Die Repositories sollen archiviert werden, bleiben aber weiterhin verfügbar. Das Projekt möchte er an niemanden übergeben, da er niemandem vertraut. Möchte man das Projekt weiterführen, so solle man es forken und unter anderem Namen fortsetzen:
„But I want and can maintain it, can I take it over?“ Let me put it plain and simple: No! I don’t know you, I don’t trust you! Fork it and carry on!
Nach ein wenig Community Feedback möchte der Maintainer nun doch auf „Best-Effort“ Basis weitermachen – selbst aber keine größeren Features mehr beisteuern.
Auch das ist „Open Source“, man hört auf, wenn man nicht mehr kann oder will, übergibt das Projekt aber nicht so einfach an einen Dritten, der dann den „Trust“ des Projekts übernehmen und ggf. missbrauchen kann. Ob das eine Entscheidung nach den Vorkommnissen bei der XZ Library ist?
Schmunzelecke
Dave Plummer beschreibt auf Twitter (link zum Screenshot bei pr0gram.com), wie er 1994 den „Format“ Dialog als „temporären Workaround“ designte. Der Designvorschlag ist heute immer noch in Verwendung – es hält einfach nichts länger als ein Provisorium.
💡 Link Tipps aus der Open Source Welt
Aider – AI Development Companion für die CLI
Aider ist ein AI CLI Tool, dass dir als Pair Programming Companion bei der Entwicklung hilft. Aider kann nach Übermittlung des Prompts nicht nur Code schreiben, sondern auch gleich den Code mit anständigen Commit-Messages in ein Git Repository committen.
Im Demo-Video siehst du ein paar Beispiel-Implementationen mit Python und Javascript. Du benötigst einen OpenAI API-Key für den Start und eben aider installiert.
Ganz witzig: aider kann über Playwright auch Websiten scrapen und verarbeiten oder per Voice Code-Änderungen beauftragen.
https://github.com/paul-gauthier/aider
Redka – Redis in SQLite
Redis in SQLite? Das hört sich etwas verrückt an – redka möchte aber genau das erreichen. Das redka Projekt ist noch recht und aktuell als Version 0.2 erhältlich.
In Zukunft soll es die 5 Standart Redis Typen – strings, lists, sets, hashes und sorted sets – unterstützen.
Warum? Das Ziel der beiden Entwickler ist, dass die Daten dann eben nicht im RAM gehalten werden müssen und eben auch ACID Transaktionen von SQLite supporten.
Im Performance-Vergleich in der aktuellen Version ist redka dann 2-6 mal langsamer als Redis selbst – kein Wunder, Redis ist halt in-memory und die Auslagerung auf die Disk erfolgt nachgelagert und asynchron. Trotzdem erreicht redka 22.000 Writes/Sekunde oder 57.000 Reads/Sekunde, was auf jeden Fall beeindruckend ist.
Die Roadmap findest du unter diesem Link – Strings und Hashes gibt es schon, Lists und Sets fehlen noch.
https://github.com/nalgeon/redka
❓ 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: