L’architecture cloud précoce est souvent surinvestie aux mauvais endroits. Les équipes passent trop de temps sur des abstractions futures et pas assez sur des releases répétables, des rollbacks clairs et une vraie visibilité runtime.
La maturité de production commence lorsque le déploiement cesse d’être un acte de confiance pour devenir une routine contrôlée.
Le problème
Les petites équipes produit livrent souvent web, workers et jobs d’intégration via un même chemin de release fragile. En cas d’échec, personne ne peut dire rapidement si le problème vient de l’application, du runtime worker, des migrations ou de l’environnement.
Ce qui casse en pratique
- Les services web et workers sont déployés ensemble alors qu’ils échouent pour des raisons différentes.
- Des différences d’environnement font qu’un build “réussi” se comporte autrement après release.
- Les rollbacks existent en théorie mais pas pour les migrations ou les jobs déjà en vol.
- Les équipes surveillent surtout l’HTTP et oublient le backlog de queue ou les démarrages workers ratés.
Décisions de conception
- Traiter web et workers comme des unités de release séparées afin que les workloads async n’héritent pas d’hypothèses web-only.
- Favoriser des artefacts reproductibles et une promotion simple entre environnements.
- Mettre des checks post-déploiement proches du parcours métier, pas seulement de la santé infra.
- Garder les décisions de rollback explicites, surtout lorsque migrations et jobs asynchrones survivent à la release.
Arbitrages
- Des unités de déploiement séparées apportent plus de contrôle mais plus de surface pipeline.
- Des garde-fous de release plus conservateurs ralentissent légèrement la cadence.
- Une topologie cloud simple sacrifie parfois de la flexibilité théorique, mais réduit l’erreur opérateur pour de petites équipes.
Patterns de production
- Builds conteneurisés pour web et workers.
- CI/CD qui vérifie tests, build, déploiement puis santé runtime.
- Dashboards de déploiement incluant backlog queue, disponibilité workers et compteurs d’échec récents.
- Checklists de rollback explicites pour migrations, jobs async et état d’intégration externe.
Ce que je ferais différemment
- Ajouter plus tôt une validation type canary pour les releases à forte composante worker.
- Suivre le risque de release par sous-système afin qu’un changement d’intégration ne soit pas traité comme un simple ajustement UI.
- Rendre les vérifications de sécurité des migrations plus visibles dans le pipeline avant de les apprendre pendant un rollback.