Impossible de mettre en place une infrastructure immuable sans une architecture par application

F5

En 2013, nous avons découvert le concept de serveur immuable. Comme le terme « immuable » l’indique, un serveur immuable est statique. Sa configuration est fixe et ne peut pas (ou du moins ne devrait pas) être modifiée. Si des changements sont nécessaires, un nouveau serveur doté de la nouvelle configuration remplace le serveur en cours d’exécution. Cette approche est souhaitable, en particulier dans les environnements cloud et sur site fortement automatisés, car elle simplifie la configuration et améliore la fiabilité des systèmes d’automatisation qui pilotent les déploiements.

Ce concept fonctionne bien dans les environnements cloud et conteneurisés, y compris pour les services réseau et applicatifs, mais se prête moins aux architectures d’infrastructure traditionnelles et partagées.

Cela s’explique par le fait que la notion d’infrastructure partagée implique l’exécution de plusieurs services. D’après les données de F5 iHealth, cela peut représenter en moyenne 123 configurations individuelles (serveurs virtuels). Il n’est ni pratique ni recommandé d’essayer d’arrêter et de redéployer 122 de ces serveurs virtuels pour apporter une seule modification à un serveur virtuel.

Mais cela ne rend pas pour autant le concept irréalisable ni indésirable. Pour adopter une infrastructure immuable parallèlement à vos systèmes d’automatisation et d’infrastructure en tant que code (IaC), il est essentiel de passer à une architecture par application.

Pourquoi une infrastructure immuable ?

Pourquoi entreprendre une transformation aussi importante de l’architecture du réseau d’entreprise ? Permettez-moi de me citer moi-même, car je ne vois pas comment mieux le reformuler aujourd’hui :

À cause de l’entropie.

La loi de l’entropie logicielle est décrite par Ivar Jacobson et al. dans « Génie logiciel orienté objet : une approche guidée par les cas d’utilisation » :

Le deuxième principe de la thermodynamique stipule, en principe, que le désordre d’un système fermé ne peut pas diminuer : il peut seulement rester inchangé ou augmenter. Ce désordre se mesure par l’entropie. Ce principe semble également s’appliquer aux systèmes logiciels : à mesure qu’un système est modifié, son désordre, ou entropie, augmente toujours. C’est ce que l’on appelle l’entropie logicielle.

Cette loi s’applique également aux systèmes qui nécessitent des mises à jour du firmware ou du système, sur lesquels sont déployés des correctifs urgents et des patchs, et dont la configuration fait l’objet d’ajustements d’urgence qui, dans un monde parfait, ne devraient être effectués que dans le cadre d’un processus de gestion des changements rigoureusement respecté. Le problème que l’infrastructure immuable (jetable) cherche à résoudre est le suivant : plus on apporte de modifications à un système, plus celui-ci semble s’encombrer de résidus et devenir instable. Désordre. Chaos. Entropie.

Il ne s’agit pas seulement de modifier la configuration pour répondre aux besoins d’une application ou de déployer en urgence des correctifs virtuels afin de remédier à une vulnérabilité récemment découverte. Ce sont de bonnes raisons de modifier la configuration d’un service applicatif, mais ce ne sont pas les seules. Les correctifs urgents, les mises à jour et les dépendances de version peuvent également vous obliger à modifier l’une des 123 configurations exécutées sur une infrastructure partagée.

En adoptant une architecture propre à chaque application, vous éliminez le risque qu’une, deux, voire dix de ces instances perturbent la centaine d’autres qui s’exécutent sur une infrastructure partagée. En attribuant à chaque application son propre chemin de données, vous posez les bases d’une approche fondée sur une infrastructure immuable, qui facilitera la transition vers des pratiques de déploiement automatisées reposant sur l’infrastructure en tant que code.

Cela implique une chaîne de services applicatifs entièrement logicielle, dans laquelle les services applicatifs sont déployés selon une véritable architecture de « microservices applicatifs », à l’image du déploiement des microservices au sein de conteneurs.

Julian Dunn de Chef l’a bien résumé dans son blog : Infrastructure immuable : réaliste ou non ?

Une infrastructure immuable est généralement définie comme une pile que l’on construit une seule fois (qu’il s’agisse d’une image de machine virtuelle, d’une image de conteneur ou d’autre chose), dont on exécute une ou plusieurs instances et que l’on ne modifie plus jamais. Le modèle de déploiement consiste à arrêter l’instance ou le conteneur et à reprendre depuis la première étape : créer une nouvelle image et supprimer les anciennes instances.

Ainsi, si nous appliquons ce principe aux services applicatifs les plus étroitement liés (affines) à une application donnée, nous obtenons une architecture réseau à deux niveaux, composée de services partagés communs et essentiels — comme la protection du réseau contre les attaques DDoS et le contrôle des accès au moyen de pare-feu traditionnels basés sur les ports — qui alimentent une « pile » propre à chaque application, considérée comme immuable et déployée/gérée selon les principes de l’infrastructure en tant que code.

Mais il est réellement impossible de mettre en place une infrastructure immuable sans disposer d’une infrastructure propre à chaque application, car il faut d’abord découpler les services applicatifs concernés de leurs plateformes partagées. Si vous pouvez utiliser la même plateforme, simplement sous forme logicielle, ce processus devient encore plus simple, car vous disposez déjà d’une grande partie des connaissances et des outils nécessaires pour avancer à toute vitesse vers un modèle immuable propre à chaque application.

Même si vous n’envisagez pas une véritable infrastructure immuable, la possibilité d’y recourir lorsque cela s’avère le plus pertinent (nouvelle version de l’infrastructure, correctifs urgents, correctifs, etc.) vous facilitera la vie, ainsi que celle des responsables DevOps de l’application prise en charge par l’infrastructure.

À propos de l’auteur

F5

Autres articles de F5