Lorsqu’il s’agit d’entreprises roulant leurs propres puces personnalisées, notre thèse principale est que faire cela pour économiser quelques dollars sur les puces est au mieux rentable. Au lieu de cela, les entreprises veulent construire leurs propres puces lorsqu’elles transmettent une certaine forme d’avantage stratégique.

L’exemple classique est Apple, qui lie ses puces à son propre logiciel pour différencier de manière significative leurs téléphones et leurs ordinateurs. Ou Google, qui personnalise les puces pour leurs charges de travail les plus intenses comme les algorithmes de recherche et l’encodage vidéo. Quelques centaines de millions de dollars de coûts de conception de puces sont plus que payés en milliards de ventes supplémentaires pour Apple ou en milliards de dépenses en capital et en économies sur les dépenses d’exploitation pour Google. Il est important de souligner que dans ces deux cas, la société contrôle entièrement le logiciel exécuté sur ses puces locales.

Note de l’éditeur:
Auteur invité Jonathan Goldberg est le fondateur de D2D Advisory, un cabinet de conseil multifonctionnel. Jonathan a développé des stratégies de croissance et des alliances pour des entreprises des secteurs de la téléphonie mobile, des réseaux, des jeux et des logiciels.

Alors, qu’y a-t-il pour Amazon?

Pour Amazon, et plus précisément pour AWS, le contrôle des logiciels les dépasse. AWS exécute le logiciel de tout le monde et donc, par définition, AWS ne peut pas le contrôler. Ils doivent exécuter presque littéralement toutes les formes de logiciels dans le monde. Néanmoins, AWS semble travailler très dur pour pousser ses clients à exécuter des charges de travail sur leurs processeurs Graviton. AWS propose de nombreuses façons de verrouiller les clients, mais le silicium n’en fait pas partie. Au moins pas encore.

AWS ne fait probablement pas cela pour économiser de l’argent sur les processeurs AMD et Intel x86 qu’ils achètent. Le fait qu’ils n’aient que deux fournisseurs signifie qu’ils disposent d’une large marge de manœuvre en matière de tarification. Dans une certaine mesure, Graviton peut être une protection contre le jour où Intel cessera d’être compétitif en x86. (Un point que nous avons peut-être déjà atteint.)

Cela étant dit, nous pensons qu’il y a une raison plus importante : le pouvoir. Aujourd’hui, la principale contrainte dans la construction de centres de données est l’électricité. Les centres de données consomment beaucoup d’énergie et, lors de la conception de nouveaux centres, les entreprises doivent respecter un budget énergétique. Imaginez maintenant qu’ils pourraient réduire la consommation d’énergie de 20 %, ce qui signifie qu’ils pourraient ajouter plus d’équipements dans la même empreinte électrique, ce qui signifie plus de revenus. Une réduction de la consommation d’énergie d’une partie du système signifie un retour beaucoup plus élevé sur l’investissement global. Multipliez ensuite ce gain par 38 à mesure que les économies se répandent dans tous les centres mondiaux de données d’AWS.

Maintenant, bien sûr, le calcul est un peu plus compliqué que cela. Les processeurs ne sont qu’une partie d’un système, donc même si Graviton est 20 % plus économe en énergie pour les mêmes performances par rapport à une puce x86, cela ne se traduit pas vraiment par 20 % de profit en plus du centre de données, mais l’échelle est à peu près correcte. Le passage à un processeur Arm conçu en interne peut générer une augmentation suffisante de la capacité du centre de données pour plus que compenser le coût de conception de la puce.

Pour aller plus loin, un obstacle majeur qui empêche davantage d’entreprises de passer aux charges de travail Arm est le coût d’optimisation de leur logiciel pour un nouveau jeu d’instructions. Nous avons touché à ce sujet précédent, le portage d’un logiciel peut demander beaucoup de travail. AWS est fortement incité à inciter ses clients à changer de fournisseur et semble faire ce qu’il peut pour faciliter ce processus. Cependant, nous devons nous demander s’il ne s’agit pas d’une rue à sens unique.

Une fois que les clients sont passés à Graviton, cela ne fait que déplacer la friction. Comme nous l’avons dit plus haut, aujourd’hui, AWS ne peut pas utiliser le silicium x86 pour verrouiller ses clients dans son service, mais une fois que les clients passent à Graviton, toute cette friction d’optimisation se déplace en faveur d’AWS, créant une nouvelle forme de verrouillage. Certes, la barrière aujourd’hui existe entre Arm et x86, pas parmi les différentes versions des serveurs Arm. Mais l’une des beautés de travailler avec Arm est la possibilité de semi-personnaliser une puce, et il est donc tout à fait possible qu’AWS puisse introduire des fonctionnalités propriétaires dans les futures versions de Graviton.

Nous pensons qu’Amazon a de nombreuses autres bonnes raisons d’encourager le passage à son processeur Graviton basé sur Arm, mais nous devons nous demander si ce verrouillage ne persiste pas quelque part au fond de leur cerveau. Si c’est vrai, cela donne simplement aux autres hyperscalers plus de raisons de passer également aux serveurs Arm.