Willkommen zu allesnurgecloud.com – Ausgabe #161
Auch heute gibt es wieder einen größeren WordPress Block im Newsletter – den kannst du zwar einfach skippen, ich würde es aber nicht empfehlen. Aktuell ist es ein dominierendes Thema: Open Source, Community & Governance und was dies alles mit Business zu tun hat. Die Lage bleibt kompliziert und jeden Tag passiert etwas, mit dem man nicht gerechnet hat.
Natürlich kommen die weiteren Cloud News nicht zu kurz.
Podcast „Happy Bootstrapping“ – FestPlan.app
Diese Woche hatte ich Malte Peters von der Festival App FestPlan im Podcast zu Gast. Malte ist Indie App-Developer und baut seit einiger Zeit an seiner Festival App. Im Podcast haben wir darüber gesprochen, warum und wieso er eine App für Festivals baut, wie er diese monetarisiert und welche Herausforderungen das Thema Festival mit sich bringt.
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:
Warum die Public Cloud besser skaliert als die eigene
Nach Rückfrage eines Lesers analysiert Kris Köhntopp in einem längeren Blog Artikel Cloud Kosten vs. On-Premise und die Historie.
In den Rahmenbedingungen zeigt er, dass Chips heute keine höhere SingleCore Leistung mehr bekommen (max 3GHz Dauerleistung), die Hersteller dafür aber mehr Transistoren auf einen Chip bekommen, da die Strukturen immer kleiner werden. Das heisst, wir bekommen mehr Cores und mehr Cache pro Chip. Das war initial der Auslöser der Virtualisierung, die wiederum die Grundlage für Cloud Computing war.
Die reinen Hardwarekosten sind deutlich unter den Preisen eines AWS Servers – aber das ist auch ein „Äpfel und Bananen“ Vergleich. Die Maschine bei AWS ist verkabelt, inventarisiert, per Software provisionierbar und und und. Hat man eine Blade in einem Blade Chassis eingebaut, oder einen 2 HE Server – so ist das erstmal nur ein Server, der eingebaut werden muss, verkabelt sein will, einen Switch/Router und ein Deployment benötigt.
Man kann das daher genauso wenig vergleichen, wie die Preise einer 24TB Harddisk, die im Einkauf als Einzelstück das gleiche kostet, wie die S3 Miete bei AWS für 24 TB für einen Monat (siehe Tweet von DHH).
Damit eigene Hardware für einen funktioniere, benötigt man eine ordentliche Größe. In Zeiten, in denen man 128 Cores pro Sockel bekommt, den Server dann mit 2 TB ausrüsten kann, ist das für eine einzelne Firma häufig schwierig zu erreichen, da ein solcher Server selbst schon zig Anwendungen parallel hosten kann. Wiederum ein Vorteil für den Cloud Provider, da der Provider die ganzen Zusatzkosten wie Netzwerk, Datacenter oder auch dem Menschen, der die Maschinen und Disks austauscht, über 100.000 Server verteilen kann.
Zudem ist On-Premise auch nicht so unabhängig, da Verfügbarkeit und Performance dann an wenigen Servern und Menschen hängt. Kris fasst die ganze Logik Kaskade dann hier zusammen, unter anderem mit:
Als Kunde will ich also eine VM auf vielen Hosts haben und auf einem Host mit vielen anderen Kunden cohosted werden. Ich gehe also lieber zu einer Public Cloud und miete mir da die passenden VMs
Als Kunde von so einem Anbieter habe ich nun reine Entwickler, die in komplett abstrakten Layers Dinge zusammenstecken, low-code und nahe an Business Problemen.
Aber auch:
Dadurch habe ich niemanden nirgendwo mehr, der auch nur einen Hauch einer Ahnung hat, was das alles bedeutet, lastmäßig, und ob der getriebene Aufwand dem Problem angemessen ist.
Das ist dann der schmale Grat, der mit selbst im Artikel zu kurz kommt. Nur weil ich eine Database as Service beziehe, bedeutet das nicht, dass ich keinen DBA mehr benötige. Meine schlecht programmierten Queries skalieren dann einfach finanziell nach oben, wenn die DB hier so flexibel ist – oder ich muss einfach größere CPUs mieten, weil die Performance stinkt. Dabei hätte ich, mit ein wenig expertise, auch durch eine kleine Query Optimierung hier Miete sparen können.
Auf der anderen Seite kann hier Kris‘ Fazit zutreffen:
Und am Ende spielen die Kosten im Vergleich keine Rolle mehr, weil andere, größere Vektoren auf die Firmen einwirken.
Und als alter Hase muss man sich vielleicht daran gewöhnen, dass in manchen Business Cases die Cloud Kosten einfach nur Portokosten sind.
Der Consultant würde vermutlich sagen – „It depends“.
Cloud Cost vs. On-Premises Cost
WordPress Fork, Login Check und das Drama geht weiter
Ok, heute etwas kürzer – versprochen. Für den ein oder anderen Leser ist das Thema bestimmt relevant, daher möchte ich nicht unterschlagen, was diese Woche bei WordPress vs. WP Engine passiert ist.
Übernahme des „Advanced Custom Fields Plugin“
Das neuste WordPress Drama habe ich direkt mal nach oben gepackt. WordPress hat das populäre Plugin „Advanced Custom Fields“ übernommen. Ja, übernommen nicht geforked. Das heisst, dass im Plugin Directory nun ein neuer Name steht (Secure Custom Fields), der Owner ein anderer ist, bestehende ACF Installationen über den Update Mechanismus dann aber die neue Version von WordPress bekommen.
Laut WordPress habe man in der Vergangenheit öfters so agiert, wenn ein Plugin gegen die Community Guidelines verstoße. In diesem Fall haben die Autoren von ACF ein Security Update scheinbar nur über die eigene Website, nicht aber über das in WordPress integrierte Plugin-Update System bereitgestellt – also die Auslieferung eines Security Patches verzögert. Das wiederum kann man ja schon verstehen, wenn man das Ökosystem schützen möchte – so argumentiert auch James Giroux, ein Automattic Mitarbeiter, in einem Blog-Post.
FreeWP – Fork oder nicht?
Mit FreeWP startet der erste Fork Versuch seit längerer Zeit (der letzte Fork war ClassicPress in 2018 wegen des Gutenberg Editors). Naja, eigentlich ist es kein richtiger Fork Versuch – der Macher dahinter hatte sich ein paar Domains gesichert, um einen potenziellen Fork zu supporten – unter anderem die Domain FreeWP.com. Matt Mullenweg hat das irgendwie mitbekommen und dann öffentlich zum Fork gratuliert, der aber aktuell gar kein Fork ist und dies in der FAQ bei FreeWP auch klarstellt – konfuse Situation. Die Diskussion und Feedback dazu gibt es in diesem Reddit Thread.
Login Check bei WordPress.org
Bei WordPress.org gibt es seit neuem eine Checkbox, in der man bestätigen muss, dass man nichts mit WP Engine zu tun hat. Was auch immer das bedeutet – ob man Plugin Developer ist, dort ebenfalls Kunden betreut – ist unklar.
Vercel CEO Guillermo Rauch hat sich den Code angeschaut und festgestellt, dass eins der Elemente „Login-lawsuit“ heisst – ein Schelm, wer Böses dabei denkt. Naja, als CEO von Vercel sollte man sich ggf. mit anderen Themen beschäftigen.
Populäre Kritiker
Kritik am Vorgehen und vor allem an der Vorgehensweise von Matt Mullenweg gibt es von vielen populären Kritikern. DHH von Basecamp meint dazu, dass wenn man Code unter der GPL zur Verfügung Stelle, man ihn der Allgemeinheit zur Verfügung stelle, und damit leben muss, was damit passiert. DHH vergleicht das Vorgehen mit dem, was er bei „Ruby on Rails“ gemacht hat. Und er zeigt auch, dass es wie bei Valkey und Redis laufen kann. Meiner Meinung nach vergisst er dabei, dass es WordPress/Automattic ja auch darum geht, dass man nicht nur nichts contributed, sondern auch sämtliche Ressourcen von WordPress.org nutzt (Community, Plugin Marktplatz und vor allem Traffic gegen die Plugin Download Architektur schickt), und dafür halt einfach keine Gegenleistung bringt.
Contributions
In einem Tweet von Colin Charles wird deutlich, wie stark WordPress an Automattic hängt, und wie wenig Firmen wie WP Engine dazu beitragen. WordPress stellt 32,2 % der Contributoren, danach kommt:
- rtCamp mit 4,3 %
- 10up mit 3,7%
- Yoast mit 3,4 %
- Multidots mit 2,8%
- und dann erst WP Engine mit 2,1 %
Google ist bei 1,5 % sogar noch vor Hoster GoDaddy (1,2 %) und dem WP Hoster Kista (0,3 %).
Natürlich sagt die Anzahl der Contributoren nichts über die Menge aus, die sie contributen, daher kann das nur ein Indiz sein, wer in der Diskussion eigentlich wieviel beiträgt und wer nicht.
TeamBlind E-Mails abgefangen?
Bei der Bewertungsplattform „TeamBlind“ werden E-Mails der Arbeitgeber zur Verifizierung verwendet, um nachzuweisen, dass man wirklich dort arbeitet. Laut einem Screenshot fängt man die Mails bei Automattic wohl ab – inklusive Umleitung zu Automattic CEO Matt Mullenweg. Ob das stimmt ist natürlich die Frage – falls ja, dann wäre das ja schon eine Nummer. Automattic E-Mails landet bei IPs von Automattic selbst – also nicht bei Google, Office365 oder einem anderen Mail Provider – daher ist eine solche Umleitung sicherlich implementierbar.
Auch ansonsten scheint Matt öfters „verbal“ zu eskalieren, hier sogar über den @WordPress Twitter Account gegen den WP Engine CEO.
Fazit
Hier ist nach wie vor viel Bewegung drin – inklusive einem Angebot von Cloudflare, beim Traffic gegen die WordPress Repositories zu helfen. Matt schreibt hier, dass man 30.000 Requests pro Sekunde habe und dies eben auch finanzieren muss. Das ist jetzt kein Pappenstiel und man kann die Argumente auf beiden Seiten verstehen, die Vorgehensweise ist schon ziemlich grenzwertig oder auch total drüber, je nachdem, welches der vielen Themengebiete man sich anschaut.
Naja, vielleicht muss ich die geplante Ghost Migration nun doch vorziehen.
Sponsored
Kundenzentrisches Monitoring mit Checkly
Checkly ist eine code-first Monitoring-Lösung, die ein kundenzentrisches Monitoring ermöglicht.
Kundenzentrisches Monitoring?
Ja, „Customer Centric Monitoring“ – wie sieht eigentlich der Kunde meine Applikation?
Funktioniert der Login, ist die Suche nach einem Produkt schnell und kann man überhaupt ein Produkt in meinem Shop kaufen?
Das fängt schon beim HTTP Handshake und dem TLS-Zertifikat an und geht durch die ganze Traffic-Kette bis zum Kaufprozess inkl. aller externen APIs, die in deiner Anwendung verwendet werden.
Checkly verwendet hierfür die Open-Source-Browser-Automatisierung Playwright und simuliert damit einen Browser aus über 20 Standorten aus der Welt. Du bekommst damit neben der rein funktionalen Überwachung auch noch einen Einblick in die Performance und Uptime.
Dabei ist Checkly Code-first und bietet wirkliches „Monitoring as Code“ über einen eigenen Terraform Provider, eine Pulumi Integration und die hauseigene CLI an.
Als neues Feature bietet Checkly nun mit Checkly Traces eine nahtlose Integration in vorhandene „Open Telemetry Tracing“ Lösungen an – in einem Webinar vom Ende September kannst du dir hier auf YouTube anschauen, wie das Ganze funktioniert.
RTO: Hektik bei Dell und Twilio CEO beruhigt Mitarbeitende
Im Sales Team von Dell gab es am Donnerstag, den 26. September, ein kurzfristiges Announcement zur 5 Tage Rückkehr ins Büro – ab dem folgenden Montag, dem 30. September. Wir erinnern uns, dass Dell hier und da schon komische Ankündigungen und Regelungen durchgezogen hat. Na gut, jedenfalls müssen die Sales- und Vertriebsmitarbeitenden nun kurzfristig entweder im Büro von Dell oder beim Kunden vor Ort arbeiten.
Man vermutet nun einen „Stellenabbau durch die Hintertür“, habe doch Dell im August noch davon gesprochen, sich in nächster Zeit von 12.500 Angestellten trennen zu wollen. Jedenfalls waren die Parkplätze teilweise überfüllt, genauso die Büros – für die Eltern kam das Announcement natürlich viel zu kurzfristig – selbst wenn man willig ist, bekommt man in der Regel nicht innerhalb dieser Zeit einen Betreuungsplatz.
Khozema Shipchandler, CEO des börsennotierten Messaging SaaS Dienstes Twilio, hat derweil auf LinkedIn die Belegschaft beruhigt, Twilio werde kein Return-to-Office durchziehen, so lange er bei Twilio arbeite.
Twilio habe ein flexibles „Open Work“ eingeführt und es funktioniere:
We cut out commutes and spend more time working on the stuff that matters or connecting with our families. And we’re intentional about creating flexibility so folks can get together in-office, with customers, or at an offsite.
93 % der „Twillions“ gaben an, dass sie effizient von überall arbeiten können. Die Kunden seien auch zufrieden, daher macht eine Rückkehr ins Büro keinen Sinn. Wie Twilio remote arbeitet und damit erfolgreich ist, wird dann in diesem Blog Artikel erklärt.
Dell schafft Homeoffice mit zwei Tagen Vorlauf ab – Chaos bricht aus
Managed Kafka Cloud Kosten: Self-Hosting Ersparnis von $ 2 Millionen
Ein LinkedIn Artikel des „The Kafka Guy“ Stanislav Kozlovski hat in dieser Woche etwas Aufmerksamkeit generiert.
Er hat einen Reddit Kommentar eines Kafka Engineers zusammengefasst. Dieser habe $ 2 Millionen Dollar (in den letzten 7 Jahren) gespart, da er Kafka selbst gehosted hat und nicht ein AWS-managed Kafka Angebot bezogen hat. Im Jahresvergleich kostet das Ganze:
- 278.000 $ in der Cloud als managed Lösung
- 72.700 $ im Eigenbetrieb
Interessanterweise hat er auch die Kosten für das Self-Hosting aufgezeigt:
- 40.000 $ für die Hardware
- 224.000 $ für die Miete der Racks (über 7 Jahre)
- 226.600 $ für den Traffic des AWS Direct Connect
- 18.400 $ für die 1 Gbps Leitung zu AWS
Da fragt man sich doch, warum man dann überhaupt noch AWS nutzt, wenn der Traffic Preis hier so enorm zu Buche schlägt?
Gerade der aus AWS ausgehende Traffic ist recht teuer, das muss man sich schon gut überlegen und ist ja irgendwie auch Absicht, damit man „treu“ bleibt.
Den ursprünglichen Reddit Post mit vielen Kommentaren zum Thema findest du hier.
Wie immer gilt – vergleichen, Optionen prüfen und dann machen – nicht einfach blind bei AWS & Co. die Wundertüte kaufen.
„The Kafka Guy“ LinkedIn Post zu „Managed Kafka“
Cloudflare: Security.txt für alle Kunden
Der regelmäßige Leser weiß schon, dass ich ein großer Fan der security.txt Datei bin – diese regelt, wie man dich bei Security Vorfällen kontaktieren kann.
In der Basis enthält sie nur eine Kontaktadresse und ein Expire Date der Angaben. Zusätzlich kann noch ein PGP Key, Acknowledgements, „Preferred-Languages“, eine Security Policy, ein Hiring Link und ein Common Security Advisory Framework angegeben werden.
Im Grunde reicht aber erstmal die E-Mail – man möchte es dem freundlichen Security Researcher ja so einfach wie möglich machen. Auf secuitytxt.org kannst du dir direkt eine security.txt generieren.
Cloudflare macht das Ganze nun für alle Kunden (inkl. Free Accounts) noch einfacher und integriert einen Security.txt Generator mitsamt Auslieferung für alle Kunden. Damit gibt es nun keine Ausrede mehr, das zu verwenden. Das ist wirklich schnell erstellt und einfach zu aktivieren.
Laut eigenen Angaben legt Cloudflare die Daten auf einem mehrfach redundaten PostgreSQL System ab, damit die Daten sicher und immer verfübar sind.
Die Security.txt von Cloudflare selbst ist recht gut gefüllt und enthält neben E-Mail, Policy und Hiring Link auch einen Link zum Portal von HackerOne.
Enhance your website’s security with Cloudflare’s free security.txt generator
Cloudflare schützt vor Weltrekord DDoS mit 3,8 Tbps
Bei Cloudflare purzeln ja jedes Jahr, teilweise im Monatsrhythmus die Rekorde für groß volumige DDoS-Attacken. Im September hat man nun 2 Rekorde gebrochen:
- 3,8 Terabits pro Sekunde (65 Sekunden lang, Schaubild)
- 2,14 Milliarden Pakete pro Sekunde (über 60 Sekunden lang, Schaubild)
Beides sind die bisher größten, jemals veröffentlichten Zahlen zu DDoS Angriffen.
Laut den Angaben von Cloudflare wurden beide Angriffe komplett automatisch erkannt und abgewehrt. Man hat sich die Details im verlinkten Blog Artikel angeschaut und festgestellt, dass die meisten IPs zu Russland (12,1%), Vietnam (11,6 %), USA (9,3%), Spanien (6,5%), Brasilien und Frankreich gehören (je 4,7 %).
Die Angriffe mit der hohen Paketrate kamen über MikroTik Geräte, DVRs (Digital Video Recorder) und Web Server. Die Angriffe mit der hohen Bitrate über ASUS Router für das Heimnetzwerk, die vermutlich nicht gepatched wurden.
Im Blog Artikel wird auch erklärt, wie Cloudflare die Attacken über sein weltweit verteiltes Anycast Netzwerk verteilt und alle IPs einfach an sämtlichen Standorten announcen kann. Interessant ist, wie die Signaturen eines Angriffs in real-time analysiert und dann auf Kernel Ebene gedroppt werden – so kann Cloudflare sicherstellen, dass die Pakete/Angriffe eben keine wertvollen CPU Ressourcen am Edge benötigen und den „bösen Traffic“ einfach wegschmeissen.
How Cloudflare auto-mitigated world record 3.8 Tbps DDoS attack
Building On-call: Our observability strategy
Building On-call: Our observability strategy
Levels.fyi: Software Engineering Heatmap
Bei dem von mir häufig verlinkten Gehaltschecker Levels.fyi gibt es nun eine Heatmap für für Software Engineering Gehälter.
Ganz vorne steht die San Francisco Bay Area mit im Median $ 243.000 Gehalt – Spitzengehälter zahlen hier Open AI, Airbnb und der aus Süd-Korea stammte E-Commerce Anbieter Coupang.
An Platz kommt dann nicht etwa New York, sondern die „Greater Seattle Area“ mit einem Median von $ 221.000. Top Zahler hier Airbnb, Uber und Databricks.
Platz 3 ist dann „New York City Area“ mit $ 175.000 Median – hier zahlen Netflix, Citadel und Jane Street am Besten. Jane Street ist ein Finanzdienstleister, kannte ich bisher auch nicht.
Software Engineer Pay Heatmap!
Cloud Provider IP Ranges Übersicht
Bei ipranges.cloud findest du Statistiken zu IP Adressen der großen und kleineren Cloud Provider, hier die Zahlen:
- AWS hat über 80 Millionen IP Adressen
- Azure über 45 Millionen
- Google Cloud nur noch 14,4 Millionen
- Digital Ocean ist mit 2,9 Millionen auf Platz 4
- Oracle folgt mit 2,7 Millionen
- Cloudflare hat noch 1,5 Millionen
- Linode knapp 1 Mio
- Fastly um die 300.000
Interessantes „Kräfteverhältnis“ – auf dem Portal kann man sich die Adressen, die Cloud Region und Präfixe/Netze als JSON/CSV herunterladen und die Daten weiterverarbeiten. In dieser SQL Workbench kannst du mit den Daten per SQL arbeiten.
Schmunzelecke
DHH ist ja für seine polarisierenden Tweets bekannt – diesmal hat aber ein anderer User eine Slide von einer seiner Präsentationen geshared, bei der sich DHH über Vercel mit AWS Markup lustig macht.
Sprich, Vercel sei nur ein Wrapper über AWS – ist das nun gut oder schlecht?
Immerhin scheint AWS hier UI bzw. DX (Developer Experience) Lücken zu haben, sonst wäre Vercel ja gar nicht so groß und beliebt geworden.
💡 Link Tipps aus der Open Source Welt
DeskPad – Virtueller ScreenSharing Desktop
DeskPad löst zumindest mal ein Problem, das ich immer wieder habe – Sharen eines Browser Tabs – dann switch auf Konsole, und wieder zurück, ohne, dass ich meinen „breiten“ Screen sharen muss, auf dem der Meeting Teilnehmer dann nichts mehr erkennt.
Sprich, DeskPad ist einfach ein weiterer Bildschirm auf deinem Mac, innerhalb welchem du mehrere Applikationen starten kannst. Also, ein Terminal und einen Browser. Wie bei einem normalen Bildschirm kannst du dann Auflösung und Verhalten anpassen.
Aktuell gibt es noch ein paar Einschränkungen – du kannst nicht einen vorhandenen Chrome Tab reinziehen oder wenn Chrome (oder eine andere Anwendung) bereits auf dem Haupt-Screen läuft, diese nicht starten – muss man mal ausprobieren, damit man versteht, was ich damit meine.
Installation einfach via brew install deskpad.
Es gibt viele Feature Vorschläge und Ideen – bin gespannt, wie es bei dem Projekt weitergeht.
https://github.com/Stengo/DeskPad
Boring SSH Tunnel Manager
Boring ist ein in Go geschriebener Tunnel Manager für SSH Tunnels. Man konfiguriert seine gewünschten Tunnel in einem .toml file und kann dann über die CLI verfügbare Tunnels auflisten und aktivieren. Kurze Demo, wie das funktioniert – oder einfach die Beispiele checken.
Boring kann dabei auf deine vorhandene .ssh/config zugreifen und nutzt auch die Daten des ssh-agent – also alles wie gewohnt, nur ebem deutlich bequemer als vorher. Boring gibt es aktuell via git oder binary für Linux und macOS – leider noch kein Brew Package.
https://github.com/alebeck/boring
❓ 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: