Willkommen zu allesnurgecloud.com – Ausgabe #258
Immer wenn man denkt, es kann nicht wilder kommen, dann kommt so eine Woche wie diese.
Die Börse schmiert ab, Nvidia CEO Jensen Huang tritt zurück und Office365 hat eine über 24 Stunden Outage, bei der keiner weiß, warum eigentlich. Der Reihe nach.
Am 9. November hat Anthropic Claude Fable 5.2 und Mythos 5.2 veröffentlicht und der IPO soll zu einer Bewertung von 1,4 Billionen Dollar 6-fach überzeichnet sein. Währenddessen verbietet Goldman Sachs seinen Bänkern und Tradern die Nutzung von Claude Code – haha, welche Ironie. Bei United Airlines dürfen die AI‑Agents keine Flüge mehr buchen, lange bevor Agentic Commerce bei uns überhaupt angefangen hat.
Von der Office365‑Downtime habe ich während eines Kneipenabends erfahren. Ein Freund ist CIO bei einem größeren Mittelständler und bekam einen Anruf aus den USA – Outlook gehe nicht mehr. Man suchte aber erst mal bei sich, Internetverbindung, lokales Problem, etc. – man vertraut großen Cloud- und SaaS Anbietern mittlerweile so sehr, dass man gar nicht auf die Idee kommt, dass es nicht das eigene Problem ist. Das finde ich verrückt. Auch etwas verrückt für mich als kleinen Anbieter – Microsoft hat einen 99,9‑%‑SLA (44 Minuten Downtime im Monat) – und Geld zurück gibt es scheinbar keins – maximal eine Gutschrift und auch nur nach Antrag. Welcher deutsche Anbieter könnte sich so was erlauben?
Laut PragmaticEngineer hat man nun eine Rolle vorwärts gemacht und Systeme der alten Welt auf Azure migriert, da man das Problem anders nicht beheben konnte. Und es war wohl kein DNS – mal auf das PM warten.
Statuswerk, meine DSGVO-konforme Statusseite, ist in der geschlossenen Beta, einen Eindruck bekommst du auf der Demo-Status-Page. Antworte einfach auf den Newsletter, dann lade ich dich zur kostenlosen beta ein und ich freu mich auf dein Feedback!
In diesem Sinne – auf bessere Zeiten und trotzdem viel Spaß mit der Ausgabe.
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 197 habe ich mit Alexander Hojas und Thomas Auer von der Sonnenschmiede aus Graz gesprochen. Die beiden bringen Solarstrom vom Dach direkt in die Wohnungen von Mehrparteienhäusern. Möglich machen das Energiegemeinschaften und die Smart Meter, die in Österreich fast überall hängen (99% Rolloutquote). Mit zehn Leuten betreuen sie rund 250 Projekte und kamen im letzten Jahr auf knapp eine Million Euro Umsatz, ohne Investoren und fast ohne Marketing. Gerne kannst du die Folge auf YouTube schauen oder wie immer bei Spotify, Apple und allen anderen Playern anhören.
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:
ClickHouse kauft Xata und gibt Gas
ClickHouse ist längst mehr als eine spaltenorientierte Analytics-Datenbank, und mit der nach eigenen Angaben größten Erweiterung seit dem Start von ClickHouse Cloud kommen auf einen Schlag vier neue Produkte dazu:
- Managed Postgres ist GA, läuft auf lokalem NVMe, repliziert per CDC in unter einer Sekunde nach ClickHouse und bringt die Extension pg_clickhouse mit
- ClickHouse Observability startet als Public Beta auf OpenTelemetry-Basis
- ClickHouse Security, ein „agentic SIEM“ auf Basis des im September übernommenen RunReveal, ist in der Private Preview
- Das Langfuse AI Gateway ist in Rust geschrieben, Open Source und self-hostbar
Obendrauf kauft ClickHouse noch Xata. Deren Storage-Engine Xatastor reicht ZFS-zvols per NVMe/TCP durch, Copy-on-Write-Branches einer mehrere Terabyte großen Datenbank sollen so in rund 3 Sekunden stehen. Ungenutzte Instanzen gehen auf null und wachen in etwa einer Sekunde wieder auf, darunter läuft unverändertes Vanilla-Postgres. Gedacht ist das für eine Datenbank pro Pull Request oder Agent-Run. Bestehende Xata-Kunden werden migriert, sobald Feature-Parität erreicht ist, einen Termin dafür gibt es nicht.
Das Muster kennt man seit der Langfuse-Übernahme in Ausgabe 220: ClickHouse kauft die Anwendungen, die ohnehin auf ClickHouse laufen. Branching war auch das Verkaufsargument von Neon, das Databricks in Ausgabe 190 geschluckt hat, und einer der zitierten Xata-Kunden ist genau von dort gewechselt.
OLTP und OLAP aus einer Hand halte ich für sinnvoll, ich baue das bei Kunden mit Airbyte und ClickHouse selbst zusammen. Managed Postgres gibt es allerdings bisher nur auf AWS, und wer europäische Souveränität ernst nimmt, landet damit wieder beim CLOUD Act.
The largest expansion of ClickHouse yet
AWS für 2027 großteils ausverkauft
Die Cloud ist bekanntlich unendlich skalierbar, zumindest bis 2027. Amazon-CEO Andy Jassy sagte im Podcast mit Ben Horowitz, die großen Kapazitäts-Commitments von AWS seien für 2026 weg, 2027 weitgehend ausverkauft und ein guter Teil von 2028 schon vergeben. Ein Rest bleibe für On-Demand, EC2 und Bedrock reserviert. InfoQ hat die Reaktionen gesammelt.
Cloud-Analyst David Linthicum hält die Schlagzeile für übertrieben. Gemeint seien die riesigen, vorab gebuchten Blöcke für Modellanbieter, nicht die GPU-Instanz, die man heute in der Konsole klickt. Auf Reddit klingt das allerdings anders: Dort berichtet ein Nutzer von Engpässen bei ganz normalen EC2-Instanzen, On-Demand wohlgemerkt, an manchen Tagen sogar für Produktions-Kubernetes. Andere sehen dasselbe bei Azure East US. Die Reaktion darauf ist absehbar, man reserviert vorsorglich Kapazität, die man vielleicht braucht. Ian Rae nennt das zu Recht ein Anti-Cloud-Pattern.
Im aktuellen Doppelgänger Podcast prognostiziert Pip übrigens, dass die Hyperscaler wegen der Knappheit nächstes Jahr Margen um 50 % sehen könnten. Wer knapp ist, bestimmt eben den Preis. Dazu passt, dass AWS die Capacity Blocks für ML schon im Januar um rund 15 % verteuert hat.
Für Europa ist das keine gute Nachricht. Dass RAM und CPUs knapp werden, war schon in Ausgabe 251 und früher ein Thema, und das trifft die kleineren Hoster zuerst. Elastisch ist an der Cloud gerade vor allem der Preis.
AWS Capacity Largely Sold out through 2027, with On-Demand Headroom Reserved
Mittwald: Angriff über den eigenen MCP-Server
Ein Hoster, der über den eigenen MCP-Server angegriffen wird, das ist neu. Laut Golem gab es beim Espelkamper Hoster Mittwald schon am 27. Oktober einen unbefugten Zugriff auf das mStudio über den MCP-Server, bemerkt wurde er erst am 4. November. Ab dem 5. November schaltete Mittwald laut Statusseite MCP-Server, mStudio-Login, SSH, Extensions und Bestellungen ab, deaktivierte einen kleinen Teil der Kundenprojekte und startete die Systeme neu. Laut Lokalpresse sollen 56 Projekte kompromittiert worden sein, Polizei, BSI und Datenschutzaufsicht seien informiert.
Am 12. November kam laut heise der zweite Anlauf. Die Angreifer kompromittierten über eine Sicherheitslücke die Unternehmenswebsite, Mittwald nahm sie vom Netz und schaltete Kundencenter, mStudio und SSH erneut ab. Ein Defacement bestreitet das Unternehmen, es spricht von professionellen Angreifern mit automatisierten KI-Systemen. Seit dem 13. November sind Kundencenter, mStudio und Website wieder da, AV-Manager und Agentur Hub laufen noch eingeschränkt. Websites und Postfächer waren laut Mittwald durchgehend erreichbar.
Als Kunde musst du laut Mittwald nichts tun. Ich würde trotzdem einen Passkey oder eine Authenticator-App einrichten (die neue 2FA per Mail ist nur das Minimum) und alle API-Tokens rotieren, die in Agenten oder MCP-Clients stecken. Ein Postmortem ist angekündigt, und mich interessiert vor allem, wie der MCP-Server gegenüber dem mStudio berechtigt war.
Die Kommunikation finde ich ordentlich, mit Updates teils im Stundentakt. Die Statusseite liegt übrigens nicht bei Mittwald selbst und blieb deshalb erreichbar, als die eigene Website offline war. So etwas gibt es DSGVO-konform und in Deutschland gehostet auch bei Statuswerk.
Angriff über MCP-Server: Webhoster Mittwald im Krisenmodus
Self-Hosting 2026: Debian, Docker und manuelle Updates
Für die jährliche Self-Host User Survey von selfh.st hat Ethan Sholly dieses Jahr 6.221 vollständige Antworten bekommen, gut die Hälfte mehr als im Vorjahr. Die Teilnehmer hosten überwiegend privat und arbeiten zu fast 80 % selbst in der IT. Repräsentativ ist das nicht, aber ein ordentliches Stimmungsbild der Homelab-Szene. Aus der langen Liste habe ich mir die Punkte rausgepickt, die auch im professionellen Betrieb interessant sind:
- Debian und Ubuntu dominieren klar bei den Distributionen, Proxmox und Home Assistant OS führen bei den spezialisierten Systemen
- Backblaze ist der beliebteste Cloud-Storage, Proton Drive und Cloudflare R2 legen zu. Ein Drittel verlässt sich auf ein einziges Backup, 10 % haben gar keins
- Docker dominiert, aber nur ein Viertel nutzt Orchestrierung. Portainer stürzt von 66 auf 33 % ab, Dockhand, Komodo und Arcane holen auf
- Fast die Hälfte aktualisiert Container von Hand, vollautomatische Updates sinken sogar von 15 auf 12 %
- Über die Hälfte setzt auf Traefik, Caddy oder Nginx Proxy Manager. Registrar Nummer eins bleibt Cloudflare, Porkbun überholt Namecheap
Neu ist dieses Jahr der AI-Teil: 60 % nutzen KI beim Self-Hosting, Claude liegt vor ChatGPT und Gemini. Fulghums These vom Self-Hosting-Jahr dank CLI-Agenten aus Ausgabe 220 scheint also aufzugehen. Forgejo hat Gitea übrigens als beliebteste Git-Plattform abgelöst.
Die manuellen Updates wundern mich nicht. Wer einmal nach einem automatischen Watchtower-Pull eine kaputte Nextcloud hatte, klickt lieber selbst, oder halt gar nicht. Bei 10 % ohne Backup ist dann aber Mut im Spiel …
2026 Self-Host User Survey Results
incident.io: „Nur noch“ 1.600 Dollar KI pro Dev und Monat
Was kostet eigentlich ein Pull Request, wenn ihn ein Agent schreibt? Bei incident.io misst man das in „Effort Points“, ein Punkt entspricht einem mittelgroßen PR. Gergely Orosz hat die Zahlen im Pragmatic Engineer veröffentlicht. Er ist allerdings selbst Investor bei incident.io.
Im Juli lagen die KI-Ausgaben bei über 300.000 Dollar im Monat, rund 4.500 Dollar pro Engineer, überwiegend für Opus 5. Mit Opus 5.5 sanken sie auf etwa 1.600 Dollar, davon gehen 80 % an Claude und 20 % an Cursor. Fürs Jahr rechnet man mit rund 1,6 Millionen Dollar bei 50 Engineers. Spannender finde ich diese Zahlen:
- Fast 80 % der PRs in Produktion enthalten Agent-Code, 43 % gehen ganz ohne menschliches Review raus
- Der Median-Engineer liefert nur 10 % mehr PRs als 2024 ohne KI, erfahrene Kollegen dagegen 70 % mehr
- Neue Leute sollen im ersten Monat bewusst auf KI verzichten, weil frühe Vielnutzer langfristig schlechter abschnitten
- Das Infra-Team zahlt pro Effort Point etwa das Fünffache, weil Exploration und Benchmarks Token fressen, ohne PRs zu erzeugen
Die Incidents pro 1.000 PRs sanken um 60 %, absolut gibt es bei dreimal so vielen PRs aber mehr. Fehlerhafter Code ist inzwischen selten die Ursache, meist fehlt dem Agenten Wissen über die Produktionsumgebung. Was mich verwirrt: Es gibt Incidents bei incident.io? Werden die dann mit der eigenen Incident-Software erfasst? Ahhh …
Den Effort Point halte ich jedenfalls für eine brauchbare Unit-Metrik, ähnlich den Cloud-Kosten pro Kunde aus Ausgabe 196. Dass die Rechnung allein durch ein neues Modell um zwei Drittel sinkt, zeigt aber auch, wie wenig planbar dieser Kostenblock noch ist. Naja, solange die Kosten immer nur sinken, ist das ja nicht schlimm …
The Pulse: Details of incident.io’s AI spend
Und auch Datadog baut sich ein eigenes Git
Jeder CI-Job beginnt mit einem git clone, und der ist nicht gratis. Bei Datadog holt CI millionenfach pro Woche Code aus tausenden Repos, die größten davon sind Monorepos mit jahrelanger History. Laut Datadog-Engineering-Blog haben Agenten den Git-Traffic um eine Größenordnung gesteigert. Das self-hosted Gitaly hinter GitLab hielt das nicht mehr aus, CI fiel teils stundenlang aus.
Mehr Nodes machten es schlimmer, weil jede Replica auch mehr Replikationslast bedeutete. Die Lösung heißt gitretriever: wenige Mirrors, die GitHub pro geänderter Branch abfragen, dahinter eine autoskalierende Flotte von Relays. Weil Git-Objekte content-addressed sind, übernehmen die Relays die Packfiles ungeprüft und bauen nichts neu, und ein Pack-Cache bedient etwa die Hälfte der identischen Fetches nach einem Push. Ergebnis: 20-fach mehr Traffic bei weiterhin rund 40 ms Median-Latenz und drei- bis viermal weniger CPU auf dem alten Backend. Dazu kam eine kleine HTTP-API für Einzeldateien und Ref-Abfragen, denn die meisten Nicht-CI-Clients brauchten gar keinen Clone. Gebaut haben das zwei Engineers mit Claude Code und einem Design-Dokument in fast jedem Ordner.
In Ausgabe 254 hatte Anthropic mit Scion gleich ganz auf Git verzichtet, und dort lief vorher übrigens ebenfalls eine Mirror-Flotte.
Inzwischen baut also jeder sein eigenes Git. Was wäre eigentlich, wenn jetzt jeder sein eigenes Datadog baut? Braucht Datadog dann noch ein eigenes Git?
Oder andersrum – wenn du dir kein eigenes Git baust, dann machst du vielleicht zu wenig mit KI?
20× the CI traffic without getting slower: How we rebuilt Git serving at Datadog
Die „Senior Engineer Death Spiral“ vermeiden
Neuer Job, hohes Gehalt, große Erwartungen, und ein bisschen Imposter-Syndrom ist auch dabei. Ein Freund fragte Sunil Pai, wie man eine 60- bis 80-Stunden-Woche durchhält, um sich zu beweisen. Die Antwort ist ein Monolog über das, was Pai die „Senior Engineer Death Spiral“ nennt.
Der Ablauf dürfte vielen bekannt vorkommen. Jemand will zeigen, dass er die neue Rolle verdient, und nimmt sich ein möglichst ambitioniertes Projekt vor. Dann taucht er für zwei, drei Wochen ab. Im Standup kommt nur das „positive Update“, man habe bald etwas zu zeigen. Insgeheim plant er, die verlorene Zeit mit Nachtschichten aufzuholen. Am Ende stehen Schlafmangel, Burnout, ein PIP oder die Kündigung. Pai schreibt offen, dass ihm das selbst mehrfach passiert ist.
Sein Gegenmittel klingt paradox: eine Stufe runtergehen und erst mal der beste Teamkollege sein. Bugs fixen, liegengebliebene Aufgaben anderer übernehmen, Dokumentation schreiben. Es geht um Momentum, kleine tägliche Schritte bringen Routine und Vertrauen, und die großen Projekte kommen danach von selbst. Und die eigene Arbeit gehört sichtbar geteilt, gerade remote und mit Coding-Agents im Silo. Schlimmer als nervig zu sein sei, wenn niemand weiß, woran du gerade arbeitest.
Vor kurzem hatte ich in Ausgabe 252 den Wechsel vom Engineer zum Manager und das neue „Scoreboard“ vorgestellt. Aus Chefsicht macht der Kollege, der regelmäßig kleine Updates liefert, wohl deutlich weniger Sorgen als der, von dem man drei Wochen nichts hört.
the senior engineer death spiral
Backstage: Ohne Teams kein Service Catalog
Nachts um zwei feuert ein Alert für einen Service, den du nie angefasst hast. Das README ist zwei Jahre alt, der Slack-Thread verweist auf ein Team, das es nach der letzten Reorg nicht mehr gibt, und Sam, der sich damit auskennt, ist im Urlaub. Nach zwanzig Minuten hast du noch nichts diagnostiziert und stattdessen Archäologie betrieben. Mit dieser Szene startet SRE Bill Duncan seine Serie über Backstage, den Developer-Portal-Klassiker von Spotify, der inzwischen ein CNCF-Projekt ist.
Duncan zerlegt das Problem in fünf Fragen: Wer besitzt den Service, wer das Repo, was hängt davon ab, wer sind die Experten und wer hat gerade Rufbereitschaft. Ownership gehört an ein Team, nicht an eine Person, denn Personen veralten zuerst. CODEOWNERS sagt dir, wer reviewt, aber nicht, wer geweckt wird. Am spannendsten finde ich die umgekehrte Abhängigkeit. Was ein Service braucht, steht im Code, wer an ihm hängt, weiß meist niemand. Deklariert jeder Service seine Abhängigkeiten in einer catalog-info.yaml im eigenen Repo, kann der Katalog das umdrehen.
Den eigentlichen Haken beschreibt er im zweiten Teil: Ein Katalog, den nur SRE will und die Entwicklungsteams nicht pflegen, ist bloß eine neuere Wiki-Seite. Sein Team hat deshalb nicht mit einem leeren Katalog angefangen. Ein Skript glich die laufenden Kubernetes-Workloads mit dem Katalog ab, der erste Lauf ergab 62 % Abdeckung und 113 unbekannte Workloads. Für jeden davon entstand ein Entwurf der YAML-Datei, den Owner leitete man aus der Commit-History ab statt aus CODEOWNERS. Dass anfangs 27 Komponenten „unknown“ gehörten, war einkalkuliert. Eine falsche Antwort vor dem richtigen Team wird schnell korrigiert, ein leeres Feld bleibt leer.
Angereichert wurde zentral, solange SRE noch selbst mergen konnte. Erst danach gingen die Dateien per Bulk-Merge-Request in rund 50 Team-Repos. Entscheidend war für Duncan etwas anderes: Entwickler interessiert Ownership kaum, ihr Deploy-Status dagegen schon. Also gibt es pro Service ein generiertes Grafana-Dashboard, Kubernetes- und Argo-CD-Status, On-Call und Runbooks auf einer Seite. Wer dort regelmäßig vorbeischaut, bemerkt auch falsche Einträge. Am Ende stand die Abdeckung bei etwa 80 %.
Spotifys eigene Backstage-Erfahrungen hatte ich vor, äh, fünf Jahren in Ausgabe 39 vorgestellt. Duncans Serie ist der ehrlichere Praxisbericht, weil sie zeigt, dass das Aufsetzen von Backstage der leichte Teil war, wie bei jedem Knowledge-Management-System.
Meta Prometheus: 1 Million GPUs und 13 % Reserve
Vor zwei Jahren lief im Rechenzentrum in New Albany, Ohio, noch normaler Web-Traffic. Heute trainiert Meta dort auf dem Supercluster Prometheus seine neuen Muse-Modelle, und das Engineering-Team beschreibt ungewohnt offen, wie es dabei kracht. Aktuell sind es mehrere hunderttausend GPUs (GB200 und GB300), am Ende sollen es rund 1 Million werden, verteilt auf Gebäude, Zelte und angemietete Flächen.
Spannender als die Größe finde ich die Fehlerstatistik. Mitte 2025 zählte Meta in der Spitze fast 1.000 Unterbrechungen pro 8.000 GPUs und Tag, inzwischen nach eigenen Angaben 99 % weniger. Größter Störfaktor war die Signalqualität der über 600.000 NVLink-Verbindungen, bei GB300 kamen Speicherfehler dazu. Mit NVL72 wächst die Fehlerdomäne von 8 auf 72 GPUs. Meta nutzt pro Rack deshalb nur 64 GPUs und hält 8 als Hot Spare vor, plus rund 2 % Reserve-Racks. Für einen Job mit 32.768 aktiven GPUs stehen so 37.656 im Rechenzentrum.
Ein zweites Problem ist der Strom: Synchrones Training erzeugt Lastsprünge von 30 bis 40 %, beim Start eines großen Jobs zweistellige Megawatt in Sekunden. Abgefangen wird das mit Power Capping, Batterien im Rack und Speichern auf Standortebene.
In Ausgabe 209 waren bei Llama 3 noch zwei Drittel der Trainingsabbrüche Hardware-Fehler. Daran hat sich offenbar wenig geändert, Meta ist nur besser im Aufräumen geworden. Trotzdem echt abgefahren, diese Zahlen: Die meisten wären froh, wenn sie so viel Zeug im DC stehen hätten, wie bei Meta kaputtgeht.
Mal schauen ob Meta bald die GPU Datacenter vermietet, ähnlich wie SpaceX oder wie auch immer die Bude jetzt heißt.
Inside Prometheus: Meta’s Journey to a Gigawatt-Scale Supercluster
Was JavaScript-Frameworks im Agenten-Zeitalter kosten
Welches Framework „besser für Agenten“ ist, wird meist nach Bauchgefühl oder anhand der eigenen Erfahrungen entschieden. Nolan Lawson hat dazu einen Benchmark gebaut: Opus 5.5 hat dieselbe Pokémon-App in 12 Frameworks je fünfmal gebaut. Geprüft wurde gegen eine Conformance-Suite und mit Lighthouse.
Am günstigsten war Hono+htmx mit 2,67 Dollar pro Durchlauf, am teuersten Angular mit 4,97 Dollar. Angular brauchte im Median auch 17 Minuten, Astro gut 8, und zweimal lieferte es eine SSR-App, die Anfragen außerhalb von localhost ablehnte. SvelteKit wurde teuer, weil der Agent in jedem Lauf den v3-Migrationsguide las. Die offiziellen MCPs und Skills nutzten die Agenten kaum. Lawson vermutet, dass sie derzeit eher schaden als helfen könnten.
Die Lighthouse-Scores lagen fast überall bei 100 und sagen daher wenig. Interessanter sind die JavaScript-Bytes: 0 KiB bei Astro, 142 KiB bei Next.js. Hono+htmx kam mit rund 1.370 Zeilen Code aus, Angular brauchte gut 2.000. Weniger Code heißt auch weniger Tokens bei jeder späteren Änderung.
Die Einschränkungen nennt Lawson selbst: Es ist eine kleine, eher statische App, und das Setup bevorzugt MPAs. Auf Hacker News berichtet unsloppable, dass Agenten bei einem komplexen Formular mit viel State an htmx scheiterten, bis umfangreiche Tests dazukamen.
Wer htmx aus Ausgabe 217 noch im Kopf hat, findet hier ein Argument mehr. Mir gefällt vor allem, dass die Zahlen nachprüfbar sind: Den Benchmark gibt es auf GitHub zum Nachbauen.
The AI cost of JavaScript frameworks
Schmunzelecke
50 KI-Agenten sollten in Minecraft eine Zivilisation aufbauen, nach der ersten Nacht hatten sie eine lähmende Bürokratie samt „Dünge-Operator“ erfunden (Golem).
Need for Speed Underground 2 läuft dank eines Fanprojekts jetzt im Browser, samt Online-Rennen: nfsu2.xyz.
💡 Link Tipps aus der Open Source Welt
Keploy – API- und Integrationstests aus echtem Traffic per eBPF
Keploy erzeugt Tests, indem es mitschneidet, was deine Anwendung tatsächlich tut: API-Calls, Datenbankabfragen und Messages aus Queues. Die Aufzeichnungen spielt es später als Tests samt Mocks wieder ab, sodass keine echte Datenbank und kein externer Dienst laufen müssen. Weil der Traffic per eBPF auf Netzwerkebene abgegriffen wird, brauchst du weder ein SDK noch Änderungen am Code, und die Sprache der Anwendung spielt keine Rolle.
Key Features:
- Record and Replay: keploy record startet die App und macht aus echten Requests automatisch Testfälle und Mocks
- Infra-Virtualisierung: Mockt nicht nur HTTP, sondern auch Postgres, MySQL/MariaDB, MongoDB, Kafka und RabbitMQ, deterministisch beim Replay
- Time Freezing: Friert die Systemzeit beim Testlauf ein, damit Timestamps keine Flaky Tests verursachen
- AI-Testgenerierung: Leitet aus Aufzeichnungen und OpenAPI-Specs zusätzliche Edge Cases ab, etwa Grenzwerte, falsche Typen oder Timeouts
- Coverage: Statement-, Branch- und API-Schema-Coverage in einem gemeinsamen Report
- CI/CD: Läuft lokal, in Pipelines wie GitHub Actions oder Jenkins oder im Kubernetes-Cluster
Der eBPF-Ansatz ist elegant, gerade für Legacy-Anwendungen ohne nennenswerte Testsuite, bei denen niemand mehr Mocks von Hand schreiben will. Mit 19.700 Stars, 146 Contributors und 860 Releases ist Keploy etabliert, auch wenn das Release-Tempo eher nach Continuous Deployment aussieht als nach stabilen Versionen. Die „90 Prozent Coverage“ aus dem README sind natürlich Marketing, mit Open Core musst du ebenfalls rechnen: Einige Protokoll-Parser und die native Windows-Interception gibt es nur in der Community- bzw. Enterprise-Variante von Keploy Inc.
https://github.com/keploy/keploy
zot – Schlanke, herstellerneutrale OCI Registry für Container Images und Artefakte
zot ist eine Container Registry, die sich konsequent auf die OCI-Standards beschränkt: Images werden im OCI Image Format gespeichert und über die OCI Distribution Spec ausgeliefert, ohne proprietäre Erweiterungen. Das Projekt ist sieben Jahre alt, stammt ursprünglich von Cisco und ist heute ein CNCF-Projekt. Neben Container Images speichert zot auch beliebige OCI-Artefakte wie Helm Charts, Signaturen oder SBOMs.
Key Features:
- Single Binary: Eine Go-Binary statt eines Microservice-Zoos, dazu eine Minimal-Variante ohne Extensions
- Storage: Lokales Filesystem oder S3-kompatibler Object Storage, mit Deduplizierung und Garbage Collection
- Sync: Spiegelt Images aus anderen Registries, als geplanter Sync oder On-Demand als Pull-Through-Cache
- Security: CVE-Scans und SBOM-Erzeugung über Trivy, Signaturprüfung mit cosign und Notation
- Auth: LDAP, OIDC und API Keys, deren Laufzeit sich jetzt per apikeyMaxLifetime begrenzen lässt
- Web UI und Events: Optionale Oberfläche (zui) und eine Events-Extension für Benachrichtigungen bei Änderungen
- Clustering: Scale-out über mehrere Instanzen mit gemeinsamem Storage
Geschrieben in Go, lizenziert unter Apache 2.0. Images gibt es für amd64 und arm64.
Wer eine eigene Registry betreiben will und dem Harbor mit seinen vielen Komponenten zu schwer ist, findet in zot eine gute Mitte zwischen der nackten Docker Distribution und einer kompletten Plattform. Mit 3.000 Stars ist das Projekt unterschätzt, 126 Contributors, 123 Releases, ein Coverage-Minimum von 94 Prozent und das OpenSSF Scorecard zeigen aber eine solide Basis. Gerade als Pull-Through-Cache vor Docker Hub ist zot für Homelab und CI interessant. Für Features wie Replikationsregeln über Projekte oder Quotas pro Team ist Harbor weiterhin die umfassendere Wahl.
https://github.com/project-zot/zot
❓ 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: