Willkommen zu allesnurgecloud.com – Ausgabe #144!
In dieser Woche ein kleiner Hinweis in eigener Sache – am Mittwoch, den 19. Juni 2024, findet am Bildungscampus in Heilbronn der „Cloud X Summit“ der STACKIT Cloud statt – die Anmeldung ist kostenlos und vielleicht sehen wir uns ja da?
Auf welcher Konferenz bist du dieses Jahr noch unterwegs?
Meine Planung ist bisher nicht ganz abgeschlossen – schreib mir gerne, wo du unterwegs bist und was sich deiner Meinung nach lohnt – danke!
Happy Bootstrapping Podcast
Im „Happy Bootstrapping“ Podcast habe ich diese Woche Folge 69 mit Jonathan Wilke veröffentlicht. Jonathan baut mit supastarter.dev ein SaaS Starter-Kit, welches den Schnellstart von SaaS Anwendungen deutlich erleichtert, da Grundfunktionen wie Authentifizierung, Payment und Internationalisierung bereits vorhanden sind. Jonathan macht das ganze Thema als Side-Hustle und du bezahlst eine einmalige Gebühr für die Verwendung des Starter-Kits.
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:
BlueSky: Aufbau, Skalierung und Cloud-Exit
Pragmatic Engineer Gergely Orosz schreibt in seinem Newsletter regelmäßig und ausführlich über „Real-World Engineering Challenges“. In der aktuellen Ausgabe geht es um den Bau und die Skalierung des Social Networks BlueSky.
BlueSky hat heute schon über 5,5 Millionen User, diese Zahl hat es nicht mal 12 Monate nach dem Start erreicht. Die erste Version wurde von 3 Engineers gebaut, zum Stand der Publikation waren es gerade mal 12 Engineers.
In der ersten Phase experimentierte man mit verschiedenen Technologien und entwickelte die erste Mobile-App als Proof-of-Concept, das war im Juni 2022 – dies wurde dann auch die erste App, mit der BlueSky live ging.
Initial startete man auf AWS mit auto-scaling Gruppen von EC2 Instanzen, die die Applikation in Docker bereitstellten. Als relationale Datenbank verwendete man PostgreSQL in einem multi-zonalen Setup. Das Deployment der Infrastruktur erfolgte über Pulumi.
Im Oktober 2022 startete die Phase 2 – mit Invite-Codes konnte man sich bei BlueSky registrieren und der Service erreichte im Juni 2023 100.000 User, im September 2023 dann schon 1 Million User. In dieser Phase baute man auch erste Services, die die Föderierung und den Betrieb eines eigenen BlueSky Netzwerks erlauben sollten. Hier schuf man Services wie der „Personal Data Server“, die „AppView“ oder den Feed Generator.
Nach dem Beta Launch lief man zudem in erste Probleme mit der PostgreSQL Instanz – Locking war in manchen Fällen ein Problem und es gab Incidents, da Postgres manchmal wirklich einen viel schlechteren und langsameren Execution Plan gewählt hatte.
Man entschied sich deshalb für den Einsatz der Apache Cassandra kompatiblen NoSQL Lösung ScyllaDB, die unter anderem auch bei Expedia und Discord im Einsatz ist. Für den „Personal Data Service“ wechselte man auf SQLite Datenbanken – die es dann tatsächlich pro User gibt:
We took a somewhat novel approach of giving every user their own SQLite database. By removing the Postgres dependency, we made it possible to run a ‘PDS in a box’ without having to worry about managing a database
Natürlich werden die Datenbanken trotzdem gesichert – nur der Operational Overhead ist viel geringer.
Und nach dem Launch und einer Kostenexplosion entschied man sich für einen Cloud-Exit von AWS. Man stellte fest, dass man bei anderen Anbietern sehr viel mehr Performance für weniger Geld bekommen konnte. Die Applikation wurde „Cloud agnostisch“ umgeschrieben und nach nur 6 Monaten begann man mit dem Cloud-Exit:
Cost and performance were the main drivers in moving on-prem. The team got hardware that was more than 10x as powerful as before, for a fraction of the price. How was this decision made? A key hire played a big role.
Heute läuft BlueSky in Shards auf Servern bei Vultr – in jedem der aktuell 20 Shards können bis zu 300.000 User verwaltet werden. Das System liefert heute 3500 Requests pro Sekunde und es werden 60-100 schreibende Events pro Sekunde verarbeitet.
In einem Podcast bei Last Week in AWS erklärte BlueSky Engineering Manager Jake Gold, der Treiber hinter der „On-Prem“ Migration, seine Beweggründe so:
With the original vision of AWS I first started using in 2006, or whenever launched, they said they would lower your bill every so often, as Moore’s law makes their bill lower. And that kind of happened a little bit here and there, but it hasn’t happened to the same degree as I think we all hoped it would.
Und da ist etwas Wahres dran – die Kosten sind zwar gelegentlich gesunken – bei Weitem aber nicht so stark, wie die Marge von AWS gewachsen ist.
Building Bluesky: a Distributed Social Network (Real-World Engineering Challenges)
AWS, Azure und Google Zahlen im Vergleich
Mit dem Ende des letzten Quartals haben AWS, Azure und Google mal wieder ihre Zahlen veröffentlicht – Zeit für einen kleinen Vergleich.
Laut einem aktuellen Research haben AWS, Azure und Google zusammen ungefähr 67 % Marktanteil im Cloud Infrastruktur Bereich. Der Markt macht in Summe aktuell 76 Milliarden Dollar Volumen aus und ist im Jahresvergleich zum Q1/2023 um 21 % – 13,5 Milliarden Dollar – gewachsen.
Die weiteren Anteile verteilen sich auf viele kleine Anbieter – als nächster „Großer“ Anbiete kommt Alibaba auf 4 Prozent und Salesforce auf 3 Prozent Marktanteil.
Der Marktanteil der Hyperscaler verteilt sich im Q1/2024 wie folgt:
- AWS – 31 %
- Microsoft – 25 %
- Google Cloud – 11 %
Bei AWS hat sich das Wachstum wieder beschleunigt – im Vorquartal war man noch mit 12 % gewachsen, nun wächst man wieder um 17 %. Somit summiert sich der Umsatz von AWS auf 25 Milliarden Dollar für das Q1/2024. AWS macht in diesem Quartal 17,5 Prozent des Umsatzes von Gesamt-Amazon aus. Allerdings liefert AWS ein Großteil des Gewinns – von insgesamt 15,3 Milliarden Gewinn steuert AWS immerhin 9,5 Milliarden Dollar bei.
Im Hause Microsoft konnte man das Wachstum nochmals etwas beschleunigen – im Vorjahr wuchs man noch um 22,1 Milliarden Dollar, im aktuellen Quartal dann um 26,7 Milliarden Dollar – ein Wachstum von 25 %. In Summe trägt die „Intelligent Cloud“ 43 % des Gesamtumsatzes von Microsoft zum Umsatz bei. Der Gesamtgewinn von Microsoft belief sich auf stolze 27,6 Milliarden Dollar und die Cloud Sparte trug 12,5 Milliarden dazu bei.
Und auch in der Google Cloud beschleunigt sich das Wachstum wieder – man wuchs um 9,6 Milliarden Dollar und in Summe um 28 %. In Prozenten ist Google somit am meisten gewachsen – allerdings ist die absolute Summe im Vergleich mit den beiden anderen auch noch deutlich kleiner. Der Anteil der Google Cloud Umsätze an Alphabet beträgt im aktuellen Quartal 12 %. Alphabet machte in der Zeit 25,4 Milliarden Gewinn und die Google Cloud steuerte 900 Millionen Dollar dazu bei.
Microsoft Vs. AWS Vs. Google Cloud Earnings Q1 2024 Face-Off
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 bloß 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.
AWS Kostenexplosion durch unerwünschte S3 Requests
In einem viel geteilten und beachteten Artikel zeigte Entwickler Maciej Pocwierz, wie man ohne Absicht eine hohe S3 Rechnung erhalten kann.
Er hatte für ein System zur Dokumentenindizierung einen S3 Bucket in eu-west-1 angelegt, Testfiles hochgeladen und das Projekt dann erst einmal ignoriert.
Zwei Tage später staunte er nicht schlecht, als seine Rechnung bereits über 1.300 $ angelangt war.
Was war passiert?
Es wurden über 100.000.000 S3 PUT requests innerhalb eines Tages verzeichnet – und logischerweise auch abgerechnet. Zunächst konnte er die Zugriffe gar nicht zuordnen, da die Logs für den S3 Zugriff im Default deaktiviert sind – diese müssen erst in AWS CloudTrail oder S3 Server Access Logging aktiviert werden.
Wie es der Zufall so will, hatte Maciej einen Bucket-Namen gewählt, den ein nicht genanntes, aber populäres open-source Tool als default konfiguriert hatte – daher kamen also die Zugriffe:
So, a horde of misconfigured systems is attempting to store their data in my private S3 bucket. But why should I be the one paying for this mistake?
Das ist die Frage – du kannst auch ohne AWS Konto ganz einfach Requests gegen S3 erzeugen, die der Bucket Besitzer dann erstmal bezahlen darf.
Kennst du also den Bucket Namen, so kannst du einen ordentlichen, finanziellen Schaden anrichten.
Maciej hatte testweise sein Bucket noch für „Public Writes“ geöffnet und innerhalb von 30 Sekunden übe 10 GB an Daten empfangen – das kann ja eigentlich nur ein Backup Tool sein, dass seine Daten hier gespeichert hat.
Das Open-Source-Tool hat inzwischen reagiert und die Default Konfiguration angepasst. Dem AWS Security Team gegenüber hat Maciej vorgeschlagen, dass man Kunden ja vor solchen Fällen schützen und ggf. bekannte Bucket Namen sperren könnte.
Man kann jedenfalls nun jedem empfehlen, einen kryptischen Hash in seinen Bucket Namen einzubauen – auf der anderen Seite binden viele ja die Buckets direkt im Web ein und liefern ihren Content darüber aus – da kann man auch schöne „Attacken“ gegen die Kreditkarte fahren.
Jeff Barr, Chief Evangelist von Amazon Web Services, hat auf Twitter angekündigt, dass man den Fall untersuchen wird und in Zukunft unautorisierte Abfragen nicht mehr in Rechnung stellen will. AWS hat zudem die Rechnung Maciej erst mal storniert.
How an empty S3 bucket can make your AWS bill explode
S3 „Denial of Wallet“ Attacke
Passend zum obigen Artikel habe ich noch ein weiteres AWS S3 Thema für euch – das ist speziell für alle interessant, die größere Files in AWS S3 (und ggf. anderen Anbietern) speichern.
Die im Artikel beschriebene „Attacke“ nennt sich „Denial of Wallet“, weil sie deinen Geldbeutel angreift. Ähnlich wie bei einer DNS Amplification Attacke werden hier spezielle Requests genutzt, um einen Download eines größeren Files auszulösen, der dann für dich selbst nicht wirklich stattfindet. Das Ganze funktioniert nur mit großen Files in Kombination mit HTTP Range Requests, bei denen die Files in kleinere Chunks (Teile) gesplittet werden.
Man fordert also nur einen Teil des Files an und bricht den Download sofort wieder ab – AWS denkt aber, man habe den ganzen Chunk geladen. In einem Fall konnten die Autoren des Artikels 300 MB echten Traffic innerhalb von 30 Sekunden erzeugen, der in 6 GB abgerechnetem AWS S3 Traffic resultierte – also 20-mal so viel, wie auf Client Seite an Kosten entstanden sind:
we were able to reproduce the scenario where we downloaded 300MB of data in 30sec from AWS S3 and were billed for more than 6GB by AWS.
If an attacker can induce costs for 6GB in 30sec how much costs can be generated in a day, or on the weekend when running many threads in parallel?
Man kann hier also schon ordentlich Schabernack mit treiben.
Die Standard-Antwort von AWS auf solche Themen ist erst mal, dass die S3 Buckets nie public sein sollten – und die Cost Anomaly Detection hilft dann auch erst im Nachhinein.
Mal schauen, ob sie das Thema mit dem oben genannten Thema von Maciej angehen und ebenfalls eine Lösung finden.
The AWS S3 Denial of Wallet amplification attack
Wird Terraform bei IBM wieder Open Source?
Diverse Analysten und Techinsider sind überzeugt, dass Terraform unter der Führung von IBM wieder zurück zur ursprünglichen Open-Source-Lizenz von Terraform wechseln könnte.
Im verlinkten Artikel bei TheNewStack beschreibt Analyst B. Cameron Gain wie IBM sich bereits Anfang der 2000er Jahre nach einer Klage von SCO geöffnet und seine Open-Source Strategie dargelegt hat:
“IBM has been actively involved in the open source movement, making significant investments in Linux business efforts over the past five years…The company participates in various Linux projects that are crucial to its operations and also contribute to the broader open-source community.”
Cloud Enthusiast und Ex-Google Cloud Principal Kelsey Hightower wünschte sich bereits zur Pressemitteilung zur HashiCorp Übernahme durch IBM eine Rückkehr zur ursprünglichen Open-Source-Lizenz. Oxide Computer CTO Bryan Cantrill geht einen Schritt weiter und meint, dass eine Unterlassungserklärung im Stile von HashiCorp vs. OpenTofu absolut gar nicht zur aktuellen IBM Kultur und Strategie passe:
It’s behavior that is not consistent with IBM. And maybe I’m being ridiculously optimistic here, but I think IBM has got a real opportunity to show the world who we know IBM to be,
I mean, I think it again, missed the exercise aside, there are always going to be missteps. But I think that IBM broadly understands that what is good for the community ultimately is going to be good for IBM.
Das kennen wir ja eigentlich schon – „We grow when we share“ war lange Jahre der Leitsatz von RedHat – allerdings hatte man es sich mit dem Switch der RHEL Lizenzen im letzten Jahr dann ordentlich mit der Community verscherzt.
Und am Ende muss man nach den 6,8 Milliarden Dollar Kaufpreis ja auch etwas Geld mit der Akquisition verdienen.
Terraform bzw. auch Nomad und Consul könnten IBM helfen ein „neutraler“ Cloud-Anbieter zu werden oder eben ein neutrales Abstraktionslayer für vorhandene Hyperscaler zu werden.
Could Terraform Return to Open Source Under IBM’s Ownership?
GitLab Duo Chat: 10 Beispiele für AI Einsatz
In der letzten Woche hatte ich das GitLab Release 16.11 mit GitLab Duo Chat als Highlight erwähnt. In diesem Blog Artikel zeigt nun GitLab Developer Advocate Michael Friedrich den Einsatz der GitLab Duo Chat AI anhand von 10 praktischen Beispielen.
Zum Einstieg lernst du, wie man überhaupt mit GitLab Duo Chat interagiert – anhand der Erstellung eines neuen Projekts mitsamt Ordnerstruktur, .gitignore File und einer CI/CD Pipeline mit mehreren Stages. Weiter geht es dann mit „Approval Roles“, wenn der Code je nach File-Typ unterschiedliche Reviewer benötigt – bei .rb Files das Backend Team, bei .js/.css und Co. eben das Frontend Team.
Zudem kannst du sehen, wie man in VS Code mit der Duo Chat Extension effizienter in der IDE arbeiten und sich Code erklären lassen kann, den jemand anderes geschrieben hat oder an den man sich selbst nicht mehr erinnern kann. Und die Erstellung von Tests nervt uns alle, warum nicht mit der initialen Test-Generierung durch die AI helfen lassen?
Das gleiche gilt für die Dokumentation, hier kann Duo Chat ebenfalls helfen.
Auch möglich ist Refactoring von C Code in Rust Code – cool, was hier alles möglich ist.
10 best practices for using AI-powered GitLab Duo Chat
Jira Alternative Plane mit One-Time Lizenz
Die Jira Alternative Plane.so hatte ich in Ausgabe 99 im letzten Jahr schon vorgestellt. Plane ist Open-Source und es gibt ein SaaS Angebot, mit dem die Entwicklung finanziert wird.
Nun geht man einen Schritt weiter und folgt dem neuen once.com Modell von Basecamp – ein Angebot für ein One-Time Payment für die komplette „Plane.so One“ Suite – inklusive sämtlicher „Pro“ Features, wie beispielsweise OIDC, SAML, Active Cycles, Importers, Wöchentliche Performance E-Mails und vieles mehr.
Das ganze Paket kostet dann einmalig 699 $ (für die ersten 100 Bestellungen) und dann 799 $ – unabhängig von der Anzahl der User. Du kannst dann alle Minor Updates kostenlos bekommen, ein Upgrade auf eine zukünftige Major 2.x Version kostet dann wieder einen einmaligen Upgrade-Preis.
Priority Support über E-Mail und Discord ist ebenfalls dabei – klingt interessant, oder?
Schmunzelecke
Bei terminal.shop kannst du Kaffee per SSH bestellen – also konntest – die erste Charge des fair gehandelten, brasilianischen Kaffees ist schon ausverkauft.
Ach, und du musst in den USA leben, aber ansonsten – Go for it.
Beweisfoto einer Bestellung auf Twitter – Screenshot des Shops im Anhang.
Zum testen einfach eine ssh Session zu terminal.shop aufmachen – ssh terminal.shop
💡 Link Tipps aus der Open Source Welt
pyinfra : Infrastruktur Automatisieren
Das Python-Tool pyinfra ist ein Tool zur Automatisierung der Infrastruktur, welches Arbeiten massiv parallel über tausende von Hosts ausführen kann. Das geht mit den bereits von ansible bekannten „ad-hoc commands“, die beispielsweise auch docker container unterstützen.
Inventory Files gibt es ebenfalls, diese sehen etwas anders aus als bei Ansible. Du kannst aber auch einen parallel „Tail“ auf 10 verschiedene Elasticsearch Logfiles machen, das funktioniert dann so:
pyinfra inventory.py exec --sudo -- tail -f /var/log/elasticsearch/elasticsearch.logPyinfra kann mit „Connectoren“ integriert werden – unter anderem mit terraform, vagrant, winrm oder auch ansible.
Bei GitHub hat das Projekt aktuell um die 3300 Sterne – ist also recht populär – ich kannte es bisher nicht.
MySQL und PostgtreSQL Dump anyonymisieren
Der nxs-data-anonymizer ist ein in Go geschriebenes Tool, mit dessen Hilfe du Datenbank Dumps anonymisieren kannst. Es supportet aktuell PostgreSQL (9/10/11/12/13/14/15/) und MySQL/MariaDB/Percona (5.7/8.0/8.1).
Einmal konfiguriert, kannst du den anonymizer in deinen CI/CD Prozess einbauen, beispielsweise in GitLab CI/CD oder GitHub Actions.
Die Konfiguration erfolgt über ein Config-File – das Tool erkennt die Felder nicht automatisch, sondern du musst ihm mitteilen, welche Felder anonymisiert werden sollen.
https://github.com/nixys/nxs-data-anonymizer
❓ 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: