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:
Microservices vs. Monolith – oder doch Modulith?
In Ausgabe 103 hatte ich den viel und kontrovers diskutierten „Scaling Prime Video Monitoring“ Artikel geteilt.
Kristian „Isotopp“ Köhntopp hat den Artikel auf heise.de kommentiert. Er fasst zusammen, dass das Team mit den von ihm gewählten Mitteln schnell habe liefern können, beim Skalieren dann aber festgestellt, dass die Produktauswahl etwas ungünstig war:
Lambda und Step-Functions seien für Web-Anwendungen gedacht, nicht aber für Batch Bearbeitung von Videostreams. Und S3 Speicher ist für niedrige Transaktionsraten gedacht, und für „für Dienste, die hohe Latenzen tolerieren können“ – in dem Fall hätte man aber einen schnellen Speicher benötigt.
Die Lösung lag nun auf der Hand: die Komponenten in einem „lokal kommunizierenden System“ zusammenzuführen, damit die Latenzen für Aufrufe gegen S3 wegfallen und grundsätzlich weniger Netzwerk Traffic nötig sei. Dies spart neben einer Menge Rechenzeit eben auch Zeit.
Prinzipiell gut sei die Kapselung der Komponenten gewesen, denn diese erlaubte dem Team, schnell auf eine andere Architektur umzusteigen:
In einem sauber konzipierten und gekapselten System mit einer guten Software-Architektur kann man die Komponenten ohne große Codeänderungen rekonfigurieren und den Zuschnitt des Systems ändern – ohne, dass man bei null neu anfangen muss.
Kris beschreibt dann, dass das Prime-Video Team einen „Modulith“ gebaut habe, nur eben anders vorgegangen sei, als man es gewohnt ist. Normalerweise baue man einen Monolithen und löse dann zu skalierende Teile heraus. AWS habe aber der Einfachheit halber Komponenten der eigenen Plattform verwendet und entsprechend kombinert.
Werner Vogels, CTO von Amazon, antwortet in „Monoliths are not dinosaurs“ auf seine Art und Weise auf das Feedback zum ursprünglichen Artikel. Er beschreibt, dass jeder heutige Stack irgendwann „steinalt“ sein wird, wie die Dinosaurier eben – wichtig sei, sich anpassen zu können. Amazon S3 selbst sei ursprünglich als Service mit wenigen Microservices gestartet und umfasse heute alleine über 300 Microservices, die nur am Betrieb, Konfiguration, Auditierung und Auslieferung von Files aus dem Object Storage verwendet werden.
In Summe komme es auch immer darauf an, wer was baue:
For example, a startup with five engineers may choose a monolithic architecture because it is easier to deploy and doesn’t require their small team to learn multiple programming languages. Their needs are fundamentally different than an enterprise with dozens of engineering teams, each managing an individual subservice
Er schreibt weiter, dass Monolithen absolut nicht tot seine, aber dass es wichtig sei, Software so zu bauen, dass sie sich weiterentwickeln kann.
Adrian Cockroft hat hier dazu noch mal eine ganz andere Meinung. Er vertritt den Ansatz „Serverless First“ – und dann „serverless“ durch andere Komponenten zu optimieren, wenn nötig:
I recommended that if you need sustained high traffic, low latency and higher efficiency, then you should re-implement your rapid prototype as a continuously running autoscaled container, as part of a larger serverless event driven architecture, which is what they did.
Er meine, Amazon habe daher „best practice“ verfolgt und vor allem schnell geliefert – dies sei dann auch voll ok, damit man einen Service vor dem Wettbewerb am Markt hat.
Diese Argumentation ist natürlich auch nicht von der Hand zu weisen.
Amazons neuer Modulith – Services neu zuschneiden macht noch keinen Monolithen
Milliardenstrafe für Meta – Konsequenzen?
Wie du vielleicht mitbekommen hast, hat es datenschutztechnisch in der letzten Woche einen ordentlichen Paukenschlag für Meta gegeben.
Der US-Konzern wurde von der irischen Datenschutzbehörde mit einem Rekord Bußgeld in Höhe von 1,2 Milliarden Euro abgestraft, da Meta Daten europäischer Nutzer an die US-Geheimdienste weitergegeben haben soll.
Meta hat nun 6 Monate Zeit, auf das Urteil zu reagieren und einen Abfluss der entsprechenden Daten zu verhindern – und dies auch nachzuweisen?
Naja, jedenfalls hofft man nun, dass die US-Regierung und die EU ein neues Abkommen für die Verarbeitung der Daten europäischer Staatsbürger verabschieden.
Ob das innerhalb der 6 Monate klappt? Naja, wir werden sehen.
Was nun witzigerweise passiert, ist, dass die Entscheidung aufgeschreckt hat. Sentry, ein SaaS Error Tracking Dienst aus den USA, hat nun in gewohnt öffentlicher Manier ein GitHub Issue namens „EU Data Residency“ in Bearbeitung. Sämtliche Tracking Daten, Session Replays, Profile und Transaktionen sollen demnach in Zukunft nur noch in der EU gespeichert werden – in einem eigenen EU Tennant von Sentry.
Weiterhin in den USA sollen weiterhin User Accounts, 2FA Token, Audit Logs und Meta-daten aufbewahrt werden. Im Prinzip sind das dann Daten von Firmen, die direkt Sentry Kunden sind und auch dafür bezahlen. Und die auch ihre Nutzer wiederum über die Nutzer von Sentry aufklären müssen.
Ob nun Google mit Analytics hier ebenfalls reagiert?
Facebook-Konzern Meta soll 1,2 Milliarden Euro Strafe zahlen
Sponsored
Incident Response – die Komplettlösung für Betriebsteams
Managen Sie Rufbereitschaften, reagieren Sie auf Vorfälle und kommunizieren Sie diese über Statusseiten in einer Software.
Jedes Feature in ilert wurde dazu entwickelt, um Ihnen zu helfen, schneller auf Vorfälle zu reagieren und die Uptime zu erhöhen.
DB Migration: Von Supabase zu Render?
„Val Town“ kannte ich bisher noch gar nicht – hier kannst du Code Snippets teilen und gemeinsam daran arbeiten. Die Code Snippets laufen direkt im Browser bzw. auf den Servern von „Val Town“.
Jedenfalls hat man bei „Val Town“ eine Migration von Supabase zum Cloud Anbieter „Render“ gemacht. Dies ist in soweit ungewöhnlich, da die Migration eigentlich in die andere Richtung laufen. Supabase ist mehr wie eine Datenbank – das ist eher vergleichbar mit Firebase von Google Cloud (Datenbank, Authentication, Storage und Funktionen – alles in einem).
Interessant jedenfalls, warum man nun gewechselt hat:
Vor allem sei die lokale Entwicklung problematisch gewesen, da man „modifikationen“ direkt in der Live DB einspielt. Man testet also Migrationen, in dem man produktive Tabellen dupliziert und auf diesen arbeitet. Teilweise wurde dann der WebEditor genutzt, der dann auch schon mal einen FK Constraint entfernt hat (Bug ist noch offen).
Eigentlich soll man lokal mit der „Supabase CLI“ testen können – die insgesamt 11 Docker Container, die mit einer kommunizieren, scheinen lokal aber nicht voll funktionsfähig zu sein.
Zusätzlich lasse die Dokumentation zu wünschen übrig und natürlich gibt es Downtimes. Diese Downtimes sind dann aber anders, als man sie sonst kennt. Supabase verspricht beispielsweise auto-grow – wenn das aber nicht funktioniert und die DB VOLL ist, dann klemmt es, logischerweise.
Lange Rede, kurzer Sinn: Man hat nun auf ein klassisches Setup bei Render mit einer „Vanilla PostgreSQL“ gewechselt und dort nun wieder zufrieden:
It feels strangely (back to the) future-istic to have migrations that run locally, in preview branches, and upon merging to main. … Back in our Supabase days, we delayed features like that merely because touching the database schema was scary
Neue Technologien sollten einem dann schon alles erleichtern, und nicht nur einen Teil der User-Experience.
Spannend, hätte nicht gedacht, dass Supabase unter der Haube mit solchen Themen zu kämpfen hat. Falls jemand ein Stellungname vom Supabase Team zur Thematik gefunden hat – gerne her damit.
Verfügbarkeitsprobleme bei GitHub
GItHub hatte Anfang Mai öfter mal einen Schluckauf – von kleineren Störungen bis zu längeren Ausfall.
Beispielsweise am 8. Mai – aufgrund eines Database Config Changes waren 8 von 10 Services nicht verfügbar – die Downtime dauerte über 1 Stunde.
Zwei Tage später, am 10. Mai, gab es eine Störung der GItHub Auth Tokens – mit Peaks von bis zu 76 % Fehler-rate beim Abrufen von GitHub App Permissions. Grund der Störung waren in performante Änderungen am API System, welche schlussendlich in Timeouts und Störungen beim User resultierten.
Einen Tag später, am 11. Mai, gab es wieder ein DB-Fehler aufgrund einer Störung der DB Replicas – von denen Daten gelesen werden können. Damit wurde die Master DB mit lesenden Zugriffen überlastet und es kam zu einer weiteren Störung, welche einen kundenseitigen Impact hatte.
Warum schreibe ich das alles?
Nun ja, nicht, um mich darüber lustig zu machen. Sondern primär um zu zeigen, dass alle nur mit Wasser kochen.
Störungen gibt es überall, jeden Tag – egal wie gut die Applikationen geschrieben, die Architektur gebaut und die Observability im Griff ist.
Entscheidend ist der Umgang mit solchen Ausfällen.
GitHub hat den Anspruch, sehr transparent mit den Ausfällen umzugehen und diese den Usern in einem „Monthly Availabiity Report“ mitzuteilen – Chapeu!
Addressing GitHub’s recent availability issues
Memory Allocation: Wie funktioniert malloc und free?
Nach der coolen „Loadbalancing“ Visualisierung in Ausgabe 100 habe ich nun etwas Ähnliches für die Erklärung von „Memory Allocation“ gefunden.malloc und free stemmen aus dem Jahr 1979 und sind damit älter als ich 🙂
Der Artikel erklärt, wie die Allokierung und die Freigabe von Memory erfolgt – und das wirklich cool visualisiert.
Zusätzlich wird erklärt, wie Memory dann „fragmentiert“ wird, also Speicherblöcke zwischendrin frei bleiben. Allerdings kann man diese dann nicht „Defragmentieren“, die Programme haben sich ja die Speicherplätze gemerkt – die dürfen wir nicht verschieben. Deshalb allokiert man eher mehr Speicher, als man benötigt, sodass noch Platz dazwischen frei bleibt.
Im Advanced Mode kannst du dann mit dem „Allocator Playground“ herumspielen.
Und wie es sich gehört, gibt es eine HackerNews Diskussion zum Thema – mittlerweile über 170 Kommentare.
GitLab 16.0 released
GitLab hat die nächste Major Version 16.0 am 22. Mai 2023 veröffentlicht. Im Release finden sich über 55 Verbesserungen von über 304 verschiedenen Contributoren.
Ein paar Highlights:
- „Value Stream Dashboards“ sind nun verfügbar – spezielle Metriken, die vor allem für den Life-Cycle und Stakeholder interessant sind (GitLab Ultimate erforderlich)
- Die GitLab SaaS Runner erhalten nun die doppelte Menge an RAM und vCPUs – ohne Mehrkosten.
- Die SaaS Runner gibt es in Premium und Ultimate nun auch GPU-enabled.
- Kommentare in Issues können nun effizienter mit „Comment Templates“ geschrieben werden
- Die neue Web IDE ist nun GA und nicht mehr Beta
- GitLab Tokens können nun per API rolliert werden
- In GitLab SaaS „Ultimate“ gibt es nun AI-powered Workflows
- GitLab Error Tracking ist nun ebenfalls GA (auch nur SaaS).
- AI basierte Code-Suggestions sind in GitLab SaaS für 13 Sprachen verfügbar.
- über ein Feature Toggle kann auf die neue Navigation umgestellt werden
- Für Labels in GitLab gibt es nun einen Color-Picker (und nicht mehr nur die vorgegebenen Farben)
- GitLab Runner können nun als User auf Instanz Ebene erstellt werden
- Self-Managed GitLab Instanzen werden auf 2 DB Instanzen migriert
Ne ganze Menge drin in Release 16.0 – schau selber mal auf der Release Page, was dir noch so gefallen hat.
Version 16.1 erscheint dann schon im nächsten Monat, am 22. Juni 2023 – ein Preview auf die darin enthaltenen Features findest du ebenfalls schon online.
Nutzt du die AI Features schon?
GitLab 16.0 released with Value Streams Dashboards and improvements to AI-powered Code Suggestions
Schmunzelecke
Tja, „Lost Children will be taugt Kubernetes Networking“ – war für mich die Woche irgendwie ähnlich passend wie vielleicht der CNCF Hype-Cycle hier.
💡 Link Tipps aus der Open Source Welt
Cron Wrapper von Axel
Tja, jetzt mache ich das so lange und kannte bisher den Cron Wrapper von Axel Hahn noch nicht – man lernt halt nie aus.
Den Cron Wrapper von Axel solltest du für all deine CronJobs verwendet.
Er fängt den Response-Code ab, speichert die Logfiles in einem Standardverzeichnis (kümmert sich also um die Umleitung) und zusätzlich kommt der Wrapper mit einem Cronstatus Script, welches alle Cronjobs überwacht, die über den Wrapper gestartet werden.
Für Cronstatus gibt es wieder check_cronstatus, welches du mit Icinga/Nagios oder kompatiblen Werkzeugen abfragen kannst.
Als wäre das nicht genug, kommt der Wrapper noch mit einem eigenen Helper Include, welche du einfach in deinen Skripten nutzen kannst, um die Möglichkeiten des Wrappers zu nutzen.
Die Doku selbst ist gut und beantwortet alle Fragen, die du jetzt noch haben könntest. Danke Axel!
https://github.com/axelhahn/cronwrapper
Kostenlose „Cloud Security“ Tutorials
Das verlinkte Repo enthält über 20 Security Tutorials – um Security direkt zu lernen.
Für Google gibt es etwa den GCPGoat – mit Skripten baust du eine Umgebung in deinem Account auf und greifst diese dann selbst an, um zu verstehen, wie sowas in der Praxis passiert. Ähnliches gibt es bei „Broken Azure“ für Azure Cloud oder auch den „AWS Goat“ nun ja, für AWS.
Ebenfalls für AWS ganz interessant, den „IAM Vulnerable“ – eine verschachtelte AWS IAM Landschaft, die eben angreifbar ist.