Ir al contenido
use-cases / idle-staging-stops-getting-deleted / hero
CONTAINERS · SNAPSHOTS · IDLE = FREE

El staging inactivo no cuesta nada, así que el staging deja de borrarse

En AWS, el staging muere porque cada hora inactiva es una hora facturable. En Hoody, los contenedores inactivos consumen disco y cero CPU — así que el staging que tu reviewer tocó hace tres semanas sigue ahí, con el estado exacto en que lo dejó. El cementerio se convierte en un working set.

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

Lo que hace realmente un contenedor inactivo

Tres estados, una fila de contenedor, una factura. El estado activo quema CPU. El estado inactivo no quema nada. El estado de despertar tarda unos cientos de milisegundos y tu staging vuelve exactamente como lo dejaste.

01 / ACTIVE

El reviewer está toqueteándolo

Tu compañero está logueado, ejercitando el nuevo endpoint, mirando el dashboard. Los procesos del contenedor están planificados, sus páginas de memoria están calientes, su tiempo de CPU es real. El servidor de tarifa plana está haciendo su trabajo.

mientras se observafacturado
02 / IDLE

Nadie lo tocó en diez días

El contenedor está suspendido. Su sistema de archivos sigue resolviéndose, su delta de disco sigue existiendo, su dominio proxy sigue respondiendo. KSM deduplica las páginas de RAM y BTRFS deduplica los bloques de disco entre contenedores en el mismo servidor — el coste marginal inactivo es estructuralmente casi cero. No añade nada al precio del servidor de tarifa plana que ya pagas.

mientras está inactivosin cargo extra
03 / WAKE

Alguien hace ping a la URL — vuelve

La primera petición que llega despierta el contenedor. El mismo ID, las mismas variables de entorno, los mismos volúmenes, el mismo host SSH. El estado que dejó tu reviewer es el estado que vuelve. Sin script de restauración, sin aprovisionamiento nuevo, sin un día reconstruyendo lo que borraste.

para reanudarunos cientos de ms

Hoody factura el servidor, a tarifa plana. El estado inactivo es el resto de la vida del contenedor — y es el estado en el que vive cada entorno de staging la mayor parte del tiempo. KSM y BTRFS dedup significan que los contenedores inactivos no añaden nada a ese precio de servidor.

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

Lo que esto cambia en el staging

Una vez que lo inactivo es gratis, dejas de tomar las decisiones que el staging tomaba por ti.

PRESERVACIÓN

Dejas de borrar entornos para ahorrar dinero

El entorno que tu reviewer usó hace tres semanas sigue ahí, suspendido, accesible por ID de contenedor. El CFO no lo ve en la factura porque no está en la factura. La conversación que solía acabar en "cargarse dos de tres" no ocurre.

VELOCIDAD

Dejas de reconstruir lo que borraste

El reviewer hace ping a la URL, el contenedor despierta, su sesión se reanuda. Sin aprovisionamiento nuevo, sin datos semilla, sin esperar a que un dyno de Heroku vuelva del modo dormido. El trabajo de la tarde anterior es el punto de partida de la siguiente.

WORKING SET

El cementerio se convierte en un working set

El staging del lanzamiento del último trimestre, la reescritura de pagos abandonada, la demo específica de cliente del Q4 — todos siguen vivos a coste cero. Cuando alguien pregunta "¿aún tenemos ese entorno?" la respuesta es sí.

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

Lo que el CFO solía ver, y lo que ve ahora

Las líneas de la factura de AWS para una flota de staging always-on, y en qué se colapsan esas líneas cuando lo inactivo no cuesta nada.

FACTURA ANTIGUA · ALWAYS-ONfacturable por hora
  • 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
cinco entornos · seis líneas · una PR de limpieza pendiente desde siempre
FACTURA NUEVA · IDLE-FREEservidor de tarifa plana · inactivo no añade nada
  • container staging-pr-2148 · inactivo 22 semanasincluido
  • container staging-customer-acme · inactivo 4 semanasincluido
  • container staging-payments-rebuild · inactivo 24 semanasincluido
  • container staging-mobile-v3 · activo esta semanaincluido
  • container staging-launch-prep · inactivo 1 semanaincluido
la semana activa aparece · el resto no cuesta nada

El CFO no pregunta por los tres entornos inactivos porque no aparecen. La conversación sobre borrarlos nunca empieza.

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

Lo que la fila del contenedor garantiza realmente

Los números vienen de la API de contenedores de Hoody y del modelo de snapshots — no de benchmarks inventados.

  1. POR MES INACTIVO$0

    Un contenedor inactivo no añade ninguna tarifa por hora. Pagas el servidor bare-metal — tarifa plana. KSM y BTRFS deduplicado significan que los contenedores inactivos se integran en el servidor que ya alquilas.

  2. HUELLA EN DISCOdelta

    Los snapshots están direccionados por contenido y se almacenan como deltas. La imagen base se comparte entre cada contenedor que desciende de ella; solo el diff es lo que pagas.

  3. VUELVE DE INACTIVOwake

    GET /api/v1/containers/[id] resuelve el contenedor suspendido. La primera petición que toca su dominio proxy lo despierta; el estado que tenía cuando dejaste de mirar es el estado que vuelve.

Según la API de contenedores de Hoody: los contenedores persisten como filas con campos snapshot_count y last_used_snapshot. La retención de snapshots tiene como valor por defecto la política de tu proyecto; expires_at es configurable por snapshot.

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

El staging puede vivir, porque dejarlo vivir ya no cuesta nada.

antes · la factura always-ondespués · la fila inactiva
LO QUE EL CFO SOLÍA VER$420/mes · 5× ec2 · 5× ebs · inactivo aún facturadodos entornos borrados el último trimestre para reducir el gráfico
LO QUE VEN AHORAGET containers/staging-pr-2148 · inactivo 90d · sigue aquísin cron, sin PR de limpieza, sin cementerio de "esto lo necesitaremos algún día"
use-cases / idle-staging-stops-getting-deleted / replaces

A qué reemplaza esto

El stack estándar de staging always-on — y los crons y el conocimiento tribal que crecen a su alrededor. Cada uno cobra por hora. El contenedor de Hoody cobra por hora activa, que para staging es casi nada.

  • Instancias EC2 de staging en AWSSiempre facturadas, incluso a las 03:00 de un domingo sin nadie logueado
  • Dynos de staging en HerokuEl modo dormido pierde el estado de sesión y añade un impuesto de cold start al despertar
  • Servicios de staging en RenderCuota mensual por servicio tanto si se accedió a la URL una vez como mil
  • crons "staging-down" personalizadosUna Lambda que borra cualquier entorno inactivo > N días, más el canal de slack donde la gente pregunta por qué se fue el suyo
  • la deuda técnica del "borramos staging"Una página de Notion con entornos que "podrían ser útiles otra vez" pero se eliminaron para aplanar el gráfico
  • el "staging" compartido por el que todos peleanUn entorno para diez reviewers porque tres parecía caro — el impuesto diario de pisarse las ramas en la stand-up
use-cases / idle-staging-stops-getting-deleted / cta

Deja de borrar entornos para ahorrar dinero. El cementerio es ahora un working set.

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

Lee los otros