Dossier spécial : Mise à jour continue

Les sites web que nous utilisons tous les jours ne connaissent que très rarement des interruptions

de service. Nous ne nous demandons pas avant d’aller sur Gmail, Amazon, Twitter, Youtube,

Instagram, Google Maps… si le service va fonctionner et pourtant nous nous y connectons tout le

temps et à toute heure. Or ces sites ne sont pas statiques ni dans leur contenu ni dans leur

évolution et il n’est pas rare de voir des nouveautés mineures ou majeures arriver du jour au

lendemain sans message d’avertissement indiquant que la plateforme serait indisponible pour

effectuer une mise à jour deux semaines plus tôt. Premier constat si on se base sur ces sites

internets (à l’exception de facebook qui a rencontré plusieurs problèmes récemment) nous pouvons

dire que cela fonctionne à merveille puisque nous ne nous souvenons pas de la dernière fois où

nous avons râlé parce que nous n’avons pas pu voir la dernière vidéo youtube ou que le mail super

important (si si dans ce cas là même le mail le plus insignifiant devient un mail super important) ne

peut pas être envoyé ou encore d’avoir ragé ne pas avoir pu préparer son prochain trajet de

weekend parce que nos services préférés sont indisponibles.

Ce mode de mise à jour s’appelle de la mise à jour continue et nous allons voir comment cela

fonctionne et comment la mettre en oeuvre de manière générale car oui la mise à jour continue est

accessible à tous et pour les projets de toutes les tailles.

1.Mais pourquoi faire de la mise à jour continue?

En tant que professionnel, et bien que nous passons plus notre temps à installer des solutions

informatiques qu’à les utiliser, nous sommes aussi des utilisateurs de solutions informatiques et

comme la très grande majorité d’entre eux (voire même plus) nous râlons, nous rageons, nous nous

plaignons quand un système informatique ne fonctionne plus, fonctionne mal ou parce qu’il manque

une fonctionnalité importante que nous jugeons indispensable.

Les interruptions de service sont de plus en plus rares de nos jours ce qui les rend de plus en plus

difficiles à accepter (un peu comme l’électricité). Ceci est dû principalement à l’introduction

d’architectures virtuelles de qualité et accessibles qui résistent très bien aux pannes et qui sont plus

simples à sauvegarder et à redémarrer. C’est surtout la durée d’indisponibilité qui a été réduite grâce

aux technologies de virtualisation et aux services d’hébergements.

Il n’y a rien de plus frustrant pour un utilisateur la tête dans le guidon de voir que son logiciel

principal sera arrêté pour cause de maintenance ou de mise à jour importante. Une autre source de

frustration c’est entendre dire que la mise à jour qui corrigera le bug détecté depuis déjà depuis trois

mois aura lieu dans 6 mois, lors de la prochaine mise à jour du logiciel.

Une DSI dont l’objectif est de de diminuer le fossé qui existe entre son service et les utilisateurs aura

immédiatement vu l’intérêt de proposer des mises à jour régulières sans interruption de service.

Effectivement la mise à jour continue améliore grandement la satisfaction des utilisateurs à

l’exception des réfractaires à tout changement bien connus des DSI; ces “irréductibles gaulois qui

résistent encore et toujours à l’envahisseur” (référence : bande dessinée Astérix de Goscinny et

Uderzo).

D’autres avantages moins évidents arrivent avec les outils de mise à jour continue comme “l’auto

scalling” qui permet à une infrastructure de s’adapter à la charge automatiquement en augmentant

ou diminuant les ressources nécessaires en temps réel, il y a aussi le déploiement partiel pour

assurer systématiquement des tests de pilotes (aussi appelés early adopters).

En résumé voici ce qu’amène la mise à jour continue :

• Rupture de service exceptionnelle
• Évolution plus rapide des demandes urgentes et très gênantes
• Auto scalling
• Déploiement partiel

2.Architecture utilisée

Pour réussir cette mise à jour continue les entreprises comme Google, Amazon ou twitter ont mis en

place une architecture haute disponibilité avec des connexions internet, des approvisionnements

électriques, des climatisations, des coeur de réseaux redondés. Bref tout ce que l’on retrouve dans

tous les datacenters dignes de ce nom mais en plus de cette base technique extrêmement solide

ces entreprises se sont entourées d’équipes humaines qualifiées qui se relaient 7/7j et 24/24h pour

monitorer les infrastructures et intervenir rapidement en cas de panne, des équipes de sécurité pour

protéger leurs installations et des équipes d’ingénieurs en sécurité informatique pour lutter contre les

cyber attaques. Nous vous l’accordons tout le monde n’a pas les moyens de mettre en place ce

genre d’organisation ni d’architecture mais c’est pour cela que le cloud privé ou public existent, ils

permettent à des clients de toute taille de se regrouper et de mutualiser leurs infrastructures et leurs

services afin de bénéficier de tous ces services au meilleur prix. A part les entreprises qui

fonctionnent sans connexion internet fiable, personne n’a d’excuse pour ne pas aujourd’hui

bénéficier des services et d’une architecture à haute disponibilité citée précédemment.

3.Le temple du devops

La mise à jour continue comme son nom l’indique propose des mises à jour régulières, certaines se

font tous les jours, d’autres toutes les semaines ou quand les développeurs l’ont choisi. Bref le

cauchemar et de quoi s’arracher les cheveux pour ceux qui ont été formés comme nous à

l’informatique traditionnelle et c’est là qu’intervient le devops puisque cette mise à jour continue

annonce la fin de l’organisation classique des DSI de l’an 2000 à savoir la division des équipes

informatiques en deux pôles majeurs développement et exploitation et la mort des déploiements de

grosses versions, des migrations bloquantes et des sessions de formations concentrées sur

quelques semaines. Tout cela ne veut pas dire que c’est la fin de la qualité, des cycles en V et que

c’est la porte ouverte aux développements tous azimuts sans réflexion et sans stratégie. Non cela

implique juste une réorganisation de la DSI et les chapitres suivants vont vous permettre de tout

comprendre et de vous rassurer : le travail informatique tel qu’on le connaît ne change pas

radicalement, ceux qui vous disent le contraire font du sensationnalisme et veulent se rendre

intéressants.

4.L’organisation des projets

Le but de la mise à jour continue est de proposer des mises jour régulières, de supprimer tous les

arrêts de service et de réduire le délais entre une demande utilisateur et la réponse concrète à celle

ci. Pour réussir ces trois objectifs il est donc nécessaire de passer sur des cycles courts de

réalisation et donc beaucoup de personnes argueront que seuls les sprints SCRUM permettent

d’aller vite et sur ce point nous ne sommes pas d’accord, un cycle en V peut être aussi efficace

qu’une série de sprints SCRUM, la clé pour avoir des cycles courts est de faire des tous petits

projets qui se concentrent sur une fonctionnalité. Les grands projets se réalisent donc en découpant

toutes les demandes en une suite de mini projets et en priorisant les tâches en fonction de

l’importance, du besoin et du temps nécessaire à la réalisation. Pas de recette miracle pour ce

découpage il faut faire confiance à son bon sens et à une bonne connaissance du métier et des

utilisateurs. Un bon découpage est essentiel à la réussite du projet.

Pour résumer : le choix de la méthode ne garantit pas le succès, à vous de choisir celle qui convient le mieux à vos équipes et à vos projets.

En faisant une multitude de livraisons l’utilisateur voit les choses avancer et n’a pas l’impression

d’être oublié ou laissé de côté, c’est le fameux effet tunnel tant connu de tous où les utilisateurs sont

dans le noir pendant tout le temps du développement.

De plus les évolutions mineures et sans risques ne sont pas obligées d’attendre la mise à jour

majeure. En effet dans ce mode de fonctionnement, on peut déployer des évolutions pour des

utilisateurs avisés qui pourront remonter les bugs en “condition réelle” d’utilisation. On peut donc

réduire le temps à passer sur certains tests. Attention à bien choisir les évolutions (surtout

cosmétique), mais c’est possible.

Les mini livraisons sont organisées comme des vrais projets avec recensement des besoins,

conception, développement, recette technique, tests pilotes et déploiement final, la différence c’est

que comme c’est un petit projet, il faut de la réactivité et donc éviter les organisations lourdes. L’idée

est de monter des équipes non pas par compétences similaires mais plutôt par projet. Les

entreprises disposant des ressources nécessaires font le choix d’avoir des référents techniques ou

experts en support à ces équipes projets pour assurer une performance optimale. Il n’est pas rare

que les nouveaux acteurs choisissent cette méthode et c’est pour cela que de nombreux produits

sortent en version beta de nos jours. Tous les produits Google de l’offre G Suite ont connu ce même

type de déploiement et cet exemple illustre parfaitement le fait qu’il est possible de sortir de jolis et

complexes produits de cette manière mais cela ne veut pas dire non plus que c’est une réussite à

chaque fois.

5.Les outils de base de la mise à jour continue dans GCP

Alors le principe fondamental de la mise à jour continue est la séparation de l’exécution du code et

des données. C’est déjà le cas dans 99 % du cas des logiciels développés mais ce principe est

poussé à l’extrême et la finalité est même de ne pas mettre 100% des utilisateurs sur la même

version de code, il n’est pas rare que dans Gmail votre collègue ait avant vous une nouvelle

fonctionnalité ou inversement que vous voyez une nouveauté avant que lui ne la voit sur son écran.

Pour orchestrer tout cela il nous faut trois éléments principaux :

• Un load balancer (répartiteur de charge en français)
• Un endroit où stocker les données
• Une armée de processeurs disponibles pour exécuter le code

Premier constat cette architecture est prête (pour peu que les données soient stockées dans un

environnement évolutif aussi) à s’adapter au nombre d’utilisateurs qui utilisent l’application et donc

on aura par la même occasion une adaptation du coût. Elle est prête pour 1 utilisateur comme pour

des millions d’utilisateurs, ce qui est le cas pour Amazon, Google et twitter.

En ce qui concerne le load balancer un seul est disponible dans GCP mais il est efficace, nous

avons d’ailleurs consacré un article dessus et nous vous invitons à le lire pour plus d’information.

Exemple :

Pour la partie stockage de données il existe plein de solutions toutes viables : base de données

relationnelles, base de données in memory, système de fichiers haute performance, solutions

NoSQL… En fait c’est l’utilisation de ces données qui dictera le choix à faire car on ne stocke pas de

la même manière une petite centaine de vidéos, des milliards d’articles ou bien les mails de plus

d’un milliard d’utilisateurs.

Exemples :

Pour la partie unités de calcul plusieurs choix s’offrent à nous, cela peut aussi bien être des VMs

d’un autre cloud, des machines physiques, des téléphones mobiles, des sites web managés comme

App Engine ou encore et ce qu’il se prête le mieux actuellement : des conteneurs (docker en

général).  

Exemples :

6.Cas d’usages expliqués

Nous allons voir dans ce paragraphe comment cette architecture réagit dans deux cas précis :

augmentation du pic de charge et mise à jour de la version

Augmentation du pic de charge :

A.La situation est utilisée de manière optimale (90% de la capacité) mais ne peut pas

recevoir un nouvel utilisateur

B.Un Nouvel utilisateur se présente il est orienté vers une unité de calcul qui n’était pas

encore utilisée par le gestionnaire de container Kubernetes

C. la situation au finale

La ressource sera libérée dès que les demandes diminueront.

Mise à jour de la version déployée :

Le scénario nous avons deux versions de code différentes une vieille version avec le carton

grisé par le temps et une nouvelle version de code toute neuve avec un carton de couleur

marron flambant neuf. C’est implicite mais les versions sont déployées et tournent dans des

containers.

A.Situation avant la mise à jour, les utilisateurs sont répartis sur tous les containers actifs.

B.On définit des utilisateurs pilotes (10 à 20% des utilisateurs globaux, de façon aléatoire ou

sur un critère) pour tester la nouvelle version et dès qu’ils se connectent on les oriente vers

cette nouvelle version et la teste le temps nécessaire.

Au bout d’un certain temps la charge s’équilibre et on se retrouve avec le même nombre de

containers où on s’en approche grandement. Dans le schéma ci dessous un container a

disparu car la demande a été réduite

Une fois la nouvelle version validée on interdit au load balancer d’ajouter des connexions sur

les anciens containers et on oriente les nouveaux utilisateurs sur les nouvelles versions,

durant cette étape on va utiliser plus de containers que nécessaire.

Au bout d’un certain moment tout le monde est sur la nouvelle version

7.le coût

Il est bon à signaler qu’il n’y a aucun coût de licence : les containers Docker et le gestionnaire de

container Kubernetes (ancien projet des équipes internes de Google rendu ouvert) sont des

solutions open source. Petite remarque ces solutions sont aussi les mêmes utilisées chez AWS et

Azur donc n’hésitez pas à choisir cette solution elle ne vous enferme pas dans un cloud plutôt qu’un

autre et je dirai même que les plus intrépides l’ont déjà mis en place en utilisant plusieurs cloud sur

cette technologie pour être pratiquement assuré d’avoir un service sans aucune interruption.

Certains DSI qu’on a rencontré étaient intéressés par cette flexibilité pour pouvoir choisir le cloud en

fonction des tarifs ou des promotions (mutli-cloud à géométrie variable, une idée pertinente mais

nous conseillons d’abord de stabiliser sa solution sur un seul cloud avant de franchir le pas).

En ce qui concerne la partie matérielle :

• le load balancer ne coûte pas grand chose moins de 50 € par mois.
• Le coût réseau ne coûte pas grand chose et sera le même si vous choisissez une VM.
• En ce qui concerne les containers chez Google vous payez l’équivalent de la VM à la puissance du container choisi
• La partie stockage de données : il y a tous les prix tout dépend de ce que vous voulez stocker et de votre budget.

A première vue optez pour les containers ne vous reviendra pas beaucoup plus cher que de faire

des déploiements classiques mais cela peut même coûter moins cher car si vous optez pour des

petits containers qui se dupliquent lors des pics de charge et s’éteignent lorsqu’ils ne sont plus

utilisés vous pouvez avoir une solution plus agile financièrement et peut même vous faire faire des

économies.

8.Les problèmes liés à la mise à jour continue

Le plus gros problème lié à la mise à jour continue est la conduite du changement, parce qu’avec

beaucoup de petits changements très régulièrement les utilisateurs ont du mal à suivre. Seuls les

plus motivés feront l’effort de lire les nouveautés reçues par mail ou les notifications qui se trouvent

dans le logiciel. Cela sera possible sur un ou deux outils principaux mais cela va lasser très vite les

utilisateurs. Se pose aussi la question des fascicules ou site de formation qu’il faudra tenir à jour

constamment et cela n’est pas anodin et a un coût. Un deuxième problème se pose quand on ajoute

trop de fonctionnalités à un outil c’est la maintenance de toutes ces fonctionnalités et là encore pas

de miracle cela a un coût et il faudra trancher entre fonctionnalité vraiment utilisée à maintenir et

fonctionnalité gadget rarement utilisée à faire mourir.

9.Conclusion

Utiliser toutes les capacités du cloud et gagner en abstraction permet d’avoir des solutions

beaucoup plus robustes et agiles et cela devrait plaire aux utilisateurs et surtout à toutes les DSI car

ces technologies sont sûres, simples à mettre en place et économes. Ces technologies comme

l’article le démontre sont à la portée de toutes les bourses et de tous les informaticiens, elles sont

déjà prêtes elles n’attendent plus que vous les mettiez en oeuvre. Bien sûr tout n’est pas parfait et il

reste à travailler sur la partie formation/conduite du changement car rester à jour exige de

l’investissement des utilisateurs mais tout dépend des utilisateurs et de leur motivation et comme

vous connaissez vos utilisateurs mieux que nous c’est à vous de jouer.