VIII. Adopter le nuage

Certains informaticiens se consolent encore en voyant des lumières clignotantes dans le placard à balais.

C'est pourquoi l'adoption du nuage va encore à l'encontre des accords contractuels standard. À vrai dire, ces informaticiens n'ont pas tort. Vous confiez vos données à une entreprise sans visage. Vous ne pouvez pas voir où elles se trouvent. Vous ne pouvez pas être certain qu'elle ne les partage pas avec la CIA. Parfois, toutes ces abstractions fantaisistes ont des fuites et quelque chose ne va pas. Et quand c'est le cas, il n'y a plus rien à frapper avec votre clé à molette. La manie du contrôle est un attribut inhabituellement bienvenu chez un administrateur système, et le nuage lui enlève le contrôle.

Lorsque nous parlons d'adopter pleinement le nuage, il arrive souvent que l'informaticien classique ne sache pas très bien ce que cela signifie. Il a adopté la virtualisation des serveurs depuis un certain temps, mais il n'est peut-être pas à l'aise avec l'idée que ces serveurs virtuels sont des clones éphémères. Comme le personnage de Sam Bell dans Moon, leur disque dur pourrait être effacé à tout moment, et cela ne devrait pas avoir d'importance, car le clone suivant est toujours prêt à sortir. 

Désormais, les conteneurs de notre batterie de serveurs virtuels portent des noms tels que 050487d5cab85820e. Il est plus difficile de s'y attacher de cette manière.

La première règle de l'élevage est de ne pas donner de nom aux animaux. C'est pourquoi nous avons abandonné depuis longtemps les systèmes de dénomination des serveurs. Aujourd'hui, les conteneurs de notre ferme de serveurs virtuels portent des noms tels que 050487d5cab85820e. Il est plus difficile de s'y attacher.

C'est ce que signifie l'adoption totale de l'informatique dématérialisée. Il ne s'agit pas simplement d'exploiter quelques serveurs virtuels. Cela signifie qu'il faut développer des applications apatrides à échelle horizontale, qui peuvent être installées, démarrées et supprimées dans le cadre d'une chorale orchestrée de serveurs. Cela signifie qu'il faut conserver les actifs statiques en dehors de l'application principale. Cela signifie qu'il faut faire confiance aux services à la demande pour les bases de données, les caches, le routage et le stockage. Quelque part, sous tout cela, il y a des serveurs, mais vous ne connaîtrez jamais leurs noms. Ils disparaissent dans une mer électrique d'"infrastructures". Bientôt, il n'y aura plus que du code, et des services comme AWS Lambda et Google AppEngine nous poussent encore plus loin dans cette direction. Ce qui est une bonne chose.

Les serveurs disparaissent dans une mer électrique d'infrastructures.

Et il arrive que les choses tournent mal. Les fournisseurs de services en nuage ont beau parler de redondance et de suppression des points de défaillance uniques, en fin de compte, c'est impossible. Seuls les naïfs croient que les services distribués à basculement, à zones multiples et à base de données en grappe sont vraiment sans faille. Les systèmes mêmes qui coordonnent la redondance deviennent des points de défaillance uniques. C'est comme une loi physique immuable qui veut que l'élimination des défauts architecturaux en introduise d'autres, plus complexes.

Et pourtant. Si l'on considère le temps de fonctionnement du système, les avantages en termes de commodité et le niveau d'expertise sous-jacent à l'infrastructure, le tout devant être acheté par cycle de processeur, c'est toujours mieux que de compter sur ce serveur dans l'armoire. De plus, l'informaticien qui cherche à tout contrôler a généralement un énorme angle mort qui couvre le point de défaillance unique le plus risqué du système : Lui-même.

Lecture obligatoire :

• Moon 2009 drame de science-fiction réalisé par Duncan Jones et écrit par Duncan Jones et Nathan Parker
• Principe d'apatridie des services principe de conception appliqué pour concevoir des services évolutifs
• La loi des abstractions fuyantes

Le mois prochain : Cachez d'abord (posez des questions plus tard)