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:
Willkommen zu allesnurgecloud.com – Ausgabe #113!
Da ist sie nun, die prall gefüllte Urlaubs-Ausgabe. Wie schon angekündigt, mache ich für 2 Wochen eine Sommerpause – die nächste Newsletter-Ausgabe erhältst du dann am 3. September.
Im Podcast kannst du mich aber weiterhin hören, in der aktuellen Folge habe ich Merlin Roth von der Agentur Akubu.de zu Gast. Merlin und sein Co-Founder wollten ursprünglich nur Produkte bauen, mussten dann aber einen Pivot zur Agentur machen. Und jetzt, einige Zeit später, bauen sie die Agentur wieder zur Produkt-Company um – coole Story und interessante Produkte. Oder weißt du, was BGM und BEM ist?
Natürlich kannst du die Sommerpause auch nutzen, um alte Folgen nachzuhören .
Falls du Interesse hast, im Newsletter oder Podcast Werbung zu buchen, kannst du das auf passionfroot machen, das teste ich nun mal.
Remote: Verpflichtenden Rückkehr ins Büro erhöht Fluktuation
Die erzwungene Rückkehr ins Büro nach der Pandemie hat sich als problematisch erwiesen. Mehrere Berichte verdeutlichen die negativen Auswirkungen dieser Maßnahme. Unispace hat herausgefunden, dass fast die Hälfte der Unternehmen mit Büro-Rückkehr-Mandaten eine höhere Mitarbeiterabwanderung erleben als erwartet, während fast ein Drittel Schwierigkeiten bei der Rekrutierung hat. Unternehmen waren möglicherweise auf etwas Mitarbeiterfluktuation vorbereitet, aber nicht auf diese gravierenden Probleme.
Greenhouse stellt fest, dass 42% der Bewerber Stellenangebote ohne Flexibilität ablehnen würden. Im Gegenzug bestätigt die SHED-Umfrage, dass Mitarbeiter, die ein paar Tage pro Woche von zu Hause aus arbeiten, diese Vereinbarung sehr schätzen.
Die Prioritäten der Mitarbeiter laut Greenhouse-Bericht sind:
- Höhere Vergütung (48%)
- Größere Jobsicherheit (34%)
- Karrierechancen (32%)
- Bessere flexible Arbeitsrichtlinien (28%)
- Positivere Unternehmenskultur (27%)
Mit anderen Worten, abgesehen von karrierezentrierten Faktoren wie Gehalt, Sicherheit und Beförderung steht flexible Arbeit an erster Stelle in den Prioritäten der Mitarbeiter.
Unispace betont einen weiteren Faktor: die Wahlmöglichkeit. Mitarbeiter, die sich freiwillig für die Rückkehr ins Büro entscheiden, zeigen positive Gefühle wie Glück (31 %), Motivation (30 %) und Begeisterung (27 %). Bei denen, die zur Rückkehr ins Büro gezwungen werden, sinken diese Zahlen auf 27 %, 26 % bzw. 22 %.
Reale Beispiele bestätigen diese Erkenntnisse:
- Ein regionales Versicherungsunternehmen mit 2.000 Mitarbeitern erlebte steigende Abwanderungsraten, nachdem es eine Büro-Rückkehr-Politik erzwungen hatte. Die Lösung war ein hybrider Ansatz, der die Mitarbeiter stärker einbezog und auf Zusammenarbeit und Mentoring setzte – die Abwanderungsraten sanken.
- Ein großer Finanzdienstleister bemerkte ebenfalls erhöhte Mitarbeiterfluktuation, obwohl er wettbewerbsfähige Gehälter und Karrieremöglichkeiten bot. Eine interne Umfrage ergab, dass flexible Arbeitsrichtlinien neben besserer Bezahlung und Karrierechancen ein entscheidender Faktor für die Mitarbeiter waren
- Ein SaaS-Start-up passte sich dem Wandel an und führte flexible Arbeitsrichtlinien ein. Das Ergebnis war ein deutlicher Rückgang der Mitarbeiterfluktuation und ein Anstieg der Bewerbungen.
Angesichts dieser Veränderungen dürfen wir die menschlichen Elemente nicht außer Acht lassen. Unternehmen müssen sich anpassen und eine Arbeitsumgebung schaffen, die Mitarbeiter im Zeitalter der Flexibilität anzieht und bindet.
Meiner Meinung nach gibt es verschiedene Möglichkeiten, auf die neue Herausforderung zu reagieren. Das deutsche SaaS Unternehmen Billbee hat beispielsweise schon vor längerem eine 30h-Woche eingeführt, 100 % remote, 30 Urlaubstage. Die Anzahl der Bewerbungen sind explodiert – In Folge 4 von „Happy Bootstrapping“ hab ich mit David Pohlmann, CEO von billbee, unter anderem darüber gesprochen, wie genau das in der Praxis funktioniert und warum man bei Bilbee nun 5 Tage mit 6 Stunden arbeitet und nicht wie initial angedacht 4 Tage mit 8 Stunden (Infos bei ihm auf Linkedin).
HashiCorp ändert Lizenz auf BSL
Nach Redis, MariaDB, Elastic, CockroachDB und Sentry ändert nun auch HashiCorp seine Lizenz. Die vorherige Lizenz war die Mozilla Public License v2.0 (MPL 2.0), nun wechselt man zu der Business Source License (BSL oder BUSL).
Was heisst das genau?
Die neue Lizenz schränkt den „Commercial Use“ von HashiCorp Produkten ein – der „Personal Use“ ist davon nicht betroffen:
BSL 1.1 is a source-available license that allows copying, modification, redistribution, non-commercial use, and commercial use under specific conditions.
….
End users can continue to copy, modify, and redistribute the code for all non-commercial and commercial use, except where providing a competitive offering to HashiCorp. Partners can continue to build integrations for our joint customers. We will continue to work closely with the cloud service providers to ensure deep support for our mutual technologies.
Es gibt neben dem verlinkten Blog-Artikel eine ausführliche FAQ bei HashiCorp.
Kelsey Hightower hat die Beweggründe auf Twitter vielleicht ganz passend zusammengefasst:
As these projects become more complex we have to be honest regarding how much money is required to sustain them. Relying on volunteers isn’t going to cut it.
Den kompletten Thread mit vielen Antworten von Kelsey findest du hier.
Wie siehst du das Ganze?
Das Cloud-Provider Open-Source Produkte nutzen, um eigene Services zu bauen und zu verkaufen, ist ja bekannt.
Kann dieser Move helfen?
ist man bereits zahlender Kunde von HashiCorp, oder hat man eine andere Vereinbarung mit den Kollegen getroffen – so ist man nicht betroffen.
HashiCorp adopts Business Source License
Sponsored
Wir kümmern uns um deine Infrastruktur – 4 Stunden kostenlos
Wir helfen Dir beim 24×7 Betrieb, bei Performance Problemen, bei Kostenoptimierung oder einfach beim Betrieb Deiner Web-Applikationen.
Betreibst Du Services wie 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 everysize.com – eine Sneaker-Suchmaschine mit Preisvergleich und Community.
Eugen Falkenstein, CEO von Everysize sagt beispielsweise über uns:
We Manage ist für uns ein optimaler Partner zur zuverlässigen Unterstützung unserer Web Applikationen und das 24/7. Neben kompetenter und zuverlässiger Beratung sind wir vor allem für die schnelle und direkte Kommunikation dankbar
Mit unseremaktuellen Angebot erhältst Du die ersten 4 Stunden gratis– 1 Stunde für die Analyse Deiner Infrastruktur und um zu schauen, ob und wie wir dir helfen können.
Die ersten 3 Stunden einer folgenden Beauftragung sind dann für dich kostenlos.
„Alles außer technische Schulden“
Im verlinkten Artikel im Blog von Honeycomb geht es um eines meiner Lieblingsthemen: „Technische Schulden“.
Die Wahrnehmung von „Tech Debt“ variiert oft innerhalb von Engineering-Teams. Engineers und Entwickler sind oft frustriert, da sie glauben, zu wenig Zeit für das Beheben von Tech Debt zu haben. Produktverantwortliche fragen sich wiederum, warum man so viel Zeit darauf verwenden soll. Die Unternehmensführung drängt häufig darauf, dass Ingenieure sich weniger darauf konzentrieren und stattdessen Wert für Kunden liefern sollten. Dennoch befürchten viele Führungskräfte im Engineering, dass ihre Teams möglicherweise zu wenig in Tech Debt investieren und das langfristig das Geschäft negativ beeinflussen könnte.
Es scheint, als ob es Missverständnisse im System gibt.
Das Problem mit „Tech Debt“ liegt teilweise in der vagen Begrifflichkeit. Fast jede technische Arbeit wurde schon einmal von jemandem als „Tech Debt“ bezeichnet, der sie nicht mochte. Die möglichen Gründe für das Beheben von Tech Debt können variieren. Ist diese Unschärfe der Grund für die Schwierigkeiten in diesen Gesprächen?
Im Hinblick auf spezifische Bereiche von Tech Debt, wie Investitionen in Tool-Chain, Zuverlässigkeit und Rework, gibt es oft interne Diskussionen. Ein präziseres Vokabular könnte hier helfen. Zum Beispiel könnten Service-Level-Objectives (SLOs) als Methode für Erhöhung der Reliability genutzt werden, indem klare Erwartungen für die Performance eines Dienstes gesetzt werden.
Dies erlaubt den Stakeholdern eine klarere Abwägung: Soll in die Zuverlässigkeit investiert werden oder ist eine geringfügige Reduzierung der Zielerreichung akzeptabel?
In ähnlicher Weise kann die Bezeichnung „Rework“ oder „Refactoring“ bei der Überarbeitung von schwierig zu wartendem Code helfen. Für den Erfolg eines Refactorings muss es nicht nur abgeschlossen werden, sondern auch die Lesbarkeit und Wartbarkeit verbessern. Die Messbarkeit solcher Maßnahmen ist allerdings schwierig.
Obwohl „Tech Debt“ als Begriff selten hilfreich ist, wenn es darum geht, das nächste Projekt zu rechtfertigen, bleibt die Vorstellung von „Schulden“ in der Softwareentwicklung wichtig.
Schulden müssen wir irgendwann zurückzahlen, und wir Zahlen eben auch Zinsen auf die Schulden, das ist bei Software nicht anders.
Warum ist DNS immer noch schwer zu lernen?
Julia Evans Blog hatte ich hier schon öfters mal erwähnt. Neben ihren coolen und hilfreichen „Zines“ schreibt sie auch hervorragende Artikel in ihrem Blog, diesmal einen zu DNS.
Sie versucht zu erklären, warum DNS, welches wir seit über 35 Jahren verwenden, eigentlich so schwer zu verstehen ist.
Als möglichen Grund sieht sie, dass viel im System verborgen ist. Man könnte nicht den Cache des Resolvers sehen oder wie die Kommunikation mit autoritativen Nameservern erfolgt. Das könnte das Debuggen schwierig machen.
Außerdem könnten es einige „gotchas“ in DNS geben, die häufig auftreten könnten, aber schwer zu lernen sein könnten, z.B. negatives Caching oder unterschiedliche Implementierungen von „getaddrinfo“. Wir könnten bessere Werkzeuge entwickeln, um diese Aspekte klarer zu machen.
Die unregelmäßige Exposition gegenüber DNS könnte auch ein Faktor sein. Die Menschen könnten oft nur selten mit DNS zu tun haben, was das Lernen erschweren könnte. Wir könnten Spickzettel und leichtere Werkzeuge nutzen, um hier zu helfen.
Insgesamt bräuchten wir möglicherweise bessere Ressourcen, die die verborgenen Aspekte von DNS klären, mehr Bewusstsein für mögliche Stolperfallen und Tools, die das Debuggen erleichtern könnten.
Dein DNS Wissen kannst du übrigens hier bei ihren Zines testen.
Why is DNS still hard to learn?
AWS: Hintergründe zur Entstehung von AWS S3
Andy Warfield, VP and distinguished engineer bei AWS zum Thema S3, hat bei der USENIX FAST ‘23 Konferenz einen Vortrag zur Entstehung von S3 gehalten. Der Vortrag auf Youtube ist über 53 Minuten lang – der verlinkte Artikel ist eine ebenfalls sehr ausführliche Beschreibung, wie es damals zur Entstehung von S3 kam und wie das Ganze heute aufgebaut ist.
Ein paar Zahlen und Fakten zu S3:
- S3 hält über 280 Billionen Objekte (Stand Juli 2023)
- Im Mittel prasseln 100 Millionen Requests pro Sekunde auf die S3 Infrastruktur ein
- Jeden Tag sendet S3 über 125 Milliarden Event Notifications an andere AWS Services
- S3 Replication bewegt über 100 PB pro Woche
- Jeden Tag werden 1 PB an Daten aus den Archivspeichern Glacier geladen
Zur Speicherung verwendet AWS hier klassische Disks mit aktuell bis zu 26 TB. In den nächsten Jahren sollen Disks bis zu 200TB Speicher erreichen – das war mir gar nicht so ganz klar. Eine spannende Herausforderung von AWS ist daher die gleichmäßige Verteilung der Daten auf sämtliche verfügbaren Disks („mehrere Millionen“ laut Artikel).
Neben den ganzen technischen Details finde ich das Thema „Ownership“ spannend. Andy nennt dies als einen, wenn nicht den Erfolgsfaktor der ganzen Geschichte:
Ownership carries a lot of responsibility, but it also carries a lot of trust – because to let an individual or a team own a service, you have to give them the leeway to make their own decisions about how they are going to deliver it.
Andy erwähnt aber auch, dass das Thema ordentlich schiefgehen kann, wenn man „Ownership“ falsch mache. Er schließt den Artikel im Fazit mit der Aussage, dass die Skalierung der Organisation und der Prozesse selbst genauso aufwendig sei, wie die Skalierung der Technik selbst.
Building and operating a pretty big storage system called S3
imgproxy: Ausgliederung in eigene Firma
Wie der regelmäßige Leser weiß, bin ich großer Fan und Anwender von imgproxy.net – einer Engine für Bildoptimierung und Änderung. Mit imgproxy kannst du Bilder on-thy-fly, im web-request, anpassen.
Die Firma hinter imgproxy, Evil Martians, hat nun bekannt gegeben, imgproxy in eine eigene Firma auszugliedern. Mit 23 Millionen Downloads und 7.300 GitHub seit das Projekt jetzt groß genug, um auf eigenen Beinen zu stehen. Imgproxy soll in Zukunft einfach bei AWS, Google und Azure in den jeweiligen Marktplätzen verfügbar sein.
Man sieht trotz der vielen SaaS Angebote eine rosige Zukunft, da SaaS nicht immer die beste Wahl für das eigene Produkt sei:
Images are often considered as protected information, so you can’t trust a third party with them. Or your business is just too big and using a SaaS charging per image transformation is unbearably costly. Sometimes you want to bring your image processing closer to the edge for more performance
Falls du wissen möchtest, wie man imgproxy at scale verwendet, kannst du gerne bei der PHP User Group der Metropolregion Rhein-Neckar vorbeischauen – am 31.08.2023 halte ich ein Vortrag zu Thema imgproxy (hier bei meetup anmelden). Und bei der stackconf in Berlin (13-14. September 2023) wäre deine zweite Chance auf den Vortrag.
imgproxy goes solo: unveiling a bold future for this new company
AWS: IPv4 Adressen finden
In der letzten Ausgabe hatte ich darüber berichtet, dass AWS sich ab Februar 2024 die Nutzung von IPv4 Adressen bezahlen lässt.
Im „Cost and Usage Report“ gibt es nun neue Funktionen, die es dir einfacher ermöglichen, all deine IPv4 Adressen zu finden.
Irgendwie ist es nicht verwunderlich, dass man dafür eine solch ausführliche Erklärung braucht.
Der Artikel im AWS blog zeigt aber auch, wie man beispielsweise die Architektur eines NAT Gateways optimieren kann, damit es durch Zusatzkosten nicht noch teurer wird.
Identify and optimize public IPv4 address usage on AWS
ilert: AI für Incident Kommunikation
Das Incident Management und Alerting SaaS ilert (Disclaimer: ilert war schon mal Sponsor im Newsletter) hat wohl als erster AI Technologien in den Incident Prozess eingebaut.
Aktuell können verschiedene Modelle genutzt werden (gpt-4, gpt-3.5-turbo, il-LLaMA-1), um Meldungen für die Statuspage schnell und effizient zu erstellen.
Wie das funktionieren kann, sieht man in den Docs relativ gut – nach Eingabe von „Spacex services unavailable“ macht ilert via AI daraus einen sprachlich korrekten 2 Zeiler.
Schließt man den Incident wieder, wählt man die „affected Services“ aus und diese werden im Text des Statusupdate dann ebenfalls erwähnt.
Das ilert Team möchte die Nutzung von AI Services weiter intensivieren – in Zukunft soll man Postmortem Einträge mithilfe von AI erstellen können.
Harness the power of generative AI
Schmunzelecke
Microsoft Teams Channel können keine MS-DOS Device Names enthalten. COM1, LPT1 und desktop.ini geht ebenfalls nicht.
Lustiger Thread dazu bei Hacker News.
Der Quake2 Rerelease Source Code von 2023 wurde von id-Software auf GitHub neu released.
💡 Link Tipps aus der Open Source Welt
Hydra: Column-oriented Postgres extension
Hydra ist eine Open-Source PostgreSQL Extension, welche die Verarbeitung von Analytics Daten in PostgreSQL massiv beschleunigt (Hydra Website).
Die Daten werden Colum-based abgelegt – und aggregierte Daten können laut eigenen Angaben bis zu 283-1412 mal schneller abgerufen werden, als in PostgreSQL selbst.
Öffentliche Benchmarks findest du hier bei ClickBench.
Seit Anfang August ist Hydra 1.0 in einer Beta-Version released worden. Du kannst Hydra in einer der angebotenen SaaS Varianten starten oder via docker bei dir lokal ausprobieren.
https://github.com/hydradatabase/hydra
SRE Checklist bei GitHub
Im verlinkten Repo auf GitHub findest du eine SRE-Checkliste – mit Prozessen, Tool-Tipps und Vorschlägen für Rollen und Ziele von SRE Teams.