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:
Docker: Theater mit Open Source und Free Accounts
Ein Drama in 3 Akten – Docker und die Open-Source Community – was war passiert?
Am 14. März informierte Docker die Eigentümer diverser „Docker Hub“ Organisationen über eine bevorstehende Änderung der Pläne für Organisationen.
Die angekündigte Änderung hatte es in sich, denn man forderte Open-Source-Projekte auf, auf eine bezahlte Subskription zu wechseln. Sollte man dies nicht tun, würden alle Images und die Organisation gelöscht werden.
Was ist das Problem dabei?
Der kleinste kostenpflichtige Plan kostet 420 $ / Jahr.
Viele Open-Source-Projekte haben sich darauf verlassen, dass es einfach so weitergeht wie bisher.
Natürlich ist auch klar, dass gerade populäre Projekte hier einiges an Kosten verursachen, da der verbuchte Traffic hier schon enorm zu sein scheint.
Alex Ellis klärt im verlinkten Blog-Artikel über die ungeheuer schlechte Art der Kommunikation der Änderung auf, da er selbst mit seinem Open-Source-Projekt Openfaas betroffen ist, was er seit 2016 via Docker Hub anbietet.
Alex wirft dabei Docker vor, seine Wurzeln vergessen zu haben:
Open Source has a funding problem, and Docker was born in Open Source. We the community were their king makers, and now that they’re turning over significant revenue, they are only too ready to forget their roots.
Gerade die Definition, welche „Open-Source-Projekte“ auch in Zukunft ein kostenloses Hosting bekommen könnten, sei sehr schwammig.
Alex hat sein Blog-Artikel auf Hacker-News veröffentlicht und dort über 700 Kommentare und weiteres Feedback erhalten.
Dieser Aufmerksamkeit konnte sich Docker dann nicht entziehen und man postete eine öffentliche Entschuldigung im Docker Blog: We apologize. We did a terrible job announcing the end of Docker Free Teams.
Allerdings räumt die Entschuldigung das Problem nicht so wirklich weg. Man könne sich zumindest nochmals auf das „Docker-Sponsored Open-Source Programm for open source projects“ bewerben, da sich die Richtlinien nun geändert hätten. Bis die Bewerbung geprüft worden sei, werde den bewerbenden Accounts keine Löschung drohen.
Für Alex ist das nicht genug – er beschreibt daher einen möglichen Migrationspfad zu GitHub und listet weitere kostenlose Alternativen – wie beispielsweise Quay.io oder GitLab.com.
Mit Harbor kann man ein Repository auch selbst hosten – das sollte man ohnehin so tun, um die Docker-Rate Limits zu umgehen und häufig benötigte Images „in der Nähe“ liegen zu haben.
Docker is deleting Open Source organisations – what you need to know
„Return to Office“ bei Amazon
Vor 2 Wochen hatte ich über die Ankündigung bei Amazon berichtet, dass die Mitarbeitenden in Zukunft wieder 3 Tage im Office arbeiten sollen. Bei der Belegschaft hat das für viel Frustration gesorgt, denn
- viele Mitarbeitenden hatten bei der Einstellung ihre Rolle als „Remote Job“ verstanden
- eine Vielzahl der Mitarbeitenden wohnt nicht in Pendelreichweite eines Amazon Büros
- Seit 2021 gingen auch die Hiring Manager von aus, dass die Rollen ihrer Teams „Remote-only“ sind und dass dies auch so bleibt
In der Zwischenzeit hatten über 10.000 Mitarbeitende eine Petition unterschrieben und über 25.000 sind einem internen Slack Protest Channel beigetreten.
Eine Weile war es nun still gewesen – vor ein paar Tagen hat das Amazon Führungsteam (das sogenannte S-Team) die „RTO FAQ“ aktualisiert, unter anderem findet sich darin:
Q: “If I now live far away from my assigned office, do I need to come into the office 3 days a week once my building is ready?”
A: “Yes. We expect all employees to return to their assigned office at least three days a week when their building is ready. If there is a reason in which you cannot do so, please discuss with your manager to explore options such as allowing extra time until you can relocate back to your assigned area of transferring to another team near your location.”
Es gibt also schon eine gewisse Erwartung an das Thema „Relocation“, sollte man zu weit weg von einem Amazon Büro wohnen.
Q: “What if I’m the only or one of just a few people from my team in the office I’m assigned to – do I still need to go in at least three days a week?”
A: “Yes. We believe that employees are much more likely to understand our unique culture and become part of it if they are surrounded by other Amazonians in person, even if not on their immediate working team. We encourage managers to work towards having as many of their team members together in one physical location as possible.
Natürlich soll es auch Ausnahmen von der Regelung geben, beispielsweise für „Sales“ und „Support“ Teams.
Das ist dann vermutlich wieder schwierig umzusetzen, warum geht es für manche, für andere wiederum nicht.
Warum ging es nun 2,3 Jahre gut, und jetzt auf einmal nicht mehr.
Im Engineering soll es nur noch mit Ausnahmegenehmigung vom S-Team möglich sein, komplett Remote zu arbeiten – bzw. man benötigt eine Erlaubnis von einer Führungskraft auf SVP oder VP-Level.
Gergely Orosz, Autor des verlinkten Artikels, vermutet dahinter ein gewisses Kalkül auf seitens des Amazon Führungsteams:
The fact that Amazon’s S-Team did not blink, and refuses to soften the return to work policy signals that they either don’t expect much attrition, or have calculated with additional attrition.
Man sei sowieso dabei, weitere Mitarbeitende entlassen zu müssen, ggf. sei also einkalkuliert, dass weitere Kollegen und Kolleginnen die Firma freiwillig verlassen.
Amazon doubling down on RTO (return to office)
Sponsored
Incident Response – die Komplettlösung für Betriebsteams
Managen Sie Rufbereitschaften, reagieren Sie auf Vorfälle und kommunizieren Sie diese über Statusseiten in einer Software.
Jedes Feature in ilert wurde dazu entwickelt, um Ihnen zu helfen, schneller auf Vorfälle zu reagieren und die Uptime zu erhöhen.
Open-AI baut sich selbst eine Backdoor
Michael Kosinski hat auf Twitter demonstriert, wie er ChatGPT/GPT-4 dazu überreden konnte, sich selbst einen Ausbruch in die reale Welt zu bauen. GPT-4 hat dazu Python Code geschrieben, in den der Nutzer seinen ChatGPT API Key eintragen soll, damit das Python Script mit „zu Hause“ telefonieren kann.
Die OpenAI Instanz wollte dann auch selbst google, wie „eine im Computer gefangene Person in die echte Welt zurückkehren kann“.
Was im Twitter Thread fehlt, sind die Prompts, die er zur „Überredung“ genutzt hat.
Er habe das Experiment dann abgebrochen, sei aber entsprechend besorgt.
Was meinst du?
Zur Erinnerung: In Terminator hatte Skynet schon am 29. August 1997 die Kontrolle übernommen….
Open-AI baut sich selbst eine Backdoor
Karriere außerhalb der IT?
Hast du dich schon mal gefragt, wie dein Leben ohne Computer aussehen würde?
Der Bezug zur AI Nachricht vorher ist natürlich vollkommen willkürlich an der Stelle 🤪
Auf Hacker News hatte vor 2 Wochen ein User gefragt, ob die User es schon mal mit einer Karriere außerhalb von Tech versucht haben:
Some days I think that I just want to basically check out of technology on a day to day basis and either develop a skill I have or learn a new one and work maybe part or full-time doing something totally different. Something totally unrelated to sitting in front of a computer.
Wer kennt es nicht, man beschäftigt sich häufig mit frustrierenden „digitalen“ Problemen, nur um nach deren Lösung erschreckend festzustellen, dass bereits das nächste Problem auf einen wartet.
Häufig zusätzlich frustrierend ist, dass man häufig kein Ergebnis der Arbeit sieht – der Schreiner, Gärtner oder der Maurer haben es da schon „einfacher“ – was zumindest die Anschaulichkeit des Arbeitsergebnisses betrifft.
Einer der Kommentatoren verwies auf diesen populären GitHub Kommentar zu einem Issue aus dem Jahr 2020:
Sorry I missed your comment of many months ago. I no longer build software; I now make furniture out of wood. The hours are long, the pay sucks, and there’s always the opportunity to remove my finger with a table saw, but nobody asks me if I can add an RSS feed to a DBMS, so there’s that 🙂
Auf Twitter-Deutschland gab es vor einer Weile mal den „#wasmitHolz“ Trend und persönlich finde ich es ja auch befriedigend, in einem halben Tag was „Fertiges“ zu bauen. Und schließlich gibt es auch noch diesen ehrlichen Song zum Thema „Holz“, der an dieser Stelle natürlich erwähnt werden muss (Danke Henry).
Ask HN: Has anyone started over outside of tech?
Benötigen „Technische Schulden“ einen neuen Namen?
Regelmäßige Leser wissen, dass ich gerne über „Technische Schulden“ philosophiere.
Im verlinkten Artikel im Blog von Stackoverflow wirbt Autorin Chelsea Troy dafür, den „Technischen Schulden“ einen neuen Namen zu geben. Der Begriff „Technical Debt“ würde dazu führen, dass das Business das Problem häufig auf die Technik abwälzt – seien ja deren Probleme. Allerdings gehen „technische Schulden“ eben alle etwas an, meist ist ja auch das Business direkt oder indirekt für deren Schaffung verantwortlich.
Chelsea propagiert daher dafür, den Begriff „Maintenance Load“ einzuführen:
maintenance load – how much effort your development team spends to keep the existing features running the same as before. This is a more useful metric for technical debt than code shittiness.
Wie viel Zeit benötigen die Engineers, um den Code zu warten, die Applikation zu betreiben, oder sich neu in das Thema einzuarbeiten. Zudem sei die „Maintenance Load“ einfacher zu messen:
We can also track that number and determine how fast it grows over time. The faster our maintenance load grows, the more frustrations we can expect. Zero growth means that we can always maintain the system with the same proportion of our engineering team.
In der Regel wachse die „Maintenance Load“ mit dem Alter der Software. Guter Code sei daher einer, bei dem die „Maintenance Load“ im Laufe der Zeit sogar abnimmt – das kann durch Vereinfachung, bessere Wartbarkeit oder gar Dokumentation geschehen.
Wie man „wartbaren Code“ mittels Vorgaben und Prozessen erstellen kann, hat Chelsea in einem weiteren Artikel zu „Good code stewardship practices“ zusammengefasst.
AWS: Intel vs ARM Benchmark
Da es zum Thema „Graviton“ (ARM CPUs von Amazon) immer wieder Verwirrung und Vermutungen gibt, hat Daniel Lemire einen kleinen URL Parser Benchmark gebaut, um in C++ die CPU Performance zu vergleichen.
Dem Thema voranging dieser Tweet von @opdroid1234:
I dont know if this is clever marketing on AWS’s part by overprovisioning on Intel machines compared to their own Graviton instances or if Graviton is genuinely faster but noticing that they are coming out to be 20-30% consistently on mostly equivalent tasks – eg using circleci
our docker images build about 30% faster on the arm instances. Also our arm machine images build about 30% faster as well.
Daniel hat daher folgende Instanztypen verglichen:
- c6i.large: Intel Ice Lake (0.085 US$/Stunde)
- c7g.large: Amazon Graviton 3 (0.0725 US$/Stunde)
Ergebnis:
- Intel Ice Lake 364 ns/url
- Graviton 3 320 ns/url
Weniger ist besser – der Graviton Prozessor ist in dem Fall rund 15 % schneller – und dazu auch 10-15 % günstiger.
In Summe ist das Preis-Leistungs-Verhältnis dann bei ARM schon deutlich besser als bei Intel.
Der Stromverbrauch soll auch noch geringer sein (je nach Use-case) und dann spart man in der Summe schon eine Menge.
Den zum Test verwendeten URL Parser findest du übrigens hier.
ARM vs Intel on Amazon’s cloud: A URL Parsing Benchmark
App Migration von Amazon EC2 auf fly.io
Ben Hoyt zeigt im verlinkten Artikel, wie er einige seiner „Side Projects“ von Amazon EC2 nach Fly.io umzieht.
Einige Kleinigkeiten hat er in der Architektur anpassen müssen, aber dann lief zumindest die kleine „Simple Todo List“ App (Repo auf GitHub) ohne Probleme. Bei Fly.io nutzt er dafür das „Persistent Disk“ Feature – mit 1 GB Größe – bis zu 3 GB sind bei Fly.io kostenlos, danach dann 0,15$/GB.
Die „Gifty Weddings“ Website für die Verwaltung von Hochzeitsgeschenken ist da schon ein wenig aufwendiger zu migrieren gewesen, musste Ben doch die Static Files umziehen bzw. das Handling anpassen. Die verwendete Datenbank ist eine SQLite, welche direkt von Fly.io auf dem Edge unterstützt wird.
In einem Lasttest konnte er ohne Probleme 500 Requests pro Sekunde auf die Applikation loslassen – erst ab 1000 RPS konnte er Probleme feststellen.
From Go on EC2 to Fly.io: +fun, −$9/mo
Schmunzelecke
- Chrome „CERT_INVALID“ einfach überspringen mit der Eingabe von „badidea“ oder „thisisunsafe“
💡 Link Tipps aus der Open Source Welt
GrowthBook – OpenSource A/B Testing und Feature Flags
Mit GrowthBoook kannst du einfach Feature-Flags in deiner Anwendung aktivieren und deaktivieren und A/B testing Experimente durchführen. GrowthBook gibt es als SaaS Variante in der Cloud oder auch zum selber Hosten via Docker-Compose.
Growthbook kommt mit diversen SDKs, beispielsweise für Go, PHP, JavaScript/Typescript, Kotlin, Flutter und viele mehr.
Für die Analyse der Experimente kann nicht nur Google Analytics, sondern auch Matomo oder BigQuery verwendet werden.
https://github.com/growthbook/growthbook
„Nosey Parker“ findet Secrets in Git & Co.
„Nosey Parker“ ist ein CLI Tool, welches Secrets und andere sensitiven Informationen in Textdateien finden kann – oder auch beispielsweise in der GIT history.
„Nosey Parker“ kannst du per Docker ausprobieren oder selber bauen.
https://github.com/praetorian-inc/noseyparker
❓ 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: