Willkommen zu allesnurgecloud.com – Ausgabe #125!
Letzte Woche habe ich es leider nicht geschafft, unter der Woche etwas für den Newsletter vorzubereiten, daher ist er ausgefallen.
Aus der Community kam ein interessanter Vorschlag, den ich gerne mal ausprobieren würde – eine Art asynchronen Ratgeber Q/A.
Hast du Fragen zu Cloud, Infrastruktur, Observability oder suchst du einfach nur Vergleichs-Erfahrungen oder Anwender einer bestimmten Technologie – schreib mir gerne eine E-Mail – einfach als Antwort auf den Newsletter.
Da ich logischerweise selber nicht alles weiß, würde ich Fragen mit in den Newsletter mit aufnehmen und dann schauen wir mal, wer die Fragen beantworten kann, ok?
Da eine Folge ausgefallen ist, habe ich zwei Podcastfolgen, auf die ich kurz hinweisen möchte:
- In Folge 48 war Albert Brückmann von Meminto Stories zu Gast – Albert war letztes Jahr bei DHDL zu Gast und du bekommst daher einen interessanten Einblick hinter die Kulissen der Show. Auch hat er für die Erstellung der Meminto Bücher schon früh mit Aleph Alpha zusammengearbeitet, das fand ich ebenfalls interessant
- Sammeln deine Kids oder du selbst Pokemon und Yu-Gi-Oh! Sammelkarten? Dann hör dir mal Folge 49 mit Tayfun Bayraktar von ReCollectibles.de an – Tayfun macht mit seinem E-Commerce Shop und den angebundenen Marktplätzen über 1 Million Euro Jahresumsatz mit Sammelkarten.
Den Podcast „Happy Bootstrapping“ kannst du übrigens direkt bei Spotify, Apple Podcasts und überall, wo es Podcasts gibt, abonnieren. Hör doch mal rein oder lass mir bitte eine Bewertung da – vielen Dank!
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:
Regionale Incidents bei AWS, Azure und Google im Vergleich
Der Pragmatic Engineer, Gergely Orosz, hatte vor einigen Wochen einen interessanten Artikel in seinem Newsletter. Er hat den Umgang und die Kommunikation von Google, AWS und Azure miteinander verglichen, und zwar anhand von jeweils 3 Incidents in diesem Jahr:
- 25. April 2023 – Die Google Cloud Region (europe-west-9) in Paris war für einen Tag offline, eine der Zonen (europe-west-9-a) für fast 2 Wochen. Details dazu im Incident Report.
- 13. Juni 2023 – Wenn AWS Probleme hat, dann in us-east-1. Die für AWS zentrale Region war 3 Stunden gestört – es waren 104 AWS Services betroffen. Und eben viele Kunden, beispielsweise Fortnite, die Bestellungen von Burger King und McDonalds, aber es traf auch Slack, Zapier und Vercel – Incident Details hier.
- 05. Juli 2023 – In Holland gab es einen heftigen Sturm und daraus resultierend einen „Fiber Cut“ – 25 % der Network Links zwischen den beiden Campus DC der Region „West Europe“ waren beeinträchtigt und damit diverse Service. Verschlimmert hatte die Situation, dass ein physischer Schaden aus dem Juni bisher nicht behoben war. Den Incident Report kann man nicht direkt verlinken – du musst dafür auf die Page hier gehen und dann bei Date „all“ auswählen und hier den Report vom 5. Juli ausklappen. Als Bonbon gibt es eine 23-minütige Videoerklärung hier drüben auf YouTube.
Im Screenshot siehst du, wie unterschiedlich die 3 Provider mit dem Thema Kommunikation des Incidents umgehen. Einzig bei Google ist der komplette Incident Report inklusive Historie noch online einsehbar. AWS hat den Incident Report nun umgebaut und eine Summary daraus gebastelt – die genaue Timeline kann man noch grob nachvollziehen – die Kommunikation zum Incident nicht mehr. Bei Azure kann man die Timeline heute gar nicht mehr nachvollziehen – Gergely schreibt, dass die Details zum Zeitpunkt des Incidents alle einsehbar waren – heute sind diese nicht mehr vorhanden und der Cronjob hat da sauber aufgeräumt.
Bei der anschließenden Kommunikation eines vorläufigen Incident Reports gibt es doch gehörige Unterschiede:
- Azure hat nach 3 Tagen einen „Preliminary Report“ veröffentlicht – dieser wurde dann aber gelöscht, sobald der Final Review veröffentlicht wurde. Azure ist der einzige Provider, der sich eine Deadline für die Veröffentlichung des ersten „Preliminary Report“ auf die Fahnen schreibt.
- Google hat 14 Tage benötigt, um den ersten „Preliminary Report“ zu veröffentlichen. Vielleicht war man hier auch etwas vorsichtiger, da man auch von einem DC Dienstleister abhing, der das DC betrieben hat. Da es ein Feuer gab, wird der Bericht der Feuerwehr sicherlich auch eine Rolle gespielt haben – so etwas dauert Zeit, bin mir daher nicht sicher, ob man die Fälle 1:1 vergleichen sollte. Google hat anders als Azure keine Deadline für die Veröffentlichung. Und auch Google entfernt den Vorläufigen Bericht, sobald die finale Version veröffentlicht wurde.
- AWS hat nach super kurzen 5 Minuten eine erste Version veröffentlicht – das ist wirklich verrückt kurz. Vermutlich muss man da mal etwas vergleichen, bin mir nicht sicher, ob die Kollegen das immer so schnell schaffen. Auch AWS hat keine Pflicht zur Veröffentlichung eines „Preleminary Reviews“, macht es aber, nennt das Dokument aber nicht so.
Beim Thema Postmortem gibt es dann gewaltige Unterschiede.
- Azure hat nach 14 Tagen ein Postmortem veröffentlicht, in dem Fall sogar mit Bildern zur Dokumentation des „Fiber Cuts“, da ein Baum umgefallen war. Gergely findet, dass man alle Items checken kann – Azure nennt Follow-up steps, damit sowas in Zukunft nicht mehr passieren kann, listet ETAs für abgeleitete Maßnahmen und deren Status. Azure listet auch Action Items, die noch nicht erledigt waren
- Google hat nach 2 Monaten ein finales Postmortem veröffentlicht – sehr detailliert, wie Gergely findet. Leider wurde ein wichtiges Detail in der finalen Version des Postmortems unterschlagen – 2 der AZs wurden scheinbar teilweise im gleichen physischen Datacenter (oder Brandabschnitt) betrieben. Gergely hatte dieses Detail bei Google moniert, aber keine Antwort erhalten. Ansonsten zeigt er sich sehr zufrieden mit der Transparenz, Google nennt im PM auch Designfehler, bzw. eine fehlerhafte Implementierung der Control Plane in dieser Region.
- AWS, ja, AWS – hat gar nichts veröffentlicht. Gergely hat dies bei AWS moniert und um eine Veröffentlichung gebeten, da er gerade an diesem Artikel recherchiert. AWS hat das Postmortem dann am 20. Oktober, über 4 Monate nach dem Incident, veröffentlicht.
Hier endet der „kostenlose“ Teil des Newsletters – ein Detail fand ich noch spannend: die Anzahl der öffentlichen Postmortems pro Provider in diesem Jahr:
- Google Cloud: Über 100 öffentliche Postmortems
- Azure: 15
- AWS: 1 (In Worten: eins)
Wie findest du das?
Wirst du lieber häufiger und transparent informiert?
Handling a Regional Outage: Comparing the Response From AWS, Azure and GCP
Skill Krise bei Slack – 1 Woche Shutdown zum Lernen
Das Slack Management hat sich entschlossen, Slack „eine Woche zu schließen“, damit die Mitarbeitenden (um die 3000) sich weiterbilden können. Man habe eine „Skill Krise“ ausgerufen und daher zu dieser Maßnahme gegriffen.
Slack gehört mittlerweile ja zu Salesforce, hier gibt es den „Ranger Status“ in der E-Learning-Plattform „Trailhead“. Bis zum Jahresende sollen alle Slack Mitarbeitenden den „Ranger Status“ erreicht haben. Man benötigt dafür 50.000 Punkte und ca. 40 Stunden Online-Learning. Bei den Modulen ist man nicht auf reine IT Themen beschränkt, es gibt auch Themen wie „die 4. Industrielle Revolution“ oder auch „Gesunde Ernährung“.
Wie siehst du das?
Eine ganze Woche E-Learning ist sicherlich ziemlich anstrengend.
Auf der anderen Seite: Zugriff auf eine E-Learning-Plattform oder andere Online-Kurse haben sicherlich viele. Aber wann nimmt man sich schon die Zeit dafür, die Dinge auch mal zu machen? Kann so ein 1-wöchiger Blocker hier helfen?
Grundsätzlich finde ich die Idee aber interessant, sich 1 Woche auf ein bestimmtes Thema zu konzentrieren. Produktweiterentwicklung, Hackathon, Sprint für technische Schulden – warum nicht auch so mit Weiterbildung?
Slack’s ‘Ranger Week’ of training could represent a growing trend
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 bloss 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.
Signal: Kosten der kostenlosen End2End Messaging App
Signal ist die weltweit am weitesten verbreitete wirklich private Messaging-App, und ihre kryptografischen Technologien bieten zusätzliche Datenschutzebenen jenseits der Signal-App selbst. Seit der Einführung im Jahr 2013 ist das Signal-Protokoll – die Ende-zu-Ende-Verschlüsselungstechnologie – zum De-facto-Standard für private Kommunikation geworden und schützt den Inhalt von Milliarden von Gesprächen in WhatsApp, Google Messages und vielen anderen Plattformen.
Signal hat in einem ausführlichen Blog-Artikel die Kosten zum Betrieb und der Weiterentwicklung von Signal offengelegt.
Signal selbst ist eine gemeinnützige Organisation, ohne Gewinnabsicht und ohne Investoren – und wird hauptsächlich von Spenden finanziert.
Die Signal-Server verarbeiten Milliarden von Requests pro Tag – und in der Regel wird solch eine Infrastruktur durch Ads finanziert – oder wie bei Meta nun durch ein Abo.
Die Kosten von Signal stellen sich folgendermaßen dar:
- Storage: $1.3 Millionen Dollar pro Jahr
- Servers: $2.9 Millionen Dollar pro Jahr
- Registration Fees: $6 Millionen Dollar pro Jahr
- Total Bandwidth: $2.8 $Millionen Dollar pro Jahr
- Additional Services: $700,000 Dollar pro Jahr
Man verwendet wohl Server und Komponenten von Google, AWS, Azure und anderen Providern, um die Last und Infrastruktur möglichst breit zu verteilen. Und obwohl die Bilder und Videos nur temporär gespeichert werden, kostet die Speicherung der Inhalte 1,3 Millionen Dollar pro Jahr – also etwas über 100.000 $ / Monat.
Der größte Posten – die „Registration Fees“, das sind tatsächlich Gebühren für den SMS Versand auf der ganzen Welt. Scheinbar haben die Telco Provider erkannt, dass SMS „nur noch“ für User Registration oder 2FA genutzt wird – und verlangen da nun wieder eher mehr Gebühren als früher.
Die Hälfte des Signal-Budgets geht an das Personal – 50 Vollzeit Mitarbeitende, die Apps entwickeln und Infrastrukturen betreiben und weiterentwickeln.
Laut Schätzungen benötigt Signal ab 2025 in Summe 50 Millionen Dollar pro Jahr, um weiterhin operativ die Messaging-Infrastruktur zu betreiben. Dies geht nur über Spenden – einmalig oder monatlich, da gibt es viele Möglichkeiten oder einfach direkt in der App.
Interessant, dass man hier so transparent alles darstellt – auf der anderen Seite hat man auch keine andere Chance, wenn man diesen Weg bestreitet.
Privacy is Priceless, but Signal is Expensive
OneUptime spart 230.000$/Jahr durch Cloud-Exit
Im Blog von OneUptime, einem relativ neuen SaaS und Open-Source Uptime Monitoring Service findet sich eine interessante „Cloud-Exit“ Story.
Natürlich ist die Kostenthematik prominent im Header und im Artikel auch dominant. Allerdings ist ein anderer wichtiger Fakt erwähnt – viele Kunden von OneUptime laufen selbst bei AWS, Google oder Azure – und auch wenn eine komplette Cloud Downtime unwahrscheinlich scheint, so möchte man doch einen unabhängigen Uptime-Service haben, sofern dies möglich ist.
Vor dem Exit hat OneUptime ein 28-Node Managed Kubernetes Cluster bei AWS mit m7a Instanzen genutzt. Inklusive Storage und Netzwerkgebühren betrug die (nicht rabattierte?) Rechnung 38.000 $/Monat. Man hat sich nun einen Co-Location-Partner gesucht und dort 40 HE reserviert, 2 HE Server gekauft und diese im DC deployed. Typischerweise bezahlt man bei einem solchen Housing Strom, Kühlung, Fläche und Remote-Hands, wenn sie denn zum Einsatz kommen. Mit der initialen Investition von 150.000 $ und 5,500 $ monatliche Kosten über 5 Jahre habe man eine Ersparnis von 230.000 $ – 55 % der AWS Kosten.
Backup erledigt man in die vorhandenen Office-Locations, ob die Kollegen Infrastruktur an 2 Locations betreiben wird im Artikel nicht klar, dort steht nur, dass man dies machen könnte. Man habe aber noch ein Backup Cluster in AWS verfügbar, welches in 10 Minuten ready wäre – Helm und k8s sei Dank. Wie kommen aber die Backup Daten dahin? Aus dem Office?
Interessant ist, dass der Autor Neel Patel erwähnt, dass die „Management“ Kosten der Infrastruktur deutlich geringer wären.
Neben den bereits erwähnten Tools Helm und k8s nutze man zudem „microk8s“ als Kubernetes Distribution, und betont, dass microk8s nicht nur für „Cloud-Edge“ Cases sinnvoll sei. Fileservices stellt das nfs-ganesha-server addon von microk8s bereit und der Loadbalancer kommt via MetalLB.
Bei Hacker News kommt der Artikel aktuell auf über 300 Kommentare, da ist alles Mögliche dabei. Der Thread Ersteller hat in keinem Kommentar geantwortet, soweit ich das sehen kann.
How moving from AWS to Bare-Metal saved us 230,000$ /yr.
Sovereign Tech Fund investiert 1 Million € in GNOME
Kennst du den Souvereign Tech Fund?
Ehrlicherweise kannte ich ihn bis heute nicht. Der STF ist ein deutscher Fund, der die „nachhaltige Stärkung des Open-Source-Ökosystems“ als Ziel hat. Ja, das ist ein deutscher Fund, der aktiv Open-Source-Projekte supportet. Man hat schon 40 Projekte unterstützt und insgesamt 15,25 Millionen € ausgeschüttet. Mit dabei beispielsweise WireGuard, OpenSSH, OpenPGP, Bundler, RubyGems und 195.000€ für curl. Das größte Investment bisher ist Prossimo mit über 1,4 Millionen €. Prossimo fördert selbst Projekte, die ihren Code auf speichersicheren (Memory Safe) Code umstellen.
Jedenfalls gab es nun ein aktuelles Investment in Höhe von 1 Million € für das GNOME Projekt. GNOME will damit die Stabilität des Produkts, die QA und Developer Experience und Barrierefreiheit verbessern oder größere Projekte wie das „individually encrypted User home“ und ein neues Secret Storage umsetzen.
Der Fund wird von Adriana Groh und Fiona Krakenbürger geführt. Interessierte Projekte können sich die Kriterien für eine Beantragung einer Förderungen online anschauen.
Übrigens feierte der Souvereign Tech Fund am 18.10.2023 sein 1-jähriges Bestehen – ist also nicht schlimm, wenn ich das nicht gekannt hab, oder?
GNOME Receives €1M Investment from Sovereign Tech Fund
Self-Hosting für 0$ in der Oracle-Cloud
Sam schreibt im verlinkten Blog-Artikel, wie er seinen Stack self-hosted auf einer VM in der Oracle Cloud betreibt.
Er hat dort:
- die Rezeptverwaltung Mealie
- den Passwort-Manager Vaultwarden
- NextCloud als Office365 Alternative
- Tailscale als VPN
- den RSS Aggregator FreshRSS
- und die Read-it-later App Wallabag
installiert. Zur Automatisierung verwendet er Ansible.
Die Dienste laufen als Docker-Container mit einem simplen nginx als Reverse-Proxy.
Backups hat er bei Backblaze konfiguriert – das kostet dann auch ein paar Dollar (6$ / TB pro Monat).
Die VM selbst läuft in der Oracle Cloud im „Always Free Tier“. Da bekommst du immerhin eine 24 GB RAM Maschine mit 4 Cores und 200 GB komplett umsonst.
Er hätte auch 2 „Oracle Autonomous Databases“ umsonst bekommen, die wollte er aber wohl nicht nutzen…
How I Save $0 a Month Hosting Open Source Software in the Cloud
Kostenloser Linux Kurs bei Monospace Mentor
Jochen hat sein Blog mitsamt Community von Opsitive zu Monospace Mentor rebranded. Bei MonoSpace Mentor findest du neben News zu Linux und der zugehörigen Discord Community auch 2 Linux Master Kurse.
Und obendrauf gibt es einen kostenlosen Linux-Kurs mit 40 Sessions, die du einfach im Selbststudium erledigen kannst. Hilfe zum Kurs gibt es im Community-Discord oder im wöchentlichen Live QA.
Es gibt Kapitel zu Linux allgemein, wichtigen Core Utilities, dem Bootvorgang und vielem mehr. Willst du einfach mal hereinschauen?
Das Kapitel zu „Text-Editoren“ geht alleine schon über 90 Minuten und ist hier komplett zum Reinschnuppern und ohne Anmeldung verfügbar.
Learn Linux system administration and level up your career
Schmunzelecke
Kannst du Gandalf überzeugen, sein Passwort zu verraten?
Das ist ein interaktives Training, in dem du deine (Social) Hacking Skills testen kannst
💡 Link Tipps aus der Open Source Welt
Docusaurus – Open Source Dokumentation
Docusaurus ist ein beliebtes Open-Source-Tool, um Dokumentationen schnell und schön online darzustellen.
Das Tool selbst kommt von Facebook / Meta und wird von deren „Meta Open Source“ Initiative aktiv weiterentwickelt, zuletzt mit Docusaurus 3.0 – der aktuellen Major Version.
Die ShowCase Page hat eine Menge Beispiele, wie Docusaurus in der Praxis eingesetzt werden kann. Schön umgesetzt finde ich unter anderem die Docs von Supabase, die Website & Docs von React Native oder die Redis Developer Documentation. Auch interessant – man bekommt Algolia für Docsearch kostenlos – Infos dazu findest du auf der Docusaurus Page von Algolia.
Wie du mit Docusaurus startest, erklärt die Docusaurus Dokumentation selbst hervorragend.
https://github.com/facebook/docusaurus
ShellCheck – QA für Bash Scripte
Mit ShellCheck kannst du die Qualität deiner Bash Skripte checken. Das geht entweder direkt online auf shellcheck.net oder mit dem CLI Tool ShellCheck, welches du beispielsweise in Ubuntu/Debian mittels apt install shellcheck als Paket installieren kannst. Natürlich gibt es das Paket auch für brew, zypper, yum, dnf, emerge oder für choco (Windows).
Als Parameter übergibst du einfach dein Shell Skript und dann kommt da unter anderem sowas bei raus.
start_date=`TZ=UTC date +“%FT%TZ“ -d ’10 seconds’`
^– SC2006 (style): Use $(…) notation instead of legacy backticks
....
So, ich bin dann mal weg.
https://github.com/koalaman/shellcheck
❓ 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: