Vjom - Fotolia

La dépendance à un seul Cloud : un risque à coûts multiples

Assurer « la neutralité du Cloud » est primordiale. L'une des personnalités les plus en vue d'Internet a souligné à quel point il était important de ne pas se lier à un unique fournisseur. Tentation à laquelle il est facile de succomber.

Dans une déclaration récente, Snap, créateur de Snapchat, a ainsi révélé qu'il allait débourser un milliard de dollars sur cinq ans pour utiliser Amazon Web Services et qu'il envisageait par la suite de construire sa propre infrastructure.

Cet accord permettra d'assurer un « soutien d'infrastructure redondante pour nos activités commerciales », a expliqué Snap dans une déclaration modifiée d'enregistrement S-1 au registre des sociétés. La première déclaration S-1 de Snap avait fait beaucoup parler d'elle, en révélant notamment le degré de dépendance de Snap à Google Cloud.

Dans ces deux déclarations, Snap a reconnu s'appuyer sur Google Cloud pour « l'essentiel » de ses « besoins de calcul, stockage, bande passante et autres services » et a estimé que « toute perturbation ou interférence avec notre utilisation de Google Cloud aurait un impact négatif sur nos activités ». Snap prévoit de dépenser deux milliards de dollars dans Google Cloud sur cinq ans.

D'ici 2020, les consommateurs de cloud remarqueront que leurs factures seront supérieures à ce que leur aurait coûté une gestion interne
Gary Bloom, CEO MarkLogic

Mais le plus effrayant est à venir. « Toute transition des services cloud actuellement assurés par Google vers un autre fournisseur de cloud serait difficile à mettre en œuvre et pourrait entraîner un temps et des dépenses considérables », explique Snap. Il met aussi en garde : « si nos utilisateurs ou nos partenaires ne parviennent pas à accéder à Snapchat par le biais de Google Cloud ou rencontrent des difficultés à le faire, nous risquons de perdre ces utilisateurs, des partenaires ou des revenus publicitaires ».

Des risques conséquents

L'énorme risque pris par Snap en délégant l'essentiel de ses services cloud à un seul et unique fournisseur ne fait aucun doute.

Comme l'a fait remarquer récemment The Information, Snap est « la plus grande entreprise de services Internet aux consommateurs à s'être entièrement développée sur une infrastructure de Cloud computing qui ne lui appartient pas ». The Information a également relevé que « Google offrait à Snap de fortes remises et autres avantages. »

Mais même si les remises sont tentantes, la dépendance envers un seul cloud représente un risque pour les activités et la santé économique de Snap.

En faisant part de son intention de construire sa propre infrastructure, Snap envoie une mise en garde à ses fournisseurs de cloud. Mais cette mise en garde n'a de poids que si Snap peut rapidement et facilement transférer ses activités informatiques d'un fournisseur cloud à un autre, ou s'il peut se reposer sur sa propre infrastructure. Snap devra assurer la neutralité du cloud dans sa construction, dans ses choix et dans l'exécution de ses systèmes, et il devra faire de cette neutralité un attribut essentiel de ses devops quotidiens s'il veut préserver cette stratégie et en tirer les avantages.

Des risques multiples

Ce n'est pas le seul risque. D'ici 2020, toutes les entreprises utiliseront le cloud d'une manière ou d'une autre.

Les fournisseurs de cloud, avec à leur tête Amazon Web Services, Microsoft et Google, voudront exécuter et gérer la capacité de leurs clients et peut-être même leur proposer des remises par volume.

Vu d'ici, ce cas de figure peut paraître avantageux. Pour bon nombre d'entreprises, le cloud est avant tout utilisé pour les services de base, tels que le stockage et les calculs flexibles. L'architecture sous-jacente, qui fonctionne dans n'importe quel environnement cloud, est standardisée autour du matériel Intel et Linux.

En fait la dépendance débute lorsque vous adoptez les services logiciels et la couche applicative de la pile logicielle.

Les fournisseurs de cloud proposent des API propriétaires qui réduisent le volume de code ou les tâches nécessaires au déploiement des applications. En utilisant ces API propriétaires, vous vous retrouvez dépendant de l'écosystème du fournisseur. Le transfert des services vers un autre fournisseur de cloud ou leur réintégration dans l'entreprise entraîne, comme le souligne Snap : « un temps et des dépenses considérables ».

Un piège discret

Les entreprises ne se rendent peut-être même pas compte du piège dans lequel elles tombent. La quasi-totalité des applications créées reposent sur une base de données. Quiconque programme un logiciel pour la base de données DynamoDB d'Amazon se retrouve dépendant d'AWS comme fournisseur de cloud. Les logiciels programmés pour DynamoDB ne peuvent pas être déplacés vers un autre fournisseur de cloud ou réintégrés à moins d'être reprogrammés, ce qui représente un coût important en termes de temps et d'argent.

Les entreprises ne se rendent peut-être même pas compte du piège dans lequel elles tombent
Gary Bloom, CEO MarkLogic

Outre le facteur du temps et de l'argent nécessaires au transfert des services Google Cloud vers un autre fournisseur, Snap explique avoir construit ses systèmes logiciels et de calculs pour pouvoir utiliser des services « fournis par Google, dont il n'existe pour certains aucune alternative sur le marché ».

Ce commentaire soulève une autre question : l'achat de services AWS suffit-il à atténuer les risques d'une dépendance envers un seul cloud ? La réponse est non s'il faut réécrire les applications et changer les devops pour parvenir à une neutralité cloud.

L'histoire se répète

Les entreprises se sont déjà retrouvées malheureusement prises au piège par le passé, en choisissant de sous-traiter leurs opérations informatiques à des fournisseurs tels que IBM et EDS. Elles pensaient que des « experts » pourraient gérer plus efficacement et de manière plus rentable leurs opérations informatiques et leurs centres de données. Au début, les chiffres semblaient encourageants. Puis elles ont vu les prix des contrats sur trois et cinq ans grimper à mesure que les sous-traitants normalisaient leurs dépenses et augmentaient leurs marges.

Ces sous-traitants n'avaient bien sûr pas l'intention de rester indéfiniment déficitaires. Le travail sous-traité a fini par coûter plus cher aux entreprises que si elles l'avaient gardé en interne. Mais elles n'étaient plus en mesure d'en reprendre le contrôle puisque toutes les personnes compétentes travaillaient désormais pour les sous-traitants, ou elles ne disposaient plus de leur propre infrastructure de centres de données.

Conclusion

Les entreprises doivent absolument éviter de se retrouver dépendantes d'un cloud, de manière à pouvoir :

- négocier les prix. Nous avons vu les tarifs de la sous-traitance informatique augmenter à mesure que les fournisseurs accroissaient leurs marges et il en sera de même pour le cloud. D'ici 2020, la plupart des consommateurs de cloud remarqueront que leurs factures de Cloud computing seront supérieures à ce que leur aurait coûté une gestion interne. Leur capacité à pouvoir faire marcher la concurrence sera cruciale.

- choisir les gagnants. Nous en sommes aux balbutiements de cette transition cloud, qui, selon 451 Research, « représente la plus grande opportunité informatique depuis des dizaines d'années ». Il est trop tôt pour savoir quelles entreprises tireront leur épingle du jeu. AWS fait peut-être figure de leader actuellement, mais Microsoft a fait des progrès remarquables. Qui sait quelles innovations et améliorations les autres entreprises nous réservent ? Dans trois à cinq ans, différents clouds seront spécialisés dans différents secteurs. Et vous aurez à cœur de choisir celui qui vous conviendra le mieux.

- être dans une position plus sûre. Personne n'est jamais totalement à l'abri des cyber-attaques. En cas de vulnérabilité d'un fournisseur de cloud, vous devrez peut-être en changer rapidement. La « neutralité cloud » est un gage d'assurance.

Bref, comme l'a révélé Snap, la neutralité cloud doit constituer l'une des priorités initiales, à mesure que le marché des services cloud évolue.

Lire aussi : Le Grand Guide du Cloud hybride et du Multi-cloud

Cloud Hybride, Multi-Cloud, APIs : comment bien administrer une architecture IT hétérogène

Pour approfondir sur Administration et supervision du Cloud

Close