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:

507 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address

Diese E-Mail ist bereits registriert.

The security code entered was incorrect

Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.

Amazon: Prime Video spart 90 % Kosten durch „serverless“ Verzicht

In dieser Woche sorgte ein Artikel von Amazon für ordentlich Furore im Netz – und ja, er ist sogar noch online.
Das Prime-Video Team hat im Amazon Tech-Blog einen Artikel zur Optimierung der Monitoring-Infrastruktur von Prime/Video veröffentlicht.
Bisher nutzte das „Video Quality Analysis“ Team AWS Lambda und AWS Step Functions (siehe Architektur)für die Überwachung der Qualität von Audio/Video Streams.
Initial sei das System nie für eine solche Workload gedacht gewesen, aber solche Systeme wachsen dann halt schnell – wer kennt es nicht.

We designed our initial solution as a distributed system using serverless components (for example, AWS Step Functions or AWS Lambda), which was a good choice for building the service quickly. In theory, this would allow us to scale each service component independently.

Jo, so geht es immer los, mit einem kleinen MVP, den man schnell bauen kann.
In der Regel bekommt man die Zeit für ein Redesign nicht, zumindest nicht bis es knallt – operativ oder finanziell.
In diesem Fall krachte es schon bei 5 % der erwarteten Last:

However, the way we used some components caused us to hit a hard scaling limit at around 5% of the expected load. Also, the overall cost of all the building blocks was too high to accept the solution at a large scale.

Das kommt jetzt unerwartet – die Limitierungen von „Serverless“ Architektur sollten gerade beim Hersteller doch bekannt sein?
Jedenfalls hat das Team das nun umgestellt, auf einen Monolith, der in ECS (Container Service) und EC2 (VMs) lebt.
Man kann damit viel besser skalieren und spart damit 90 % der Kosten ein!

Moving our service to a monolith reduced our infrastructure cost by over 90%. It also increased our scaling capabilities. Today, we’re able to handle thousands of streams and we still have capacity to scale the service even further.

Und natürlich hat man einen „Savings Plan“ abgeschlossen – auch diese werden wohl intern verrechnet.
Da braucht man sich nicht wundern, dass AWS so eine Marge abliefert.

Jedenfalls war dies ein toller Aufhänger für die Community.
David Heinemeier Hannson (DHH) schreibt provokant „Even Amazon can’t make sense of serverless or microservices“ – und ja, da hat er einen Punkt.
Er schreibt, dass sich „Serverless“ in der Theorie ganz nett anhöre, die Realität hat uns dann aber schnell eingeholt:

Now the real-world results of all this theory are finally in, and it’s clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system. And serverless only makes it worse.

Kelsey Hightower (Google Cloud, nicht Police Academy) ordnet das Thema auf Twitter sinnvoll ein. Er sagt, dass Lambda für schnelle Entwicklung und Erprobung am Markt geeignet sei, nicht aber für dauerhafte Workload mit viel Datentransfer:

But it is a testament to the overhead of microservices in the real world. Moving data around is typically an underestimated cost.

Man müsse das richtige Tool für den richtigen Job nutzen. Die Frage ist nur, wer erkennt das und hört man zu?
Kennst du eine App, die „serverless“ läuft und tausende oder gar Millionen Nutzer hat? Also eine kenne ich auf jeden Fall.

Die Cloud Provider freut es, denn diese lassen sich den „Verschnitt“, der bei solchen Systemen entsteht, sehr gut bezahlen. Denn man kann die Einheiten noch viel kleiner schneiden und deutlich besser über-provisonieren. Dies steigert die Marge, die am Ende hängenbleibt.
Auch auf HackerNews wurde der Artikel ausführlich diskutiert. Man fragt sich sogar, ob der Artikel noch lange online bleibe.

Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%

Cloud Spendings Report mit Überraschungen

Passend zum vorherigen Artikel ist diese aktuelle Analyse von Vantage zu den „Cloud spendings“ in Q1 2023.
Zum ersten mal gibt es einen Vergleich der Top-Services bei AWS, Azure und Google.
Und ja, das Geld wird immer noch mit VMs verdient, und das nicht mal wenig.
Bei AWS sind die Top 3 Services:

1. EC2 Instanzen (VMs): 42 %
2. RDS (Datenbanken): 7 %
3. S3 (Object Storage): 4 %

bei Google:

1. Compute Engine (VMs): 28 %
2. Cloud Storage (S3): 19 %
3. BigQuery (Data Warehouse): 9 %

bei Azure:

1. Virtual Machines: 29 %
2. Managed SQL: 17 %
3. App Service: 10 %

Interessant, dass es bei AWS sehr viel mehr VMs gibt als bei den anderen beiden Providern.
Dazu spannend, dass bei Azure Managed SQL sehr beliebt scheint – viele scheinen ihre SQL Server in die Cloud zu packen. Denn die „SQL Databases“ sind mit 7 % nochmals extra ausgewiesen. App Service scheint ebenfalls populär zu sein – ob die alle den Prime-Video Artikel lesen werden?

Bei Google macht BigQuery ordentlich was aus – hier scheint sich vielleicht die Integration in Services wie Google Analytics und Co. auszuzahlen. Überraschend für mich: Bigtable und Spanner sind noch vor dem normalen „Cloud SQL“ Service. App Engine mit 2 % eher abgeschlagen.

Und bei AWS hätte ich das NAT Gateway eher mit 5-10 % erwartet – nicht „nur“ mit 1 % – vermutlich sind viele direkt im Internet?
Graviton, die Amazon eigenen ARM CPUs, machen in Q1 2023 etwas über 5 % der CPUs aus – Intel ist mit über 75 % noch absolut dominierend.

Für alle, die eine eigene Cloud bauen, oder dies vorhaben interessant: diese Übersicht über die verschiedenen CPU Typen seit Januar – auch hier ist mehr Bewegung drin als ich dachte.

Vantage Cloud Cost Report

Basecamp: Cloud Exit zahlt sich aus

Dass Basecamp mit dem Cloud-Exit deutlich einsparen will, hast du hier bereits gelesen.
Dass die Performance mit dem Cloud-Exit sogar noch besser wird, ist dann doch vielleicht eine Überraschung.
37signals betreibt mit Absicht alle älteren Versionen ihrer Software weiter – so auch die erste Version von Basecamp. Das ist die Firmen-Philiosophie „Until the End of the Internet“ – ein für 37signals wichtiges Versprechen an die Kundschaft, die nicht umsteigen möchte.

Nun hat man jedenfalls die erste Version von Basecamp (live seit 2004) von Amazon AKS (Managed Kubernetes Service) auf eigene Server mit MRSK umgezogen.
Dabei hat man erstaunlicherweise sogar Performance-Verbesserungen festgestellt:

1. Im Median laufen die Requests nun in 19ms, anstatt 67ms vorher
2. Mean Requests sind nach 95ms fertig – vorher 138ms
3. 95 % aller Requests sind nun in unter 300ms erledigt – das war vormals nicht so

Basecamp V1 macht noch immer „millions of dollars in revenue per year“ – dieser Umzug wird die Marge der abgehangenen Software noch weiter steigern.
Die Hauseigene Container Software MRSK hat nun eine ordentliche Landingpage verpasst bekommen.
Mittlerweile gibt es ein Release v.0.12.0 bzw. v.0.12.1 mit diversen Contributors, nicht nur aus dem Hause 37signals/Basecamp.

Hast du MRSK schon ausprobiert? Bei mir steht es noch auf der Liste.

Cloud exit pays off in performance too

Neue Google Cloud Location in Berlin-Brandenburg

Google startet im Juli mit der neuen Region in Berlin-Brandenburg.
Das Ganze wird mir einem virtuellen Event am 6. Juli 2023 (14:00-18:15 Uhr) mit diversen Vorträgen gefeiert. Die Agenda ist hier online einzusehen – es gibt Vorträge zum Thema AI, Nachhaltigkeit und Souveränität.
Das RZ entsteht auf einem 30 HA großen Grundstück in der Nähe von Schenkenhorst in Brandenburg.
Wer die genaue Location hat, darf sie mir gerne schicken – habe das nicht direkt gefunden.
Jedenfalls bin ich gespannt, ob diese Google eigene Region dann Kosten-technisch günstiger wird als Frankfurt.
In der Regel sind die Kosten in Google eigenen Regionen günstiger als in angemieteten – das kannst du beispielsweise sehen, wenn du Google Cloud Preise in Belgien (europe-west1) mit Frankfurt (europe-west3) vergleichst.
Berlin ist aktuell auf der Übersicht der Zonen als „zukünftige Region“ gelistet, man sieht also nicht, welche Services es gleich zum Start geben wird.
Angekündigt hatte Google die neue Region im Jahr 2021, im September 2022 wurde dann das Grundstück bekannt – und nun geht es im Juli schon los – nicht schlecht!

Cloud. Nach deutschen Maßstäben.

IBM will 7.800 Jobs mit AI ersetzen

Dass IBM bei RedHat zum Kahlschlag ansetzt, hatte ich letzte Woche berichtet.
Laut einem Interview des IBM CEO Arvind Krishna mit Bloomberg News möchte man in nächster Zeit bei IBM nun keine weiteren Einstellungen vornehmen.
Man plant eher, Rollen in den Backoffice und HR Bereichen mit AI zu ersetzten:

Hiring specifically in back-office functions such as human resources will be suspended or slowed, Krishna said, adding that 30% of non-customer-facing roles could be replaced by AI and automations in five years.

Ob dies dann wirklich so schnell geht?

IBM to pause hiring in plan to replace 7,800 jobs with AI, Bloomberg reports

Google: Passkey Login verfügbar

In der letzten Woche hatte ich auf das neue und fragwürdige (unverschlüsselte) Backup Verfahren von „Google Authenticator“ hingewiesen.
Google hat die Aufregung genutzt und das neue „Passkey“ Verfahren für Google Accounts freigeschaltet.
Falls du einen normalen Google Account hast, kannst du das hier direkt einschalten.
Nutzer von Google Workspace Accounts müssen auf die Admin-Option warten, um das Feature freizuschalten.
Nur 2 Tage später wurde diese ausführliche Analyse zum Passwortlosen-Login veröffentlicht.
Google sieht 2 große Vorteile in der Verwendung, neben der gestiegenen Sicherheit:

Success Rate

Google interne Daten (von März – April 2023) zeigen, dass die Erfolgsrate von Passkey-Logins 4-mal höher ist als mit Passwort.
64 % der Passkey-Logins seinen erfolgreich, aber nur 14 % mit Password.
Da müssen ja ganz schön viele User kein Passwortmanager nutzen, oder?

Performance

Im Mittel dauert ein erfolgreicher Passkey-Login nur 14,9 Sekunden, einer mit Passwort aber 30,4 Sekunden.

Mich hätte jetzt interessiert, warum trotzdem „nur“ 64 % der Passkey-Logins erfolgreich sind – da hätte ich mit mehr gerechnet.
Es werden nur „Logins auf dem gleichen Device“ gezählt, wenn ich das richtig verstanden habe. Dann können Brute-Force und andere Scripte hier ja nicht mit reinzählen.

The beginning of the end of the password

Packagist.org: Maintainer Accounts übernommen

Ganz ohne 2FA und Passkey scheinen noch immer diverse Package-Maintainer zu sein.
Am 1. Mai wurden 14 Pakete auf Packagist.org manipuliert und die Ziel-Adressen der Pakete auf eine andere Repository URL geändert.
Packagist hält die Repositorys selbst nicht, sondern ist nur der Metadata Server, der die Referenzen enthält.
Scheinbar haben die betroffenen User Passwörter aus einem vorherigen Leak verwendet – also neben fehlendem 2FA noch Passwörter zwischen ihren Anwendungen geshared (und kein Passwort Vault verwendet?).
Ich nutze beispielsweise Enpass – hier kannst du einfach auf kompromittierte Passwörter testen und die Accounts ändern oder gleich löschen.

Packagist.org maintainer account takeover

Frankreich: Brand bei Maxnod Datacenter

Auf den Google Cloud Ausfall in europe-west9 habe ich einiges an Feedback erhalten – danke!
Aktuell ist europe-west9a noch immer gestört – den detaillierten Ausfallbericht gibt es noch nicht.
Dies spricht jedenfalls dafür, dass hier ordentlich etwas kaputt ist.
Ein aufmerksamer Leser hat mir den verlinkten Twitter Thread geschickt (danke).
Hier beschreibt Hugues Voiturier, ein Freelance Network Engineer, den Brand am Datacenter von Maxnod Ende März 2023.
Scheinbar haben hier die Batterien der PV Anlage gebrannt und der Brand sich ausgebreitet bzw. die Löscharbeiten den Rest vom DataCenter beschädigt.
Eine englische Beschreibung des Vorfalls findest du bei datacenterdynamics.com – einem News-Blog für Datacenter.
Hugues teilt auf Twitter auch Fotos aus dem Inneren, dort kannst du dem ordentlichen Beschädigen des Equipments sehen.

Well, the Maxnod Datacenter is on fire, fire on the battery room of the photovoltaic panels.

Schmunzelecke

Ein Netflix Engineer braucht dringende Hilfe bei der Skalierung von Kubernetes – bei all dem Witz in den Kommentaren – wer weiß schon, ob das nicht doch echt ist?

💡 Link Tipps aus der Open Source Welt

Kubeshark – Kubernetes API Traffic Analyzer

Kubeshark ist ein umfangreiches Debugging Werkzeug für Kubernetes Cluster. Falls du aus der klassischen Welt kommst, so etwas wie TCPDump und Wireshark, aber eben für Kubernetes (Daher auch der Name Kubeshark, logisch, Andy!).
Die WebUI sieht auch echt cool aus – Traffic wird nach bekannten Ports und Protokollen gruppiert – und du kannst dir live Request/Response, Body und Header von Requests anschauen.
Kubeshark kann zudem Netzwerk Metriken an InfluxDB, Grafana und Elasticsearch senden – damit kannst du die gesammelten Informationen weiter auswerten.
Auf YouTube findest du hier ein Intro Video und hier ein Deep-Dive zum Thema.
Kubeshark kannst du auf dem Mac einfach via Homebrew installieren: brew tap kubeshark/kubeshark & brew install kubeshark.

https://github.com/kubeshark/kubeshark

Frogmouth – Markdown Browser fürs Terminal

Mit Frogmouth kannst du .md Files einfach und direkt im Terminal anschauen.
Frogmouth ist in Python gebaut – du kannst das Tool einfach mit pipx install frogmouth oder pip install frogmouth installieren.
Das sieht dann nicht mal schlecht aus, wie man auf den Screenshots sehen kann.
Als kleines Gimmick kann man mit frogmouth gh textualize/textual direkt eine GitHub Readme auf der Kommandozeile öffnen.

https://github.com/Textualize/frogmouth

❓ 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:

507 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address

Diese E-Mail ist bereits registriert.

The security code entered was incorrect

Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.