Zum Inhalt springen
use-cases / idle-staging-stops-getting-deleted / hero
CONTAINERS · SNAPSHOTS · IDLE = GRATIS

Idle-Staging kostet nichts, also wird Staging nicht mehr gelöscht

Auf AWS stirbt Staging, weil jede Idle-Stunde eine abrechenbare Stunde ist. Auf Hoody fressen Idle-Container Disk und null CPU — also ist das Staging, das dein Reviewer vor drei Wochen angefasst hat, immer noch da, mit genau dem Zustand, in dem er es hinterlassen hat. Der Friedhof wird zur Working Set.

Containers-Docs lesen
use-cases / idle-staging-stops-getting-deleted / lifecycle

Was ein Idle-Container tatsächlich macht

Drei Zustände, eine Container-Zeile, eine Rechnung. Der aktive Zustand verbrennt CPU. Der Idle-Zustand verbrennt nichts. Der Wake-Zustand braucht ein paar hundert Millisekunden und dein Staging ist wieder genau so, wie du es verlassen hast.

01 / AKTIV

Reviewer stochert drin rum

Dein Teamkollege ist eingeloggt, klopft den neuen Endpoint ab, schaut aufs Dashboard. Die Prozesse des Containers sind eingeplant, die Memory-Pages heiß, die CPU-Zeit real. Das ist der einzige Zustand, der dich etwas kostet.

während beobachtetabgerechnet
02 / IDLE

Niemand hat ihn zehn Tage angefasst

Der Container ist suspendiert. Sein Dateisystem löst noch auf, sein Disk-Delta existiert noch, seine Proxy-Domain antwortet noch. KSM dedupliziert die RAM-Seiten und BTRFS dedupliziert die Disk-Blöcke über Container auf demselben Server — Idle-Marginalkosten sind strukturell nahe null. Dies addiert nichts zu dem Pauschalserver-Preis, den du eh schon zahlst.

während idlekeine zusätzliche Gebühr
03 / WAKE

Jemand pingt die URL — er ist zurück

Der erste Request, der ankommt, weckt den Container. Dieselbe Container-ID, dieselben Env-Vars, dieselben Volumes, derselbe SSH-Host. Der Zustand, den dein Reviewer hinterlassen hat, ist der Zustand, der zurückkommt. Kein Restore-Skript, kein frisches Provisioning, kein Tag, an dem du nachbaust, was du gelöscht hast.

zum Aufwachenein paar hundert ms

Hoody rechnet den Server pauschal ab. Der Idle-Zustand ist der Rest des Container-Lebens — und er ist der Zustand, in dem jede Staging-Umgebung die meiste Zeit lebt. KSM und BTRFS deduplizieren bedeuten, dass Idle-Container dem Server-Preis nichts hinzufügen.

use-cases / idle-staging-stops-getting-deleted / powers

Was sich an Staging dadurch ändert

Sobald Idle gratis ist, hörst du auf, die Entscheidungen zu treffen, die Staging für dich getroffen hat.

ERHALT

Du löschst keine Umgebungen mehr, um Geld zu sparen

Die Umgebung, die dein Reviewer vor drei Wochen genutzt hat, ist immer noch da, suspendiert, per Container-ID adressierbar. Der CFO sieht sie nicht auf der Rechnung, weil sie nicht auf der Rechnung steht. Das Gespräch, das früher mit „nuk zwei von drei“ endete, findet nicht statt.

TEMPO

Du baust nicht mehr nach, was du gelöscht hast

Der Reviewer pingt die URL, der Container wacht auf, seine Session läuft weiter. Kein frisches Provisioning, keine Seed-Daten, kein Warten, bis ein Heroku-Dyno aus dem Schlaf zurückkommt. Die Arbeit von gestern Nachmittag ist der Startpunkt von heute Nachmittag.

WORKING SET

Der Friedhof wird zur Working Set

Das Staging vom Launch letztes Quartal, der abgebrochene Payments-Rebuild, die kundenspezifische Demo aus Q4 — sie alle bleiben am Leben, zu Nullkosten. Wenn jemand fragt „haben wir die Umgebung noch?“, lautet die Antwort ja.

use-cases / idle-staging-stops-getting-deleted / ledger

Was der CFO früher sah, und was er jetzt sieht

Die Posten auf der AWS-Rechnung für eine Always-On-Staging-Flotte, und wozu diese Posten zusammenschrumpfen, wenn Idle nichts kostet.

ALTE RECHNUNG · ALWAYS-ONstündlich abgerechnet
  • ec2 staging-pr-2148 · t3.medium · 720h
  • ec2 staging-customer-acme · m5.large · 720h
  • ec2 staging-payments-rebuild · t3.large · 720h
  • rds staging-db cluster · 720h
  • elb shared-staging-alb · 720h
  • ebs gp3 attached volumes · 1.4 TB
fünf Umgebungen · sechs Posten · ein Cleanup-PR ewig in der Warteschlange
NEUE RECHNUNG · PAUSCHALSERVER · IDLE ADDIERT NICHTSPauschalserver · idle addiert nichts
  • container staging-pr-2148 · idle 22 Wochenincluded
  • container staging-customer-acme · idle 4 Wochenincluded
  • container staging-payments-rebuild · idle 24 Wochenincluded
  • container staging-mobile-v3 · diese Woche aktivincluded
  • container staging-launch-prep · idle 1 Wocheincluded
die aktive Woche zeigt sich · der Rest kostet nichts

Der CFO fragt nicht nach den drei Idle-Umgebungen, weil sie nicht auftauchen. Das Gespräch über ihr Löschen beginnt nie.

use-cases / idle-staging-stops-getting-deleted / numbers

Was die Container-Zeile tatsächlich garantiert

Zahlen kommen aus der Hoody-Containers-API und dem Snapshot-Modell — nicht aus erfundenen Benchmarks.

  1. PRO IDLE-MONAT$0

    Ein Idle-Container addiert keine Stundenmiete. Du zahlst für den Bare-Metal-Server — pauschal. KSM und BTRFS deduplizieren bedeuten, dass Idle-Container sich in den Server falten, den du eh schon mietest.

  2. DISK-FOOTPRINTDelta

    Snapshots sind content-adressiert und werden als Deltas gespeichert. Das Base-Image wird über jeden Container geteilt, der davon abstammt. Storage ist im Pauschalserver-Preis enthalten — keine separate Pro-Delta-Gebühr.

  3. ZURÜCK AUS IDLEWake

    GET /api/v1/containers/[id] löst den suspendierten Container auf. Der erste Request auf seine Proxy-Domain weckt ihn; der Zustand, den er hatte, als du aufgehört hast hinzuschauen, ist der Zustand, der zurückkommt.

Laut Hoody-Containers-API: Container persistieren als Zeilen mit den Feldern snapshot_count und last_used_snapshot. Die Snapshot-Aufbewahrung folgt standardmäßig der Policy deines Projekts; expires_at ist pro Snapshot konfigurierbar.

use-cases / idle-staging-stops-getting-deleted / punchline

Staging darf leben, weil leben lassen nichts mehr kostet.

vorher · die Always-On-Rechnungnachher · die Idle-Zeile
WAS DER CFO FRÜHER SAH$420/Monat · 5× ec2 · 5× ebs · idle wird trotzdem berechnetzwei Umgebungen letztes Quartal gelöscht, um die Grafik kleiner zu machen
WAS SIE JETZT SEHENGET containers/staging-pr-2148 · idle 90d · immer noch hierkein Cron-Job, kein Cleanup-PR, kein „das brauchen wir bestimmt mal wieder“-Friedhof
use-cases / idle-staging-stops-getting-deleted / replaces

Was das ersetzt

Der Standard-Always-On-Staging-Stack — und die Cron-Jobs und das Stammeswissen, die drumherum wachsen. Jeder davon rechnet stündlich ab. Hoody rechnet den Server pauschal ab; für Staging-Umgebungen, die die meiste Zeit idle sind, sind die Marginalkosten strukturell nichts.

  • AWS EC2 Staging-InstanzenImmer abgerechnet, auch um 03:00 am Sonntag, wenn niemand eingeloggt ist
  • Heroku Staging-DynosSleep-Mode verliert Session-State und fügt eine Cold-Start-Steuer beim Aufwachen hinzu
  • Render Staging-ServicesMonatliche Gebühr pro Service, egal ob die URL einmal oder tausendmal getroffen wurde
  • Eigene „staging-down“-Cron-JobsEine Lambda, die jede Umgebung löscht, die > N Tage idle ist, plus der Slack-Channel, in dem Leute fragen, warum ihre weg ist
  • Die „wir haben Staging gelöscht“-Tech-DebtEine Notion-Seite mit Umgebungen, die „nochmal nützlich sein könnten“, aber zur Glättung der Grafik genuked wurden
  • Geteiltes „Staging“, um das sich alle streitenEine Umgebung für zehn Reviewer, weil drei zu teuer wirkten — die tägliche Steuer im Standup, sich gegenseitig auf den Branches zu stehen
use-cases / idle-staging-stops-getting-deleted / cta

Hör auf, Umgebungen zu löschen, um Geld zu sparen. Der Friedhof ist jetzt eine Working Set.

Snapshot-Docs lesen
use-cases / idle-staging-stops-getting-deleted / related

Lies die anderen