Willkommen zu allesnurgecloud.com – Ausgabe #194
und damit einen schönen guten Morgen. Nach der „Incident Ausgabe“ letzter Woche ist die Themenauswahl in dieser Woche wieder etwas anders. Content gibt es im Internet ja genug – falls du aber auch mal interessanten Content findest, so kannst du mir den gerne schicken.
Einfach als E-Mail Antwort auf den Newsletter oder kurz über LinkedIn schicken – Vielen Dank!
Danke! Falls du Interesse hast, im Newsletter oder Podcast Werbung zu buchen, kannst du dir die Angebote auf passionfroot mal anschauen – ich bin da aber auch flexibler für andere Ideen – melde dich gerne.
Ich erhalte immer mal wieder Anfragen zu einer Community zum Newsletter und Podcast, um sich auszutauschen – füll doch schnell diese Umfrage aus, damit ich hier abschätzen kann, ob und wie ich das machen sollte – dauert weniger als 1 Minute – falls du schon abgestimmt hast, bitte nicht noch einmal abstimmen.
Happy Bootstrapping Podcast
In Folge 127 von Happy Bootstrapping habe ich mit Hannes Zwetschke von der Agentur Zwetschke aus Augsburg gesprochen. Agentur Inhaber habe ich nicht so oft zu Gast und man muss auch immer schauen, dass es passt – Hannes hat neben dem Agenturangebot auch eine eigene Community und Agentur Coaching Angebot am Start – das fand ich sehr interessant – und natürlich seine authentische Art – falls du auf TikTok unterwegs bist – schau dir sein Profil gerne mal an – Folge 127 jetzt anhören.
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:
Goodbye AWS: 90% Kosteneinsparung und ISO 27001-Compliance
Das dänisches Workforce-Management-Unternehmen Datapult hat erfolgreich den kompletten AWS-Exit geschafft und dabei ihre jährlichen Cloud-Kosten von 24.000 Dollar auf 2.400 Dollar reduziert – eine 90%ige Ersparnis.
Die Motivation für den Wechsel
Das Unternehmen sah sich mit zwei kritischen Problemen konfrontiert: US-Rechtsprechung durch den CLOUD Act und FISA gefährdete die GDPR-Compliance europäischer Kundendaten, selbst bei EU-Servern. Zusätzlich erschienen 2.000 Dollar monatlich unverhältnismäßig für ihre tatsächlichen Anforderungen.
Der Wechsel erfolgte zu Hetzner und OVHcloud mit folgenden Services bzw. Umbaumaßnahmen:
- EC2 → Hetzner Cloud VMs plus dedizierte Server für Datenbanken
- RDS → Self-managed Postgres mit Ansible-Orchestrierung
- Lambda → Monolith-Integration und Prometheus-Jobs
- CloudWatch → Prometheus + Grafana + Loki
- S3 → OVH Object Storage (Hetzner S3 war noch nicht ausgereift)
- SQS → Apache Kafka für garantierte Delivery
Der Personalaufwand stabilisierte sich nach der Migration wieder bei 0,1 FTE – lediglich die 3-4 monatige Übergangsphase erforderte 0,5 FTE – zumindest laut Aussagen der Dataport Kommentare im verlinkten Medium Artikel. Besonders clever: Ansible dient als Compliance-Tool, da jede Serverkonfiguration direkt ISO 27001-Kontrollen zugeordnet werden kann.
Bei starkem Wachstum (5-10x) sollen stateless Services weiterhin selbst betrieben werden, während bei stateful Services wie Postgres entweder Multi-Tenant-Architekturen oder eine Rückkehr zu Managed Services evaluiert würde. Die europäische Datenhoheit erwies sich als starkes Verkaufsargument gegenüber den SaaS Kunden.
Kommt für mich nicht überraschend – gerade das ist ein typischer AWS Stack, bei dem vor allem EC2 und die RDS kostentechnisch reingehauen hatte. S3 wird teuer, wenn es viel Traffic gibt. Aus eigener Erfahrung kann ich sagen, dass man solche Werte durchaus erreichen kann.
Klar, ist das jetzt „nicht viel Geld“, aber man stelle sich vor, dass man anstatt 240.000 Dollar nur 24.000 Dollar braucht – da könnte man schon eine Person einstellen – bei der 0 mehr wird es dann schon gravierend.
Weitere Insights und Diskussion (aktuell 193 Kommentare) zu diesem Thema findest du hier bei Hacker News.
Bei Everysize haben wir das mit „We Manage“ ähnlich gemacht und 80 % Kosten eingespart – antworte mir gerne per Mail, falls du Interesse oder Beratung zu dem Thema benötigst.
Goodbye AWS: How We Kept ISO 27001, Slashed Costs by 90%
Wie könnte Kubernetes 2.0 aussehen?
Ein sehr interessanter und relevanter Artikel von Mat Duggan beschreibt, was Kubernetes nach 10 Jahren Entwicklung besser machen könnte. Seit dem ersten Commit am 7. Juni 2014 ist K8s zu einem zentralen Werkzeug für Container-Orchestrierung geworden – aber mit bekannten Schwächen.
Die Erfolgsgeschichte von K8s
Kubernetes revolutionierte drei zentrale Bereiche: Container-Skalierung von Laptop bis Tausende Server, wartungsarme Infrastruktur durch den Wechsel von „Pets zu Cattle“ und robuste Job-Verarbeitung statt fragiler Cron-Server. Dazu kommt Service Discovery ohne hardcodierte IP-Adressen.
Verbesserungsvorschläge für K8s 2.0
- YAML durch HCL ersetzen: Das „Norway Problem“ (NO = false) und fehlende Typsicherheit machen YAML problematisch. HCL aus Terraform bietet Typsicherheit, Variablen und Funktionen
- etcd-Alternativen: Ressourcenschonende Backends wie SQLite mit Raft-Konsens für kleinere Cluster
- Nativer Package Manager: Helm ist zu komplex und fehleranfällig. Ein Linux-ähnlicher Package Manager mit echten Dependencies und Signierung wäre besser
- IPv6 als Standard: Eliminiert NAT-Probleme, vereinfacht Netzwerk-Topologie und löst IP-Adress-Knappheit
Der Autor argumentiert: Defaults sind die mächtigste Kraft in der Technologie. Wenn K8s diese Verbesserungen als Standard implementierte, würde das Ökosystem automatisch folgen. Nach 10 Jahren sei es Zeit für eine grundlegende Überarbeitung der Plattform.
Vielen Punkten kann ich nur zustimmen – teilweise hat man das Gefühl, dass Themen mit Absicht verkompliziert werden, damit man sich einen Hyperscaler sucht, der ein entsprechenden Abstraktionslayer anbietet. Bei etcd Alternativen, YAML und dem Thema Package Manager bin ich komplett seiner Meinung – das sollte einfacher gehen. Vielleicht verschwindet Kubernetes auch mehr und mehr aus dem Developer Alltag – entweder durch Plattform Tools und Standardisierungen, die auf K8s andocken – oder durch PaaS und FaaS Offerings, die K8s nutzen und weiter abstrahieren. Was meinst du?
What Would a Kubernetes 2.0 Look Like
Anzeige
Cloud Exit mit „We Manage“ – 80 % Kosten gespart bei Everysize.com
Als everysize mit seiner Cloud-Infrastruktur an Grenzen stieß, fand das Unternehmen in We Manage den idealen Partner.
Das Ergebnis: 80% Kostenreduktion bei gleichzeitiger Leistungssteigerung.
„Der Profi-Sysadmin, den ich inhouse bräuchte, der aber bei mir zu wenig zu tun hätte,“ beschreibt Mitgründer Eugen Falkenstein treffend die Rolle von We Manage für sein Unternehmen.
Durch maßgeschneiderte IT-Operations, 24/7-Monitoring und Cloud-Migration befreite sich everysize vom teuren AWS-Vendor-Lock-in. Die Serverkosten sanken von 50.000 auf nur 10.000 Euro jährlich – bei höherer Zuverlässigkeit und Agilität.
Brauchst du Hilfe bei Cloud-Optimierung oder IT-Operations?
Lies die vollständige Case Study und erfahre, wie auch dein Unternehmen von We Manage profitieren kann – buch dir jetzt einen Termin zum Kennenlernen.
zur Case Study: Warum everysize die AWS Public Cloud hinter sich lässt
Remote Work: Drei bewährte Produktivitäts-Tools im Test
Eine interessante Analyse diverser Remote Work Tools von Marissa Goldberg zeigt, welche Software sich langfristig bewährt. Marissa hat jahrelang verschiedene Produktivitäts-Apps getestet und stellt drei Tools vor, für die sie tatsächlich bezahlt und die sich dauerhaft etabliert haben.
Todoist – Task Management ohne Schnickschnack
Todoist überzeugt durch reibungslose Erfassung von Aufgaben mit natürlicher Spracheingabe – „Quarterly report Friday 10am“ landet automatisch zur richtigen Zeit im Kalender. Besonders praktisch: nahtlose Integration in Google Calendar, Slack und Notion. Das Tool erwies sich bei der Familienplanung als zentrale Koordinationsstelle für Termine, Einkaufslisten und Baby-Vorbereitungen.
Bin selber großer Fan von Todoist und lange Jahre Nutzer, da es einfach schick und schlicht ist – zu todoist.com.
Tella – Loom-Alternative ohne Bugs
Nach Jahren mit Loom-Problemen wechselte die Autorin zu Tella für Async-Video-Kommunikation. Das Tool punktet mit fehlerfreier Aufnahme, professionellem Design ohne zusätzliche Bearbeitung und sofortiger Wiederverwendbarkeit von Onboarding-Walkthroughs und Produkt-Demos. Allerdings gibt es bei Tella im Vergleich zu Loom keinen kostenlosen Account (bei Loom 25 Minuten / 5 Videos kostenlos)
Brain.fm – Fokus auf Knopfdruck
Brain.fm löst das Problem der unvorhersagbaren Arbeitszeiten als Elternteil. Die wissenschaftlich entwickelten Audio-Tracks reduzieren Ablenkungen und fördern sustained attention. Kombiniert mit integriertem Pomodoro-Timer ermöglicht es produktive 30-Minuten-Blöcke auch in chaotischen Phasen. Das kannte ich nicht – ob ich damit meinen Schweinehund besiege?
Interessant – ich hab solche Musik bisher auf YouTube gehört – vermutlich ist Spotify / Apple Music da sogar besser als YT – brain.fm kostet nochmal 9,99$/Monat – irgendwie summiert sich das dann ja schon. Wie machst du das?
Marissa beschreibt im Fazit, dass für sie die besten Tools nicht die glänzendsten sind, sondern die reibungslosesten. Sie reduzieren Friction, respektieren Zeit und unterstützen den individuellen Workflow – ohne täglich neue Features zu versprechen.
My Quiet Power Tools for Remote Work
OpenTelemetry: Das Kosten-Problem der modernen Observability
Leon Adato, ein erfahrener Monitoring-Spezialist mit 27 Jahren Branchenerfahrung, deckt ein oft übersehenes Problem auf: OpenTelemetry (OTel) löse zwar das Vendor-Lock-in-Problem, verstärke aber gleichzeitig die Kostenexplosion bei Observability-Tools.
Die Preise scheinen auf den ersten Blick moderat:
- New Relic: 35¢ pro GB
- Datadog: $15-34 pro Host, 60¢-$1,22 pro Million Netflow-Records
- Dynatrace: 15¢ pro 100.000 Metriken plus Retention-Kosten
- Grafana: $8 für 1k Metriken, 50¢ pro GB für Logs/Traces
Doch in der Produktion entstehen schnell sechsstellige Monatsrechnungen – ein Unternehmen bekam sogar eine 65-Millionen-Dollar-Rechnung von Datadog.
Während OTel erfolgreich Vendor-Lock-in eliminiert, mache es Datenübertragung ineffizienter:
- Syslog-Message: 228 Bytes → OTLP-Format: 520 Bytes (25% größer)
- Prometheus-Metrik: 291 Bytes → OTLP-Format: 751 Bytes (2,5x größer)
Das Problem liege im „Sammle alles“-Mindset aus der On-Premises-Ära. Damals war Hardware-Kapazität der limitierende Faktor, heute sind es die Übertragungskosten. Unternehmen instrumentieren jeden Code-Span, versenden jede Log-Message und behalten alles „für alle Fälle“ – ohne konkrete Nutzungspläne. Manchmal wird auch aus Versehen „Debug“ aktiviert und läuft dann übers Wochenende…. 😉
Vor jeder Telemetrie-Implementierung sollten daher vier Kernfragen beantwortet werden:
- Was mache ich mit diesen Daten?
- Wer wird sie nutzen?
- Wie lange muss ich sie speichern?
- Wer zahlt dafür?
Der Autor prognostiziert einen Pendelschlag zurück zu Pauschaltarifen, ähnlich wie bei Mobilfunkverträgen von Per-Minute zu Flatrates.
Interessanterweise ist der Artikel aus dem Februar diesen Jahres und seit April arbeitet Leon bei Catchpoint, die m.W. ein ähnliches Pricing wie oben beschrieben haben – ob er das heute noch so sieht?
Who the Hell is Going to Pay For This?
ClickHouse LogHouse: Von 19 PB auf 100 PB – OpenTelemetry an seinen Grenzen
Ein ausführlicher Praxisbericht von ClickHouse bestätigt die im vorherigen Artikel beschriebenen OpenTelemetry-Ineffizienzen auf dramatische Weise. Während der 27-jährige Observability-Experte vor theoretischen 2,5x Overhead-Problemen warnte, liefert ClickHouse konkrete Zahlen: Das Unternehmen skalierte seine LogHouse-Plattform von 19 PB auf über 100 PB – und musste OTel größtenteils ersetzen.
Die ernüchternden OTel-Performance-Zahlen
Während OTel-Collector 800 CPU-Cores benötigten für 2 Millionen Logs/Sekunde, schafft das neue SysEx-System mit nur 70 CPU-Cores satte 37 Millionen Logs/Sekunde – das ist eine 20x höhere Effizienz. Um die gleiche Zuverlässigkeit mit OTel zu erreichen, hätte ClickHouse 8.000 CPU-Cores benötigt.
Das Problem: Ineffiziente Daten-Transformationen und die ClickHouse Lösung SysEx
OTel führe zu einem klassischen Serialisierungs-Overhead: ClickHouse-Daten wurden als JSON geschrieben, von OTel geparst, in OTel-Format konvertiert und wieder in ClickHouse eingefügt. Diese Mehrfach-Transformation verbrannte CPU-Zyklen und führte zu Datenverlust bei Traffic-Spitzen.
Der System Tables Exporter (SysEx) überträgt Daten byte-für-byte zwischen ClickHouse-Instanzen ohne Zwischentransformationen. Das System nutzt einen Pull-basierten Ansatz mit Hash-Ring-Verteilung und eliminiert die Buffer-Probleme von OTel komplett. Interessant: Dynamische Schema-Generation löst das Problem sich ändernder ClickHouse-System-Tables.
Nach der HyperDX-Akquisition durch ClickHouse (Folge 192, und Folge 117) entstand eine schema-agnostische Observability-UI mit Lucene-Syntax und SQL-Support. Diese ersetzt schrittweise die Grafana-basierte Custom-UI und unterstützt Wide Events ohne Konfigurationsaufwand.
ClickHouse verfolgt einen radikalen High-Cardinality-Ansatz: Statt Metriken werden wide Events mit vollständigem Kontext gespeichert. Aggregation erfolgt zur Query-Zeit, nicht beim Ingest – ein Paradigmenwechsel weg von traditionellen Three-Pillar-Modellen.
Hast du den ClickStack schon ausprobiert?
Scaling our Observability platform beyond 100 Petabytes by embracing wide events and replacing OTel
Prokrastination bei Software-Entwicklern: Mehr als nur „Faulheit“
Eine wissenschaftliche Studie mit 15 professionellen Software-Ingenieuren aus sieben Organisationen deckt die komplexen Ursachen von Prokrastination in der Softwareentwicklung auf. Das Ergebnis: Es ist nicht nur ein Produktivitätsproblem, sondern oft ein wichtiges Signal.
100% der Entwickler nannten uninteressante Tasks als primären Trigger. Weitere häufige Ursachen:
- Task-Vagheit (67% der Befragten)
- Unklare Prioritäten (73%)
- Hohe Komplexität (60%)
- Persönliche Faktoren wie Stress oder Imposter-Syndrom (87%)
- Externe Störungen und Kommunikationsprobleme (73%)
Drei Prokrastinations-Typen wurden identifiziert
- Task Aversion: Vermeidung langweiliger oder irrelevanter Aufgaben
- Task Avoidance: Stressbedingte Vermeidung aus Angst vor Fehlern
- Strategic Delay: Bewusste Verzögerung für bessere Deadline-Performance
Das SPACE-Framework zeigt komplexe Auswirkungen
Die Studie nutzte das SPACE-Framework (Satisfaction, Performance, Activity, Communication, Efficiency) und identifizierte 15 negative vs. 8 positive Effekte:
Negative Spitzenreiter: Emotionaler Stress (100%), reduzierte Performance (86%), geschwächte Teamkultur (93%)
Positive Überraschungen: Near-deadline Efficiency (93% berichten von Effizienz-Boosts), bessere Kreativität durch Reflexionszeit, Stress-Relief durch kurzzeitige Vermeidung
Lösungsansätze für Engineering Leads
- Tasks aufteilen: Vage oder komplexe Arbeit in kleinere, klar definierte Einheiten gliedern
- Sichere Kommunikation: Mechanismen schaffen, um Verzögerungen früh zu kommunizieren
- Produktive Delays unterstützen: Künstliche Deadlines und strukturierten Druck für deadline-orientierte Entwickler
Prokrastination ist kein persönliches Versagen, sondern oft ein Indikator für Probleme in Aufgabenstellung, Kommunikation oder Arbeitsumgebung. Uff, da bin ich ja beruhigt – halt, was ist, wenn man sich selbst die Aufgaben stellt?
Zum Thema Prokrastination kann ich diesen Ted Talk von Tim Urban auf YouTube sehr empfehlen – geht nur 14 Minuten – unbedingt schauen und nicht verschieben – hat schon 59 Millionen Aufrufe, ist also wirklich gut.
RDEL #93: What causes procrastination for software engineers?
DNS-Performance in Kubernetes: NodeLocal DNSCache als Game-Changer
Dieser Praxisbericht von Mercari zeigt, wie DNS auch heute noch Probleme machen kann und wie diese Probleme in großen Kubernetes-Clustern gelöst werden können. Das japanische E-Commerce-Unternehmen kämpfte vorher vor allem mit DNS-Ausfällen während Peak-Zeiten, die sogar zu Major-Incidents führten.
Das Problem: Überlastete kube-dns Pods
Bei extrem hohen Request-Raten stieß das Standard kube-dns-Setup an seine Grenzen. Die wenigen kube-dns-Pods mussten alle DNS-Queries für Services wie [service].[namespace].svc.cluster.local verarbeiten. Resultat: häufige DNS-Fehler, NXDOMAIN-Responses und „failed to refresh DNS cache“-Errors, die zu Produktionsausfällen führten.
Die Lösung: NodeLocal DNSCache
NodeLocal DNSCache implementiert DNS-Caching auf Node-Ebene statt zentral über kube-dns. Jeder Kubernetes-Node bekommt seinen eigenen DNS-Cache, wodurch Pods lokale DNS-Auflösung nutzen können, bevor sie kube-dns kontaktieren.
Die beeindruckenden Ergebnisse:
- 10x Reduktion der DNS-Calls an kube-dns
- 93% weniger DNS-Query-Rate für Cluster-Services
- 10x-100x Reduktion von DNS-Level-Fehlern
- 100% Eliminierung der „failed to refresh DNS cache“-Errors
- Deutlich verbesserte Cluster-Skalierbarkeit
Ein weiterer Optimierungsansatz betrifft externe DNS-Auflösung: CoreDNS kann bei Domains wie linkedin.com bis zu 3-4 Sekunden benötigen, da es systematisch verschiedene Kubernetes-Suffixe ausprobiert (.default.svc.cluster.local, .svc.cluster.local, etc.). Die Lösung: Punkt am Ende der Domain (linkedin.com.) für direkte externe Auflösung – besonders relevant bei tausenden Pods (zur Quelle bei LinkedIn).
Tja, nicht umsonst heisst ein bekanntes Blog „Everything is a Freaking DNS Problem“ – schöne Grüße an Kris.
From DNS Failures to Resilience: How NodeLocal DNSCache Saved the Day Infrastructure
Weltrekord: Cloudflare blockt 7,3 Tbps DDoS-Attacke autonom
Mitte Mai 2025 verzeichnete Cloudflare den größten jemals dokumentierten DDoS-Angriff mit 7,3 Terabits pro Sekunde – das sind 12% mehr als der bisherige Rekord. Die Attacke übertraf sogar einen kürzlich von Brian Krebs berichteten 6,3 Tbps-Angriff.
In nur 45 Sekunden wurden 37,4 Terabytes übertragen – das entspricht 9.350 HD-Filmen oder 7.480 Stunden hochauflösendem Video. Der Angriff bombardierte durchschnittlich 21.925 Zielports einer einzigen IP-Adresse mit Spitzen von 34.517 Ports pro Sekunde.
Multivektor-Angriff aus 161 Ländern
Die Attacke nutzte verschiedene Angriffsvektoren: 99,996% UDP-Floods, dazu QOTD-Reflection, NTP-Amplification, Mirai-Botnet und weitere. Sie stammte von über 122.145 IP-Adressen aus 5.433 Autonomous Systems in 161 Ländern – fast die Hälfte des Traffics kam aus Brasilien und Vietnam.
Autonome Abwehr ohne menschliches Eingreifen
Cloudflares dosd-System (denial of service daemon) analysiert Pakete über eBPF-Programme im Linux-Kernel und erstellt Fingerprints verdächtiger Muster. Die Abwehr erfolgte in 477 Rechenzentren an 293 Standorten weltweit – komplett autonom ohne Alerts oder Incidents.
Ziel der Attacke war übrigens ein Hosting-Provider, der Cloudflares Magic Transit nutzt. Hosting-Provider werden zunehmend zur Zielscheibe von DDoS-Attacken – allein Januar/Februar 2025 registrierte Cloudflare 13,5 Millionen Angriffe gegen Infrastruktur-Anbieter.
Defending the Internet: how Cloudflare blocked a monumental 7.3 Tbps DDoS attack
Schmunzelecke
The last six months in LLMs, illustrated by pelicans on bicycles – man sieht hier schön die Evolution der Modelle in den letzten Jahren.
💡 Link Tipps aus der Open Source Welt
NXTscape: Open-Source AI-Browser für lokale Agenten
NXTscape ist ein Chromium-basierter Open-Source-Browser (AGPL-3.0), der AI-Agenten lokal ausführt und sich als Privacy-Alternative zu kommerziellen Browsern positioniert.
Das Problem der aktuellen Browserlandschaft:
- 70+ offene Tabs sind Standard
- Einfache Tasks wie „Tide Pods aus Amazon-Verlauf bestellen“ sollten automatisch funktionieren, da man die Waschmaschinenkapseln ja regelmäßig braucht
- Browser haben sich seit 10 Jahren kaum weiterentwickelt
Kernfeatures von NXTscape:
- Lokale AI-Agenten mit browser-use & computer-use Models für Workflow-Automatisierung
- Ollama-Integration für komplette Datenkontrolle ohne Cloud-Abhängigkeit
- LLM-basierter Ad-Blocker als Antwort auf Chromes uBlock Origin-Blockade
- Native Produktivitäts-Tools: Highlighter, ChatGPT-Bookmarker, semantische Suche über Browser-History
Typische Use Cases:
- Automatisierung: Meetings planen, Formulare ausfüllen, repetitive Tasks
- Deep Research: Automatische Web-Recherche mit Report-Generierung
- Content Curation: LinkedIn/Twitter nach relevanten Posts durchsuchen
Browser sollen Open Source sein, nicht im Besitz von Search/Ad-Companies. Die Zukunft seien AI-Agenten, die lokal und sicher arbeiten – ohne dass Browser-History zum Werbeprodukt wird.
https://github.com/nxtscape/nxtscape
s3mini: Ultraleichter S3-Client für Edge Computing
s3mini ist ein 14 KB kleiner Typescript S3-Client für moderne Plattformen, der sich auf Geschwindigkeit und Einfachheit konzentriert.
Kernmerkmale:
- 15% mehr Operations/Sekunde bei nur 14 KB Größe (minified)
- Zero Dependencies mit AWS SigV4-Support
- Edge-Ready: Läuft auf Cloudflare Workers, Node.js und Bun
- Essential S3-APIs: list, put, get, delete und einige weitere
- Multi-Provider: Getestet mit Cloudflare R2, Backblaze B2, DigitalOcean Spaces, MinIO, Garage und Oracle
Ideal für:
- Edge Computing, beispielsweise mit Cloudflare Workers
- Serverless Functions mit minimaler Bundle-Größe
- Moderne Runtimes wie Bun
- S3-kompatible Services jenseits von AWS
Der Client verzichtet bewusst auf Browser-Support und unnötige Features zugunsten von Performance und geringer Größe – perfekt für Backend- und Edge-Anwendungen.
https://github.com/good-lly/s3mini
❓ 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: