Willkommen zu allesnurgecloud.com – Ausgabe #217
Und damit willkommen zur letzten Ausgabe im Jahr 2025. Nach der Ausgabe mache ich eine kleine Weihnachtspause – die nächste Ausgabe bekommst du dann vermutlich am 10. Januar 2026. Dafür ist die Ausgabe hier recht umfangreich geworden!
Vielen Dank an alle treuen Leser:innen hier, die Öffnungsrate hier ist konstant bei 65–70 % und mit einer der Gründe, warum ich das hier mache. Per RSS gibt es mittlerweile auch eine überraschend hohe Leserzahl – auch hier schöne Grüße und danke für euer Interesse.
Ich wünsche allen ein frohes Fest und gute Erholung über die Feiertage. Und natürlich hoffe ich, dass die OnCall-Pager-App bei allen ruhig bleibt, die das Internet und die zahlreichen Applikationen am Laufen halten – Guten Rutsch und bis in 2026!
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 152 ich mit Victor Vecsei aus Wien, der 2020 mit 20 Jahren Marswalk gegründet hat – eine Gen Z Agentur, die Unternehmen und Konzernen hilft, junge Zielgruppen auf Social Media zu erreichen. Unter dem Motto „We connect Boomers with Zoomers“ beschäftigt Marswalk heute 45 Mitarbeitende, macht 5 Millionen Euro Jahresumsatz und hat Büros in Wien und Berlin. Interessant fand ich, dass die sehr jungen Gründer dann noch jüngere Menschen einstellen, damit sie am Zahn der Zeit bleiben – klasse, hör gerne mal rein (Spotify / Apple).
Wenn dir die Podcastfolgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).
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:
Das Verschwinden der DBAs und die Kosten der Bequemlichkeit
Tim O’Brien erzählt in seinem Blogpost auf Medium eine Geschichte aus dem Jahr 1999: Er wollte unbedingt einen Index anlegen, sein DBA Albert riet ab – und innerhalb von Minuten nach dem Go-Live brach die gesamte Site zusammen. Albert fixte das Problem wortlos mit zwei Fingern tippend. Die Lektion: Datenbanken vergeben keine Arroganz.
Das Problem heute: Es gibt kaum noch Alberts. Die Zahlen könnten unterschiedlicher nicht sein:
- Im Jahr 2000 kamen auf 6 Entwickler ein DBA
- 2023 liegt das Verhältnis bei 22:1.
Die Anzahl der Software-Entwickler stieg um 159%, während DBA-Stellen um 29% sanken. Gleichzeitig explodierte die Datenbanklandschaft von 28 Systemen im Jahr 2012 auf heute 426 verschiedene Datenbanksysteme – von relationalen Klassikern über Document Stores bis zu Vector-Datenbanken.
Die Cloud hat den DBA als operativen Wächter weitgehend ersetzt. Backups, Failover, Patching – alles nur noch Checkboxen in einer Console. Laut Gartner stammten 2022 rund 98% des Datenbankmarkt-Wachstums aus Cloud-Angeboten.
Was dabei verloren ging: Das institutionelle Wissen, das früher warnte „Leg keinen Index auf den Hot Write Path“ oder „Dieser Workload gehört in einen Key-Value-Store, nicht in ein relationales Schema“. Stattdessen wird heute oft einfach die nächstgrößere Instanz gebucht, wenn die Performance nicht stimmt. Ein fehlender Index oder eine schlecht geschriebene Query skaliert in der Cloud eben finanziell nach oben statt technisch zu scheitern. Was früher Albert in 30 Minuten optimiert hätte, löst man heute mit einem Klick auf „Upgrade“ – und wundert sich am Monatsende über die Rechnung.
Vor einer weile habe ich einen Artikel von Kris Köhntopp (Ausgabe 161) ausführlicher vorgestellt, der neben der Rechenleistung auch die DBA Expertise aufgreift. Wie man PostgreSQL auf OpenAI Niveau in der Cloud skalieren kann, kannst du hingegen in Ausgabe 190 nachlesen.
Wie ist deine Meinung zum Thema? Gibt es bei dir noch DBAs, die du bei „Die Datenbank ist aber langsam“ Fragen belästigen kannst?
Falls nicht – ich kann zumindest ein Tool wie Sentry (gibt es auch self-hosted, auch von We Manage) empfehlen – hier hast du eine tolle Observability über deine ganze Anwendung bis runter zu den DB Queries in einem Tool, das auch wirklich hilfreich ist. Ansonsten natürlich ganz uneigennützig nochmal der Hinweis auf einen „Customer Centric Monitoring“ Vortrag von mir – den bei langsamen Queries landet am Ende auch der Kunde.
How Databases Changed While DBAs Vanished
AWS-CEO: Junior-Entwickler durch KI ersetzen ist „eine der dümmsten Ideen“
AWS-CEO Matt Garman hat im WIRED-Podcast „The Big Interview“ der Idee widersprochen, Junior-Entwickler durch KI zu ersetzen. Er nannte diese Strategie eine der „dümmsten Ideen“, die er je gehört habe – und liefert drei Argumente.
Erstens: Junior-Entwickler beherrschen KI-Tools oft besser als ihre erfahrenen Kollegen. Sie sind mit der Technologie aufgewachsen und können mehr aus den Werkzeugen herausholen. Laut Stack Overflow Developer Survey 2025 nutzen 55,5% der Berufseinsteiger täglich KI-Tools – mehr als erfahrene Entwickler. Über die Hälfte der Gen-Z-Mitarbeiter helfe sogar Seniors beim KI-Upskilling.
Zweitens: Junior-Entwickler sind meist die günstigsten Mitarbeiter. Wer Kosten optimieren will, sollte nicht bei den niedrigsten Gehältern anfangen. Interessanterweise hätten laut einer Studie 30% der Unternehmen, die Mitarbeiter entließen, am Ende höhere Kosten – und mussten später wieder einstellen.
Drittens: Ohne Nachwuchs bricht die Talent-Pipeline zusammen. Garman vergleicht es mit einem Sportteam, das nur Veteranen behält und keine Rookies rekrutiert. Wenn die Veteranen gehen, steht niemand mehr auf dem Spielfeld. Zudem brächten Berufseinsteiger frische Ideen und neue Denkweisen mit – oft entstünden dort die besten Innovationen.
Garman räumt allerdings auch ein, dass sich Jobs verändern werden. KI mache Unternehmen und Mitarbeiter produktiver, was zu mehr Projekten und neuen Märkten führe. Langfristig werde KI mehr Jobs schaffen als vernichten – aber der Weg dorthin werde holprig.
AWS CEO Explains 3 Reasons AI Can’t Replace Junior Devs
Anzeige
Hier könnte Deine Werbung stehen
Du möchtest Deine Firma, angebotene Dienstleistungen & Services oder Dein SaaS Produkt hier im Newsletter vorstellen?Du suchst neue Mitarbeiter und möchtest diese direkt erreichen?
Erreiche über 2000 Cloud und Open-Source Enthusiasten direkt per E-Mail und im RSS Feed. Dazu kommen 1000+ Impressions im LinkedIn Artikel des Newsletters.
Bei Interesse antworte mir direkt auf den Newsletter oder kontaktiere mich über LinkedIn ich schreib dann auch ganz schnell zurück.
Falls du ein SaaS Tool bewerben möchtest, bin ich bestimmt auch bei einer Affiliate Geschichte dabei – schreib mir einfach bei Interesse!
Jetzt Werbung anfragen (und Freitags deployen)
GitHub Actions Pricing-Drama und GitLab 18.7 Release
GitHub hat eine Preisänderung für Actions angekündigt – und nach heftiger Community-Kritik teilweise zurückgezogen. Parallel dazu erscheint GitLab 18.7 mit zahlreichen KI-Features, die allerdings meist kostenpflichtige Add-ons erfordern.
GitHub wollte Self-Hosted Runner bepreisen – und ruderte nach Backlash zurück. Die ursprüngliche Ankündigung sah vor, ab März 2026 eine „Actions Cloud Platform Charge“ von $0.002 pro Minute auch für Self-Hosted Runner zu erheben. Die Begründung: Die Kosten für die Control Plane würden bisher von den GitHub-Hosted Runnern quersubventioniert.
Die Community reagierte prompt. In der GitHub-Diskussion finden sich Kommentare wie: „Charging customers by the minute for using their own hardware makes them feel bad; like you are taking their hardware hostage.“ Ein Nutzer wies darauf hin, dass ältere, langsamere Hardware plötzlich teurer würde – „basically actions saying if you want to self-host, you better not be self-hosting old hardware.“ Ein OpenSSH-Maintainer rechnete vor, dass ein einzelner git push mit seinen Tests $6.33 kosten würde.
Viele kritisierten zudem, dass GitHub jahrelang Self-Hosted-Features vernachlässigt habe. Issues seien seit fünf Jahren offen, die Actions Runner Controller-Entwicklung nach der Übernahme eingeschlafen. „If they want to charge for things fine, but actually provide a service that doesn’t require your users doing 90% of the work“, schrieb ein Nutzer.
GitHub zog die Self-Hosted-Gebühren zurück und will nun „mehr zuhören“. Die Preissenkung für GitHub-Hosted Runner um bis zu 39% bleibt bestehen und tritt am 1. Januar 2026 in Kraft. Mal schauen, was das für die vielen „Hosted Runner“ Startup Alternativen bedeutet, die es ja zurecht gibt – da die GitHub eigenen Runner einfach ein schlechtes Preis/Leistungsverhältnis haben.
Parallel zum Fauxpas erscheint GitLab 18.7 mit über 25 Verbesserungen. Die Highlights: Secret Validity Checks sind nun GA und prüfen automatisch, ob geleakte Credentials noch aktiv sind. Der neue Planner Agent (Beta) unterstützt Product Manager bei Backlog-Analysen. SAST False Positive Detection nutzt KI zur Triage. Auffällig: Die meisten neuen Features – vom Duo Analytics Dashboard bis zum Data Analyst Agent – erfordern Duo Pro oder Duo Enterprise, also kostenpflichtige Add-ons. Für Self-Managed-Nutzer, die nur die Open-Source-Features nutzen, bleibt in diesem Release wenig Neues übrig – das war in den letzten Releases ja leider auch schon so.
Pricing changes for GitHub Actions
Twilio: Von 140 Microservices zurück zum Monolithen
Alexandra Noonan beschreibt im Twilio-Blog, wie Segment von über 140 Microservices zurück zu einem Monolithen migrierte – und damit ihre Entwicklerproduktivität massiv steigerte.
Segments Infrastruktur nimmt hunderttausende Events pro Sekunde entgegen und leitet sie an über 100 verschiedene Destinations weiter – Google Analytics, Optimizely, Webhooks. Um Head-of-Line-Blocking zu vermeiden, hatte man ursprünglich für jede Destination einen eigenen Service mit eigener Queue gebaut. Wenn eine Destination Probleme hatte, stauten sich nur deren Events – sinnvolle Isolation also.
Das Problem: Jeder Service landete in einem eigenen Repository, mit eigenen Dependencies und eigener Test-Suite. Shared Libraries divergierten über die Zeit, weil niemand Lust hatte, Änderungen in 140 Repos auszurollen. Drei Vollzeit-Engineers verbrachten den Großteil ihrer Zeit damit, das System am Leben zu halten. Nachts wurden On-Call-Engineers wegen Load-Spikes bei einzelnen Destinations geweckt – sich in dem Dschungel dann zurechtzufinden, ist natürlich nicht so einfach, gerade nachts nicht.
Die Lösung war dann doch recht radikal: Alle Destinations wurden zurück in ein Monorepo migriert, alle Services in einen einzigen Service konsolidiert. Für die Test-Suite baute man „Traffic Recorder“ – ein Tool, das HTTP-Requests aufzeichnet und bei späteren Testläufen abspielt. Die Tests für alle 140+ Destinations laufen jetzt in Millisekunden statt Minuten.
Das Ergebnis spricht für sich: Im Jahr vor der Migration gab es 32 Verbesserungen an den Shared Libraries, im Jahr danach waren es 46. Ein Engineer kann den gesamten Service in Minuten deployen, und der große Worker-Pool absorbiert Load-Spikes, ohne dass jemand nachts aufwachen muss.
Microservices sind also nicht immer das Problem für eine Lösung, manchmal sind sie auch das Problem selbst. Das Thema hatte ich nun schon öfters hier, beispielsweise in Ausgabe 105 (Prime Video Modulith-Diskussion), Ausgabe 91 („Nur 1% brauchen Microservices“) und Ausgabe 189 (versteckte Kosten bei Microservices).
Goodbye Microservices: From 100s of problem children to 1 superstar
Cloudflare Customer Zero mit Infrastructure as Code
Cloudflare nutzt die eigenen Produkte intern im großen Stil – und ein kleiner Konfigurationsfehler kann sich in Sekunden über das gesamte Edge-Netzwerk verbreiten. Im aktuellen Engineering-Blogpost beschreibt das Customer Zero Team, wie man hunderte interne Produktions-Accounts konsistent absichert, ohne nachts wegen manueller Fehler geweckt zu werden.
Die Lösung: Sämtliche Produktionskonfigurationen werden als Infrastructure as Code verwaltet. Jede Änderung ist an einen User, Commit und ein internes Ticket gebunden. Das Dashboard dient nur noch für Analytics – kritische Änderungen laufen ausschließlich über Code mit Peer-Review.
Der Stack besteht aus Terraform mit Atlantis für CI/CD, integriert in GitLab. Alle Account-Konfigurationen leben in einem zentralen Monorepo, wobei Teams ihre jeweiligen Bereiche als Code-Owner verantworten. Für Policy Enforcement nutzt das Team Open Policy Agent (OPA) mit Rego-Policies – aktuell etwa 50 Stück. Diese prüfen beispielsweise, ob nur @cloudflare.com-E-Mails in Access Policies verwendet werden oder ob Session-Längen die Vorgaben einhalten.
Das System kennt zwei Modi: Warning (Merge erlaubt, aber Kommentar) und Deny (Deployment blockiert). Ausnahmen werden über Jira beantragt und als Code in einem separaten exceptions.rego-Repository formalisiert.
Drei Lessons Learned aus der Migration: Erstens unterschätzt man die Terraform-Lernkurve – das Tool cf-terraforming half beim Import bestehender Ressourcen. Zweitens passiert Configuration Drift, wenn Teams bei Incidents schnell im Dashboard klicken. Ein Custom Drift Detection Service vergleicht kontinuierlich Terraform-State mit der API und erstellt automatisch Tickets. Drittens war der Terraform Provider oft hinter der API – gelöst durch den neuen v5 Provider, der automatisch aus der OpenAPI-Spezifikation generiert wird.
Ich finde ja schon die Motivation hinter dem „Customer Zero Team“ sehr geil, kann man wieder einiges für die eigene Arbeit von lernen:
Within our security division, a dedicated Customer Zero team uses its unique position to provide a constant, high-fidelity feedback loop to product and engineering that drives continuous improvement of our products. And we do this at a global scale — where a single misconfiguration can propagate across our edge in seconds and lead to unintended consequences.
Das eigene Produkt intern verwenden und auch noch Gehör finden, das ist super cool!
Shifting left at enterprise scale: how we manage Cloudflare with Infrastructure as Code
Grace-Hopper für 7.500€: Mit Reddit zum 235B-Parameter-Desktop
Auf Reddit stolperte David Noel Ng über ein Angebot, das zu gut klang um wahr zu sein: Ein Grace-Hopper NVL2 System mit zwei H100 GPUs für 10.000 Euro – Hardware, die normalerweise über 100.000 Dollar kostet und nur an Rechenzentren verkauft wird. In seinem Blogpost dokumentiert er den abenteuerlichen Umbau zum Desktop-System.
Das System war ein „Frankenstein-Server“, ursprünglich flüssigkeitsgekühlt, dann auf Luftkühlung umgebaut. Nach einer zweistündigen Fahrt zu einem Bauernhof in Bayern und der Übergabe eines Stapels Bargeld saß ein 20 kg schwerer, staubbedeckter Server angeschnallt auf dem Rücksitz. Die acht Server-Lüfter waren so laut, dass Gehörschutz nötig war – seine Frau verbannte das System sofort aus dem Home-Office.
Was folgte, war ein Projekt voller Katastrophen: Das Mainboard wurde mit Isopropanol gewaschen, Custom-Wasserkühlungsadapter CNC-gefräst, und beim ersten Einschalten gab es ein „Pop“ gefolgt von magischem Rauch – die Stromschätzung für die Lüfter war etwas daneben. Mehrere Mainboard-Fan-Header starben.
Das System bootete danach nur noch in 25% der Fälle und crashte nach zwei Minuten. Der Grund laut Logs: Die GPU meldete eine Temperatur von 16.777.214 Grad Celsius. Das ist kein Tippfehler – es ist 2²⁴ – 2, der Maximalwert eines 24-Bit Integers. In Hardware-Sprache bedeutet das: Der Sensor schreit „Ich habe keine Ahnung was passiert!“. Unter dem Mikroskop fand David beschädigte SMD-Komponenten, die er freihändig lötete und mit UV-Harz fixierte.
Das Ergebnis nach 9.000 Euro Gesamtkosten: Ein Desktop, der 235B Parameter Modelle lokal ausführt. Llama.cpp kompiliert mit 144 Cores in 90 Sekunden, und erste Benchmarks zeigen vielversprechende Token-Generierung bei nur 300W pro GPU – weit unter den möglichen 900W.
Na, da brauchst du sicher dann auch keine Heizung mehr – aber cooles Projekt!
Alternativ hat Hetzner übrigens auch einen neuen GPU Server im Angebot – den GEX131 – für schlappe 1057,91€ plus Mwst. bekommst du eine NVIDIA RTX PRO™ 6000 Blackwell Max-Q-GPU mit 96 GB RAM.
Building a High-End AI Desktop
Container-Isolation gegen Monero-Mining auf eigenem Server
Jake Saunders wachte mit einer E-Mail von Hetzner auf: Sein Server scanne IP-Ranges in Thailand, er habe vier Stunden Zeit zur Stellungnahme. In seinem Blogpost dokumentiert er die anschließende Panik und Spurensuche – ein lehrreiches Beispiel für Container-Sicherheit in der Praxis.
Ein Blick auf ps aux zeigte das Problem: 819% CPU-Auslastung durch einen Prozess namens javae in /tmp/.XIN-unix/ und mehrere xmrig-Prozesse – Monero-Mining-Software, die seit zehn Tagen lief. Die Prozesse gehörten alle User 1001.
Die Ursache fand Jake in seinem Umami-Container, einem Privacy-fokussierten Analytics-Tool. In dessen Next.js-Verzeichnis lag ein komplettes xmrig-6.24.0-Directory. Die Schwachstelle: CVE-2025-66478, eine RCE-Lücke in Next.js React Server Components. Jakes erster Gedanke beim Lesen der CVE-Meldung war gewesen: „Betrifft mich nicht, ich nutze kein Next.js.“ Nur dass Umami eben auf Next.js basiert.
Der entscheidende Moment kam bei der Frage: Ist die Malware aus dem Container entkommen? Jake prüfte, ob /tmp/.XIN-unix/javae auf dem Host existiert – tat es nicht. Die Container-Isolation hatte gehalten. Der Container lief als User nextjs (nicht root), war nicht privilegiert und hatte keine Volume-Mounts. Die Malware konnte Mining betreiben und Netzwerke scannen, aber nicht auf das Host-Dateisystem zugreifen oder Persistence-Mechanismen installieren.
Die Lektion: „I don’t use X“ bedeutet nicht, dass die eigenen Dependencies X nicht nutzen. Und Container-Isolation funktioniert – wenn man sie richtig konfiguriert. Jake aktivierte UFW, löschte den Container, und die CPU-Last sank von 15 auf 0,5.
Witzigerweise hatte ich das neulich auch bei einem Kunden – ebenfalls eine Testinstallation einer Analytics Lösung, die mit hoher CPU Last aufgefallen ist. „Kannst du mal geschwind mir das hinstellen zum Testen“ – alle haben es vergessen und zack, passiert sowas.
Beim Evaluieren neuer Software also immer drauf achten, das Zeug zu löschen, das man nicht braucht.
I got hacked, my server started mining Monero this morning.
16-Jähriger pwnt Discord, X und Vercel – $11.000 Bounty
Ein 16-jähriger Sicherheitsforscher hat eine kritische XSS-Schwachstelle in Mintlify gefunden, einer KI-Dokumentationsplattform. Das Writeup zeigt: Die Lücke betraf X, Vercel, Cursor, Discord und hunderte weitere Unternehmen – für insgesamt nur $11.000 Bounty.
Der Angriffsvektor war erschreckend simpel: Mintlify hostet Dokumentation auf Kunden-Domains wie discord.com/_mintlify/. Ein Endpoint prüfte nicht, ob Anfragen zum aktuellen Host gehörten. SVG-Dateien wurden durchgelassen – und SVGs können JavaScript enthalten. Ein Angreifer konnte also Schadcode auf seinem eigenen Mintlify-Account hochladen und über discord.com/_mintlify/static/evil/exploit.svg im Kontext der Discord-Domain ausführen. Damit hätte er Zugriff auf Session-Cookies und Auth-Tokens gehabt.
Die HN-Diskussion ist aufschlussreich. Ein Nutzer: „Your Discord session cookies and token could be stolen, leading to complete account takeover. […] The $4,000 bounty feels like a slap in the face.“ Ein anderer kritisiert die Architekturentscheidung: „All of this could have been avoided if Discord didn’t run their API docs through discord.com“ – auf einer separaten Domain wäre der Same-Origin-Schutz des Browsers wirksam gewesen. Auf der anderen Seite wollen heute viele Firmen die Docs aus SEO Gründen auf example.com/docs haben anstatt auf docs.example.com.
Discord reagierte schnell: Die Dokumentation ging offline, dann kehrte man zur alten Plattform zurück. Die Bounty-Kritik dominiert bei dem Thema die Diskussion: „Billion dollar zero day turned into a measly eleven thousand dollars.“ Der Fall zeigt, dass Supply-Chain-Risiken nicht nur in npm-Paketen lauern, sondern in der gesamten Traffic Kette der Auslieferung von Inhalten – ufbasse musch!
Pricing changes for GitHub Actions
GraphQL im Enterprise Einsatz: Ernüchterung nach Honeymoon
John James hat GraphQL mit Apollo Client und Server mehrere Jahre in einer echten Enterprise-Anwendung eingesetzt. Sein Fazit im Blogpost fällt ernüchternd aus: GraphQL löse ein reales Problem, aber dieses Problem sei viel nischiger als die meisten zugeben wollen.
Das Kernversprechen ist die Vermeidung von Overfetching. In der Praxis aber oft irrelevant: Die meisten Enterprise-Architekturen hätten bereits ein Backend for Frontend (BFF), das genau diese Aufgabe übernehme. Und da Downstream-Services meist REST seien, verschiebe GraphQL das Overfetching nur eine Ebene tiefer.
Die Implementierungszeit liege deutlich höher als bei REST: Schema, Types, Resolver, Data Sources – alles synchron halten. Besonders kritisch sieht James die Observability: GraphQL gibt 200 zurück, auch wenn im errors-Array Fehler stecken. Das merke man erst, wenn man On-Call sei. Apollos Caching sei theoretisch beeindruckend, in der Praxis fragil. Und das Onboarding dauere länger, weil Entwickler mit REST vertrauter seien.
Was James nicht erwähnt: Security ist bei GraphQL ein eigenes Kapitel. Tief verschachtelte Queries können ohne Depth Limiting Server lahmlegen. Die standardmäßig aktivierte Introspection verrät Angreifern das komplette Schema. Und während REST-Endpoints einzeln abgesichert werden, muss bei GraphQL die Autorisierung auf Resolver-Ebene erfolgen – vergisst man einen, hat man ein Datenleck.
In der Praxis besonders heikel: Die Mandantentrennung. Jeder Resolver muss prüfen, ob der User nur seine eigenen Daten sieht und nicht die anderer Kunden – bei dutzenden Resolvern ein fehleranfälliges Unterfangen. Hab ich in der Praxis jedenfalls schon hier und da gesehen und mitbekommen, dass man hier äh fahrlässig unterwegs war.
GraphQL: the enterprise honeymoon is over
Please Just Try HTMX – Plädoyer gegen überkomplexe Frontends
Die Webentwicklung bietet aktuell zwei laute Lager: „Just use HTML!“ auf der einen Seite, React/Vue/Svelte auf der anderen. Ein neuer Blogpost – nein eigentlich ist es ja ne Landingpage – plädiert für einen dritten Weg – und liefert gleich funktionierende Demos mit.
Das Problem mit der falschen Wahl: Pures HTML stößt an Grenzen, sobald man einen Button braucht, der nur einen Teil der Seite aktualisiert. Also greift man zu React – und hat plötzlich eine package.json mit 847 Dependencies, einen Build-Step von 45 Sekunden und Diskussionen über State Management in jedem Pull Request. Für eine To-Do-Liste. Oder ein Kontaktformular…inklusive der im obigen Artikel beschriebenen „Herausforderungen“.
HTMX bietet einen Mittelweg: Jedes HTML-Element kann HTTP-Requests machen, der Server antwortet mit HTML-Fragmenten, diese werden ins DOM eingesetzt. Kein JavaScript schreiben, keine Build-Pipeline, 14kb gzipped. Ein Button, der sich selbst ersetzt, sieht so aus: <button hx-post="/clicked" hx-swap="outerHTML">. Das war’s.
Die Zahlen sind beeindruckend: Das Unternehmen Contexte baute seine React-App auf Django-Templates mit HTMX um. Das Ergebnis: 67% weniger Code, 96% weniger JS-Dependencies (von 255 auf 9 Pakete), Build-Zeit von 40 auf 5 Sekunden, Ladezeiten halbiert. Jeder Entwickler wurde „Full-Stack“, weil es kein separates Frontend mehr gab.
Der Autor räumt ein: Für Google Docs, Figma oder Offline-First-Apps ist HTMX nicht die Antwort. Aber für Dashboards, Admin-Panels, E-Commerce-Sites und SaaS-Apps – also das, was die meisten von uns tatsächlich bauen – sei es „peinlich gut“.
Schmunzelecke
„“Super secure” MAGA-themed messaging app leaks everyone’s phone number“ – und damit ist eigentlich auch schon alles dazu gesagt.
Und wieder haben manche Menschen zuviel Zeit – hier wird erklärt, wie die Landung auf einem Flugzegträger auf dem NES Game „Top Gun“ auch wirklich funktioniert. Für die jüngeren Leser:innen – das Spiel gab es 1987 auf der NES – damals immerhin in Farbe!
💡 Link Tipps aus der Open Source Welt
GoAlert – Open-Source On-Call Management
GoAlert ist eine Open-Source On-Call-Scheduling- und Alert-Management-Plattform von Target. Das Tool automatisiert Rufbereitschaften, Eskalationen und Benachrichtigungen, um sicherzustellen, dass kritische Alerts nie verloren gehen.
Features:
- On-Call Scheduling: Flexible Dienstpläne und Rotationen für Rufbereitschaften
- Automatische Eskalation: Mehrstufige Eskalationspolicies wenn primäre Kontakte nicht reagieren
- Multi-Channel Alerts: SMS, Voice Calls, Push-Notifications und weitere Kanäle (Für SMS und Voice brauchst du einen Twilio Account)
- Service Management: Zentrale Verwaltung von Services mit individuellen Eskalationsregeln
- Rotation Management: Automatische Übergabe zwischen Team-Mitgliedern
- Integration-Ready: Webhooks und APIs für bestehende Monitoring-Systeme
- Mobile-First Design: Responsive UI optimiert für nächtliche Alert-Bearbeitung
- Custom Themes: Anpassbare Farbschemata für verschiedene Environments
Architektur:
- Vollständig Open Source unter Apache 2.0
- Self-Hosted Only – keine Cloud-Version
- Docker-Support für einfaches Deployment
- Go-basiert für hohe Performance
Community:
- Aktiver Support via Slack (Golang Gophers)
- Direkte Team-Kommunikation möglich
- Enterprise-backed durch Target – aber kein aktiver Support oder so.
GoAlert füllt eine Lücke für Teams, die eine selbst-gehostete Alternative zu PagerDuty oder Opsgenie suchen. Allerdings bin ich mir nicht sicher, ob man an genau dieser Stelle eine Self-Hosted Lösung haben möchte. Da braucht man einfach ein Tool, das funktioniert und man sich immer drauf verlassen kann. Kann mir trotzdem gut vorstellen, dass es in Verbindung mit Keep von letzter Woche ganz gut funktioniert.
https://github.com/target/goalert
carl – CLI-Kalender mit iCal-Support
carl ist ein Kommandozeilen-Kalender in Rust, der klassische cal(1) Implementierungen nachahmt, aber mit modernen Features wie Farben, Themes und iCal-Integration erweitert.
Features:
- iCal Integration: Importiere Events aus
.icsDateien und zeige sie im Kalender - Themes & Styling: Anpassbare Farben und Styles via TOML-Konfiguration
- Jinja Templates: Vollständig anpassbares Layout über Template-Engine
- Agenda-View: Liste aller Events unter dem Kalender mit
--agenda - Flexible Ansichten: Ein-, Drei-Monats oder Jahresansicht
- Julian Dates: Optional Tage seit Jahresbeginn anzeigen
- Custom Properties: Definiere eigene Date-Properties für Styling
carl kann ganze Verzeichnisse mit iCal-Dateien einlesen und Events mit unterschiedlichen Farben je Kalender darstellen – praktisch für die Kombination von Arbeit, Privat und geteilten Kalendern.
Gibt natürlich ein haufen Customizing Optionen – Einige Beispiel Darstellungen kannst du auf der verlinkten GitHub Page sehen. Braucht man wirklich alles in der CLI? Hm, den Kalender brauch ich da nicht, glaub ich.
https://github.com/b1rger/carl
❓ 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: