Editions ENI Livres | Vidéos | e-Formations
Automatisation et Lean IT
Automatiser tout ce qui peut l’être
L’automatisation intervient à tous les niveaux de la fabrication d’une application, quelle que soit l’industrie ou le marché auquel elle s’adresse. Alors que la qualité d’une fabrication manuelle est liée à la performance des personnes, une fabrication automatisée garantit un niveau de qualité globale constante. Il en va de même pour la capacité à réduire le temps de mise à disposition sur le marché, de la conception au déploiement.
Il ne faut pas confondre industrialisation et automatisation. L’industrialisation consiste à maximiser la productivité par activité, par la segmentation du processus de réalisation, créant ainsi des pôles d’expertise et donc des silos. Il n’est pas rare, et même plutôt courant, que l’automatisation renforce des logiques d’industrialisation en fiabilisant des processus silotés. Si ce n’est évidemment pas une mauvaise pratique dans le contexte de ces organisations, cela ne s’apparente pas à du DevOps car l’automatisation n’a alors pas pour objectifs d’effacer les frontières entre les équipes ni de les rapprocher dans une démarche agile. Si l’automatisation est un outil puissant et nécessaire du DevOps, elle n’est pour autant pas suffisante pour entrer dans cette démarche.
L’automatisation dans le DevOps a pour objectif de fiabiliser et fluidifier l’ensemble du processus de manière globale, plutôt que de façon segmentée. Pour cela, elle s’appuie sur un outillage présent sur chaque activité de réalisation mais complètement orchestré dans des chaînes d’automatisation visant à...
Le rollback
Comme vu avec le déploiement bleu/vert, une stratégie simple de rollback consiste à mettre deux environnements côte à côte sur les deux dernières versions déployées en production et de permuter du plus récent au plus ancien en cas de retour arrière nécessaire.
Mais il n’est pas toujours possible d’appliquer cette stratégie. Différentes possibilités se présentent alors :
-
Exécuter un script qui permet à la plateforme de revenir à l’état -1. Ce type de rollback nécessite que le script de retour arrière soit prévu dans le développement de chaque nouvelle version. Il peut même être maintenu de façon continue en même temps que le développement de l’application. Il s’agira alors de remonter la version précédente à partir de la chaîne de CI/CD. La base de données pourra être réalignée sur la version précédente avec Liquibase. Dans une architecture de services, il faudra s’assurer que tous les services sont bien remontés à partir d’une version antérieure dans un état compatible. La configuration de l’application dans le précédent état devra également être appliquée. Généralement, cela est intégré dans la chaîne de CI/CD.
Le plus gros écueil de ce type de rollback est le risque de revenir dans un état instable, notamment à cause du modèle de données. Il est en effet possible que des transactions aient été exécutées sur la nouvelle version mais ne soient pas réversibles sans une perte de cohérence. Nous revenons alors à la stratégie de gestion...
L’infrastructure as code
Cette formulation englobe l’automatisation du montage des ressources systèmes dans leur ensemble, ce que l’on appelle le provisioning de ressources, ainsi que leur configuration, c’est-à-dire l’installation et le paramétrage nécessaire pour faire fonctionner l’application. Dans la pratique, ces deux processus sont souvent réalisés par les mêmes outils. Il n’est donc pas absurde de considérer qu’il s’agit d’un seul et même processus allant de l’allocation de ressources jusqu’à l’installation complète du produit.
Par ailleurs, on peut pousser le paradigme jusqu’au paramétrage fonctionnel qui peut également être automatisé. L’ensemble permet de monter une application parfaitement fonctionnelle de façon entièrement automatisée.
1. La création de ressources système
a. Le provisioning automatique
On parle de provisioning de ressources lorsque que l’on installe un accès à des ressources locales ou externes sur un système. L’automatisation de ce processus consiste à appliquer des scripts au démarrage du système afin de créer ou lier ces ressources. Ce processus concerne l’ensemble des ressources système automatisables :
-
machines virtuelles ;
-
conteneurs ;
-
processeurs ;
-
mémoire vive ;
-
espace de stockage ;
-
DNS ;
-
ports réseaux ;
-
load balancer.
Les outils d’automatisation proposent deux stratégies de scripting différentes. Dans un mode déclaratif, on décrit les ressources dans un fichier. Elles sont décrites en termes de caractéristiques, attributs, nommage, dimensionnement. Le langage de description peut être JSON, YAML, ou HCL (HashiCorp Configuration...
Les environnements générés "à la demande"
1. Avant DevOps
Comme abordé dans le chapitre Le mur de la confusion, de façon classique, c’est-à-dire sans automatisation, une application en construction nécessite plusieurs lignes d’environnements :
-
une ligne pour des tests unitaires (au niveau du développeur) ;
-
une ligne pour des tests d’intégration (au niveau du testeur) ;
-
une ligne de préproduction, ou d’acceptation (au niveau métier et production) ;
-
une ligne de production.
Ce schéma répond évidemment à une organisation silotée où chaque service nécessite son propre environnement pour un fonctionnement optimal.
Ces environnements ne sont pas tous identiques. Plus on monte vers la production, plus le dimensionnement et l’architecture système se rapprochent des conditions d’utilisation réelles. Évidemment, ce schéma n’est pas du tout DevOps !
Par ailleurs, cette configuration possède un autre défaut de taille, puisqu’elle revient très cher ! En effet, il est nécessaire que ces plateformes restent en place pendant tout le temps du développement de l’application, voire pendant toute sa période de maintenance. Il faut donc en provisionner le coût dès le début, en faisant l’évaluation de son dimensionnement et en dessinant son architecture à l’avance. Nous retombons dans un anti-pattern du Lean, le fameux "big upfront plan", la construction d’un plan prédéfini à l’avance. Cela constitue un frein terrible pour une équipe agile qui doit à la fois s’engager dans une architecture technique en prenant des hypothèses (très) structurantes, et dépenser...
La relation avec le cloud
1. Les principes d’automatisation dans le cloud
Il est a priori possible de déployer n’importe quelle configuration sur un cloud public. Les fournisseurs les plus importants tels qu’Azure, AWS, Google Cloud Platform, permettent de déployer tout type d’architecture applicative. Il peut s’agir d’applications monolithiques structurées autour d’un serveur web et d’une base de données, ou d’architectures orientées services construites autour de micro-services, d’annuaires de services, de base de données NoSQL et spécialisées. Tout est possible.
La relation entre le cloud et le DevOps réside dans l’obligation de ces plateformes de proposer une interface programmable (API) de leurs infrastructures. Comme il n’est pas possible d’accéder physiquement à leurs serveurs, ils ont chacun dû fabriquer une interface entière qui permette à la fois d’assurer au fournisseur de cloud le respect de ses stratégies d’administration et de sécurité, et de laisser la main au client pour qu’il puisse utiliser l’infrastructure quelle que soit l’architecture de ses applications.
Ces API sont accessibles au travers de langages de scripting propres accessibles au travers de CLI (Command Line Interface), telles que PowerShell pour Azure. C’est efficace, mais cela n’offre aucune des fonctionnalités de pull ou de push et de convergence automatique qu’apportent les outils de gestion de configuration. Par ailleurs, ces scripts ne sont absolument pas portables d’un cloud vers l’autre.
Les gestionnaires de configuration tels que Chef, Puppet ou Ansible proposent un accès complet aux API des principaux clouds publics. Il est donc tout à fait possible de reproduire la même stratégie opérationnelle...
