Vous ne pouvez pas créer une infrastructure immuable sans une architecture par application

En 2013, nous avons été initiés au concept de serveur immuable . Un serveur immuable est, comme le terme immuable le suggère, statique. Sa configuration est fixe et ne peut pas (ou du moins ne doit pas) être modifiée. Si des modifications sont nécessaires, un nouveau serveur avec la nouvelle configuration remplace le serveur en cours d'exécution. La raison pour laquelle cela est souhaitable, en particulier avec les environnements cloud et sur site hautement automatisés, est que cela simplifie la configuration et améliore la fiabilité des systèmes d'automatisation pilotant les déploiements.

Ce concept fonctionne bien dans les environnements cloud et conteneurisés, même pour les services réseau et applicatifs, mais pas aussi bien dans les architectures d’infrastructure partagée traditionnelles.

C’est parce que la définition d’une infrastructure partagée implique plusieurs services opérationnels. D'après les données F5 iHealth , « multiple » peut signifier en moyenne 123 configurations individuelles (serveurs virtuels). Il n’est ni pratique ni recommandé de tenter 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 le concept impraticable ni indésirable. La clé pour adopter une infrastructure immuable avec vos systèmes d’automatisation et d’infrastructure en tant que code (IaC) est de passer à une architecture par application.

Pourquoi une infrastructure immuable ?

Pourquoi entreprendre un changement aussi important dans l’architecture du réseau d’entreprise ? Permettez-moi de me citer , car je ne vois pas de meilleure façon de reformuler mes propos aujourd'hui :

Parce que l'entropie.

La loi de l'entropie logicielle est décrite par Ivar Jacobson et al. dans « Object-Oriented Software Engineering : Une approche axée sur les cas d'utilisation :

La deuxième loi de la thermodynamique stipule, en principe, que le désordre d'un système fermé ne peut pas être réduit, il ne peut que rester inchangé ou augmenter. Une mesure de ce désordre est l’entropie . Cette loi semble également plausible pour les systèmes logiciels ; lorsqu'un système est modifié, son désordre, ou entropie, augmente toujours. C’est ce qu’on appelle l’entropie logicielle.

Cette loi s'applique également aux systèmes pour lesquels des mises à jour du micrologiciel ou au niveau du système doivent être appliquées. Pour lesquels des correctifs et des correctifs sont déployés. Pour quelles modifications d'urgence une configuration devrait-elle, dans un monde parfait, être modifiée uniquement via un processus de gestion des changements strictement suivi. Le problème que l’infrastructure immuable (jetable) tente de résoudre est que plus vous introduisez de changements dans un système, plus il semble devenir instable et instable. Désordre. Chaos. Entropie.

Il ne s’agit pas simplement de modifier la configuration du service d’une application ou de déployer des correctifs virtuels d’urgence pour une vulnérabilité récemment découverte. Ce sont de bonnes raisons de modifier la configuration d’un service d’application, mais ce ne sont pas les seules. Les correctifs, les correctifs et les dépendances de version sont également de bonnes raisons pour lesquelles vous pourriez avoir besoin de modifier l’une des 123 configurations exécutées sur une infrastructure partagée.

En passant à une architecture par application, vous éliminez le risque de perturbation d'une ou deux, voire de dix de ces instances par rapport aux centaines d'autres exécutées sur une infrastructure partagée. En donnant à chaque application son propre chemin de données, on ouvre la voie à une approche d’infrastructure immuable qui permettra de mieux soutenir l’évolution vers une pratique de déploiement automatisée basée sur l’infrastructure en tant que code.

Il s’agit d’un pipeline de services d’application entièrement basé sur un logiciel, avec des services d’application déployés dans ce qui est en grande partie une architecture de « micro-application-service », semblable à la façon dont les microservices sont déployés dans des conteneurs. 

Julian Dunn de Chef l'a bien exprimé dans son blog - Immutable Infrastructure : Pratique ou pas ?

Une infrastructure immuable est généralement définie comme une pile que vous créez une fois (qu'il s'agisse d'une image de machine virtuelle, d'une image de conteneur ou autre chose), que vous exécutez une ou plusieurs instances et que vous ne modifiez plus jamais. Le modèle de déploiement consiste à mettre fin à l'instance/au conteneur et à recommencer à partir de la première étape : créer une nouvelle image et supprimer les anciennes instances.

Ainsi, si nous appliquons cela aux services d’application les plus étroitement couplés (affine) à une application donnée, nous obtenons une architecture réseau à deux niveaux comprenant des services communs partagés de base (comme les attaques DDoS réseau et l’accès via les pare-feu traditionnels basés sur les ports) qui alimentent une « pile » par application qui est traitée comme immuable et déployée/gérée à l’aide de concepts d’infrastructure en tant que code.

Mais vous ne pouvez pas vraiment faire quelque chose d'immuable sans une infrastructure par application, car vous devez d'abord découpler les services d'application concernés de leurs plateformes partagées. Si vous pouvez utiliser la même plateforme, simplement sous forme de logiciel, ce processus devient encore plus facile, car vous disposez déjà d'une grande partie des connaissances et des outils dont vous avez besoin pour avancer à toute vitesse vers un modèle immuable par application.

Même si vous n’envisagez pas une véritable infrastructure immuable, la possibilité de l’exploiter lorsque cela est le plus judicieux (nouvelle version de l’infrastructure, correctifs, patchs, etc.) facilitera la vie à la fois pour vous et pour les propriétaires DevOps de l’application prise en charge par l’infrastructure.