Mettre en place une architecture élastique

Identifiants

Catégories

Indications

Description

Dans la plupart des cas la charge subie par une application n’est pas constante au cours du temps. Par exemple il peut n’y avoir que peu, voire pas du tout d’utilisateurs connectés la nuit. Dans ce cas, il n’est pas nécessaire d’utiliser des infrastructures techniques aussi importantes aux heures creuses qu’aux heures de plus forte demande.

Grâce à la mutualisation des déploiements (voir la bonne pratique #89 « Utiliser des serveurs virtualisés »), en particulier sur le cloud, il est possible de modifier dynamiquement et automatiquement la taille de l’infrastructure en fonction de la charge. Cette modification peut obéir à une programmation horaire (par exemple éteindre la nuit les applications utilisées uniquement aux heures de bureau) ou se faire en réaction au nombre de requêtes : si la charge augmente on ajoute de nouvelles machines virtuelles, de nouvelles instances de l’application (conteneurs, processus ou fonctions serverless, …), que l’on décommissionne quand elle baisse.

Des outils comme Docker permettent de créer des images de vos applications qui peuvent être facilement déployées ou décommissionnées par des outils d’orchestration comme Kubernetes. Les fournisseurs de Cloud proposent en général des services permettant de tirer profit de ces outils.

Les environnements de tests et d’expérimentation en particulier peuvent être éteints la nuit et les jours non ouvrés très facilement.

Mettre en place une architecture élastique permet de plus de faire des économies, puisque moins de ressources serveurs sont utilisées, et que celles-ci sont facturées.

Une architecture élastique a un coût de mise en place important en termes de charge de travail et de complexité accrue de la solution. Si votre application a peu de charge ou que celle-ci varie peu, il n’est pas indispensable de la mettre en place.

Principe de validation