Certains informaticiens trouvent encore du réconfort dans le clignotement des voyants du serveur planqué sous l’escalier.

C’est pourquoi adopter le cloud va encore à l’encontre des contrats standard. À vrai dire, ces informaticiens n’ont pas tout à fait tort. Vous confiez vos données à une corporation anonyme. Vous ne savez pas où elles se trouvent. Vous ne pouvez pas être certain qu’elles ne sont pas partagées avec la CIA. Parfois, toute cette belle abstraction se fissure, et quelque chose tourne mal. Et quand ça arrive, il n’y a plus rien sur quoi taper avec sa clé à molette. Le besoin de tout contrôler est une qualité inhabituellement bienvenue chez un SysAdmin — et le cloud confisque ce contrôle.

Quand on parle d’adopter pleinement le cloud, votre informaticien type ne saisit souvent pas vraiment ce que ça implique. La virtualisation de serveurs, il connaît depuis longtemps — mais l’idée que ces serveurs virtuels sont des clones éphémères, ça le met moins à l’aise. Comme le personnage de Sam Bell dans Moon, leur disque peut être effacé à n’importe quel moment, et ça ne devrait pas avoir d’importance, parce que le clone suivant est toujours prêt à prendre le relais.

Aujourd’hui, les conteneurs de notre ferme de serveurs virtuels portent des noms comme 050487d5cab85820e. Difficile de s’y attacher.

La première règle de l’élevage, c’est de ne pas donner de prénoms aux animaux. C’est pourquoi nous avons abandonné les schémas de nommage des serveurs il y a bien longtemps. Aujourd’hui, les conteneurs de notre ferme de serveurs virtuels portent des noms comme 050487d5cab85820e. Difficile de s’y attacher.

C’est ça, adopter pleinement le cloud. Ce n’est pas simplement faire tourner quelques serveurs virtuels. C’est développer des applications sans état, à mise à l’échelle horizontale, que l’on peut installer, démarrer et supprimer au sein d’un orchestre de serveurs coordonnés. C’est garder vos ressources statiques en dehors de votre application principale. C’est faire confiance à des services à la demande pour les bases de données, les caches, le routage et le stockage. Quelque part, en dessous de tout ça, il y a des serveurs — mais vous ne connaîtrez jamais leurs noms. Ils se dissolvent dans une mer électrique d’« infrastructure ». Bientôt, il n’y aura plus que du code : des services comme AWS Lambda et Google AppEngine nous poussent déjà dans cette direction. Ce qui est une bonne chose.

Les serveurs se dissolvent dans une mer électrique d’infrastructure.

Et parfois, ça va mal tourner. Les fournisseurs cloud ont beau parler de redondance et d’élimination des points de défaillance uniques, c’est en définitive impossible. Seuls les naïfs croient que les services distribués, avec basculement automatique, multi-zones et bases de données en cluster, sont vraiment sans faille. Les systèmes chargés de coordonner la redondance deviennent eux-mêmes des points de défaillance uniques. C’est comme une loi immuable de la physique : éliminer les failles architecturales, c’est en introduire de nouvelles, plus complexes.

Cloud

Cela dit. Quand on regarde la disponibilité globale du système, qu’on pèse les avantages en termes de commodité, et qu’on considère le niveau d’expertise qui sous-tend l’infrastructure — le tout facturé au cycle processeur — c’est encore mieux que de miser sur ce serveur dans le placard. Et de toute façon, l’informaticien qui cherche à tout contrôler a généralement un énorme angle mort couvrant le point de défaillance unique le plus risqué du système : lui-même.

Lectures recommandées :

Le mois prochain : Cache d’abord (les questions après)