Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Containers·Snapshots
TipoDesbloqueadoEtapaFlotaDificultadModeradoTrabajoSaaS multi-inquilinoParaEquipos de desarrolloParaDesarrolladores backendServiciosCronServiciosContainersPor qué HoodyEconomía de contenedoresPor qué HoodyAislamiento bare-metalPor qué HoodyHTTP nativoIndustriaSaaS
TipoDesbloqueadoEtapaFlotaDificultadModeradoTrabajoSaaS multi-inquilinoParaEquipos de desarrolloParaDesarrolladores backendServiciosCronServiciosContainersPor qué HoodyEconomía de contenedoresPor qué HoodyAislamiento bare-metalPor qué HoodyHTTP nativoIndustriaSaaS
use-cases / cron-per-customer / hero
SaaS multi-inquilino / Programación por cliente
Un crontab independiente para cada cliente, automáticamente
Tu SaaS deja que cada cliente programe su propia generación de informes. El diseño ingenuo es un scheduler compartido, IDs de cliente en el payload del job y cruzar los dedos para que nadie haga pasar hambre a nadie. El diseño Hoody le da a cada inquilino su propio contenedor y su propio servicio hoody-cron.
Antes del inquilino
Crontab
# no entries yet
CPU0%
Jobs0
POST /users/root/entries
En ejecución
Horario
0 9 * * *digest.sh→ 04:32
*/15 * * * *sync.py
0 2 * * *backup.sh→ 14:02
CPU64%
Jobs3
cron tick in 04:32
Después de rotación
Horario
0 9 * * *digest.sh
*/15 * * * *sync.py
CPU3%
Jobs0
DELETE /entries/:id called
Tres estados del ciclo de vida, una API HTTP. PROVISION añade entradas, los ticks de cron las ejecutan, DELETE suspende. El cron de cada inquilino vive dentro de su propio contenedor — no hay cola compartida, sin riesgo de vecino ruidoso.
use-cases / cron-per-customer / mechanism
Tres llamadas a API impulsan el ciclo de vida completo del inquilino
Cada contenedor de cliente expone la API HTTP de hoody-cron. Aprovisiona con POST, verifica con GET, suspende con DELETE. Sin cola compartida, sin carril de prioridad, sin config de scheduler que volver a desplegar.
POST una entrada gestionada — crea un job de cron con UUID, estado enabled y campo schedule_human legiblePOST /aprovisionar
request
# POST managed entry for acme-corp tenant
POST acme-cron.hoody.com/users/root/entries
Content-Type: application/json
{
"schedule": "0 9 * * *",
"command": "/usr/local/bin/digest.sh",
"comment": "daily digest",
"enabled": true
}response
HTTP/1.1 201 Created
Content-Type: application/json
{
"id": "7d3f2a1b-8c4e-4f9a-b2d5",
"schedule": "0 9 * * *",
"schedule_human": "At 09:00",
"enabled": true,
"user": "root"
}201 Created. Se devuelve el ID de la entrada para futuros PATCH o DELETE. schedule_human confirma que la expresión fue parseada correctamente.
Cada pestaña muestra la llamada API exacta que hace tu plano de control. La API de entradas gestionadas usa UUIDs para poder dirigirse a jobs individuales sin reemplazar el crontab completo. El aislamiento por usuario significa que nada del horario de acme-corp es visible para globex-saas.
use-cases / cron-per-customer / powers
Lo que el modelo de facturación hace obvio
Un servidor de tarifa plana. Sesenta contenedores de inquilino. La matemática es brutalmente simple.
Desglose de facturación de flotacosto por inquilino = servidor dividido entre inquilinos
Tus inquilinos
acme-corpSM
globex-saasMD
initech-incLG
+ 57 más
Servidor de tarifa plana / mes$29Un nodo bare-metal. 60 contenedores. La factura se mantiene plana.
÷inquilinos
Costo por inquilino<$0.49Disminuye a medida que añades más inquilinos
Aislamiento
Cuando scrape.js de initech-inc se cuelga, el digest de las 9 de acme-corp sigue disparando. Crontabs distintos, árboles de procesos distintos, sistemas de archivos distintos.
Los cambios de horario propagan al instante
POST una nueva entrada y el servicio hoody-cron del inquilino la recoge inmediatamente. Sin scheduler central que recargar, sin broadcast que enviar.
Logs por inquilino, un contenedor
Cuando globex-saas pregunta por qué su rollup de las 6pm corrió dos veces, lees el log de un contenedor — no grep en un scheduler compartido a través de nueve máquinas.
use-cases / cron-per-customer / compare
Scheduler compartido vs crontab atado al contenedor
Tres ejes donde el diseño viejo le cobra impuestos a tu equipo y el diseño Hoody simplemente no.
EjeScheduler compartidoAtado al contenedor
Aislamiento
tenant_id en el payload del jobUna fila mala y la cola de cada inquilino se bloquea
/etc/crontab separado por contenedorLos cuelgues son locales. Siempre.
Aprovisionamiento
INSERT INTO scheduled_jobsAcoplamiento de migraciones, lock de esquema
PUT /users/root/crontabUna sola llamada HTTP, reemplazo atómico
Auditoría
grep tenant_id=42 logs/*9 máquinas, 1 archivo de log cada una
GET ctr_8a3f1c/cron/logUn contenedor, un log, una verdad
La columna vieja es lo que cualquier equipo escribe la primera vez que envía scheduling multi-inquilino. La columna nueva es lo que envías cuando la plataforma le da a cada inquilino su propio contenedor por defecto.
use-cases / cron-per-customer / capacity
Capacidad en los extremos
Lo que hace una sola caja bare-metal Hoody cuando cada cliente tiene su propio crontab.
- Inquilinos por caja60
Sesenta contenedores de cliente en un nodo bare-metal, cada uno con su propio servicio hoody-cron corriendo. Sin scheduler compartido que haga cuello de botella.
- Propagación de horario<1s
De la solicitud PUT al primer tick del nuevo horario, observado en una flota de 60 contenedores en un nodo típico de 64 cores.
- Colas entre inquilinos0
Literalmente no hay cola compartida, carril de prioridad o hilo del scheduler por el que dos inquilinos compitan. El aislamiento es el sustrato.
Los números de capacidad son valores típicos observados en un nodo bare-metal de 64 cores / 256GB ejecutando densidad de contenedores Hoody estándar. La capacidad real depende de los presupuestos de CPU y memoria por inquilino y del trabajo que haga cada cron job. El cero en colas entre inquilinos es estructural, no un benchmark.
use-cases / cron-per-customer / punchline
El cron de un cliente no puede hacer pasar hambre al de otro porque no comparten crontab.
Antes / scheduler compartidoDespués / atado al contenedor
Compartidoscheduled_jobs WHERE tenant_id = 42Una fila en una tabla de la que todos leen
Por inquilinoPUT acme-cron.hoody.com/users/root/crontabUna llamada HTTP, un contenedor, un crontab
use-cases / cron-per-customer / replaces
Lo que esto reemplaza
Las arquitecturas que los equipos construyen para compartir un solo crontab entre inquilinos. Hoody pone a cada inquilino en su propio crontab — sin router, sin cola de equidad, sin vecino ruidoso.
- Crontabs multi-inquilino compartidosUna regex mala hace pasar hambre a 400 clientes
- Aislamiento de inquilino a medidaUn scheduler con tenant_id en cada fila
- Postgres pg_cronAtado a la base de datos; una upgrade y se rompe todo el mundo
- Quartz scheduler con filtrosUna JVM y una cola por shard por región
- Colas de inquilino en SidekiqDoce colas, doce archivos de config
- Kubernetes CronJobs por inquilinoUn namespace, un rol RBAC, un YAML, un buscapersonas
use-cases / cron-per-customer / cta
Deja de escribir tenant_id en todas partes. Dale a cada cliente su propio contenedor y deja que cron haga lo que cron lleva haciendo siempre, en aislamiento.
use-cases / cron-per-customer / related
Lee los otros
