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:
Nachhaltige Software Architektur in der Cloud Ära
Das große Thema dieser Zeit ist die Nachhaltigkeit. Doch was bedeutet Nachhaltigkeit im Bezug auf moderne Software Architektur in der agilen & digitalen Welt, in der Software in der Cloud läuft?
Der verlinkte Artikel im StackOverflow Blog versucht hier etwas Licht ins Dunkel zu bringen und beschreibt erstmal 6 Prinzipien einer „Continuous Architecture“, denn wie Software auch, ist IT Architektur nie fertig – sondern ein kontinuierlicher Prozess.
Man sollte sich an folgenden 6 Prinzipien orientieren:
- „“Architect products; evolve from projects to products“: Man sollte seine Arbeit als sich ständig veränderndes Produkt sehen, und nicht als ein statisches Projekt
- „Focus on quality attributes, not on functional requirements“: Der Fokus sollte auf Qualitätsmerkmalen liegen, die der Kern einer nachhaltigen Architektur sind (Beispielsweise sind dies: Cost Effectiveness, Configurability, Performance, Robustness)
- „Delay design decisions until they are absolutely necessary“: Manche Design Entscheidungen trifft man zu einem Zeitpunkt, wo man gar nicht genau weiß, die das Produkt am Ende aussehen wird. Deshalb ist es vollkommen ok, mit keiner 100% Lösung zu starten, die alle Eventualitäten abdeckt – aber Vorsicht, hier entstehen „Technische Schulden“.
- „Architect for change—leverage the “power of small.”: Änderungen sind an kleineren Einheiten einfacher, als an großen Monolithen. Zu klein darf es meiner Meinung nach auch nicht werden, denn hier lauert massiver Overhead.
- „Architect for build, test, deploy, and operate“: Man sollte bei der Architektur auch Konsequenzen bezüglich „testing“, „deployment“ und „operations“ im Auge behalten, und nicht nur „build“ im Fokus haben
- „Model the organization of your teams after the design of the system you are working on“: Teams so aufstellen, dass sie zur Architektur der Systeme passen.
Die Autoren empfehlen dann 4 wesentliche Aktivitäten, wovon mir eine ins Auge sticht:
Know your technical debt, the understanding and management of which is key for a sustainable architecture.
Mit vielen Architektur Entscheidungen geht man Kompromisse ein, die teilweise nicht ohne Konsequenzen bleiben. Hier entstehen technische Schulden, die man irgendwann zurückzahlen sollte. Hier ist ein transparenter Umgang mit dem Thema wichtig, denn es kann absolut Sinn machen, zum Zeitpunkt A eine technische Schuld in Kauf zu nehmen, die einem zu Zeitpunkt B auf die Füße fallen könnte. Irgendwann dazwischen sollte man sie daher beheben.
Sustainable architectures in a world of Agile, DevOps, and cloud
NPM Package löscht Files aus Protest zum Ukraine Krieg
Die Maintainer des populären NPM Packages node-ipc haben am 8. März eine modifizierte Version ihres Packages veröffentlicht, welche die kompletten Projektdaten löscht, falls der User eine externe IP aus Russland oder Belarus verwendet.
Die Aktion dient als Protest gegen den Ukraine-Krieg und stellt das Node Ökosystem ein wenig auf den Kopf.
Durch teilweise automatisches Dependency Management wurde die „kompromittierte“ Version in diversen Abhängigkeiten gezogen, und hat beispielsweise um Vue.js Universum für ordentlich Furore gesorgt, beispielsweise beim CLI Tool „Vue.js CLI“.
Das Paket node-ipc hat über eine Million Downloads in der Woche und eine solche Änderung kann ordentlichen Schaden anrichten.
Die betroffenen Versionen sind mittlerweile von npm entfernt worden – zusätzlich gibt es einen eigenen CVE dafür (CVE-2022-23812).
Diese Fall zeigt mal wieder, wie verwundbar das Node Ökosystem gegen solche „Supply Chain“ Attacken sein kann, und warum es Sinn macht, seine Versionen zu pinnen und regelmäßig auf CVEs zu scannen.
Golem hat hier ebenfalls über den Fall berichtet.
BIG sabotage: Famous npm package deletes files to protest Ukraine war
Sponsored
Managed Hosting für Symfony und Laravel
Wir helfen Dir beim 24×7 Betrieb, bei Performance Problemen, bei Kostenoptimierung oder einfach beim Betrieb deiner Laravel & Symfony Web-Applikationen beim Cloud-Anbieter deiner Wahl.
Betreibst du Services wie GitLab, Zammad und Matomo selbst – hierbei unterstützten wir ebenfalls gerne – schau Dir einfach mal unsere Leistungen an.
Unsere Kunden kommen in unseren Case Studies zu Wort – wie beispielsweise diginights.com – ein Online Ticketing System auf Basis von Symfony.
Interessiert? Lerne uns einfach in einem 15 Minuten Video-Call kennen.
Kaskadenfehler in verteilten Systemen
In der letzten Woche hatte ich es mal wieder mit einem größeren, kaskadierenden Fehler zu tun.
Kaskadierende Fehler (Cascading failures) kann man sich als eine Art Lawine vorstellen – häufig bringt ein kleiner Stein Vorgänge ins Rollen, die dann später komplett verteilte Systeme in Mitleidenschaft ziehen können.
Solche Fehler sind schwer zu debuggen oder in Testsystemen nachzustellen, da häufig das User-verhalten, oder die Reaktion von Dritten die Vergrößerung der Lawine maßgeblich beeinflusst.
Wie es der Zufall so will widmet Harri Fassbender im Blog der HDM (Hochschule der Medien, Stuttgart) dem Thema „Cascading Failures“ einen ausführlichen Artikel und nennt diverse, populäre Beispiele für solche Ausfälle:
Harri beschreibt auch Antipattern, die man vermeiden sollte, unter anderem sind dies:
- Acceptance of an unrestricted number of requests: Eure Umgebung sollte von einem rate-limiting fähigen Reverse Proxy/Load-Balancer geschützt werden können
- Dangerous (client) retry behavior: Der so genannte „F5 Effekt“, wenn User denken, „das liegt an mit“ und kontinuierlich F5 drücken und somit für die 10/100-fache Request Anzahl sorgen.
- Work prompted by failure: Fehler in einem System können die Load/Fehler in anderen Systemen deutlich erhöhen.
Schaut gerne mal rein, der Artikel beschreibt das viel besser als das ich das hier ansatzweise zusammenfassen könnte.
Cascading failures in large-scale distributed systems
macOS: Docker Desktop mit massivem Performance Gewinn
Docker Desktop auf dem Mac hat in der Vergangenheit für teilweise lange Laufzeiten bei lokalen Entwicklungsumgebungen geführt. Dies ist war allem der Fall, wenn man mit einer Vielzahl an kleinen Files gearbeitet hat, beispielsweise mit NPM, oder auch beim Import von MySQL Datenbanken.
In Docker Desktop for Mac ist nun das neue „VirtioFS“ als Filesystem Layer verfügbar, welches die Performance drastisch erhöhen soll:
- MySQL Import Performance um 90% verbessert (im Beispiel von 3m 16 Sekunden auf 18 Sekunden)
Composer installPeformance um 87% verbessert (von 1m 27 Sekunden auf 11 Sekunden)- Bootvorgang einer Typescript Applikation um 80% verbessert (1m 30 Sekunden auf 18 Sekunden)
Installiert einfach die neuste Version von Docker Desktop (Download Version 4.6) und aktiviert „VirtioFS accelerated directory sharing“ in den Preferences unter „Experimental Features“.
Speed boost achievement unlocked on Docker Desktop 4.6 for Mac
Essentielle Optimierung des Entwickler Workflows
Zach Wolfe, ein Software Engineer bei Amazon, erzählt von den Herausforderungen und Möglichkeiten, den Entwickler „Cold Start“ zu verbessern. Er beschreibt den „Cold Start“ als die Dauer für eine Entwickler Contribution nach einer längeren Abstinenz vom eigentlich Projekt. „Cold Start“ ist für ihn eine Komponente des Onboardings, aber nicht nur das, für ihn gehören dazu: Berechtigungen und Encryption Keys, Datenbankzugriffe, Dependencies, Deployment tools und mehr.
In this context, Cold Start is what it takes for a typical new-to-the-team engineer to make the simplest possible change to an application (think: Hello World).
Laut Zach haben diese Themen großen Einfluss auf die Entwickler Produktivität, Verfügbarkeiten, Umsätze, Qualität und Sicherheit von Applikationen. Als Beispiel nennt er die Log4J Lücke, die teilweise in älterer, nicht mehr aktiv weiter entwickelter Software gefixed werden musste.
Er nennt außerdem diverse Möglichkeiten, das Thema ganzheitlich zu optimieren:
- Entwickler Feedback einholen und das Feedback verarbeiten und optimieren
- Gibt es Skripte/Automatisierungen um die Entwicklungsumgebung einfach zu reproduzieren?
- Prüfung der Abhängigkeiten: Sind die wirklich alle nötig? Was ist überflüssig?
- Dokumentation der zum Kaltstart nötigen Aktivitäten – welche können automatisiert werden? Hier von eine pro Monat beheben (Hallo technische Schuld)
Im Artikel sind auch weiterführende Inhalte verlinkt, schaut gerne mal rein.
Optimize Development Cold Start
Linux Performance debuggen
Das hier gezeigte Schaubild ist auf eurem Mail Client vermutlich viel zu klein.
Es zeigt auf einen Blick eine Vielzahl an Möglichkeiten, um die Performance von Linux über verschiedene Debugging Möglichkeiten zu untersuchen und zeigt außerdem, an welcher Stelle im OS diese Tools ansetzen.
Manche davon kennt ihr sicherlich alle (top, ps, free, netstat) – einige davon sind eher nicht so well-known (lsof, vmstat, strace, perf).
Das Bild in Originalgröße findet ihr im unten verlinkten Artikel oder direkt hier.
Warum man einen Raspberry Cluster braucht
Der bekannte OpenSource Entwickler beschreibt im verlinkten Blog Beitrag, warum man einen Raspberry Pi Cluster braucht – oder auch nicht.
Er verteilt dort dir für sich und sein zu Hause nötigen Systeme in einem verteilten System. Für ihn sind dies: Sein Internet Monitoring System, sein Pi-hole, sein Home Backup, eine Kubernetes Test Umgebung und die Website pidramble.com.
Für ihn bringt es natürlich auch Spaß, aber viel Lerneffekte und die Möglichkeit, Dinge in einer eigenen und abgeschlossenen Umgebung auszuprobieren.
Why build a Raspberry Pi Cluster?
Anstehende Konferenzen im Frühjahr/Sommer 2022
Falls ihr im Frühjahr/Sommer eine Konferenz besuchen möchtet, habe ich hier folgenden Konferenz-Tipps für euch:
- 16.-20. Mai 2022 – KubeCon und CloudNativeCon Europe in Valencia, Spanien (und Virtuell)
- 17. Mai 2022 – GitOps Con Europe in Valencia, Spanien (Teil der KubeCon)
- 19.- 20. Juli 2022 – StackConf in Berlin
- 22.-26. Juli 2022 – Hacker Camp in Holland
- 05. September 2022 – Container Days in Hamburg (auch virtuell)
- 15.-18. September 2022 – EuroBSDCon in Wien
Habt ihr noch weitere Tipps? Welche Konferenzen besucht ihr in 2022?
Schmunzelecke
„Every kubernetes tutorial ever“ – @memenetes
💡 Link Tipps aus der Open Source Welt
PiVPN – OpenVPN und Wireguard
PiVPN ist sicherlich eine der einfachsten Möglichkeiten, um ein VPN auf einen Raspberry Pi zu bekommen.
PiVPN unterstützt die beiden populären VPN Protokolle WireGuard und OpenVPN. Das Tool kommt mit dem eigenen binary pivpn, mit dessen Hilfe ihr VPNs erstellen, ändern, debuggen und backupen könnt. In der Dokumentation zu PiVPN findet ihr dann Hinweise für diverse Clients, beispielsweise Windows, Mac/Linux, Android und iOS.
https://github.com/pivpn/pivpn
Estafette – OpenSource Container Scanner
Estafette ist ein vulnerability scanner für Container innerhalb eines Kubernetes Clusters. Estafette scanned hier regelmäßig aktive Container mit Hilfe der Trivy Scan Engine und reported diese dann.
Installiert wird Estafette via helm chart, das Reporting erfolgt innerhalb von Grafana und die Alarmierung über Prometheus.
Container Scanning sollte man zweistufig machen: während/nach dem Build und eben laufende Container (die ggf. schon länger nicht mehr neu gebaut wird) – bei Zweiterem hilft eben Estafette.
https://github.com/estafette/estafette-vulnerability-scanner
HOUDINI – Docker Images für Network Intrusion
HOUDINI ist eine Kollektion der Penetration Tester von SecSI.
Die Kollektion selbst könnt ihr hier online browsen und für eure Umgebung passende Docker-Images heraussuchen. Die Images sind Kategorisiert, beispielsweise für networking, malware, php oder javascript.
Möchtet ihr selbst weitere Tools beisteuern? Dann schaut doch mal im unten verlinkten GitHub Repository vorbei.
https://github.com/cybersecsi/HOUDINI
❓ 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: