Das war mal wieder eine ereignisreiche Woche. Auf der Heilbronn Slush’d durfte ich einen kleinen Workshop zu meinem Podcast „Happy Bootstrapping“ halten. Auch ansonsten war die Veranstaltung ein sehr beeindruckendes und cooles Start-up Festival.
Im Podcast war die Woche Gregor Schweizer von der SEPP’Manufaktur Südtirol zu Gast – einem E-Commerce Shop für Spezialitäten aus Südtirol. Da hab ich mal wieder einiges gelernt, beispielsweise was man in diesem Bereich alleine alles schaffen und gut WhatsApp als direkter Kanal zu Kunden funktionieren kann.
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:
Kelsey Hightower: Cloud vs. OnPrem
Eigentlich mag ich ja nicht mehr so viel auf Twitter verlinken, spannende Inhalte finden sich dort aber immer noch.
Seit Kelsey Hightower nicht mehr bei Google ist, wird er zunehmend „neutraler“, was Cloud-Themen betrifft. Wobei ich schon immer den Eindruck hatte, als sei er recht neutral unterwegs gewesen. Jedenfalls hat er nun einen Tweet verfasst, der ein wenig Aufsehen erregt hat:
It might just turn out that the cloud was the best way to research and design better ways of managing our systems, and thanks to the open source community standardizing the APIs on top, we might finally have the blueprints we need to close the gap on-prem.
Dank den Public Cloud Angeboten haben wir gelernt, wie wir in Zukunft auch On-Prem skalierbare Systeme bauen könnten – und diese mit Standard-APIs in Code zu beschreiben und erzeugen.
Er argumentiert dann weiter, dass die Kosten für den Betrieb von eigenen Lösungen in den letzten 15 Jahren deutlich gesunken seien. Zudem seien Systeme erhältlich, die einem den Betrieb im Datacenter vereinfachen. S3 kann durch Minio bereitgestellt werden, Container Betrieb mit Kubernetes, Datenbanken aller Art mit dem Ökosystem von PostgreSQL, Memory Speicher mit Redis und so weiter. Mit Tools wie Crossplane, OpenTofu und Pulumi könne man diese Systeme auch On-Premise betreiben und automatisieren.
Er erwähnt auch Oxide.computer als spannende Alternative für das eigene Data Center. Oxide hatte ich hier früher schon mal erwähnt – man baut dort komplette Racks, Hardware im Bundle integriert mit Software, die einen einfachen und API basierten Betrieb einer eigenen Cloud versprechen. Nach 3 Jahren Entwicklungszeit wurden im Sommer die ersten Racks an Kunden ausgeliefert. In Einem längeren Vortage auf der Linux Expo erklärt Oxide Gründer Bryan Cantrill, warum und wieso er an das Modell von Oxide glaubt, und gleichzeitig räumt er mit vielen Mythen zu der Cloud auf.
Und natürlich gibt es Beistand von David Heinemeier-Hansson auf Twitter.
Kelsey sagt aber auch, dass es für viele Firmen absolut ok sei, die IT Probleme zu einem Cloud-Provider outzusourcen, bis man dann eine kritische Masse erreiche, bei der man mit standardisierten APIs etwas Eigenes betreiben möchte.
Entlassungen bei MariaDB und Übergangskredit
Im Hause MariaDB gibt es einen kleinen Paukenschlag – nachdem es bezüglich Layoffs hier ruhiger wurde – entlässt MariaDB nun 28 Prozent der Belegschaft – das sind laut aktuellen Rechnungen 85 Jobs. Man hat zudem einen kurzfristigen VC-Kredit in Höhe von 26,5 Millionen Dollar aufgenommen.
Des Weiteren stoppt man die Cloud DB-as-a-Service Angebote SkySQL und Xpand und möchte sich in Zukunft wieder auf das Kerngeschäft, MariaDB und MariaDB Enterprise Server, konzentrieren.
Wenn ich das richtig verstanden habe, so ist der Kredit ein kurzfristiger Kredit mit Fälligkeitsdatum 10. Januar 2024 – bis dahin muss klar sein, wohin die Reise geht.
Bei Hacker News gab es diverse Kommentare zur Entlassung bei MariaDB – interessanterweise ist man aber auch in eine PostgreSQL vs. MySQL abgedriftet, bei der der PlanetScale CEO Sam Lambert ein paar knackige Statements rausgehauen hat:
I see the “Postgres is technology superior” take on hn all the time. Can you actually back that up?
Facebook has evaluated every database on the planet and still uses MySQL. https://engineering.fb.com/2021/07/22/core-infra/mysql/
When MySQL has more users, can scale significantly more, runs some of the largest sites on earth, and even lends its storage engine to other databases like Dynamo you should backup your claims that Postgres is technically superior. Please.
Sam listet dann auch die Migration von Uber von PostgreSQL zu MySQL und einen größeren Ausfall bei GitLab in Verbindung mit PostgreSQL als Grund an, warum MySQL at Scale einfach besser funktioniere. Natürlich hat er auch gute Gründe, für MySQL Partei zu ergreifen – sein Cloud MySQL Angebot PlanetScale („is the world’s most advanced MySQL platform) basiert auf Vitess – einem Open Source Database Cluster System, welches ursprünglich bei YouTube entwickelt wurde und heute unter anderem bei AirBnB, GitHub, Slack, Shopify, Pinterest, Box und weiteren namhaften Firmen betrieben wird.
MariaDB verzinst den Kredit übrigens mit 10 % – bis zum Januar sind dann auch nur 3 Monate – ob daraus was wird?
MariaDB ditches products and staff in restructure, bags $26.5M loan to cushion fall
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.
Layoffs auch bei Stack Overflow
Seit einiger Zeit ist bekannt, dass der Traffic von Stack Overflow um 15 % – 20 % eingebrochen sei. Das hat solche Kreise gezogen, dass sich Stack Overflow genötigt fühlte, in ihrem Blog einen Artikel zur Klarstellung zu veröffentlichen. Im Blog-Artikel bei Stack Overflow ist dann sogar von berichteten Einbrüchen bis zu 50 % die Rede.
Man argumentiert damit, dass man viel umgestellt hätte (Google Analytics 4, Privacy Einstellungen, etc.) und man deshalb einige Änderungen am Traffic Pattern sehen würde, aber dass man in Summe sagen könne, im Jahr 2023 nur 5 % weniger Traffic zu haben, als im Jahr 2022.
In den meisten Artikeln hieß es, ChatBots wie ChatGPT seien für den Traffic Einbruch verantwortlich – Stack Overflow kontert dies damit, dass die Entwickler die AI zwar nutzen, ihr aber nicht vertrauen würden:
There is no shortage of ways developers can leverage AI. But there is one core deterrent in its adoption: trust in the accuracy of AI-generated content. Stack Overflow’s annual Developer Survey of 90,000 coders recently found that 77% of developers are favorable of AI tools, but only 42% trust the accuracy of those tools.
Jedenfalls hat die 15 Jahre alte Firma hinter den Stack Overflow Q&A Portalen nun bekannt gegeben, sich von 28 % der Belegschaft trennen zu wollen. In Summe hat Venture Beat berechnet, dass um die 215 Personen Entlassen würden. Im Blog-Announcement von Stack Overflow CEO Prashanth Chandrasekar wird ebenfalls nur der betroffene Headcount mit 28 % angegeben – und keine absolute Zahl.
Stack Overflow baut an einer eigenen AI, der OverflowAI, die mit den Daten der Portale trainiert wird.
Wenn nun Stack Overflow weniger Traffic bekommt, dort weniger Fragen gestellt und Antworten geliefert werden – woher nimmt die interne AI dann die Daten für zukünftige Herausforderungen? OpenAI hat diese Daten doch bestimmt auch mit gecrawled – zumindest hatte man sich überlegt, Geld von Crawlern einzufordern, die die Daten für AI Training verwenden wollen.
Stack Overflow confirms layoffs affecting 28% of workforce
Slacks Job Queue verarbeitet 33.000 Messages pro Sekunde
Im Engineering Blog von Slack gibt’s mal wieder einen interessanten Artikel – diesmal Details zum Job Queue System von Slack.
Die Job Queue verarbeitet alle Nachrichten – Posts, push notifications, URL Previews, Kalender Erinnerungen und Billing Nachrichten. Insgesamt prozessiert das System so bis zu 1,4 Milliarden Nachrichten pro Tag – im Peak bis zu 33.000 Messages pro Sekunde. Und wie hat Slack das gebaut?
Initial hat Slack Redis als einzige Job Queue verwendet – dies hatte ein paar architektonische Probleme:
- Gab es Nachrichten Stau – so stieg der Memory Verbrauch in Redis massiv an – im „Outage“ Fall, konnten teilweise keine neuen Nachrichten mehr angenommen werden
- Client Connection Overhead bei Verwendung von mehreren Redis Instanzen
- Worker Anzahl konnte nicht beliebig skaliert werden – da jeder weitere abarbeitende Worker die Last auf Redis selbst erhöht hat
- Aufgrund der Datenstruktur in Redis wird das alles komplexer und aufwendiger, je mehr Daten Redis enthielt
Man hat sich überlegt, auf eine reine, persistene Lösung – wie Kafka zu wechseln oder gar eine eigene zu schreiben. Allerdings sah man auch das Risiko, eine solch große Änderung in ein bestehendes, komplexes und weltweit rund um die Uhr genutztes System einzubauen:
We knew that implementing all these potential architectural enhancements would require significant changes in the web app and the job queue workers.
The team wanted to focus on the most critical problems and gain production experience with any new system components rather than attempt to do everything at once.
Daher entschied man sich, für diverse, kleinere Iterationen und gegen eine einzelne, größere Änderung. Kafka vor Redis zu stellen, erschien als die sinnvollste Variante – so konnten Produzenten und Consumer langsam migrieren, und man kann diverse Use-Cases trotzdem noch in Redis belassen, wo dies sinnvoll ist.
Die Kafka Infrastruktur hat man auf eigenen EC2 Hosts bei AWS aufgesetzt und diese natürlich vorher ordentlich getestet.
Auch der Migrationspfad im Blog-Artikel ist eine gute Empfehlung für eine Migration in der Größenordnung.
Jabber.ru Traffic Interception bei Hetzner und Linode?
Ein Artikel hat am Freitag auf Hacker News und anderweitig für ordentlich Furore gesorgt.
Laut einer detaillierten Debugging-Analyse hat Hetzner und Linode den Jabber / XMPP Traffic von jabber.ru abgefangen und ggf. weitergeleitet. Man habe die Man-in-the-Middle (MITM) bemerkt, da man auf ein abgelaufenes Zertifikat stieß – was ungewöhnlich war, da dies ansonsten automatisch funktionierte.
Es sieht danach aus, als habe man vor den Servern bei Linode und Hetzner den Traffic abgefangen und ein eigenes Zertifikat ausgestellt – da die Betreiber von jabber.ru kein CRT Logging aktiv haben bzw. diese nicht beachtet haben, haben sie den Vorfall erst mit dem abgelaufenen Zertifikat mitbekommen.
Der angegriffene Service, jabber.ru, ist der älteste und größte russische XMPP Server, den es schon seit dem Jahr 2000 gibt.
Das erste Zertifikat wurde am 18. April 2023 erstellt und vermutlich lief seit kurz danach der Mitschnitt des Traffics.
Hetzner und Linode waren bisher für eine Stellungnahme nicht zu erreichen – mal schauen, ob da überhaupt was kommt.
Am Ende des Artikels gibt es Tipps und Tricks, um solche Vorfälle zumindest im Monitoring der Traffic oder Zertifikats-Kette mitzubekommen.
Postmortems: Wissenstransfer und Erfahrungsaustausch
Im Blog von Incident.io gibt es einen tollen Guide zum Thema postmortem Dokumente.
Warum sollen sie erstellt werden? Wieso? Und was hat das Ganze für einen Zweck?
Der Zweck ist jedenfalls nie, Schuldzuweisungen schriftlich niederzuhalten. Die Idee eines Postmortems ist immer, Incidents besser zu verstehen, Wissen zu teilen und widerstandsfähigere Prozesse zu entwickeln, damit ein ähnlicher Incident in Zukunft vermieden werden kann. Das Verständnis ist ganz klar im Vordergrund – und dieses Wissen dann auch zu teilen.
Postmortem-Dokumente fördern zudem kontinuierliches Lernen und Verbesserungen, indem sie Problemfelder wie unzureichende Schulungen, Schwachstellen im System und Prozessverbesserungen aufdecken. Am besten beginnt man mit der Erstellung des Dokuments schon während des Incidents, wenn das nicht klappt – dann direkt danach, damit man auf keinen Fall etwas vergisst. Auch sollten alle Beteiligten Ihren Senf beisteuern und das Verfassen nicht einer Person alleine überlassen werden.
Die Learnings können dann später verteilt und transparent gemacht werden. Mit der Zeit sollte das System robuster und das Wissen breiter gestreut worden sein.
Better learning from incidents: A guide to incident post-mortem documents
Spacedrive – Next Generaton FileManager
Das Spacedrive Projekt hatte ich hier im letzten Jahr schon vorgestellt. Nun hat es noch fast 1,5 Jahre bis zum ersten Release gedauert – immerhin eine erste Alpha Version.
Immerhin hat man 2 Millionen $ Funding und über 22.000 GitHub Sterne eingesammelt – da kann man auch mal was releasen.
Spacedrive ist in soweit besonders, da es mehrere lokale und Netzwerkdrives organisiert, indiziert und auch Offline zur Verfügung stellt. Es synct beispielsweise euer (daheim lokales) NAS mit eurem Desktop in beide Richtungen, zeigt Thumbnails an, organisiert die Files mit Tags und sucht über alle Folder.
Später soll es möglich sein, Dropbox, Google Drive und andere Cloud-Services mit in den einen Spacedrive einzuhängen – am Ende wird Spacedrive also sowas wie ein Meta-Cloudspeicher mit modernem Frontend.
Spacedrive ist zudem außergewöhnlich, da es neben MacOS und Windows auch Support für einen Linux Client gibt.
Übergreifend soll es zudem ein zentrales Backup und ein SaaS Angebot geben – alle Features findest du im verlinkten Blog Announcement zum Alpha Release.
Caschy war nach einem ersten Test jetzt nicht so begeistert, aber ist ja wie gesagt auch noch alles im Alpha Stadium.
Schmunzelecke
Kennst du noch Lotus 1-2-3?
Nein?
Das ist eine 30 Jahre alte Software… oder älter?
Jedenfalls hat Tavis Ormandy sich die Software besorgt, ein wenig Reverse Engineering betrieben und Lotus 1-2-3 nun auf Linux portiert.
Verrückt, oder?
💡 Link Tipps aus der Open Source Welt
Marvin – Security Scanner für K8s
Marvin ist ein CLI Tool, welches einen Kubernetes Cluster scannt und über Sicherheitslücken und Fehlkonfigurationen informiert.
Es versucht sicherzustellen, dass man sich an „Best practices“ hält.
Marvin kannst du per cURL installieren oder auch via krew – kubectl krew install marvin.
Wie so ein Check Ergebnis aussieht, kannst du hier anschauen. Marvin erlaubt zudem das Schreiben eigener Checks über CEL Expressions – neue Standard Checks gibt’s dann auch über Release Upgrades von Marvin.
https://github.com/undistro/marvin
PostgREST – Rest API für PostgreSQL
PostgREST ist, wie der Name schon sagt, eine RESTful API für eine vorhandene PostgreSQL DB.
Falls du schnell eine API für deine DB benötigst oder keine Zeit hast, eine eigene zu schreiben – diese kannst du einfach installieren und nutzen.
PostgREST verwendet die Security Mechanismen, die PostgreSQL schon bietet (via Web Tokens) – auch da musst du also nichts bauen. Eine Versionierung der API ist über verschiedene DB-Schema möglich – cool gelöst. Und Dank OpenAPI Standard kannst du Tools wie Swagger-UI für die Dokumentation der API verwenden.
PostgREST startet einen Daemon auf Port 3000 – darüber wird die API dann exposed.
https://github.com/PostgREST/postgrest
❓ 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: