Récemment, Sarah Wang et Martin Casado, investisseurs associés d'Andreesen Horowitz, ont affirmé que le passage au cloud avait un impact négatif sur les marges bénéficiaires et pouvait coûter aux entreprises cotées jusqu'à 100 milliards de dollars de capitalisation boursière collective. Cette affirmation audacieuse et controversée, est aussi erronée. Ou, pour le dire plus poliment et plus précisément, pointer sur la réduction des coûts est peut-être la bonne réponse à une mauvaise question.
Corey Quinn, analyste chez Duckbill Group, n’est pas d’accord avec ce point de vue. Selon lui, « l'optimisation des coûts passe toujours après l’accélération de la mise sur le marché de nouvelles fonctionnalités auprès des clients ». Pas occasionnellement. Pas souvent. Mais toujours. « Fondamentalement, les entreprises qui se concentrent davantage sur l'optimisation/la réduction des coûts que sur la croissance sont souvent des entreprises en déclin », a ajouté M. Quinn. En d'autres termes, la bonne question n'est pas de choisir entre « le cloud et le on-premise ». L’IT en entreprise est trop compliquée pour se satisfaire de réponses faciles à des questions binaires de ce type. La bonne question est de savoir « quelle approche (parmi celles-ci ou d'autres) permet à une entreprise de disposer d’une capacité d'investissement optimale pour favoriser la croissance ».
Le rêve du rapatriement des workload
Sarah Wang et Martin Casado travaillent pour l'une des sociétés d'investissement les plus prospères au monde. Leur mission consiste à aider les entreprises à se développer, puis à en tirer profit quand elles font leur entrée en bourse ou quand elles sont rachetées. Les deux investisseurs ont beaucoup réfléchi à leur théorie que l’on peut résumer ainsi : « Si le cloud tient clairement ses promesses dans les premiers temps, la pression qu'il exerce sur les marges peut commencer à l'emporter sur les avantages à mesure que l’entreprise se développe et que sa croissance ralentit ».
En conséquence, ils avancent que le cloud coûte aux entreprises cotées jusqu'à 100 milliards de dollars en valorisation boursière. C'est beaucoup d'argent. Ils suggèrent aux startups d’intégrer dès le départ l'option du rapatriement dans leur architecture. Les entreprises devraient, selon eux, concevoir leur infrastructure de manière à faciliter le « rapatriement » des charges de travail du cloud vers les datacenters sur site quand le coût de cette opération est justifié.
Sauf que cette belle idée est totalement irréalisable. L’IT d'entreprise ne fonctionne tout simplement pas comme ça dans le monde réel. Personne ne déplace les charges de travail vers le cloud sur un coup de tête, et personne ne les déplace à nouveau sur un autre coup de tête. Il y a toutes sortes d'inerties qui compliquent ces transferts, y compris la technologie pour le faire. Et non, Kubernetes n'est pas la panacée pour déplacer comme par magie les charges de travail entre les clouds ou entre un datacenter privé et un cloud, ce que j'ai déjà souligné auparavant. C'est l'une des raisons pour lesquelles le cloud, malgré son importance, ne représente encore que cinq à six pour cent des dépenses IT mondiales.
Á ceux qui pourraient me dire que « Dropbox l'a fait », je réponds que Dropbox n'est pas un modèle que peuvent suivre la plupart des entreprises. L’éditeur a déplacé une application de niche vers son datacenter privé avec un type de ressources dont ne dispose pratiquement aucune autre entreprise. Ce n'est pas un exemple à suivre en matière de rapatriement des charges de travail. Il y a aussi un autre problème que souligne Corey Quinn : « En construisant une architecture pour un exode théorique, l’entreprise paye l'avantage de l’optionalité en se privant de la vélocité des fonctionnalités et réduit ses chances d'arriver à une situation où les coûts du cloud ont un impact significatif sur le succès global de l’entreprise ». Mais, ce n'est pas tout !
Ne pas négliger le coût humain
Subbu Allamaraju dirige les équipes qui développent les produits de recherche d'Expedia. Le premier problème qu'il soulève par rapport à l’affirmation de Sarah Wang et Martin Casado concerne Kubernetes et la critique que j'ai mentionnée plus haut : « Aucune technologie ne peut faciliter le rapatriement des workload. La référence à Kubernetes est un mensonge que nous nous racontons à nous-mêmes ». Subbu Allamaraju ne dit pas que Kubernetes n'a pas de valeur, loin de là. Il conteste l'idée selon laquelle Kubernetes rend toutes les applications fongibles entre les environnements opérationnels. C’est une condamnation sévère de ce qu’affirment Sarah Wang et Martin Casado. Mais celui-ci va plus loin. Selon lui, le problème le plus important est celui des personnes. « Les entreprises qui opèrent avec succès (grande agilité et coûts gérables) sur site doivent mobiliser certains de leurs meilleurs talents d'ingénierie pendant trois à cinq ans, et plus, pour faire mûrir l'architecture et l'ingénierie de leur infrastructure de base. Très peu d'entreprises peuvent se permettre cela », a-t-il affirmé.
Et même si votre entreprise peut se le permettre, est-ce vraiment ce que vous souhaiteriez ? Après tout, Zack Kanter, cofondateur et CEO de Stedi, affirme que reconstruire le cloud pour économiser de l'argent revient à accepter « le coût culturel (dévastateur à long terme) du recrutement d'ingénieurs de classe mondiale pour mener des tâches lourdes indifférenciés ». Zack Kanter et Corey Quinn font remarquer que « même si une entreprise parvient à disposer d’ingénieurs pour mettre en place des services cloud de base (calcul, stockage, etc.), elle passe complètement à côté de l'intérêt du cloud ». La véritable valeur d’une construction sur un cloud public réside dans les services de niveau supérieur, et pas nécessairement dans les éléments de base. Si une entreprise passe des années à reproduire ces services de niveau inférieur, elle finit par perdre les éléments de niveau supérieur. M. Allamaraju termine en appuyant ce que M. Quinn a déclaré plus haut : « Pour réussir à l'échelle dans une architecture hybride et maximiser la valeur client, la rentabilité et l'agilité, il faut prendre en amont beaucoup de décisions techniques, humaines et de processus, plusieurs années avant que cela ne soit nécessaire. Et même si l’entreprise peut se le permettre, elle a peu de chances de prendre correctement ces décisions ».
C'est une bonne idée de prévoir son infrastructure une décennie à l'avance afin d'intégrer des options à long terme. Mais c'est aussi une chimère. Oui, il y a des choses que l’on peut et doit faire pour préserver l'agilité de l’architecture. Mais l'approche recommandée par Sarah Wang et Martin Casado coûte trop cher pour un gain trop faible.