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.