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:
Naht das Ende der Remote Arbeit?
Im verlinkten Artikel bei „The Pgramatic Engineer“ schreibt Gergely Orosz über die Wahrscheinlichkeit einer „Return to Office“ Welle. Wie die meisten sicherlich wissen, hat Elon Musk bei Twitter diverse Policies kassiert – Mitarbeitende müssen mittlerweile wieder 5 Tage der Woche im Büro arbeiten.
Ansonsten gibt es weitere RTO Bewegungen:
- bei Apple arbeiten die Mitarbeiter seit September wieder 3 Tage der Woche im Büro
- beim Streaming Anbieter DAZN wurden die Mitarbeiter zum 4. Dezember 4022 zurück ins Office gerufen – angekündigt am Freitag, 2.12.2022 – Gerüchten zufolge möchte man damit die Anzahl der Mitarbeiter verringern, ohne einen Layoff.
- Bei Guidewire Software, einem Anbieter für Versicherungssoftware mit Sitz in Kalifornien, sollen die Mitarbeiter wieder 4 Tage der Woche ins Büro kommen
- Google: Mitarbeiter sollen wieder 3 Tage zurück ins Büro – machen es laut Angaben im Artikel nicht – weiß hier jemand mehr?
- Datadog: 3 Tage/Woche – vor allem für neue Mitarbeiter. Andere, früher eingestellte Mitarbeiter, haben scheinbar Remote Veträge, die man nicht so einfach ändern kann
- Bloomberg: 3 Tage/Woche zurück ins Büro.
Gergerly erwartet, dass die meisten US-Tech-Companies ihre Mitarbeiter im Schnitt 3 Tage/Woche im Büro sehen möchten.
I expect to see more tech companies mandate a 3 days/week return to office. Businesses which will most likely do this are those like those in this article: large tech companies with hundreds or thousands of employees and office space they intend to make use of.
Klar, wenn die Bürofläche da ist, sollte sie nicht leer stehen. Oder man zahlt halt einfach keine Miete mehr, dann wird man auch die teuren Büros los.
Laut einer Statistik des Business Insider waren vor der Pandemie in den amerikanischen Großstädten 95 % der Büros besetzt. Aktuell sollen nur noch um die 47 % davon besetzt sein. Erleben wir nun auch einen Office-Leerstand und die Rückkehr von Loft Wohnungen?
Es ist schwer zu beurteilen, bei manchen Entscheidungen hängen wir den Amerikaner ein Stück weit hinterher – andere Themen setzen wir nicht um oder ändern sie nicht mehr. Bestehende Arbeitsverträge, so kurzfristig wie oben beschrieben, wieder zu ändern – ist sicherlich schwierig. Fachkräftemangel trägt seinen Teil zur Flexibilisierung des Arbeitsortes bei. Ins Büro gehen, um in Online-Meetings rumzuhängen? Finde ich persönlich schwierig. Im Büro die Kolleg:innen sehen, gemeinsam in der Kaffeeküche stehen, Mittagessen oder ein Bierle nach der Arbeit – super gerne.
The Scoop: A Return to the Office (RTO) wave?
Tipps für asynchrone Entscheidungsfindung
A propos Remote-Arbeit – für manche Themen hilft es ja schon. Asynchrone Arbeit geht hier nochmal einen Schritt weiter.
„This Meeting could have been an E-Mail“ – da gibt es mittlerweile T-Shirts und Tassen dazu (Siehe auch meine Wunschliste 🙂 )
Im Async Blog von Twist steht im verlinkten Artikel hierzu provokant:
90% of decisions can be made async
Peter Yang gibt 5 Tipps für erfolgreiche, asynchrone Entscheidungen:
- Loop in the right people – Klar, man braucht die richtigen Leute dazu – und auch nicht zu viele davon
- Give full context: Man benötigt alle nötigen Details: Menschen, Zeitleiste, eigene Empfehlung, Zusammenfassung und Herleitung der Empfehlung, andere Optionen und kurze Erklärung, warum sie keine Option sind.
- Keep the discussuon in one place: Die Diskussion zum Thema an einem Ort halten, ohne Medienbrücke – Klar, das Twist Blog empfiehlt dafür Twist selbst – man sollte die Diskussion nicht über Chats, Dokumente und E-Mails verteilen.
- Push for a decision: Eine Entscheidung sollte man erreichen – man kann diese auch vorgeben und nach Einwänden fragen
- Document the decision: Die Entscheidung sauber dokumentieren und mit dem restlichen Team sharen – Erhöhung der Transparenz und Nachvollziehbarkeit
In einem Beispiel findet sich eine Vorlage für eine mögliche Abschaltung von „Twitter Fleets“ (Twitter, was? Genau, Fleets gab es mal.) zudem findest du noch eine Empfehlung für den erfolgreichen Ablauf von Meetings, dabei interessant:
If people haven’t read the document, spend the first 5 minutes of the meeting forcing everyone to read it themselves. Meetings should be a discussion, not a dog and pony show.
Exakt – Amazon geht hier mit den „Silent Meetings“ noch ein Stück weiter. Allerdings wäre es schon erstmal wünschenswert, wenn alle den gleichen Stand zu einem Thema haben, bevor man etwas diskutiert oder gar entscheidet.
How to make great decisions async (and avoid endless meetings)
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.
Postgres als Antwort auf alle Fragen
Redis als Cache, RabbitMQ als Queue, Elasticsearch für die Suche, MongoDB für JSON Daten und irgendein DBMS für relationale Daten. Warum nimmst du nicht eigentlich PostgreSQL für alles?
Stefan Schmidt hatte ich mit seinem Ansatz zu radikaler Einfachheit (Radical Simplicity) schon mal hier verlinkt – Stefan hat seine Gedanken nun nochmals in einem weiteren Artikel zusammengefasst. In der Regel reiche für einen Großteil der use-cases Postgres als Antwort auf die oben genannten Fragestellungen. Per Default kann PostgreSQL schon eine ganze Menge, und mittels Extensions ist es um weitere Funktionalitäten erweiterbar, wie beispielsweise „Timescale“ für Time-Series Datasets, PostGIS für Geodaten oder auch der GraphQL Adapter Graphjin.
Solch eine Strategie erleichtert die Fokussierung auf das Produkt und abstrahiert viele Probleme weg. Zudem kann man sich nur auf eine Technologie konzentrieren und muss nicht einen Technologie-Zoo verwalten. Betrieb und Administration sind auch deutlich einfacher, wie mit 6 verschiedene Technologien, das steht außer Frage.
Sein Vorschlag hat auf HackerNews für einige Furore gesorgt – ein Beispiel-Kommentar:
We needed a queue system and I wrote a postgres prototype in about 100 lines of code that would have worked fine for our use-case and would have likely scaled with us for years of growth.
My boss said he just wanted to install the best thing and be done with it forever. So we ended up spending 10x the time and wrote like 10x the code to integrate a third-party solution and we only ended up using the most basic features
Ja, genau – solche Lösungen meine ich. Wenn man diesen entwächst, kann man sich noch immer um eine dedizierte Lösung bemühen.
Just Use Postgres for Everything
Warum ein Incident Commander sinnvoll ist
Ein „Incident Commander“ kümmert sich während eines Incidents dediziert um Kommunikation, Eskalation, Dokumentation des Ausfalls und um das Stakeholder Management.
Er/Sie hat die Aufgabe, den Engineers den Rücken freizuhalten und den Direktzugriff von Stakeholdern auf Engineers zu unterbinden. Meiner Erfahrung nach ist die Rolle essenziell und super wichtig – gerade bei Ausfällen mit Außenwirkung ist die ständige Unterbrechung der an der Entstörung beteiligten Mitarbeiter destruktiv und trägt nicht zur schnellen Lösung des Incidents bei. Selber habe ich auch schon erlebt, dass durch externe Einmischung die Anzahl der Fehler noch erhöht oder die Lösung des Incidents verzögert wurde.
Zudem sind „Incident Commander“ als dedizierte Mitarbeiter häufig in der Lage, die Dokumentation und Kommunikation eines Ausfalls gegenüber Stakeholdern viel besser zu vertreten. In der Regel haben Sie auch die Möglichkeit, weitere Teams und Engineers zu einem Incident dazuziehen, sodass die Engineers keine Zeit in Warteschleifen verbringen.
Der verlinkte Artikel fasst Best Practices und ein möglicherweise nötiges Skillset für die Rolle eines Incident Commanders zusammen.
What is an Incident Commander in ITSM?
imgproxy: On-thy-fly Bild-Optimierung bei Schwarz
Mit dem Open-Source-Tool imgproxy kannst du Bilder on-thy-fly modifizieren und optimieren. Du kannst die Bilder nicht nur verkleinern und vergrößern, sondern auch schneiden, rotieren und mit „Watermarks“ versehen. Eine Übersicht über alle Features findest du hier.
Im verlinkten Artikel findest du einen Use-Case, wie wir imgproxy in der Schwarz IT auf unserer STACKIT Cloud betreiben. Wir verwenden imgproxy dort als Docker Container in einer automatisch skalierenden Cloud Foundry Instanz und modifizieren und optimieren damit die Bilder für alle digitalen Flyer von Lidl und Kaufland (Digital Leaflets). Im Monat liefern wir damit ca. 1 PB an Bildertraffic über unser CDN aus. Imgproxy wandelt die Bilder einmal um, das CDN cached die neu berechnete Variante dann anhand des HTTP Headers.
Falls dich weitere Details interessieren, hier auf YouTube findest du einen ca. 30-minütigen Mitschnitt von unserem SIT-Meetup zum Thema Web-Performance. Dort hatte ich im November das Thema etwas ausführlicher vorgestellt.
Neben ebay, Algolia und Substack setzt mittlerweile auch das Storage Angebot von Supabase auf imgproxy.
Melde dich gerne bei Fragen zu imgproxy oder dem genannten use-case.
Dynamic Image Optimization with imgproxy on STACKIT Cloud Foundry
Fragwürdiger Umgang mit Sicherheitsvorfall bei Obi
Der Ethical Hacker Jean Pereira hatte eine Sicherheitslücke an 45 Stadtverwaltungen und an die Baumarktkette Obi gemeldet. Obi hatte nach der Meldung Ende September 2022 erstmal nicht reagiert und später die Existenz der Lücke erstmal abgestritten.
Jean gab nicht auf und machte die Lücke dann in einem Video auf LinkedIn Video öffentlich, und dann kam es endlich zu einer Reaktion. Man nahm die vermeintlich unwichtige Seite offline – freunde.obi.de.
Auf OpenBugBounty gibt es Meldung vom 12. April 2018 zur Lücke – hier wurde ebenfalls nicht reagiert.
Schade eigentlich, OpenBugBounty ist sogar umsonst – und das mindeste, was man tun kann, ist auf freiwillige Meldungen auf der Plattform zu reagieren.
Im Google Drive Dokument wird auch die Stadt Neckarsulm genannt (bei mir um die Ecke) – laut der Timeline wurde die Lücke zeitgleich bei diversen anderen Stadtverwaltungen geschlossen – haben die etwa alle den gleichen Dienstleister?
Das Projekt security.txt hatte ich auch schon diverse Male erwähnt – vermutlich bringe ich das nun in jeder Ausgabe – bitte verwende auf Kundendaten verarbeitenden Webseiten die einfache Einbindung von security.txt als Kontaktmöglichkeit für freundliche Security-Researcher.
Wie ein Hacker die Baumarktkette Obi warnen wollte – und fast verzweifelte
Schmunzelecke
kubectl scale –replicas=100 – öhm, haben die wirklich schon so viele davon?
💡 Link Tipps aus der Open Source Welt
Open-Source Postgres Prometheus Exporter
Coroot-pg-agent ist ein open-source Prometheus Exporter für PostgreSQL Datenbanken. Um diese Informationen bereitzustellen, schaut der Agent auf die Statistiken von pg_stat_statements und pg_stat_activity und aggregiert diese.
Um die Locks auf andere Queries zu analysieren, prüft der Exporter zusätzlich pg_lock_awaiting_queries.
Zur Installation benötigt der Exporter die pg_monitor Rolle und eine aktivierte pg_stat_statements Extension – dann kann es auch schon losgehen.
https://github.com/coroot/coroot-pg-agent
ChatGPT Plugin für VSCode
Jetzt wirds wild – ChatGPT ist nun als Plugin für VSCode verfügbar. Über einen einfachen Rechtsklick kannst du deinen eigenen Code erklären lassen, ChatGPT nach Problemen im Code suchen lassen oder dir ein Refactoring eines Code-Ausschnitts vorschlagen lassen.
Alles, was du dafür benötigst, ist einen Auth-Cookie von ChatGPT – also einen User und einen erfolgreichen Login im System selbst.
https://github.com/mpociot/chatgpt-vscode
NAXSI: Open-Source WAF für nginx
NAXSI ist eine high-performance und open-source WAF für nginx. NAXSI steht für „Nginx Anti XSS & SQL Injection“.
NAXSI kommt mit einem Core Ruleset, welches bereits gängige Angriffe abdeckt. Dazu gibt es applikationsspezifische Regeln, beispielsweise für WordPress, Drupal oder auch Dokuwiki.