L’évolution vers le (Dev)NoOps

Conteneurs, Serverless, Architectures Micro-Service

D’autres innovations telles que les conteneurs, Serverless ou encore architecture orientée micro-service, ont également apporté de nouvelles façons d’appréhender les applicatifs, que l’on désignerait comme Cloud Native, si un certain nombre de caractéristiques sont appliquées, comme le résume très bien les TWELVE FACTORS, que nous aborderons ici.

DevNoOps ou DevSecOps

L’ensemble de ces innovations introduisent de nouveaux concepts ambitieux comme le DevNoOps ou le DevSecOps, qui annonce la mort certaine à court terme de métiers tels que les administrateurs systèmes, par exemple, dans le sens où les applications seront « intelligentes » grâce aux technologies et concepts que nous allons aborder ici.

Le but n’étant pas de détailler ici toutes les technologies existantes d’un point de vue technique, mais de faire un tour d’horizon sur les tendances actuelles et futures et aussi pour s’ouvrir l’esprit à nos métiers de demain (transformation ?) et la façon dans les applications seront conçues…

Nous allons aborder un certain nombre de concepts et technologies, comme le concept DevOps, l’intégration continue, … afin d’obtenir l’horizon le plus large possible et de se rendre compte à quel point tout bouge rapidement et d’intégrer tout cela dans vos futures réflexions.

1 – Intégrer les douze facteurs d’une application Cloud Native

En premier lieu, si nous désirons qu’une application soit Cloud Native, il convient de respecter un certain nombre de critères, selon TWELVE FACTORS, qui reprend l’ensemble des concepts et technologies abordées ici:

• Utilisent un format déclaratif pour l’automatisation des installations
• Ont un contrat clair avec l’OS sous-jacent et qui offrent une portabilité maximale pour l’exécution sur différents environnements
• Sont adaptés à un déploiement sur des plateformes cloud
• Minimisent la divergence entre développement et production et permettent un déploiement continu pour un maximum d’agilité
• Peuvent monter en charge sans changement majeur d’outillage, d’architecture ou de pratique de développement

2 – L’approche DevOps

Dans le cadre de la mise en production d’une application en passant par la conception, le test, … (la chaîne) il existe plusieurs approches, classique (Waterfall par exemple) et DevOps (Agile, …) qui incluent les OPS (Ingénieurs systèmes, architectes, …) et les DEV (développeurs, Architectes logiciels, …).

Dans une approche classique, les équipes sont le plus souvent compartimentées, et ne pensent qu’à leurs tâches, en bref, les DEV produisent du code, les évolutions fonctionnelles, … et les OPS mettent à disposition les infrastructures sans tenir compte des évolutions logicielles mais plutôt en se concentrant sur le SLA du service ainsi que la performance associée.

Le concept DevNoOps, les nouvelles technologies permettront de s’affranchir des OPS dans le sens où le code de l’infrastructure ne deviendra plus qu’une variable dans la chaîne. Nous y reviendrons plus tard.

Comprendre la différence entre la livraison, le déploiement et l’intégration continue CI/CD

Les acronymes CI et CD sont couramment utilisés lorsque l’on parle de DevOps:

• CI

Intégration Continue, une pratique qui vise à faciliter la préparation d’une version

• CD

une Livraison Continue ou un Déploiement Continu, et bien que ces deux pratiques aient beaucoup en commun, elles ont également une différence significative que nous allons détailler

Intégration Continue

Les développeurs pratiquant une intégration continue fusionnent leurs modifications dans la branche principale aussi souvent que possible. Les modifications du développeur sont validées en créant une génération et en exécutant des tests automatisés par rapport à la génération. L’intégration continue met l’accent sur l’automatisation des tests pour vérifier que l’application n’est pas interrompue chaque fois que de nouveaux commits sont intégrés dans la branche principale.

Livraison continue

La livraison continue est une extension de l’intégration continue pour permettre de générer rapidement de nouveaux changements. Cela signifie qu’en plus d’avoir automatisé les tests, vous avez également automatisé votre processus de publication et vous pouvez déployer votre application à tout moment en cliquant sur un bouton.

Déploiement continu

Le déploiement continu va plus loin que la livraison continue. Grâce à cette pratique, chaque modification apportée à toutes les étapes de votre pipeline de production est transmise aux utilisateurs. Il n’y a pas d’intervention humaine, et seul un test échoué empêchera le déploiement d’un nouveau changement dans la production.

Quelques outils appartenant à une chaîne DevOps:

• Code & Commit: Git, Github, Visual Studio, Eclipse, …
• Build & Config: Docker, Chef, SaltStack, Puppet, Ansible, …
• Scan & Test: Sonar, BlazeMeter, Gerrit, …
• Release: uDeploy, Serena, CollbaNet, XL Release, …
• Deploy: Kubernetes, Azure, VMware, OpenStack, …

Un schéma est toujours utile pour illustrer les dires précédents…

Selon un sondage effectué en 2016 par Puppet auprès de 4 600 professionnels de l’informatique, les services informatiques disposant d’un flux de travail DevOps ont déployé un applicatif 200 fois plus fréquemment. De plus, ils ont récupéré 24 fois plus vite et ont eu trois fois moins de taux de défaillance. Simultanément, ces entreprises consacrent 50% de temps en moins aux problèmes de sécurité et 22% de temps en moins au travail non planifié.

3 – Les Conteneurs ou architecture orientée micro-service

En exploitant les conteneurs dans le cadre de votre stratégie, vous pouvez gagner en efficacité, en souplesse et améliorer la sécurité des applications.

Les conteneurs permettent de facilement packager, déployer et exécuter n’importe quelle application en tant que conteneur léger, portable et autonome, pouvant s’exécuter pratiquement n’importe où, en isolant le code dans un seul conteneur, ce qui facilite sa modification et sa mise à jour.

Docker, par exemple, est construit sur LXC (LinuX Container). Comme avec toute technologie de conteneur, il dispose de son propre système de fichiers, de son stockage, de son processeur, de sa mémoire vive, etc… La principale différence entre les conteneurs et les machines virtuelles réside dans le fait que l’hyperviseur extrait un périphérique entier, mais que les conteneurs ne font que présenter le noyau (kernel) du système d’exploitation.

Les applications actuelles dites « classiques » ou legacy s’exécutent sur un système d’exploitation. Le système d’exploitation peut être exécuté sur un hôte Bare Metal ou sur une machine virtuelle. Les conteneurs fournissent la virtualisation du système d’exploitation sur les hôtes Windows et Linux. Plusieurs conteneurs indépendants peuvent être exécutés au sein d’une même instance Linux ou Windows, évitant la surcharge liée au démarrage et à la maintenance des machines virtuelles.

Les conteneurs vous permettent de conditionner l’application avec son environnement d’exécution complet, soit tous les fichiers nécessaires à son exécution. L’image de conteneur contient toutes les dépendances de l’application, elle est portable et cohérente au fur et à mesure qu’elle passe du développement au test et enfin à la production.

Les conteneurs permettent de configurer des environnements de développement locaux qui s’exécutent exactement comme un serveur de production, exécuter plusieurs environnements de développement à partir du même hôte avec un logiciel, des systèmes d’exploitation et des configurations uniques, tester des projets sur de nouveaux ou différents serveurs, et permettre à quiconque de travailler sur le même projet avec les mêmes paramètres, quel que soit l’environnement hôte.

Les entreprises utilisent les conteneurs pour réduire leur dépendance aux technologies de virtualisation commerciales telles que vSphere de VMware, il en résulte une réduction des coûts tout en réduisant l’utilisation de technologies de virtualisation classique.

Selon une étude de Diamanti menées auprès de 576 responsables informatiques datant de 2018,  44% des sondés prévoient de remplacer des machines virtuelles par des conteneurs. Plus de la moitié (55%) consacrent plus de 100 000 dollars par an aux droits de licence VMware, et plus du tiers (34%) dépensent plus de 250 000 dollars par an en droits de licence VMware. Près de la moitié des responsables informatiques interrogés prévoient de déployer des conteneurs en production, tandis que 12% déclarent déjà en avoir.

Efficacité

Prenons le plus connu, Docker, une plate-forme de conteneurs qui possède des nombreuses références à son actif. Avec Azure, la consommation a lieu sur le conteneur plutôt que sur l’application ou la machine virtuelle et donc les coûts Azure sont moindres, tout comme les dépenses de maintenance et de licence. Je prends l’exemple de mon blog où j’ai plus que divisé par deux les coûts de son hébergement en passant d’une VM à une solution de conteneur, en l’occurrence Docker.

Les plates-formes de conteneurs sont capables de générer un impact mesurable à tout point de vue grâce à une densité d’applications bien supérieure à celle des machines virtuelles.

Sans sacrifier les performances des applications et tout en réduisant le temps nécessaire pour effectuer des tâches courantes, en accélérant le développement et le déploiement en s’intégrant parfaitement dans une chaîne de déploiement continu DevOps.

Flexibilité

Avec une plate-forme de conteneurs véritablement agnostique, les entreprises bénéficient d’une réelle flexibilité en libérant les applications de leur environnement et en pouvant les héberger en fonction des besoins.

De plus, les conteneurs offrent une véritable portabilité car ils sont basés sur des normes ouvertes et s’exécutent sur toute infrastructure (Cloud, virtuelle, …). Ainsi, les entreprises n’ont plus besoin de s’engager à long terme sur leur infrastructure.

Sécurité

Les plates-formes de conteneurs isolent les applications de l’infrastructure, ainsi que d’autres applications, ce qui réduit la surface exposée. Les espaces de noms du noyau Linux isolent la vue de l’application d’un environnement d’exploitation, y compris les arborescences de processus, le réseau, les ID utilisateur et les systèmes de fichiers montés, tandis que les groupes de contrôle du noyau limitent les ressources, notamment le processeur, la mémoire, …

 a) Avantages

Rationalisation du cycle de développement des logiciels sur les différents environnements, car il n’existe plus d’adhérence comme nous avons pu en connaître dans des architecture traditionnelles

Les tests et le suivi des bugs deviennent également moins compliqués car il n’y a pas de différence entre les environnements

Les conteneurs sont légers et peuvent démarrer en quelques secondes

Ils partagent un système d’exploitation commun, ce qui réduit les coûts, moins de serveurs (car consomment moins de ressources), moins d’OPS, …

b) Inconvénients

• Les conteneurs ont un domaine de défaillance plus élevé lorsqu’ils partagent le même système d’exploitation hôte

D’où l’importance d’un orchestrateur !

• Les conteneurs sont moins sécurisés que les machines virtuelles

Les conteneurs partagent le noyau et les autres composants du système d’exploitation hôte et disposent d’un accès root. S’il existe une vulnérabilité dans le noyau, cela peut compromettre la sécurité des conteneurs (en théorie car aucun exploit n’est connu à ce jour)

L’implémentation de la mise en réseau et du stockage des conteneurs reste un problème par rapport aux machines virtuelles

Toujours l’importance d’un orchestrateur et d’un SDN

Les architectures micro-services permettent des déploiements plus petits, plus fréquents et plus nombreux pour ce faire ils doivent être fortement découplés, distribués et élastiques.

Ce qui induit une multiplication des conteneurs (Cattle) car une application pensée micro-services est découpée en de multiples services/composants qui sont faciles à updater, débugger, etc…