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
TipoDesbloqueadoEtapaFlotaDificultadAvanzadoTrabajoSaaS multi-inquilinoParaEquipos de desarrolloParaDesarrolladores backendServiciosCronServiciosContainersPor qué HoodyEconomía de contenedoresPor qué HoodyHTTP nativoIndustriaSaaS
TipoDesbloqueadoEtapaFlotaDificultadAvanzadoTrabajoSaaS multi-inquilinoParaEquipos de desarrolloParaDesarrolladores backendServiciosCronServiciosContainersPor qué HoodyEconomía de contenedoresPor qué HoodyHTTP nativoIndustriaSaaS
use-cases / byo-cron-per-tenant / hero
BYO cron / programaciones por tenant
Deja que tus clientes traigan su propia programación cron.
Tus clientes escriben la expresión cron. Tú haces POST al crontab de su contenedor. No hay cola compartida que repartir, ni intervalo mínimo que imponer, ni ticket de soporte por «por qué mi job no se ejecutó el lunes pico».
your-saas.com — automatizaciones
https://app.your-saas.com/settings/automationsacme-corp
Tus tareas programadas
{count, plural, =1 {# programación activa} other {# programaciones activas}'}Sync Salesforce contactssiguiente: every 15 min
*/15 * * * *Email weekly KPI digestsiguiente: Mon 08:00
0 8 * * 1Archive closed ticketssiguiente: 1st of month, 02:00
0 2 1 * *Añadir nueva programación
próximas ejecuciones: Mon-Fri 09:00
Una página de ajustes real orientada al cliente — programaciones editadas por el tenant, parseadas por su contenedor.
use-cases / byo-cron-per-tenant / mechanism
El cliente escribe en tu UI. Tú haces POST a su contenedor.
Tu página de ajustes pinta un campo de input. Su contenedor de tenant expone una API de Cron. El submit reenvía un POST. Sin scheduler global, sin lógica de filtrado por tenant, sin tope de «máximo 100 jobs entre todos los clientes».
your-backend → tenant-container
POST /users/root/entries// el submit del formulario reenvía la expresión del cliente sin cambios
POST https://acme-cron.hoody.com/users/root/entries
Content-Type: application/json
{
"schedule": "0 9 * * 1-5",
"command": "/jobs/sync_crm.sh",
"comment": "Sync Salesforce contacts",
"enabled": true
}tenant-container → your-backend
201 CreatedHTTP/1.1 201 Created
Content-Type: application/json
{
"id": "sch_8a3f1c",
"schedule": "0 9 * * 1-5",
"next_run": "2026-05-04T09:00:00Z",
"enabled": true
}
// la programación está ahora en el crontab de este tenant y en ningún otro sitioEl servicio Hoody Cron corre dentro de cada contenedor de tenant con entradas gestionadas y aislamiento por usuario. La programación vive donde corre el trabajo.
use-cases / byo-cron-per-tenant / powers
Lo que el cron BYO te da y un scheduler compartido no.
Cuando la programación vive junto al trabajo, las reglas de la programación multi-tenant cambian. Las restricciones son locales. El radio de impacto es local. Las funcionalidades son locales.
sin cola compartida
Sin impuesto de fair-queueing
No hay un thread pool global por el que pelear. Tu tenant más exigente corre cada minuto y nunca mata de hambre a los tranquilos — no están en el mismo crontab.
self-service
Los clientes se autoservicio, tú no validas
Dejas de ser el portero de «¿está */1 * * * * permitido para tu tier?». Su contenedor, su cron, su factura de CPU. Tu inbox de soporte se vacía.
ligado al contenedor
La programación viaja con el tenant
Haz un snapshot del contenedor del tenant y haces snapshot del crontab. Vuelve atrás, restaura, bifurca — las programaciones van con él. Sin estado externo de scheduler que sincronizar.
use-cases / byo-cron-per-tenant / compare
Scheduler multi-tenant compartido vs cron ligado al contenedor.
La diferencia se nota en tres sitios: la experiencia del cliente, tu carga de soporte y la superficie de ingeniería.
ejescheduler compartidocron BYO en contenedor
Lo que el cliente puede elegir
mínimo de 5 minutos, solo días laborables, sin ejecuciones concurrenteslimitado por tier, reglas de fair-share, aplazamientos en hora pico
Cualquier expresión cron de 5 campos que su contenedor pueda manejar*/1 * * * * si lo quieren; su CPU lo paga
Dónde ocurre la validación
Tu código, antes de persistir, contra un modelo de cola globalregex + check de capacidad + check de tier + check de solape
El daemon cron del contenedor parsea la expresiónsolo sintaxis; la capacidad es la de un contenedor, no la de la flota
Radio de impacto del fallo
Un job lento de un tenant para la cola para todosincidentes de noisy-neighbor, alertas por profundidad de cola
El cron de un contenedor retrasa a un tenantaislamiento a nivel de kernel; el resto de la flota ni se entera
La versión con scheduler compartido de esta funcionalidad es un mar de matices. La versión BYO es una caja de input de cinco campos.
use-cases / byo-cron-per-tenant / support
Lo que desaparece cuando el cron es por tenant.
Tres números que cambian el día que dejas de tener una cola global. Cada uno mapea a una funcionalidad que ya no tienes que escribir ni operar.
- reglas de validación que mantener0
Sin intervalo mínimo limitado por tier, sin máximo de jobs por tenant, sin ruedas de fair-share. El contenedor es el límite.
- POST por programación creada1×
El cliente escribe, tú reenvías, el contenedor parsea. El submit de la página de ajustes es una sola llamada REST, no una orquestación.
- campos que el cliente controla5
minuto · hora · día-del-mes · mes · día-de-la-semana. Más macros (@hourly, @daily). POSIX estándar, no tu DSL.
Las cifras reflejan el modelo BYO ligado al contenedor — las entradas cron reales escalan con la CPU de cada contenedor y el plan del cliente.
use-cases / byo-cron-per-tenant / punchline
La expresión cron del cliente es del cliente, no algo que tú tengas que validar contra una cola global.
scheduler compartidocron BYO por tenant
antesif (tier !== 'enterprise' && interval < 5min) reject()impuesto de validación: cada cliente pagaba por el peor cliente
despuésPOST /users/root/entries → 201 Createdla programación vive en su contenedor; su CPU, sus reglas
use-cases / byo-cron-per-tenant / replaces
Lo que esto reemplaza.
Las piezas de infraestructura que un cron BYO ligado al contenedor jubila silenciosamente.
- schedulers multi-tenant compartidossin cola global que repartir
- Quartz con filtrado por tenantsin columna tenant_id en cada fila de job
- UIs de cron-as-config a medidalos clientes escriben, el contenedor parsea
- Airflow gestionado por proveedorsin servicio de DAGs para una expresión de 5 campos
- Sidekiq compartido con throttlingsin rate limiter global entre tenants
- BullMQ con colas por tenantsin Redis que cuidar por cada cliente
use-cases / byo-cron-per-tenant / cta
Deja de ser el portero de la programación de otra persona. Dales el campo cron, dale el trabajo a su contenedor.
use-cases / byo-cron-per-tenant / related
Lee los otros
