allesnurgecloud #07 – Linux auf dem Mars, Testing in Production, AWS Historie und mehr.

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:

506 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.

Anwendungen skalieren kann man nur, wenn man sie versteht

Das übliche Argument für eine Cloud Migration ist das Thema „Skalierung“. „Wir müssen in die Cloud gehen, weil das on-premise nicht mehr skaliert“. In der Regel sind die Skalierungsprobleme hier aber nicht Infrastruktur bedingt, sondern zu 95% ein Problem aufseiten der Anwendung.

Kris erklärt dies im Beitrag „Testing in production blues“ anhand von zwei prominenten Beispielen. Der eine ist der „Moodle Case“ von Anfang Januar, bei dem ein fehlender DB-Index reihenweise für Ausfälle der Lernplattform gesorgt hatte. Das Problem einfach in die Cloud zu verschieben oder mit noch mehr Servern zu erschlagen wäre hierbei absolut nicht zielführend gewesen.

Beim zweiten Beispiel war ich häufig an der Entstörung beteiligt, da der Login Dienst von web.de damals in der Verantwortung meines Teams lag. 10 Millionen Logins pro Tag waren hierbei auf den ganzen Tag verteilt für die Anwendung und darunter liegende Infrastruktur kein Problem – fiel aber ein anderer Dienst aus und alle Nutzer mussten sich neu einloggen, so führte das zu einem „DDOS“ der User auf den Login Dienst. Häufig haben User, die permanent F5 gedrückt haben, diese Situation noch weiter verschlimmert. Die Lösung war damals eine recht einfache Änderung der Datenstruktur – hinterher ist man immer schlauer.

Testen muss man seine Anwendung daher permanent und nach jeder Änderung. Den besten Test machen immer die User/Kunden selbst.

Eine Cloud Migration verlagert das Skalierungsproblem häufig nur. Anders formuliert: Versteht man seine Anwendung on-premise schon nicht, versteht man sie in der Cloud erst Recht nicht.

zum Artikel „Testing in production Blues“


Linux ist auf dem Mars gelandet

Mit der Landung des Mars Rover Perseverance ist das Linux Betriebssystem auf dem Mars angekommen. Der Mars Rover selbst nutzt zwar ein proprietäres OS(VxWorks) – die mit dem Rover gelandete, Helikopter ähnliche Drohne „Ingenuity“ läuft hingegen mit Linux. Die Flugsteuerung basiert auf dem Software Framework F‘, welches sogar von der NASA JPL (Jet Propulsion Laboratory) open-sourced wurde und frei zur Verfügung steht. Das Flight Software & Embedded Systems Framework findet ihr auf GitHub. Es kann für „diverse Anwendungen im Weltraum“ verwendet werden. Ein interessantes Interview mit dem Piloten von Ingenuity zur Vorbereitung und den bevorstehenden Herausforderungen findet ihr auf heise.de.

Die Entscheidung für Linux fiel aufgrund der Verwendung des Snapdragon 801 Prozessors von Qualcomm, welcher zu VxWorks nicht kompatibel war. Einen Vergleich der bisher verwendeten Betriebssysteme inkl. technische Daten der Rover könnt ihr bei Wikipedia einsehen. Spannend finde ich, dass der Rover selbst die gleiche CPU/RAM Spezifikationen nutzt, wie Curiosity aus dem Jahr 2011 – eine 200 MHz CPU mit 256 MB RAM. Vermutlich läuft da nichts mit Java und auch kein NodeJS.

zum Artikel „Linux is now on Mars“ im PC Mag


Die Anfänge von AWS – aus der Sicht von Dan Rose

In Ausgabe #03 hatte ich bereits die Historie von GCP aus der Sicht eines Mitarbeiters geschildert. Anfang Januar teilte Dan Rose seine Sicht zu den Anfängen von AWS auf twitter.

Er berichtet in einem Twitter Thread über seinem Start bei Amazon in 1999 und den horrenden Ausgaben für Hardware und dem Tausch der teurer SUN Hardware gegen HP Server mit Linux an Bord. Während der einjährigen SUN ⇒ Linux Migration mussten Produkt Innovationen hinten anstehen und das Gelingen der Linux Transition war kritisch für das komplette Unternehmen. Immerhin sollten 80 % der IT Kosten damit eingespart werden.

Die Migration hat dann glücklicherweise ohne Probleme geklappt. Aufgrund der „Peak“ Optimierung auf das Weihnachtsgeschäft im November/Dezember überlegte Jeff Bezos, ob es nicht besser wäre, die überschüssige Server Kapazität für den Rest des Jahres an andere Firmen zu vermieten. Das habe schließlich mit dem Stromnetz auch so geklappt. Im Jahr 2000 benötige man ja schließlich keinen eigenen Stromgenerator mehr, warum brauche man in Zukunft ein eigenes Data Center? Heute ist AWS mit über 45 Milliarden Dollar Umsatz und 13,5 Milliarden Dollar Gewinn für über 60 % des Profits von Amazon verantwortlich.

zum Threadreader Twitter Thread von Dan Rose


Cloud Kosteneinsparung durch Komprimierung

Lawrence Jones, ein Site Reliabilty Engineer des Zahlungsanbieters GoCardless, beschreibt in einem Blog Beitrag mögliche Kosteneinsparungen durch Komprimierung. GoCardless verwendet für die Migration von 60 TB JSON Log Dateien zwischen 2 Elasticsearch Clustern den Google Cloud Messaging Dienst Pub/Sub. Den dominierenden Kostenanteil machen die Anzahl bzw. Größe der übertragenen Daten und die Speicherdauer aus.

Eine einmalige Übertragung der Rohdaten (in der Regel bleibt es nicht bei einmalig) hätte fast 13.000 Dollar gekostet. Die Kompressionsrate der Logdateien (üblicherweise besonders hoch) betrug 12 %, d.h. die Daten konnten auf 12 % ihrer ursprünglichen Größe reduziert werden. Die Ersparnis der einmaligen Übertragung betrug 11.500 $. Natürlich kostet es auch CPU Zeit am Origin, die in diesem Fall nicht betrachtet wurde.

GoCardless hat die Komprimierung nun auch für die „normale“ Logfile-Übertragung aktiviert und spart somit auch mehrere 1000 $ Pro Monat an reinen Kosten. Hierfür haben Sie das fluentd Pub/Sub Plugin gepatched.

Im Beitrag könnt ihr auch lesen, dass Komprimierung bei Datenbanken ebenfalls Sinn ergeben kann, was man sich aber im Detail anschauen müsste.

zum Blog von „Lawrence Jones“


💡 Link Tipps aus der Open Source Welt

Apprise – Push Notification Framework

Apprise ist ein in Python geschriebenes Meta Notification Framework, welches man einfach in Anwendungen einbinden kann.
Über Apprise könnt ihr über alle gängigen Notification Dienste versenden:
Populäre Notification Dienste wie Discord, Matrix, Nextcloud, Microsoft Teams, RocketChat, Slack und Twitter sind ebenso unterstützt, wie der SMS Versand über AWS SNS, Nexmo oder Twilio. Selbst Desktop Notifications an Linux (Gnome/DBUS) oder MacOS sind genauso möglich wie eine Standard-E-Mail.

https://github.com/caronc/apprise

Superwerker – Best Practice Schnellstart in der AWS Cloud

Superwerker ist eine Open Source Lösung der AWS Advanced Partner superluniar und kreuzwerker, welche es Start-ups und KMUs erleichtern soll, ihre Dienste auf AWS aufzubauen.
Die best-practice Lösung rollt euch hierbei über AWS Cloudformation eine komplette Infrastruktur auf den AWS nativen Diensten aus: AWS Control Tower, Amazon GuardDuty, AWS Security Hub, AWS Backup und AWS System Manager.
Ist euch das zu viel „Gefachsimpel“, schaut euch einfach die „non technical“ Erklärung auf GitHub an.

https://github.com/superwerker/superwerker

SSH tunnels – Visuelle Beispiele und use Cases

Wie funktioniert der SSH Tunnel jetzt nochmal, wenn ich die Datenbank Connection tunneln will?
Hierbei hilft euch vielleicht diese Visualisierung, oder ihr könnt sie präsentieren, falls euch jemand fragt.
Dadurch wird auf einfache Weise gezeigt, in welcher Richtung und mit welchen Ports der Tunnel nun aufgebaut wird.
Im GitHub Projekt könnt ihr Änderungen vorschlagen oder bestehende Beispiele verbessern.

https://github.com/linrock/ssh-tunnels

drapunir – anonymisierte Test Datenbanken als Service

Die oben erwähnte Firma GoCardless hat ein Toolset veröffentlicht, mit dem ihr PostgreSQL Datenbanken mit Testdaten erzeugen könnt. Spätestens nach dem Lesen des „Testing in production Blues“ sollte klar sein, dass ihr sicherstellen solltet, euren Testdatenbestand ähnlich groß zu halten, wie eure live Daten. Sonst müsst ihr eben wirklich in Produktion testen.
Verwendet ihr statt PostgreSQL eher MySQL oder MS SQL, so könnte euch der pynonymizer vielleicht helfen.

https://github.com/gocardless/draupnir

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

506 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.


  • Neueste Beiträge

  • Neueste Kommentare


  • Share

    By About
    Abonnieren
    Benachrichtige mich bei
    guest

    0 Comments
    Inline Feedbacks
    View all comments

    allesnurgecloud.com

    © 2024 allesnurgecloud.com
    0
    Would love your thoughts, please comment.x