Scale to Zero avec Laravel Cloud : réduire ses coûts d'infrastructure pour les charges intermittentes

Le 26 mai dernier, Laravel Cloud a lancé ses Managed Queues, une fonctionnalité qui promet de simplifier radicalement la gestion des workers de file d'attente. L'annonce est séduisante : des workers qui s'allument quand les jobs arrivent, qui s'éteignent quand il n'y a plus rien à traiter, et un dashboard intégré pour les échecs. Ni configuration Supervisor, ni tuning Redis, ni commande horizon:terminate dans vos scripts de déploiement.

Pour une PME dont la charge de travail est par nature intermittente — traitements de nuit, imports batch hebdomadaires, notifications événementielles — cette promesse mérite qu'on s'y arrête sérieusement.

Ce que sont vraiment les Managed Queues

Sous le capot, les Managed Queues reposent sur AWS SQS. Laravel Cloud provisionne la file, configure les accès, et lit la profondeur de la queue directement depuis SQS, sans passer par votre application. Côté dépendance, il suffit d'ajouter aws/aws-sdk-php à votre composer.json.

Chaque worker tourne dans un conteneur isolé avec de la mémoire garantie. Vous choisissez un tier entre 256 MiB et 8 GiB, le CPU s'adapte en conséquence. Le scaling s'appuie sur deux signaux combinés : la profondeur de la queue et l'âge des messages. Ce second critère est important — il évite qu'un job coincé attende indéfiniment faute de worker disponible.

Le scale to zero est la fonctionnalité clé pour les PME : quand aucun job n'est en attente, vous ne payez rien pour les workers. C'est un changement de paradigme par rapport à Horizon, qui nécessite au minimum un processus PHP tournant en permanence.

L'argument économique pour les charges intermittentes

Prenons un cas concret : une application SaaS qui envoie des rapports consolidés chaque nuit, traite des imports CSV à la demande, et envoie des notifications push en réponse à des événements utilisateurs sporadiques.

Avec Laravel Horizon classique, vous maintenez :

• Un serveur (ou un pod Kubernetes) actif 24h/24 pour le processus Horizon
• Une instance Redis dédiée pour le stockage des jobs et les métriques
• Une supervision (Supervisor, systemd) pour redémarrer le processus en cas de crash
• Un pipeline de déploiement qui orchestre le redémarrage propre avec horizon:terminate

Cette infrastructure tourne à plein régime même à 3h du matin quand aucun job ne transite. Pour une PME, c'est du coût fixe difficile à justifier.

Avec les Managed Queues de Laravel Cloud, vous ne payez que pendant les pics de traitement. La nuit, entre deux rafales de jobs, les workers sont à zéro. L'économie peut être substantielle si votre taux d'utilisation réel est faible — ce qui est précisément le cas pour les charges intermittentes.

Ce que vous abandonnez en migrant depuis Horizon

L'article original de Hafiz sur dev.to est honnête sur les compromis, et il faut les connaître avant de migrer.

La limite des 15 minutes sur les délais. SQS impose un délai maximum de 15 minutes sur la visibilité des messages. Si votre application utilise ->delay(now()->addHours(2)) pour planifier des jobs à plusieurs heures d'intervalle, les Managed Queues ne peuvent pas reproduire ce comportement nativement. Ce point peut silencieusement casser des fonctionnalités existantes si vous ne l'anticipez pas.

La disparition des fonctionnalités Redis spécifiques à Horizon. Horizon s'appuie sur Redis pour des mécanismes avancés : rate limiting par job, tags de jobs, métriques temps réel détaillées, et la possibilité de rejouer des jobs échoués avec leur payload complet. Ces fonctionnalités n'ont pas d'équivalent direct dans le monde SQS. Le dashboard Managed Queues couvre les cas basiques (jobs échoués, profondeur de queue) mais sans la profondeur analytique de Horizon.

Le couplage à l'écosystème Laravel Cloud. En adoptant les Managed Queues, vous déléguez la gestion de l'infrastructure à une plateforme spécifique. C'est un avantage en termes de simplicité opérationnelle, mais c'est aussi une dépendance supplémentaire à évaluer selon votre stratégie d'hébergement.

Quand choisir les Managed Queues plutôt que Horizon ?

Les Managed Queues sont particulièrement adaptées si :

• Vos jobs sont courts et indépendants : traitements d'images, envois d'emails, webhooks entrants. Des tâches qui s'exécutent en quelques secondes et ne nécessitent pas de coordination complexe.
• Votre charge est clairement intermittente : des pics prévisibles (import du lundi matin, rapport du vendredi soir) entourés de longues périodes creuses.
• Vous n'utilisez pas les délais longs : si vos jobs sont déclenchés quasi-immédiatement ou avec des délais inférieurs à 15 minutes, la contrainte SQS ne vous touche pas.
• Vous cherchez à réduire la charge opérationnelle : pas d'équipe DevOps dédiée, volonté de déléguer la supervision et le scaling à la plateforme.

En revanche, gardez Horizon si vous avez des jobs longue durée avec des délais arbitraires, si vous exploitez les métriques avancées pour du capacity planning, ou si votre architecture multi-cloud rend la dépendance à AWS SQS problématique.

Conclusion

Les Managed Queues de Laravel Cloud répondent à un vrai problème : le coût et la complexité de maintenir une infrastructure de queue active en permanence pour des charges de travail qui ne le justifient pas. Pour une PME avec des pics de traitement bien définis et des périodes creuses longues, le scale to zero peut représenter une économie réelle et une simplification opérationnelle bienvenue.

Mais la migration depuis Horizon n'est pas transparente. La limite des 15 minutes sur les délais et l'absence des fonctionnalités Redis avancées sont des contraintes concrètes à auditer dans votre codebase avant toute décision. Listez vos usages de ->delay(), vérifiez vos rate limiters de jobs, et évaluez si les métriques simplifiées du dashboard Cloud suffisent à vos besoins de supervision.

La bonne question n'est pas « Horizon ou Managed Queues ? » mais plutôt : quel est mon profil de charge réel, et quel est mon appétit pour la complexité opérationnelle ? La réponse à cette question détermine naturellement le bon outil.

Source originale : Laravel Cloud Managed Queues vs Horizon: What You Give Up and What You Get par Hafiz sur dev.to.