La fin des années 90 marque le début de la démocratisation d'internet :
Le nombre de clients potentiels pour une application en ligne suivra cette courbe.
Les géants du web naîtront sur cette période et feront rapidement face aux requêtes de plusieurs millions d'utilisateurs :
Ils répondront par de nouvelles approches au niveau des traitements (ex : MapReduce (2004)) et du stockage (ex : stockage NoSQL) permettant la scalabilité horizontale :
Cette approche induira :
Ainsi, ces acteurs seront aussi des pionniers en matière de DevOps en répondant avec une nouvelle approche dans la gestion des infrastructures.
Le rôle de Site Reliability Engineer (SRE) posé par Google en 2003 pour assurer un haut niveau de disponibilité des services en collaboration étroite avec les développeurs sera précurseur en matière de DevOps.
La démocratisation d'internet et des applications en réseau se traduira aussi par la possibilité de livrer à moindre frais des évolutions et des correctifs
La publication du manifeste agile en 2001 marquera un tournant dans les méthodes de développement qui exploitera pleinement la possibilité de livrer à moindre frais.
En effet, l'agilité inclura entre autre de :
L'agilité des développements imposera d'améliorer les outils et méthodes de gestion du code source des applications pour faciliter la collaboration et mieux gérer l'historique des évolutions et corrections.
Nous nous souviendrons des heures sombres où l'utilisation d'un gestionnaire de code source n'était pas une pratique répandue :
La gestion de l'historique d'un projet d'étudiant (avant que l'utilisation d'un gestionnaire de code source soit enseignée à l'ENSG)
Nous soulignerons l'évolution des gestionnaires de code source (SCM) avec :
Nous tâcherons de mesurer l'apport du concept de pull-request en terme de traçabilité par rapport aux processus de validation traditionnels. Il motivera l'utilisation des SCM pour d'autres cas d'usage (gestion des infrastructures, gestion de la documentation,...)
Livrer rapidement et régulièrement sera incompatible avec le fait procéder à de longues recettes manuelles pour éviter l'introduction de bug.
L'agilité se déclinera donc en plusieurs méthodes de développement qui inciteront à réduire le risque de régression à l'aide de tests unitaires et fonctionnels.
Nous citerons par exemple la méthode Test-driven development (TDD) formalisée en 2003 par Kent Beck où l'idée est de commencer par écrire les tests unitaires.
Les outils d'intégration continue tels Hudson sorti en 2005 (forké et renommé en Jenkins) gagneront naturellement en popularité. Ils seront utilisés entre autre pour :
www.jenkins.io - Creating a Jenkinsfile
Il sera très rapidement tentant d'exécuter les tests avant d'accepter des demandes de modification du code (pull request).
Des solutions d'intégration continue telles GitHub actions et GitLab-CI seront donc intégrées aux gestionnaires de code source quelques années plus tard.
mborne/node-extract - actions
La virtualisation gagnera en popularité auprès des développeurs grâce à la sortie de logiciel gratuit tels VirtualBox supportant les architectures x86 :
Illustration de l'utilisation de VirtualBox pour construire un environnement de développement
Pour la culture, nous soulignerons qu'il existe différents types d'hyperviseurs :
Les différents type d'hyperviseurs.
A l'usage, nous mémoriserons que l'utilisation de VM permet de faire abstraction sur l'infrastructure :
Virtualisation des applications.
Il sera possible d'héberger plusieurs applications sur une même VM mais nous constaterons que ceci implique un partage des bibliothèques systèmes posant des problèmes de compatibilité de version (python 2/3, PHP 5.6/7.4/8.1,...)
En 2006, Amazon lancera deux services qui contribueront à populariser le concept d'informatique en nuage :
Avec ces services :
Au niveau d'AWS, Jeff BEZOS posera une règle d'architecture importante : Toutes les communications entre les projets doivent passer par l'exposition et l'utilisation d'API en réseau ( c.f. The API Mandate: How a mythical memo from Jeff Bezos changed software forever ). Ceci jouera beaucoup dans :
NB : Cette règle s'applique aux communications entre les services (ex : s'efforcer de construire toutes ses applications uniquement sur la base d'API REST/JSON développées par d'autres est assez limitant...)
Plus largement, le principe de mise à disposition d'une API permettant de contrôler une infrastructure virtualisée se généralisera par la suite sous le nom IaaS (Infrastructure as a Service) :
Les offres cloud se diversifieront assez naturellement avec une prise en charge variables des différentes couches du système par les fournisseurs de service :
Source : www.redhat.com - IaaS, PaaS, SaaS : quelles sont les différences ?
A ce stade, les possibilités d'automatisation des déploiements sont là mais les méthodes héritées de l'exploitation traditionnelle se traduisent généralement par un processus sacralisant un cloisonnement strict des rôles entre les DEV et les OPS.
Il en résulte des situations où l'infrastructure est virtualisée et dotée d'une API permettant d'automatiser la gestion des VM sans que les DEV aient connaissance de cette possibilité.
Nous trouverons par exemple le processus suivant pour déployer une application :
C'est oublier la loi de Murphy!
La mise en production initiale de l'application prendra facilement 1 mois pour diverses raisons :
Il en sera de même pour chaque évolution induisant le moindre changement d'architecture (ajout d'un paramètre, ajout d'un service support,...) ce qui laissera deux options :
Une demande d'exploitation ou une procédure pourra être mal comprise ou mal traduite en opérations sans que l'expertise de chacun soit mise à contribution :
La frontière entre les rôles se traduit humainement par une tendance des équipes DEV et OPS à chercher à limiter leur responsabilité en cas de problème avant de chercher à éviter l'apparition de problèmes voire à corriger rapidement un problème.
Typiquement, avant de chercher une solution :
Voir la BD www.commitstrip.com - Comment savoir si votre entreprise est DevOps? qui résume bien la situation.
Le terme DevOps naîtra d'une prise de conscience sur ces problématiques :
devopssec.fr - L'histoire du DevOps aborde cette genèse plus en détail.
DevOps dépasse à ce titre la simple problématique de l'automatisation des déploiement. DevOps est avant tout un constat :
Dans la partie les principes de DevOps, nous allons tâcher de voir plus précisément comment procéder pour atteindre cette cible.