Willkommen zu allesnurgecloud.com – Ausgabe #150
Wow – 150 Ausgaben hab ich hier schon geschrieben – vielen Dank dir fürs Lesen und für das viele Feedback, dass ich hier erhalte.
Und auch ein herzliches Willkommen an alle neue Leser, die ihren Weg über den letzten Doppelgänger Podcast hier her gefunden haben.
Philipp und Pip hatten in Folge 369 die Atlassian Teams Studie diskutiert, die ich in Ausgabe 148 vorgestellt hatte.
Happy Bootstrapping Podcast
Im Podcast hatte ich diese Woche mal wieder ein Start-up, welches noch am Anfang steht – Mariana Schmitz macht mit Felicitares.de Rawfood Törtchen in München. Das sind leckere Torten, die nicht gebacken werden und ohne Einer und sonstige Zusatzstoffe hergestellt werden.
Wie genau das funktioniert und wie sie in Zukunft weiter wachsen will – das erfährst du in Folge 79 von Happy Bootstrapping.
Team Connections durch asynchrone Kurz-Videos erhöhen
Aus der Atlassian Teams Studie wollte ich ein Thema herauspicken, das ich echt interessant finde. Für eine Studie haben 44 Führungskräfte sich bereiterklärt, jede Woche ein kurzes Team Update zu sharen – am Montag, was die Woche anstehe, welche Prioritäten ein Thema habe, und welche Ziele für diese Woche wichtig seien. Am Freitag, pünktlich zum Wochenende, gab es Updates zum Status und Lob und Wertschätzung für erledigte Themen.
Das Besondere: Die Hälfte der Führungskräfte sollte die Informationen schriftlich teilen, die andere Hälfte ein kurzes Video aufzeichnen.
Die Teams gaben an, dass kurze, asynchrone Video Check-ins deutlich zur Verbindung zur Führungskraft und zu der Aufklärung über Ziele beigetragen haben. in Zahlen:
21% of team members felt more connected to their managers, 24% felt that they were getting more recognition for their efforts, and 25% reported that they had clarity on their goals for the week.
Im Artikel gibt es ein Vergleichsdiagramm, welches ich im Artikel hier angehängt habe. Vor allem auf das Thema Wahrnehmung, Vertrauen und Wertschätzung zählt das Video ein.
Im Atlassian Blog findest du am Ende des Artikels einen kleinen Leitfaden für das kurze Team Update – finde ich eine super Idee.
Gibt es so etwas in der Art auch bei dir im Team?
New research: Boost team connection (without scheduling another meeting)
Raiffeisen-Bank CIO: On-Premise günstiger als Cloud
In einem Interview von Inside-IT mit dem Niklaus Mannhart, dem CIO der Schweizer Raiffeisen Bank, gab dieser bekannt, dass man nicht nur wegen des Security Aspekts auf „On-Premise“ Systeme setze, sondern dass der Betrieb der eigenen Datacenter kostengünstiger als der Einsatz von Cloud sei:
On-Premises in unserem eigenen Rechenzentrum in St. Gallen, mit einem Backup in Gossau (SG). Wir haben dies mehrfach durchgerechnet und sind immer zum gleichen Schluss gekommen: Es ist am kostengünstigsten, wenn wir unser Kernbankensystem selbst betreiben.
Natürlich gäbe es auch Systeme, die man in der Cloud nutze oder dass man auch SaaS Tools verwende – aber das elementar wichtige Kernbankensystem läuft im eigenen Rechenzentrum. Man erfährt im Interview leider nicht, welche Datenbank bzw. System hier im Einsatz kommt – viele Banken haben ja Mainframe/AS400 Systeme genutzt und dann lässt sich sowas gar nicht in der Cloud betreiben.
Mannhart beschreibt zusätzlich, dass bei „berechenbaren, konstanten Kapazitäten On-Prem-Lösungen viel kostengünstiger als Cloud-Angebote seien“ – und das kennen wir ja schon von Ahrefs, Basecamp oder dem Gaming Anbieter Roblox.
Im Interview fehlen viele Details um Rückschlüsse auf das eigene Geschäft ziehen zu können – trotzdem fand ich das interessant. Wobei es in der Schweiz regulatorisch so ist, dass die Daten auch in der Schweiz bleiben müssen, dann ist die Provider Auswahl hier zusätzlich eingeschränkt.
On-Prem ist viel günstiger als die Cloud
Sponsored
Wir kümmern uns nachhaltig um deine Cloud-Infrastruktur
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.
Deployments und Rollouts bei AWS
In einem recht aktuellen Artikel aus dem May 2024 im Blog der Code Review SaaS Software Graphite werden verschiedene Informationsquellen zum Thema „Deployments und Rollouts bei AWS“ zusammengetragen.
Am Beispiel von AWS S3 mit einem SLA von 99,9% wird klar, dass Downtimes eigentlich keine Option sind – 4 Minuten und 20 Sekunden pro Monat dürfte ein AWS S3 down sein, ansonsten bezahlt AWS Geld zurück. Im Falle von S3 bei erreichen von 99,0% – 99,9% gibt es 10 % zurück, zwischen 95,0% und 99,0% gibt es 25 % Erstattung und bei einer Uptime von unter 95 % gibt es 100 % der Kosten zurück.
Eine SLA von 95 % würde in der Praxis bedeuten, dass der Service in einem Monat 1 Tag und 12 Stunden nicht verfügbar war. Das wäre schon harter Tobak, da kann man vermutlich auch schon 100% Geld zurück versprechen.
Ein Großteil der Logik von Deployments bei AWS ist daher komplett automatisiert – inklusive einem Rollback. Zuerst wird automatisiert in ein Pre-Production Environment deployed, dann Metriken wie Error Rate, CPU Nutzung, Health Checks, Memory Usage und weitere Metriken geprüft und verglichen. Sollten Ausreißer auftauchen wird die ganze Pipeline gestoppt und der On-Call informiert.
Interessanter Zusatz – die Pipeline checkt auch abhängige Dienste automatisiert – also vorgelagerte IaaS Services oder nachgelagerte Services, die vom eigenen Service abhängen.
Der Rollout erfolgt immer progressiv – das heisst immer auf einer kleinen Einheit – einem Host, einem Container, einem kleinen Anteil von Lambda Instanzen – und so weiter. Bei der Anzahl der vorhandenen Regionen kann man auch mit „kleinen Regionen“ starten, bevor man sich an größere wagt. Weiter geht es dann mit individuellen Zellen, Availability Zones und anderen gekapselten Einheiten.
Dadurch das alles automatisiert ist, kann man die Rollouts auch langsam durchführen und Pausen planen, damit man auch „neue Instanzen“ zu jeglichen Traffic Spike Zeiten mal online gesehen hat, und sich wirklich sicher sein kann, mit dem Rollout fortzufahren – bei AWS heisst das „Bake time“:
A typical pipeline waits at least one hour after each one-box stage, at least 12 hours after the first regional wave, and at least two to four hours after each of the rest of the regional waves, with additional bake time for individual Regions, Availability Zones, and cells within each wave.
Natürlich dauert dann der Rollout einer neuen Version oder eines neuen Service auch mehrere Tage – das nimmt man bewusst in Kauf, um die allgemeine Sicherheit deutlich zu erhöhen. Neue Feature Flags oder Konfigurationsänderungen werden mit dem gleichen Mechanismus deployed.
Interessant, wie man das alles erledigt – auch klar, dass man dafür eine gewisse Größe braucht, damit man solche Methoden anwenden kann. Will heißen – nur weil AWS das so macht, macht der gleiche Prozess nicht 1:1 bei einem selbst Sinn.
Down for less than four minutes a month: how AWS deploys code
Die Gefahren von öffentlichen CDNs
Im neuen Newsletter von Jochen (The Monospace Mentor) hab ich einen Artikel zu „Public CDNs“ gefunden und mir hier mal angeschaut.
Der Artikel ist zwar schon etwas älter zeigt aber klar die Schwächen bei der Verwendung eines CDN wie cdnjs für die Einbindung von Javascript Bibliotheken über 3rd Party URLs. Man muss dem Service vertrauen können und bekommt unter Umständen eine aktualisierte und ggf. gefährliche neue Version untergejubelt, wie die Polyfill Supply Chain Thematik zeigt.
Neben der ganzen Security Problematik exposed man seine User dadurch ja auch an diverse 3rd Party Services, ohne, dass diese dies in der Regel wissen. Das ist ebenfalls nicht so schön, da man nie weiß, was mit den Daten passiert bzw. man davon ausgehen kann, dass man selbst das Produkt ist, wenn man nicht bezahlt.
Der Autor des Artikel empfiehlt deshalb auch, lieber die nötigen Skripte selbst zu bauen und auszuliefern, anstatt jede Library komplett zu laden und dann nur einen Bruchteil davon zu nutzen. Weiterhin kann man mit modernen Webservern selbst einfache Caching Infrastrukturen (nginx-cache, Varnish, etc.) bauen oder ansonsten ein Paid CDN beauftragen. Er nennt hier Cloudflare, Fastly, Akamai und Cloudfront – ich schiele eher auf das immer beliebter werdende BunnyCDN aus Europa.
Public CDNs Are Useless and Dangerous
AT&T verliert 110 Millionen Kundendaten – via Snowflake?
Das amerikanische Telco-Provider AT&T hat bekannt gegeben, 110 Millionen Kundendaten verloren zu haben. Dabei sind nicht nur Telefonnummern verloren gegangen, sondern sämtliche Kommunikationsdaten der betroffenen Kunden. Also wann wer mit wem wie lange telefoniert hat, welche SMS man wann erhalten oder verschickt hat, und so weiter.
Der „Angriff“ erfolgte über eine „Cloud Datenbank“, welche nur mit Usernamen und Passwort geschützt erreichbar war keine Multi Factor Authentication oder sonstige Absicherungen. Laut dem SEC Filling bei der amerikanischen Börsenaufsicht wurden die Daten auf einer 3rd Party Cloud Plattform abgezogen und betreffen Datensätze vom 1. Mai 2022 bis zum 31. Oktober 2022.
Man war zwar schon am 19. April auf das Leck aufmerksam gemacht worden, verzichtete aber erstmal auf Wunsch der Behörden auf die Veröffentlichung. Das FBI hat mindestens 1 Person im Zusammenhang mi dem Vorfall verhaftet.
Laut einem Sprecher von AT&T ist die genannte „Cloud Datenbank“ eine Snowflake Instanz von AT&T, welche wiederum laut Snowflake nicht mit MFA abgesichert wurde (Quelle: Techcrunch). Wir erinnern uns – Anfang Juni wurde bekannt, dass um die 165 größere Kunden von einem Sicherheitsvorfall bei Snowflake betroffen waren und Kundendaten „verloren“ gingen.
Mir ist schleierhaft, wie man so amateurhaft mit Kundendaten umgehen kann und dann noch zusätzlich ohne vernünftige Absicherung der Daten arbeitet. Dass man seine Kundendaten in sämtlichen Clouds ablädt, damit man den „Mehrwert der Daten“ heben kann ist ja das eine, aber sie dann so stümperhaft abzusichern…Naja, ich hoffe, das wird eine ordentliche Strafe für die Firmen mit sich ziehen, damit andere sich an der Stelle mal hinterfragen und Daten entsprechend schützen.
Crooks Steal Phone, SMS Records for Nearly All AT&T Customers
CCC: 2FA via SMS ist noch immer unsicher
Passend zum obigen Thema hat der Chaos Computer Club (CCC) einen aktuellen Leak zum Thema 2FA-SMS veröffentlicht. Man war „zur rechten Zeit am passenden Ort“ und sei darüber an SMS Nachrichten mit über 200 Millionen 2FA Codes und Login-Links gelangt.
Die Daten gehören dem Provider IdentifyMobile aus Großbritannien, welches im Auftrag vieler Unternehmen, Banken, App-Entwicklern und anderen Betreibern SMS Nachrichten als zweiten Faktor verschickt. Häufig enthalten diese Nachrichten dann auch One-Click Logins in diverse Applikationen.
Der CCC schreibt im Leak aber auch, dass man zusätzlich zu den Codes in den meisten Fällen noch das Passwort des Users benötigt hätte. Und man weisst auch darauf hin, dass auch ein schlechter 2. Faktor zur Absicherung besser ist als gar keiner. Das zeigt ja auch der AT&T Vorfall mal wieder.
Ich denke es könnte hierbei viel helfen, wenn Apple und Google in ihren mobilen Betriebssystemen eine 2FA App Standardmässig integrieren würden und dem Nutzer auch erklären würden, wie das funktioniert. Meta, Amazon, DHL, Airbnb und Co. fallen ja auch auf SMS zurück, da es für den User das bequemste und einfachste ist.
Die Zeit und „Borns IT – und Windows-Blog“ berichten ebenfalls über den Sicherheitsvorfall und dessen Implikationen.
Zweiter Faktor SMS: Noch schlechter als sein Ruf
Was ist ein „Personal User Manual“?
Nun bin ich innerhalb einer Woche zweimal über das Konzept des „Personal User Manual“ gestolpert – Zeit, es sich mal kurz anzuschauen.
Ein Personal User Manual ist ein Handbuch über dich für andere – es beschreibt deinen Background, deine Werte und deinen Kommunikationsstil. Hier eine englische Beschreibung:
Personal User Manuals (also known as “Personal Operating Manuals”) are short descriptions of your background, values, and communication style. All team members should complete and exchange a Personal User Manual to help teammates better understand each other.
Finde ich ein spannendes Konzept und kann helfen, bestimmte Situationen zu vermeiden oder auch eine Erwartungshaltung von Beginn an klarzustellen. Im Grunde beschreibt es auch für andere, wie man am Besten mit einem selbst kommuniziert – also die typischen Do’s and Dont’s.
Im verlinkten Artikel wird auch genannt, dass man ein Format schon vorab klarstellen kann – oder dass man eben schlechte Nachrichten am liebsten direkt erhält und nicht über Dritte.
Damit das Konzept klarer wird – hier ein öffentliches Beispiel von Vercel CTO Malte Uber.
Er lässt darin auch die Hosen runter und sagt beispielsweise über sich selbst:
- I’m really bad at remembering names
- My style is to observe how orgs behave and adapt rather than force my style of work onto others
- I’m more of an early-morning-work person. Sorry Asia.
- KnowledgeGood: Framework, programming models, etc.Good: Web platformWeak: Applied CSS. Future: HopelessWeak: Infrastructure operations. Future: Teach me
Ich kann mir gut vorstellen, dass dies gerade für neue Kollegen ein super Einstieg ist, um eine neue Führungskraft kennenzulernen und eine Verbindung oder Vertrauen aufzubauen. Malte schreibt auch, dass er Kids hat, Snowboard fährt und auf Home-Automation steht. Hier hat man auch gleich mal einen Einstiegspunkt für ein persönliches Gespräch. Aber auch Führungsstil und Erwartungshaltung ist durch sowas deutlich klarer.
Das Thema finde ich schon interessant – hast du sowas in der Art auch schon über dich geschrieben bzw. gibt es sowas in deiner Firma?
What is a Personal User Manual?
PostgreSQL und UUID als primary key
Über UUIDv7 hatte vor einigen Ausgaben schon berichtet, Entwickler Maciej Walkowiak hat nun die Performance und Größen von Text Indizes mit UUID verglichen. In einem Beispiel ist eine normale „Text“ ID um 54 % größer und der Index sogar um 85 % größer.
Was mir nicht so klar war, das UUIDv7 format ist im Beispiel und mit PostgreSQL sogar 2 mal so schnell als das „normale“ UUIDv4 Format.
Aktuell benötigt man in PostgreSQL noch eine Library im Client, um UUIDv7 supported zu bekommen – es gibt aber einen Patch für Postgres und der native Support ist für Version 17 von Postgres angedacht – eine Beta gibt es schon.
PostgreSQL and UUID as primary key
Chrome, Edge, Brave und Linksys telefonieren nach Hause
Nicht nur E.T. telefoniert nach Hause sondern auch sämtliche auf Chromium basierende Browser und auch Linksys Router.
Ein Twitter User hat Informationen veröffentlicht, nach denen alle Chrome basierten Browser (auch der „sichere“ Brave) CPU, GPU und Memory Nutzungsdaten deines Systems über eine API für alle unter *.google.com laufenden Dienste bereitzustellen. Sprich, Google erhält die Daten der CPU und Memory Nutzung, wenn du dich in Gmail bewegst oder ein Google Meeting durchführst – nicht aber Zoom. Google nutzt diese Infos dann, um die beispielsweise in einem Meeting darzustellen und ggf. auch die Meeting Experience zu optimieren. Die API, die das im Browser ermöglicht, ist aber nur für Google selbst zugreifbar und im Tweet wird nun diskutiert, ob dies ein Wettbewerbsnachteil für andere Anbieter ist.
Am selben Tag wurde bekannt, dass die Linksys Velop Router die SSIDs und Passwörter sämtlicher konfigurierter WLANs über eine Schnittstelle im Klartext an AWS Server senden (Quelle: Stack Diary). Kann man sich nicht ausdenken, macht man aber. Die Sicherheitsforscher von Stack Diary haben Linkssys kontaktiert und um eine Stellungnahme gebeten, bisher aber nichts gehört.
Linksys Velop routers send Wi-Fi passwords in plaintext to US servers
Schmunzelecke
Ein Leser (Danke Torsten) hat die FAX KI aus der letzten Woche tatsächlich ausprobiert und mit folgendem, ironischen Prompt gefüttert:
Erstelle mir eine Lobeshymne auf eine künstliche Intelligenz namens Simple-Fax, welche mit der ultra-modernen Technologie Fax kommuniziert
Ein kleiner Auszug der Antwort:
O Simple-Fax, du kluges Wesen,
mit Papier und Toner stets genesen,
Im digitalen Zeitalter, so robust,
ein Technologierelikt, das man einfach lieben muss.
….
Kein Internet, kein schneller Klick,
braucht es für deine Magie, dein ganz spezielles Glück
Ach herrje, vielen Dank fürs Einsenden.
Die vollständige Antwort findest du hier als PDF.
💡 Link Tipps aus der Open Source Welt
Ente Auth als Google Authenticator Alternative
Die Google Fotos Alternativ Ente hatte ich schon mal empfohlen – Ente hat aber auch eine Authenticator App, die aktuell komplett kostenlos ist und mit einem End2End verschlüsselten Backup ausgestattet ist. Bei Google ist das nicht so, deshalb empfiehlt sich ein Umstieg auf die kostenlose Variante von Ente, falls das Thema für dich interessant ist.
Ente Auth ist aktuell noch kostenlos und bleibt es auch, für Mitglieder, die sich vor einer vielleicht in der Zukunft eine Konvertierung zu einem Paid Modell geben:
If in the future we convert this to a paid service, existing users will be grandfathered in. So please sign up @ ente.io/auth
Also, einfach hier anmelden und Konten aus dem vorherigen Auth Tool importieren.
Das Projekt selbst ist Open-Source und das GitHub Repo enthält alle Produkte in einem monorepo.
https://github.com/ente-io/ente
Pongo – MongoDB für PostgreSQL
In der letzten Woche habe ich die Popularität der MongoDB analysiert – nun gibt es mit Pongo ein Projekt, welches als NodeJS Library daherkommt und als Wrapper native MongoDB Queries nach PostgreSQL portiert. Du kannst also deine DB weiterhin als „Collections“ Storage mit den für Mongo typischen Abfragen nutzen – im Hintergrund erzeugt Pongo dann eine Tabelle in PostgreSQL und legt die Daten in JSONB Tabellen ab.
Ein paar Beispiele erklären auf GitHub die Funktionsweise – im Blog Artikel erklärt Autor Oskar Dudycz warum und wieso er Pongo gebaut hat.
https://github.com/event-driven-io/Pongo
❓ 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: