Voyez en grand
Faites mieux avec moins
“Here's One I Made Earlier” est la formule de détresse des programmes télévisés lorsqu'ils sont confrontés à l'éventualité d'un problème. Les démonstrations sont toujours risquées. Dans le cas de ce livre, c'est doublement le cas. J’aimerais vous faire participer à une mise en pratique, hélas, je ne suis même pas là pour corriger les choses si vous allez de travers. Afin de minimiser les risques d’erreur, avant d'aborder les scénarios (chapitres 13 et 14), je vais aborder certains aspects de la cartographie de manière plus détaillée. C'est un peu méchant, car les idées étant fraîches dans votre esprit, elles risquent de créer un biais de lecture. C’est exactement ce que j'espère. J'indique la réponse avant même que nous n'y soyons parvenus. C'est le moyen le plus proche que j'ai trouvé pour dire “En voici un que j'ai fait plus tôt” sans écrire d'abord la réponse.
Toutefois, pour rendre l'exercice encore plus stimulant, j'ai pris la liberté de parsemer de nombreux concepts utiles, mais pas directement pertinents, dans une panoplie de concepts légèrement utiles. Les concepts que nous examinerons portent sur l'opportunité du changement, le problème des contrats, les mensonges courants que nous nous racontons à nous-mêmes et la manière de maîtriser la stratégie.
Les activités, les pratiques, les données et les connaissances évoluent et coévoluent dans un processus qui n'est pas toujours fluide ou continu. Au chapitre 10, nous avons abordé le cycle de la paix, de la guerre et de l'émerveillement et la manière dont les anciens géants qui se trouvaient dans une phase de concurrence pacifique peuvent être dépassés par de nouveaux venus dans la “guerre”. Ces nouveaux venus sont susceptibles de s'installer pour devenir les titans du secteur. L'aspect le plus intéressant de ce cycle réside dans le changement (point 1 de la figure 133) entre les deux états de paix et de guerre, et c'est sur ce point que nous nous concentrerons.
Alors que l'acte (par exemple, l'informatique) peut être bien compris, cette transition (par exemple, l'informatique qui passe de produits tels que les serveurs à des services d'utilité publique tels que le cloud) provoque une grande confusion parce que la nature de l'acte change — nous passons d'un monde de différenciation constante des fonctionnalités à un monde d'opérations en volume d'une qualité suffisante. Ce changement est aggravé par des pratiques coévolutives (telles que DevOps), notre inertie face à ce changement, la vitesse surprenante à laquelle il se produit et les intérêts particuliers qui répandent généralement toutes sortes de craintes, d'incertitudes et de doutes.
Figure 133 — Une époque de changement
Derrière la confusion, ce qui se passe fondamentalement, c'est la montée en puissance de nouvelles normes, l'optimisation de facto d'un marché et le passage aux commodités. Cela ne signifie pas qu'il n'existe pas d'alternatives, nous avons souvent une bataille sur les normes, par exemple AC contre DC dans les “guerres de l'électricité” ou VHS contre Betamax pour les normes d'enregistrement vidéo. C'est toutefois l'adoption par le marché et les effets de réseau qui désigneront le vainqueur et relégueront les autres au créneau de l'histoire. Il est important de comprendre que dans les premiers temps, tout est à prendre.
Lorsque Amazon a lancé EC2 (son environnement de calcul utilitaire) en 2006, j'ai passé un certain nombre d'appels à des cadres d'entreprises de matériel informatique traditionnelles et leur ai proposé de les aider à mettre en place un service concurrent à l'aide de notre technologie Borg — une suite d'outils que nous avions utilisés pour fournir des machines virtuelles à la demande au sein de ma propre entreprise. J'étais persuadé que nous pouvions facilement émuler les API d'Amazon et que, même si nous étions en retard dans certains domaines, nous avions une longueur d'avance dans d'autres. Dans l'ensemble, il n'y a eu aucun intérêt et les deux réunions que j'ai réussi à organiser se sont toujours terminées par le même résultat : “Comment cela va-t-il nous aider à vendre plus de serveurs ?”
J'aimerais dire qu'en 2008, l'attitude avait changé, mais ce n'était pas le cas. Fin 2008, lors du premier d'une longue série de voyages de ce type, je me suis rendu aux États-Unis. J’y ai rencontré un certain nombre de personnes dirigeantes. Je leur ai dit que toutes leurs activités dans le domaine des matériels informatiques seraient perdues. Bien-sûr, je leur ai montré comment, en créant un marché de clones d'AWS et en déclenchant une guerre des prix, ils pourraient exploiter une contrainte qu'Amazon aurait dans la construction de centres de données et l'utiliser pour fragmenter le marché en poussant la demande au-delà de l'offre. J'ai expliqué pourquoi ils ne le feraient pas en raison de l'inertie existante et pourquoi ils perdraient la guerre. Le manque d'intérêt n'était pas seulement palpable, il était dédaigneux. Amazon n'était pas considérée comme une menace, mais comme un vairon et seul un “fou” aurait pu penser autrement. Pour paraphraser ce qu'on m'a dit, ces entreprises “feraient quelque chose à l'avenir sur ce marché, créeraient leurs propres normes et éloigneraient ce secteur d'Amazon s'il devenait sérieux”, ce qu'elles m'ont assuré ne pas être le cas. À l'exception des mots actuels, le message était clairement “va-t'en mon garçon, laisse les adultes s'occuper de ce problème de manière responsable”. L'air était toujours chargé d'interminables pronostics sur leur propre grandeur future, ainsi que du vieux refrain “comment vos produits vont-ils vendre plus de serveurs ?”
À vrai dire, je me suis senti comme le vilain garçon qui montre l'empereur du doigt en disant “il n'est pas habillé”. C'était comme regarder des généraux en face et leur dire que ce n'était pas une bonne idée d'ordonner à des troupes de continuer à marcher vers le nord en franchissant une falaise, et recevoir une petite tape sur la tête ou un pincement de joues accompagné d'un rire bienveillant : “marcher vers le nord, c'est ce que nous faisons !”
Le problème de l'évolution dans les entreprises est que la menace est beaucoup plus grande que la plupart des personnes ne le pensent en raison de l'équilibre ponctuel et de la rapidité du changement. Vous pouvez soit créer un grand écosystème rapidement, ce qui signifie un effort très ciblé sur la création d'un marché fondé sur une certaine forme de normes ouvertes, soit coopter et éventuellement viser à posséder la norme. Ce que vous ne pouvez pas vous permettre, c'est de tergiverser, de vous reposer sur vos lauriers ou d'essayer de créer une autre solution de produit différenciée pour concurrencer l'évolution. Malheureusement, c'est exactement ce qui s'est passé. Les entreprises qui ont perdu la guerre du cloud avaient tous les avantages — elles avaient les finances, les compétences, le talent, la portée, la marque et tout ce que l'on peut souhaiter pour gagner. Elles étaient comme des généraux à la tête d'armées modernes et massives face à un David armé d'une fronde et d'un fusil à eau. Heureusement pour David, les généraux ont tous ordonné à leurs troupes de marcher vers le nord, de courir à leur perte par-delà de la falaise.
La guerre du cloud dans l'infrastructure a été perdue non pas en raison d'une quelconque capacité d'ingénierie magique d'Amazon, mais plutôt en raison de l'échec exécutif des géants du passé. Chacun d'entre eux aurait pu gagner la guerre facilement. Lorsqu'ils ont finalement agi, c'était trop tard, avec trop peu d'investissements et souvent dans la mauvaise direction en raison d'une préoccupation pour ce qu'ils voulaient (“vendre des serveurs”) et non pour ce dont leurs utilisateurs avaient besoin. Mais, les utilisateurs ont également fait preuve d'inertie face à ce changement et, dans un acte de désespoir quelque peu tragique, cette inertie a été mise à profit. Les géants du passé avaient trouvé leur moment Kodak.
Lorsque Kodak a finalement surmonté sa propre inertie face au passage aux images numériques, il a résolu le conflit avec son activité traditionnelle de traitement en promouvant l'idée de l'imprimante photo numérique. Il s'agissait de faire entrer l'impression de photos dans le monde numérique ! Le projet a échoué parce que les utilisateurs ont commencé à partager des images et ont contourné l'intérêt de la photo traditionnelle. Dans le monde du cloud, la même erreur tragique a été commise avec le cloud privé. Nous vous apporterons tous les avantages des opérations en volume avec des composants de base par l'intermédiaire d'un fournisseur utilitaire, mais en utilisant du matériel de type “entreprise” adapté à vos besoins et fonctionnant dans votre propre centre de données ! En d'autres termes, ils ont prévu d'introduire la “vente de serveurs” dans le monde des services utilitaires.
Il est certain que l'informatique dématérialisée a un certain mérite pour faire face à l'inertie (c'est-à-dire aux préoccupations souvent injustifiées en matière de sécurité), mais il s'agit au mieux d'une solution transitoire. Il s'agit d'une solution de courte durée et non d'une solution définitive. Hélas, même aujourd'hui, en 2017, certains affirment que l'avenir est un mélange hybride de nuages publics et privés. Ce n'est pas le cas, et ça ne l'a jamais été. L'avenir a toujours été un hybride de plusieurs clouds publics. Mais pourquoi plusieurs clouds publics ? La première préoccupation est la résilience, qui est résolue par ces pratiques coévolutives telles que les systèmes distribués et la conception pour la défaillance. Aujourd'hui, plusieurs clouds publics ne signifient pas nécessairement plusieurs fournisseurs de clouds publics. Vous pouvez utiliser plusieurs régions ou zones de disponibilité d'Amazon, ce qui constitue un modèle hybride. La décision d'utiliser plusieurs fournisseurs est un compromis entre le risque de défaillance d'un seul fournisseur, le coût du passage d'un fournisseur à l'autre et le pouvoir de négociation qu'il peut offrir.
Au sein de l'écosystème Amazon, le coût du passage d'une région à l'autre est faible, votre pouvoir de négociation est relativement faible, mais vous pouvez atténuer les risques en concevant des produits dans plusieurs zones. Pour beaucoup, c'est plus que suffisant. Lorsque vous devez aller plus loin et combiner plusieurs fournisseurs publics, vous subissez alors un coût de changement accru, non seulement en raison de tout mouvement de données, mais aussi de tout changement dans la compatibilité syntaxique ou sémantique des interfaces de programmation (API). La compatibilité syntaxique signifie simplement que les API ont la même structure et la même forme. La compatibilité sémantique signifie qu'elles fonctionnent de la même manière. Sans cette compatibilité, vos outils de gestion qui fonctionnent avec l'un peuvent ne pas fonctionner avec l'autre, ce qui entraîne un coût de transition.
Pour réduire ce coût, il faut soit de multiples fournisseurs de services d'utilité publique interopérables, soit des outils de gestion qui couvrent ces deux types de services. Les outils de gestion ne peuvent couvrir les deux qu'en offrant le plus petit dénominateur commun, c'est-à-dire les facteurs communs entre les deux. À moins de disposer d'un moyen d'assurer l'interopérabilité, le changement de fournisseur entraîne un coût supplémentaire au-delà du mouvement des données, soit par des coûts de transition, soit par la perte d'une fonctionnalité utile. Mais, le changement de fournisseur est toujours souhaitable en termes de pouvoir de négociation et de garantie d'une tarification concurrentielle sur un marché. Tels sont les compromis à étudier. Dans la pratique, ce n'est pas le cas. Il n'existe pas de marché interopérable et concurrentiel entre plusieurs fournisseurs. Il n'y a qu'un continent (Amazonie), quelques îles importantes et un grand nombre de petits atolls dont la plupart s'enfoncent rapidement dans la mer. Mais, il n'était pas nécessaire qu'il en soit ainsi, et il n'est pas nécessaire qu'il en reste ainsi.