Dans les discussions à propos du cloud AWS, la question de la réversibilité (la capacité à changer de fournisseur de cloud) revient souvent. C’est logique du point de vue du client : les conditions qui conduisent aujourd’hui à choisir AWS pourraient changer demain, et les marchés publics (lorsque les clients sont publics) contraignent de toutes façons à la remise en concurrence régulière. En outre, l’histoire de l’informatique a montré combien les systèmes d’information historiques sont adhérents à certains composants logiciels, au travers notamment de mécanismes de licences et de formats propriétaires, qui finissent par retenir les clients en partie contre leur gré, et les a logiquement rendu particulièrement attentifs à la question. D’ailleurs, j’en ai fait personnellement l’expérience difficile, au cours de ma carrière au Ministère de l’Intérieur et au Ministère de l’Education Nationale, à au moins deux reprises : une première fois avec un audit de conformité très dur au moment de quitter un système de messagerie très répandu, une seconde fois avec des changements de conditions très désavantageux à l’occasion d’une montée de version d’un logiciel propriétaire de gestion de base de données.

Chez AWS, nous sommes conscients que cela n’est pas la bonne façon de vendre nos services, et pensons que les clients auront d’autant plus envie d’utiliser nos services qu’ils seront effectivement libres, à tout moment, de repartir et de changer de fournisseur.

Mais pourquoi serions-nous différents chez AWS ?

Ce qui fait notre particularité, dans la culture d’entreprise d’Amazon, ce sont les leadership principles, et notre volonté de rester une “day one company” comme une condition essentielle pour rester innovante (voir la lettre aux actionnaires de Jeff Bezos de 2016). Savoir qu’un client peut quitter AWS à tout moment, c’est un mécanisme puissant qui nous oblige à obtenir et conserver sa confiance sur le long terme pour qu’il ait envie de continuer à utiliser le cloud, parce que la qualité de ce que nous faisons lui plaît, et parce que ça l’aide à résoudre ses problèmes. C’est un mécanisme extrêmement important, lié à plusieurs leadership principles (“Earn Trust”, “Customer Obsession”), assumé par notre management, qui fait partie des rouages essentiels de notre succès, pour nous obliger à innover, à nous renouveler pour répondre aux nouvelles attentes, et ainsi éviter de devenir “Day Two”. De façon très concrète, nos actions individuelles sont effectivement évaluées, qu’on ait un rôle technique ou commercial, sur ces principes de long terme.

C’est pour cela que la réversibilité nous tient à coeur, et nous travaillons volontiers avec nos clients pour les aider à faire les choix qui correspondent le mieux à leurs enjeux de réversibilité.

Et du coup, concrètement, comment assure-t-on la réversibilité ?

Premièrement d’un point de vue financier : par essence, le paiement à l’usage est plus propice au changement que l’investissement. Lorsque, dans son datacenter, on a acquis du matériel et des licences logicielles, on est un peu “coincé” dans cet investissement au minimum pendant le temps de son amortissement. Chez AWS, le paiement à la demande supprime cet effet. Il est possible, à tout moment, d’arrêter les services dans le cloud et immédiatement d’arrêter de payer.

Deuxièmement d’un point de vue légal : rien, dans nos contrats, ne vous retient chez nous. Vous avez toute la maîtrise de vos données, de leur sauvegarde, de vos algorithmes, les mettre dans le cloud n’affecte pas leur propriété, la propriété intellectuelle sur elles, … Il n’y a pas d’ambiguité sur notre modèle de responsabilité partagée : nous fournissons les outils et les automatismes, ce que le client en fait ne nous concerne pas, nous ne développons aucun business autour de cela, nous n’accédons pas aux données et aux contenus du client. Rien, d’un point de vue légal, ne contraint le client à rester chez nous.

Troisièmement, d’un point de vue technique : une fois que les aspects financiers et légaux sont traités, c’est le nerf de la guerre. Si la réversibilité est une exigence parfaitement compréhensible et légitime, ce n’est évidemment pas le seul but dans un projet d’adoption du cloud, et il faut prêter attention que cette exigence n’annule pas tous les bénéfices attendus, ou pire, gèle toute décision en espérant un idéal inatteignable. On peut perdre un temps infini et dépenser une fortune à définir ou à acheter des surcouches d’abstraction (dont on sera in fine très dépendants).

En réalité il est nécessaire de faire un compromis éclairé. De la même manière que la bonne approche de la sécurité, c’est une analyse de risque avec un équilibre entre bénéfice attendus, mécanismes de réduction des risques et risques résiduels (la sécurité absolue n’existe pas, sauf à ne rien faire), la bonne approche pour la réversibilité est également de trouver le bon équilibre pour faciliter la création rapide sans mettre trop de contraintes a priori, tout en se ménageant les portes de sortie souhaitées. Je recommande fortement la lecture de cet article de blog.

Il faut donc décortiquer le besoin de réversibilité : S’agit-il de se préserver la liberté à un moment donné de développer une nouvelle application dans un autre cloud ? S’agit-il de se donner la liberté de déplacer des applications d’AWS vers un autre cloud à un coût et un délai maîtrisés ? Quel est l’ordre de grandeur : la semaine, le mois, l’année ?

Souvent, mes interlocuteurs disent “pour des raisons de réversibilité, on n’utilisera que du IaaS chez vous”. En réalité, il est possible de maintenir une réversibilité à coûts et délais maîtrisés, avec des services d’infrastructures, des services managés ou des services abstraits. C’est une représentation complètement fausse, couramment rencontrée chez les clients, que d’imaginer que “PaaS” et “SaaS” seraient par essence moins réversibles. Je vais prendre quelques exemples :

• Amazon S3 est notre service de stockage objet, service très “abstrait”. Stricto sensu, les services de stockage des concurrents ne sont pas exactement équivalents. Pour autant, par principe, du stockage objet c’est toujours plus ou moins la même chose (on stocke un objet, on lit un objet, on l’efface) : la plupart du temps, il est raisonnable d’utiliser ce service de stockage, peu cher et performant, quitte à avoir à ajuster les appels d’API de stockage si un jour on change de fournisseur de cloud. En échange d’un bénéfice technique et fonctionnel important, on accepte un possible coût de transformation, qui peut être précisément documenté à l’avance et anticipé (d’autant plus que désormais, S3 est devenu un standard de facto mis en oeuvre par de nombreux produits).
• Amazon RDS est notre service de base de données relationnelle managée, avec plusieurs bases supportées : Oracle, Microsoft, MySQL, PosgreSQL, MariaDB. La réversibilité est complète : il vous suffit de monter la base considérée chez un autre fournisseur de cloud ou chez vous, et de récupérer les données (le plus simple étant un “dump” de la base, il est également possible d’utiliser des mécanismes de synchronisation progressive pour limiter les interruptions de service). Il n’y a rigoureusement aucun obstacle technique à la réversibilité.
• Amazon Sagemaker est notre plateforme pour l’apprentissage automatique, pour les clients souhaitant introduire des mécanismes d’intelligence artificielle dans leurs applications. Cet outil est conçu pour faciliter la création, l’entraînement et le déploiement d’algorithmes d’intelligence artificielle. En supposant qu’un client ait créé et entraîné ses algorithmes sur Sagemaker, il peut les exporter à tout moment (sous forme de docker) pour les exploiter ailleurs. De même, toute la logique d’entraînement de l’algorithme est stockée dans un Jupiter Notebook managé, transposable dans tout autre Notebook.
• Amazon Translate est un service de traduction automatique. Si l’API est spécifique à ce service, la logique d’appel du service est toujours la même : on envoie un texte dans la langue A, et le service renvoie un texte dans la langue B. Un client qui choisit aujourd’hui Amazon Translate peut demain aller chez un autre fournisseur en modifiant simplement l’appel de service, sans rien changer à la logique.

Bref, on peut continuer ainsi sur de nombreux services ; certains pour lesquels la réversibilité est plus immédiate, d’autres demandent quelques précautions, mais rien qui ne justifierait une sorte de dogme “Iaas-only”, au contraire. Il ne faut pas confondre “agnosticité du code” et réversibilité : la réversibilité est un objectif rationnel, qui nécessite d’anticiper les besoins liés à une éventuelle migration pour sortir. L’agnosticité du code est un moyen extrêmement contraignant (qui perd beaucoup des avantages du cloud) pour obtenir la réversibilité dans un modèle où le cloud est cantonné à sa fonction d’hébergeur, lorsqu’on ne maîtrise pas vraiment les développements. Cela rejoint mon précédent post de blog, il ne s’agit pas uniquement d’héberger un développement, mais de s’appuyer sur un ensemble de services cloud.

Le “multi-cloud” est également une fausse bonne idée pour assurer la réversibilité, à peu près pour les mêmes raisons (voir ce témoignage par exemple).

Si vous souhaitez en discuter, en tout cas, n’hésitez pas à me contacter.

Il y a quelques jours, au cours d’une table ronde, j’entendais un intervenant expliquer les nouveaux développements informatiques qu’il pilotait dans son organisation, concluant en disant *”et il faudra bien poser ces développements quelque part, on est d’ailleurs ouverts à héberger dans le cloud”*.

C’est une étape intéressante, et je ne bouderai pas le plaisir de voir qu’on est susceptible de répondre à ce besoin simple d’hébergement. Ce que j’espère que cet intervenant puisse découvrir ensuite, une fois cette première étape franchie, c’est que le cloud n’est pas seulement un “hébergeur”, c’est un facilitateur, un puissant libérateur d’innovation pour toute la chaine de création de valeur, ce qui est fourni, ce n’est pas seulement de la capacité de calcul, ce sont aussi des ensembles de briques de construction, d’automatisation, de sécurisation, etc…

Si on prend l’image de l’artiste peintre, dans la conception traditionnelle de l’informatique, le peintre devrait définir par avance exactement l’ensemble des couleurs dont il a besoin, attendre que les couleurs soient disponibles, noter les compositions des mélanges, peindre sur une première toile (“environnement de développement”), passer tout cela à une autre équipe qui refait les mêmes mélanges de peinture, recopie la toile (dans un format différent), et l’expose à quelques critiques d’art. Quand les critiques d’art sont satisfaits, on recopie à nouveau la toile pour l’exposer au grand public (chez “l’hébergeur” donc).

La proposition de valeur du cloud, c’est de mettre à tout instant à disposition du peintre des toiles de tous formats, une grande palette de couleurs, et dès qu’il le souhaite l’accrocher au mur pour l’exposer au public et l’améliorer ensuite en permanence. Et il ne paye que la peinture qu’il utilise, pas le pot entier.

Une fois, un de mes clients discutait avec un fournisseur de solution “SaaS” pour qu’il en installe une version dans son cloud privé hébergé dans son datacenter privé, et était déçu que celui-ci s’y refuse. Pourtant, les raisons pour lesquelles un éditeur ne souhaite pas nécessairement “exporter” ses solutions SaaS dans un autre environnement sont exactement liées à cette différence entre hébergement, et utilisation du cloud :

• le fournisseur SaaS s’appuie généralement sur de nombreuses briques de construction packagées/managées, parce qu’elles lui permettent d’innover très vite : elles sont performantes, immédiatement disponibles et sans effort de configuration : aller vite est essentiel dans le monde logiciel, pour pouvoir tester en réel avec des clients/utilisateurs, et ajuster vite tout ce qu’il y a à ajuster. Il ne s’agit pas que des services “avancés” (machine learning,…) : même sur des briques très simples comme le stockage des données, s’il s’appuie sur S3 dans le cloud pour du stockage, il peut compter sur la très haute durabilité native (99,999999999%), ce qu’il n’atteindra très vraisemblablement pas dans un datacenter, ce qui l’obligerait à ajouter une couche de réplication/sauvegarde. Egalement, pour le monitoring, la sécurité, la répartition de charge, …
• le fournisseur SaaS développe initialement ses services sans savoir dans le détail s’il aura du succès, ni quelles seront les profils de consommation de ses clients. La capacité à adapter automatiquement le dimensionnement à la réalité du besoin (“scalabilité”) est essentielle pour obtenir ainsi des coûts de fonctionnement en proportion de la réalité de l’usage, et donc les plus réduits possibles pour son client final.
• le fournisseur SaaS fait évoluer en continu son service logiciel (et l’infrastructure sous-jacente). Il y a un seul système, utilisé par l’ensemble de ses clients. Il peut éventuellement gérer en parallèle plusieurs versions à des fins de test, mais c’est lui qui est responsable de la version délivrée ; en terme de support, de gestion de l’interopérabilité, de gestion des montées de version, … c’est beaucoup plus efficace de maîtriser complètemet le versionning que de dépendre de la bonne volonté du client pour monter de version.

Un logiciel SaaS, ce n’est donc pas juste un logiciel “hébergé dans le cloud” mis à disposition à la demande, ce n’est pas qu’une modalité particulière de commercialisation de logiciels. C’est aussi une autre façon, pour les fournisseurs logiciels, d’innover, de concevoir rapidement, de distribuer de façon cohérente et mondiale, leurs services.

Corrolaire : choisir un fournisseur cloud, ce n’est pas uniquement choisir un hébergeur, mais c’est aussi et surtout choisir un fournisseur de services qui permet de gagner du temps dans la conception et la délivrance de ses services, qui lui permet d’atteindre une très haute disponibilité, qui lui permet d’évoluer rapidement.

Ceci est le troisième épisode d’une série d’articles décrivant des solutions simples que le cloud apporte à des problèmes compliqués auxquels j’ai été confronté dans ma carrière.

“La nouvelle version de l’appli ralentit tout ! Faut vite trouver le problème et patcher avant le pic de charge, on ne tiendra pas !” (MJ, stressé à l’idée de devoir sacrifier son week end encore une fois)

On a beau faire des tests de performance avant les versions majeures, ça arrive qu’un changement applicatif qu’on croyait mineur, ou que la réalité de la charge par rapport à ce qu’on a prévu, sature le système. Il y a aussi le cas (que toute DSI a déjà rencontré, ceux qui prétendent le contraire, j’ai du mal à les croire) où on est un peu contraint par le délai et que les tests de performances ne sont pas vraiment exhaustifs.

Et là, quand on fait tourner l’appli sur son infra maison, on n’a pas beaucoup de solutions. On peut essayer de couper des fonctions non critiques, des scripts, des batches, … mais il n’y a pas de magie, si l’appli est plus gourmande que prévu, les infras ne suivent pas forcément.

Sur AWS, on peut “scaler”, de 2 façons. Soit mettre plus de machines en parallèle (scaling “horizontal”), soit remplacer des machines trop petites par des plus grosses (scaling “vertical”). Les 2 sont plutôt simples.

Le “scaling horizontal” est typiquement mis en oeuvre pour des frontaux web, ou pour des microservices. Quand la charge augmente, on ajoute des machines. Comment on fait ? Et bien c’est simple, on crée un groupe d’auto-scaling, on met les frontaux web dedans, on définit une règle (du genre quand le taux d’utilisation du processeur est supérieur à 75% deux minutes de suite) qui déclenche l’ajout d’une machine dans le groupe, on met une règle à la baisse aussi, et on met un équilibreur de charge devant. C’est tout. On peut aussi faire ça avec des containers pour des microservices…

Le “scaling vertical”, c’est pareil, ce n’est pas très compliqué. Je vais prendre pour exemple un blog wordpress hébergé sur cette architecture de référence wordpress. Si je veux basculer sur une instance de base de données de plus grosse taille (en imaginant que le blog ait un succès important…), je n’ai rien d’autre à faire que de… changer d’instance et le système se charge du reste qui est compliqué (basculer vers la secours - arrêter la première, changer d’instance, redémarrer la base, synchroniser les données, rebasculer vers le principal, puis changer l’instance de secours aussi).

Du coup, si on revient au problème de départ : une mise à jour un peu gourmande en ressource ? Pas grave, on augmente les capacités quelques jours, le temps de trouver la cause, et on revient à la dimension initiale ensuite. Coût : quelques jours d’une infra plus grosse, c’est à dire très faible. Temps d’arrêt du système : zéro. Impact sur les utilisateurs : aucun. Retard de mise en production : aucun. A nouveau, si on regarde les problèmes de retard des grands projets de l’Etat, l’échec des tests de performance, alors que le projet est largement avancé, est un sujet récurrent : c’est un moyen de surpasser cette difficulté.

Du mal à y croire ? Testez donc, par exemple sur une architecture de référence Wordpress : créez un compte AWS, montez l’architecture, jouez à augmenter et diminuer la taille des machines, et vérifiez !

J’ai bien sûr pris des exemples plutôt simples, et comme pour tous les sujets en matière d’informatique, la performance d’un système repose d’abord sur une conception initiale de l’architecture adaptée à ce que l’on veut faire, et ensuite sur un travail d’optimisation progressive, et enfin, pour des besoins très pointus (calcul intensif, temps réel critique, …), sur du travail de spécialistes. Si la question de la performance dans le cloud vous intéresse, je vous encourage à regarder cette vidéo, qui explique les différentes stratégies envisageables depuis 1 utilisateur jusqu’à 10 millions d’utilisateurs pour votre application dans le cloud.

Cette fois-ci, voici un article (un peu) pratique, qui tombe a pic pour préparer les vacances et vider les cartes mémoires des appareils photos avant cet été. Depuis une quinzaine d’années, comme beaucoup de monde, je prends des photos numériques et des vidéos, et j’ai accumulé un nombre important de souvenirs, à peu près 200 Go. J’ai une grosse hantise : la perte de ces souvenirs (cambriolage, incendie, panne), et je n’avais jusque là pas trouvé de solution idéale ; j’ai bien un disque en réseau à la maison, mais qui ne résistera pas à un incendie ou un cambriolage. Et les offres cloud, j’y ai bien pensé, mais je trouvais ça relativement coûteux alors que mon besoin ne consiste qu’en du stockage “au cas où”, et non d’avoir des outils de partage, d’accès à tout moment, …

AWS a sorti, il y a quelques mois, Amazon Glacier Deep Archive, un service d’archivage longue durée à un prix vraiment abordable. Le principe est simple : le stockage n’est vraiment pas cher (descend jusqu’à 1$ par mois par To), est très durable (99,999999999% de durabilité), conçu pour une durée longue et une restauration occasionnelle des objets archivés (facturation de 6 mois minimum de stockage et facturation de la restauration). Voilà qui me convient parfaitement ! Je n’ai pas envie de payer cher (mes 200 Go me coûtent donc… 20 centimes par mois), je n’ai pas envie de perdre mes photos et vidéos (99,999999999 % est bien mieux que tout ce que je pourrai faire par moi-même), et si je ne subis ni cambriolage, ni incendie, ni panne - je n’aurai jamais besoin de les récupérer.

J’ai fait un petit calcul tout bête. Au coût actuel de l’électricité, 20 centimes, ça couvre un peu moins de 1,5 KWh. Sur un mois, c’est l’équivalent d’une puissance constante de 2 W ; bref, en fonctionnement, ça coûte dix fois moins cher que mon lecteur réseau, dont la puissance est d’environ 20 W. Et zéro investissement. Et pas de risque d’incendie/de vol/de panne.

AWS propose ce service, mais ne commercialise pas de logiciel de sauvegarde pour les utilisateurs particuliers comme moi (AWS, c’est plutôt B2B). Au moment où j’ai cherché, je n’ai pas trouvé non plus de logiciel du marché s’appuyant sur deep archive, je suppose que ça va venir. Du coup, en attendant, je me suis débrouillé tout seul, ce qui n’est pas très difficile.

Voilà ce que j’ai fait, dans mon compte AWS personnel :

• j’ai créé un répertoire S3
• j’ai créé un utilisateur IAM userS3sauvegarde qui a uniquement le droit de lire et d’écrire dans ce répertoire
• j’ai installé l’accès en ligne de commande à AWS (AWS CLI) sur mon mac perso et l’ai configuré pour l’utilisateur IAM userS3sauvegarde précédemment créé.
• à chaque fois que j’uploade des photos depuis mon appareil photo, je lance la commande de synchronisation avec les archives (aws sync ./repertoiresourcephotossurmondisque s3://destinationrepertoiresuraws –profile userS3sauvegarde –storage-class DEEP_ARCHIVE)

C’est tout ! ça vaut le coup de mettre les mains dans le cambouis, non ? 20 centimes par mois, et je ne risque plus de perdre mes photos et vidéos numériques !

post scriptum : rclone embarque désormais DEEP_ARCHIVE, c’est un peu plus évolué que ma simple ligne de commande pour ceux qui veulent aller plus loin.

post scriptum 2 : Après réflexion, je me suis dit que mon principal risque était désormais que je perde accès à mon compte AWS… d’où, authentification multifacteur pour le compte root, et, cerise sur le gâteau, ajouter dans la gestion de compte un second gestionnaire administratif du compte (mon épouse), et une carte bleue secondaire (au cas où la mienne ait des problèmes).

Chaque année, simultanément à la publication du rapport annuel, Jeff Bezos envoie aux actionnaires d’Amazon une lettre éclairante sur une partie de l’activité ou du fonctionnement d’Amazon ; c’est souvent passionnant, elles se trouvent toutes ici. Dans la lettre aux actionnaires de 2016, Jeff Bezos explique pourquoi il travaille dur pour que l’entreprise reste une “Day One Company”.

J’aime beaucoup cette lettre, que je trouve très inspirante et très éclairante sur ce qu’il faut entreprendre dans des grandes organisations, pourquoi pas l’administration, pour y maintenir ou réinjecter de l’envie d’entreprendre, de l’efficacité collective, de l’épanouissement de chacun. Ce que je vis aujourd’hui au sein d’AWS est assez éloigné de ce que j’ai vécu pendant mes premiers 15 ans de carrière, et ce contraste mérite de s’y pencher un peu.

Qu’est-ce que ça veut dire, “Day one company” ? L’image qui est convoquée par ces termes est celle de la start-up dans ses premiers jours : tout le monde est aligné avec les mêmes objectifs, la même envie de déplacer des montagnes, la facilité d’entreprendre des projets, la rapidité de décision et de changement de cap, … Et dès lors que l’entreprise croît, qu’elle accumule de l’historique, le risque est grand qu’elle bascule dans le “Day two company”, avec, selon l’analyse de Jeff Bezos, que je cite :
“Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1. To be sure, this kind of decline would happen in extreme slow motion. An established company might harvest Day 2 for decades, but the final result would still come.”

La première chose qui est intéressante, c’est de voir au travers de cette lettre que ce sujet est l’une des toutes premières préoccupations du PDG, qui va consacrer une partie importante de son temps à travailler sur les mécanismes et les éléments de culture qui vont faire perdurer cet esprit “Day one”. Si on veut améliorer l’efficacité collective dans les grandes entrprises et les administrations, il faut que l’encadrement supérieur s’occupe en priorité, en profondeur, dans le détail, dans la durée, du fonctionnement collectif et de la culture de collaboration. Au delà de l’importance que la lettre confère au sujet, ce qui me marque c’est que ce sujet est considéré comme complexe, ça ne va pas de soi pour Jeff Bezos qu’on va facilement y arriver, cela nécessite des efforts importants, du plus haut niveau, avec une capacité à réinterroger régulièrement le système pour prévenir les dérives. Le management n’est pas considéré comme quelque chose d’inné chez les managers et la formation, le mentoring, sont largement répandus.

Un des symptômes mortifères d’une “day 2 company”, tel que Jeff Bezos la décrit, est le fait que certains processus, qui ne devraient exister que pour aider à mieux servir le client, deviennent l’objet principal de certaines équipes. Ce qui se passe, c’est qu’on arrête de regarder le résultat collectif attendu, et on se focalise uniquement sur le fait qu’on réalise bien le processus. Cela ne veut pas dire qu’il ne doit pas y avoir de processus, ça veut dire que le processus doit être conçu pour l’objectif collectif final, et qu’on se donne la capacité de l’ajuster régulièrement (ou de le remettre en cause complètement) s’il n’est pas efficace par rapport à l’enjeu global, avec donc des métriques, et des boucles d’amélioration continue.

Si on regarde bien, certaines initiatives récentes de l’administration tirent les conséquences de ces constats. Les projets “dites le nous une fois”, qui consistent à mettre en place des échanges de données entre administrations plutôt que de redemander plusieurs fois la même information, décloisonnent les processus isolés pour en faire un seul qui fait sens à l’usager. Les projets de nombreuses start-ups d’Etat sont également basés sur la résolution d’un point de douleur de l’usager, et sont là pour les résoudre de bout en bout. J’ai aussi de nombreux souvenirs, dans ma carrière administrative, où en gestion de crise, toutes les équipes s’alignaient presque miraculeusement sur un objectif commun, qui pouvait être un objectif vital que tout le monde comprenait, intériorisait, et agissaient du coup de concert avec une efficacité redoutable : ce sont probablement mes meilleurs souvenirs.

L’idée, c’est d’aller plus loin et de considérer l’ensemble du système, pas uniquement des initiatives ponctuelles (bien qu’exemplaires) ou des alignements “accidentels” en situation de crise. Ce n’est évidemment pas facile, mais cela doit aussi concerner l’informatique, les ressources humaines, les finances, les achats, les services généraux, le juridique, dans leur fonctionnement quotidien.

Bien entendu, c’est d’autant plus difficile quand l’échelle est grande. Il y a beaucoup de raisons à cela, notamment parce que la coordination et la communication perdent le caractère spontané des petites équipes. C’est pourquoi on retrouvera à la base des organisations “Day One” à grande échelle :

• des équipes autonomes dans leur fonctionnement quotidien. Ces équipes ne doivent pas dépasser la taille qui leur permet de se synchroniser quasi spontanément.
• un renforcement de cette autonomie en limitant les frictions et les temps d’attente ; typiquement, les développeurs ayant besoin d’infrastructures doivent trouver leur bonheur en “self-service” dans le cloud.
• des circuits permettant de prendre des décisions rapides quand les sujets dépassent le périmètre d’une seule équipe.

La théorie, c’est bien, et la réalité c’est encore mieux : Amazon Web Services fonctionne comme ça, au quotidien, et quand on travaille pour AWS, c’est extraordinairement confortable.

Pour la première fois cette semaine, j’ai utilisé moi-même (configuré, interfacé) un “HSM”.

De quoi s’agit-il ? Un HSM est un “hardware security module”, un module de sécurité matériel qui sert à protéger des clés de chiffrement. L’idée est toute simple, dans l’informatique beaucoup d’élements de sécurité reposent sur des mécanismes de cryptographie (qu’il s’agisse de chiffrer les données pour des besoins de confidentialité, qu’il s’agisse de s’assurer de l’authenticité d’un document, qu’il s’agisse de vérifier l’identité d’un système distant, …) et il est important de protéger les clés contre toute utilisation par une personne ou un système non autorisé. Aussi, la clé est stockée dans un module matériel spécifique, et tous les calculs cryptographiques utilisant cette clé sont également exécutés dans ce module spécifique, de sorte que la clé ne sort jamais en clair de ce module. Evidemment, pour raffiner, ce module est conçu pour se protéger de toutes sortes d’attaques (par exemple : si on essaye d’ouvrir physiquement le module, la clé est effacée, si on mesure la consommation électrique, on ne devine aucune information sur la clé, …). Généralement, les fabriquants de ces boîtiers ont à coeur de faire auditer leurs solutions et de les soumettre à des batteries de test, de sorte que les clients puissent avoir confiance dans la technologie proposée (évaluation FIPS 140-2, évaluations critères communs, …). En France, notamment, Atos-Bull commercialise la gamme Proteccio, et Gemalto la gamme Safenet.

Dans mon parcours professionnel, j’ai eu à plusieurs reprises l’occasion d’avoir ce type d’engins dans le système d’information. Et à chaque fois, ça a été un long calvaire pour mes équipes, parce que, le matériel étant coûteux, difficile d’avoir la possibilité d’expérimenter pour apprendre, et parce que fondamentalement c’est difficile et complexe à mettre en oeuvre et à configurer dans des conditions de sécurité et de disponibilité compatibles avec les besoins d’une production informatique opérationnelle (en cluster, avec des sauvegardes, …).

Et j’ai découvert… cloudHSM ! CloudHSM, c’est une partition d’un HSM (un vrai, un physique), dans le cloud, avec donc toutes les caractéristiques de sécurité décrites précédemment. Et donc des clés de chiffrement protégées par un module matériel qui empêche toute récupération, exportation, utilisation des clés, y compris par AWS. En utilisant cloudHSM, vous avez le niveau de maîtrise de la sécurité d’un matériel en propre ayant un haut niveau de certification et d’audit (et donc de quoi répondre à des enjeux spécifiques de conformité également, comme dans le domaine bancaire), et la commodité de son utilisation et de son intégration dans le cloud.

Ceci est le second épisode d’une série d’articles décrivant des solutions simples que le cloud apporte à des problèmes compliqués auxquels j’ai été confronté dans ma carrière.

Combien de fois ai-je rencontré, sur le chemin critique d’un nouveau projet, la réalisation du dossier d’architecture, qui précède l’achat et la configuration des infrastructures dédiées à une nouvelle application ? Cette étape était souvent critique, parce qu’il fallait être précis dans l’évaluation des besoins d’un système pas encore développé, et c’était l’occasion de tensions entre les architectes techniques (qui voulaient le maximum de détails et cherchaient à optimiser), les équipes de dev (qui voulaient que ça aille vite), et souvent les sous-traitants (qui avaient une fâcheuse tendance à pousser au sur-dimensionnement pour éviter d’avoir à optimiser le code).

Le cloud ne supprime évidemment pas le besoin d’un travail d’architecte. Simplement, le changement essentiel vient du fait qu’il n’y pas de décision irrévocable, tout peut être modifié au fur et à mesure de l’évolution des besoins applicatifs. On a prévu de faire tourner la base de données sur un serveur 4 coeurs, et on se rend compte que ce serait mieux 8 coeurs ? Pas de problème, on change ; et changer est une opération anodine (en configuration cluster, sans même arrêter la prod !). On veut changer une machine de sous-réseau ? Trois clics ! On veut rajouter un composant pas prévu ? On l’ajoute ! On regrette ? On l’enlève !

Et ça change tout : les décisions n’étant pas irrévocables, n’ayant que des conséquences limitées, peuvent être prises beaucoup plus vite. Et être prises au plus proche de l’équipe. On peut revenir en arrière. On peut tester des idées. Bref, on acquiert une plus grande rapidité et une plus grande liberté d’innovation.

Là où l’étape du dossier d’architecture était une étape cruciale, bloquante, pleine de risque (et in fine facteur de nombreux délais), elle devient un élément du processus normal et continu de conception - développement - intégration. La diminution des risques sur la définition et l’achat des infrastructures constituerait une avancée majeure pour l’Etat dans sa recherche de sécurisation de ses grands programmes informatiques.

On peut aller encore plus loin, ensuite, en mettant en place un processus d’intégration et de déploiement continu conjoint entre le code applicatif et le code qui décrit l’infrastructure ; comme vu dans un post précédent, la description de l’infrastructure, c’est du code ! Donc on peut gérer des modifications d’infrastructure comme on gère des modifications de code, et intégrer cela dans la chaîne de développement et d’intégration continue. C’est ainsi qu’on peut définir des déploiements prêts à l’emploi embarquant conjointement le code applicatif et l’infrastructure, comme on peut en trouver plein d’exemples sur github.

Je suis particulièrement impressionné par les outils de sécurité informatique disponibles sur AWS, et je partage cette sentiment avec de nombreux collègues, dont des spécialistes de sécurité informatique qui travaillent aujourd’hui dans les équipes d’AWS en France. On va faire un petit quizz, juste pour vous permettre de vous rendre compte.

1. Avez-vous une cartographie exhaustive cohérente, mise à jour en temps quasi-réelle de toute votre configuration réseau/sécurité/serveur/stockage sur l’ensemble de vos environnements ?

2. Tracez-vous et enregistrez-vous, toute action de création, de modification, de reboot, de suppression d’un quelconque élément de vos environnements (réseau/règle de filtrage/serveur/stockage/…) ?

3. Avez-vous mis en place des outils d’analyse automatique de ces logs et de réaction automatique en cas de détection ?

4. Chiffrez-vous toutes les données personnelles et sensibles au repos, en base de données, dans vos entrepôts de données ?

5. Avez-vous mis en place des mécanismes pour supprimer toute possibilité d’accès direct par vos administrateurs systèmes aux données sensibles en production ?

6. Ajoutez-vous un niveau de protection contre les erreurs en imposant une authentification multi-factorielle pour les opérations les plus sensibles sur les environnements de production ?

7. Testez vous régulièrement vos plans de continuité et de reprise d’activité ?

8. Avez-vous en place une protection efficace contre les attaques en déni de service sur l’ensemble des ressources exposées à Internet ?

9. En cas de départ d’une personne de votre équipe et de révocation de ses droits, êtes vous assuré qu’il n’a pas gardé de droits d’accès à des ressources sur vos infrastructures ?

10. Assurez-vous une rotation fréquente et régulière des clés d’authentification sur les serveurs ?

Si vous avez moins de 10 réponses positives, vous devriez regarder ce qu’AWS peut apporter. Jetez par exemple un coup d’oeil au recueil des bonnes pratiques sur la sécurité chez AWS !

Dans toute ma carrière, si la préoccupation de la sécurité informatique a toujours été présente, elle était toujours accompagnée de forts éléments de contrainte :

• complexité: la plupart du temps, les différents composants reposent sur des paradigmes et des outils de sécurité très différents, qui nécessitent, pour un minimum d’exploitabilité, une intégration longue et fastidieuse; c’est le cas de la gestion des droits d’accès, du chiffrement, des outils d’inventaire, …
• coûts: beaucoup de matériels et de logiciels spécialisés sont coûteux (je pense notamment aux infrastructures à gestion de clés, aux matériels protection anti DDoS sur le réseau)
• performance: la latence induite par le chiffrement à la volée, par l’initialisation des connexions sécurisées, pouvait être impactante sur l’utilisateur.
  Et c’est certainement pour ces raisons que mon résultat à ce quiz, dans plusieurs environnements professionnels précédents, aurait été plus proche de 0 que de 10.

Fondamentalement, le cloud AWS permet de mettre en oeuvre des pratiques de sécurité très exigeantes, avec plusieurs atouts majeurs : facilité de mise en oeuvre, faible coût, performance préservée. Par exemple, mettre en place du chiffrement au repos (sur disque) pour protéger des données stockées en base (et par exemple, éviter que vos propres administrateurs de votre système puissent en extraire des données) se met en oeuvre en quelques clics, gratuitement, sans perte de performance.

Ce que cela signifie aussi, c’est que ce niveau de protection des données a vocation à devenir le nouveau standard notamment pour les autorités de régulation, alors que c’est un défi complexe à mettre en oeuvre avec des moyens limités dans son propre datacenter; bon courage pour ceux qui s’y lancent hors cloud !

C’est mon premier anniversaire de travail chez AWS !

Petit clin d’oeil au slogan d’AWS : Work hard, have fun, make history. Work hard, nous travaillons dur, les défis sont très nombreux pour accompagner nos clients sur le chemin d’une transformation en profondeur, la technologie évolue très vite et nous oblige à des remises en cause permanentes, la croissance des équipes modifie en permanence les rôles et exige une adaptabilité permanente. Have fun, les équipes sont incroyables, l’organisation diminue drastiquement les réunions inutiles, notre croissance à deux chiffres limite le risque de compétition interne, et c’est génial d’utiliser le cloud par soi-même pour construire des solutions et des démonstrations. Make history : aujourd’hui, nous avons, chacun des “amazoniens”, le sentiment de mettre à disposition le meilleur de la technologie, qui devient accessible, à portée de quelques clics, de tout le monde, depuis le jeune étudiant qui veut expérimenter et découvrir jusqu’aux laboratoires de recherche les plus pointus qui ont à leur disposition une immense puissance de calcul à la demande. La technologie n’a d’intérêt que ce qu’elle permet de faire, et c’est au quotidien que nous nous réjouissons de permettre à nos clients de relever des défis qu’ils n’auraient pas pu relever autrement; le cloud change le cours de l’histoire de l’informatique.

Cet anniversaire est l’occasion pour moi de rendre public ce blog personnel, qui parle de mon aventure chez AWS qui m’enthousiasme chaque jour !

Mon rôle de “solutions architect” est d’expliquer à mes interlocuteurs comment utiliser le mieux possible la plateforme cloud d’Amazon Web Services, pour que la solution soit performante, moins coûteuse, sécurisée, évolutive, et simple à gérer pour le client. Parmi les nombreux arguments que nous utilisons régulièrement, nous mettons en avant la richesse de l’offre de services d’AWS, et sur le fait qu’au-delà de répondre à des besoins immédiats, choisir AWS signifie également faire le choix de briques de constructions variées, à l’état de l’art, avec régulièrement de nouveaux services. Dans ce cadre, j’aime bien employer l’image de la boîte de LEGO à partir de laquelle on construit son système d’information. On peut aussi poursuivre un peu cette métaphore.

Un ensemble de services adaptés à tous les besoins

Les briques de construction d’AWS sont adaptées aussi bien pour des applications simples, ou pour des petits acteurs qui ont des moyens limités (le petit camion de gauche), que pour des applications complexes, avec des acteurs qui assemblent de nombreuses briques pour atteindre leurs objectifs. Tout le monde peut profiter de la qualité, de la performance de chacune des briques, quel que soit l’enjeu. C’est ainsi qu’on trouvera, parmi nos clients, des petites associations qui hébergent leur site internet via lightsail, ou des multinationales qui hébergent leurs systèmes d’information critiques. Tous bénéficient de la même qualité des briques de construction, pour des objectifs différents.

Choisir son cloud provider, ce n’est pas anodin !

Vous n’avez pas la même liberté, la même facilité et vous n’atteignez pas le même résultat si vous fabriquez votre camion avec des LEGO, des MECCANO ou des KAPLA. Choisir son cloud provider, c’est choisir l’ensemble de briques avec lesquelles vous voulez construire votre système d’information, le choix est donc structurant sur la diversité des éléments, sur la façon d’assembler les éléments, sur la solidité et la performance du montage final.

Le multicloud, ça peut être bancal !

Mélanger des LEGO et des MECCANO, c’est possible, mais ce n’est pas simple, c’est contraignant pour assembler les pièces, et le résultat n’est pas très satisfaisant. De la même manière, monter des architectures basées sur plusieurs fournisseurs du cloud, c’est possible. Mais c’est compliqué, contraignant, et gare à ne pas faire n’importe quoi, à défaut de quoi le système construit ne fonctionnera pas bien. L’idée complémentaire, c’est que les services d’un fournisseur et d’un autre ne sont pas superposables, et se limiter à ceux qui sont similaires et compatibles ne permet pas de faire énormément de choses. Bref, faire le choix du multi-cloud, c’est ajouter une contrainte supplémentaire là où en réalité l’idée initiale, c’est de libérer la capacité d’innovation et libérer les contraintes.

Si vous avez d’autres idées pour poursuivre cette analogie des services AWS et des briques de construction, n’hésitez pas à les partager avec moi !

PS : Merci à mes enfants qui m’ont gentiment prêté leurs jouets, même s’ils se demandent encore ce que je peux bien faire avec les photos que j’ai prises…