Infrastructure as Code : automatiser vs orchestrer. Quels bénéfices, concrètement ?
16 juin 2021
3 mn de lecture
Lors de nos missions de conseil ou nos séminaires, nous avons souvent noté qu’une confusion existait entre automatiser et orchestrer lorsque l’on parle Infrastructure as Code. Attention, nous précisons bien ici que nous parlons dans le contexte de l’Infrastructure as Code et non dans le domaine des containers et de l’orchestration des containers que nous aborderons d’ailleurs dans un prochain article ! De plus, plusieurs clients pensaient également que l’automatisation n’était pas rentable. Nous allons essayer dans cet article d’expliquer ces points.
Le principe de l’automatisation est de mettre en œuvre une abstraction entre le provisioning des ressources liées à un service et le lieu de provisioning afin de ne faire l’effort qu’une seule fois, quelle que soit l’infrastructure sous-jacente (on-premises, Cloud…) Nous aimons alors parler d’infrastructure reproductible. En effet, le code écrit et exécuté permet de garantir la reproductibilité de l’installation et de la configuration afin d’être sûr et certain de disposer exactement des mêmes ressources provisionnées. Or, nous considérons qu’il s’agit d’un préalable incontournable pour l’orchestration des ressources…
Nous répondons déjà à un point : l’orchestration ne peut être réalisée efficacement que si et seulement si l’automatisation est effective.
L’objectif de l’orchestration est d’orchestrer les différentes ressources automatisables et de les coordonner dynamiquement. Cela représente donc un panel plus large que l’automatisation. Pour rester sur l’image de l’orchestre en musique : l’automatisation représente chaque partition liée aux instruments individuels (la trompette) ou groupés (les premiers violons). L’orchestration, via le chef d’orchestre, va faire en sorte que l’ensemble de ces partitions soit initié dans le bon ordre, dans le bon tempo afin de garantir l’harmonie entre les instruments. Prenons un exemple plus technique : des scripts d’automatisation ont été écrits pour permettre l’installation et la configuration de plusieurs serveurs frontaux web, des serveurs d’applications middleware et de deux serveurs de base de données répliqués. L’orchestrateur va alors orchestrer ces ressources en s’assurant que les serveurs web soient installés, configurés et prêts à recevoir les connexions utilisateurs avant de les ajouter par API au load balancer, au CDN, aux règles de micro-segmentation réseau, au DNS externe, etc. L’objectif est alors de tendre vers le concept d’infrastructure immuable où la mise à jour d’une pile applicative se fait en reprovisionnant complètement l’infrastructure avec les nouvelles versions, en basculant les connexions utilisateurs sur cette nouvelle version, puis en supprimant l’ancienne. Ce type de mises à jour, blue-green, permet de limiter la durée de vie des ressources et ainsi augmenter leur stabilité, car comme l’affirment les aficionados de l’Infrastructure As Code, un serveur ne devrait jamais avoir une durée de vie supérieure à la semaine pour garantir sa stabilité ! C’est ici qu’apparait la fameuse notion de serveurs Phénix, les serveurs qui renaissent de leurs cendres ! Comme quoi les informaticiens peuvent être poètes parfois…
Mais quel effort à faire pour automatiser et orchestrer ? L’effort engendré est-il rentable ? La réponse aujourd’hui est OUI, OUI et OUI !
OUI parce que l’effort est de plus en plus limité grâce à des outils comme Ansible ou Terraform pour lesquels de nombreuses ressources et patterns sont disponibles notamment du fait de communautés très actives. Par ailleurs, plus on automatise, plus on réutilise donc plus on accélère l’automatisation du prochain service ou pile applicative à mettre à disposition.
OUI parce que c’est rentable. Je me rappellerai toujours d’un client nous disant « je ne vois pas l’intérêt d’automatiser, car je ne mets en production que 10 serveurs par an ». Nous lui avons demandé combien d’installations étaient réalisées pour atteindre ce chiffre de 10 serveurs par an en tenant compte des différents environnements de staging (test, qualification, préproduction et production) … et la réponse a été 400 !! Automatiser 400 installations, oui c’est rentable !
OUI parce qu’automatiser signifie infrastructure reproductible. Donc pour reprendre l’exemple précédent, lorsque cela fonctionne en préproduction, cela fonctionnera en production ! Cela garantit donc la qualité de mise en production. De plus, automatiser signifie indépendance vis-à-vis des couches basses de l’infrastructure donc c’est également une, voire LA, garantie de réversibilité pour passer d’un cloud à un autre dans le contexte VM (nous verrons dans un prochain article que les containers apportent d’autres bénéfices à ce niveau)
Tous les clients que nous avons accompagnés dans l’industrialisation de leur processus d’installation et configuration par de l’automatisation et de l’orchestration ont vu la qualité de leurs mises en production s’accroitre drastiquement. Cela a permis également de libérer du temps progressivement aux équipes opérations tout en garantissant la réversibilité et la capacité à migrer vers un cloud provider.
Auteurs
Vincent Branger – ILKI
Gaël Corlay – ILKI