27 mars 2021

Le cloud, seulement du marketing ?

A la suite du récent incident chez OVH, de nombreuses personnes ont accusé "le cloud", notamment sur les réseaux sociaux. Le cloud ne serait qu’un argument marketing et n’aurait aucune autre réalité. Qu’en est-il vraiment ?

Le méchant cloud

Cet article n’est pas là pour discuter de l’aspect vous êtes responsable de vos sauvegardes ou encore lisez les contrats de votre hébergeur, certains l’ont déjà fait (comme cet article de Teddy Ferdinand), mais d’un autre sujet qui revient à chaque panne chez un hébergeur.

En cas de problèmes chez un cloud provider, on a un certain nombre d’individus qui sortent du bois pour critiquer le cloud. Voici les arguments que l’on voit principalement:

  • Le cloud, ce n’est que du marketing, il n’y a rien derrière.

  • Le cloud, ce n’est pas fiable.

Le cloud, que du marketing ?

C’est une critique que l’on voit beaucoup. Le cloud ne serait qu’un outil permettant de vendre des choses qui existaient déjà. Il est vrai que certaines entreprises peuvent essayer de surfer sur la vague et de mettre le mot "Cloud" partout. Mais dire "Le cloud ça n’existe pas" en parlant des fournisseurs d’infrastructures (PaaS, IaaS…​ je ne ferai pas la distinction dans cet article) est incompréhensible.

Je vois souvent ce discours dans la bouche de personnes ayant une certaine expérience de l’informatique et qui n’ont pas suivi (et compris) l’apparition du Cloud. Le mécanisme traditionnel "je ne comprends pas donc je critique" apparaît très vite. Vous voyez les vieux du village critiquant Internet, les téléphones portables, ou la technologie en général ? C’est exactement ça.

Etait-il possible avant le Cloud de piloter de l’infrastructure 100 % via API, le tout géré par de l’outillage permettant un travail collaboratif (via Git par exemple) ?
De pouvoir provisionner des centaines de machines virtuelles, en gérant leurs templates, en les connectant via des réseaux privés, d’en rajouter ou en enlever à la demande, de réaliser des snapshots et restorations, de démarrer des load balancers devant…​ le tout en quelques commandes shell et en quelques minutes ?
De créer des bases de données en quelques secondes, de démarrer des solutions d’orchestration, de métriques, de gestion des logs…​ Très facilement ?
Et surtout, de permettre à de petites équipes de gérer des infrastructures composées de dizaines ou centaines d’applications, de centaines ou milliers de machines, de manière très flexible ?

Le dernier point est le plus important. Le cloud, en amenant sa flexibilité et sa tarification à l’usage, aide les équipes dev et ops à construire des infrastructures répondant à leurs besoins sans avoir à gérer eux même un grand nombre de problèmes (gestion du matériel physique en datacenter notamment).
Et comme dit précédemment, c’est l’automatisation des tâches et le contrôle de l’infrastructure via API (et l’outillage) qui permet également cela.

Est ce que tout cela est magique et ne demande aucune connaissance pour être utilisé ? Non. Des connaissances en système et réseaux, en architecture (que ce soit logicielle ou au niveau de l’infrastructure du SI) sont toujours obligatoires.
Est ce que des gens utilisent mal le cloud ? Probablement. Mais des gens qui faisaient n’importe quoi, ça n’existait donc pas avant le cloud ?

Je comprends également tout à fait les gens préférant gérer eux même de l’infrastructure physique. Cela peut complètement se justifier, et cela peut même être très intéressant financièrement pour certains besoins.

Mais au bout d’un moment, les critiques à base de "Olol le cloud, moi avec mes 2 machines dans mon salon, mon Nagios et 3 scripts shell je fais pareil" sont assez pénibles (surtout venant de gens qui n’ont aucune idée de quoi ils parlent).

Le cloud n’est pas fiable

Quel que soit le Cloud Provider, lorsqu’il y a une panne, on voit les traditionnels messages du type "le Cloud n’est pas fiable" apparaître.

Tout d’abord, personne n’a jamais dit que les cloud providers étaient 100 % fiables. Les cloud providers gèrent du matériel physique (et donc les pannes associées) et beaucoup de logiciels (car c’est des programmes qui vont piloter l’infrastructure), les problèmes réseaux arrivent…​ le 100 % d’uptime n’existe pas, et c’est (comme partout) à l’utilisateur de prendre ses dispositions pour limiter l’impact d’une panne. Et on voit aussi que de très gros incidents peuvent malheureusement arriver.

Ensuite, c’est facile de critiquer le Cloud, mais les pannes n’existaient pas avant ? Un rack de serveur dans un datacenter est subitement plus fiable si c’est vous qui le gérez et pas le cloud provider ?

Et pour avoir travaillé dans une boîte où l’infra était gérée dans des datacenters en interne (sauf quelques uns qui étaient sous les bureaux, je me rappelle qu’une fois que quelqu’un a fait le tour de tous les étages pour trouver un serveur physique essentiel qui répondait plus et qui était "perdu", plus personne ne savait où il était posé), je peux vous dire que les équipes n’attendaient qu’une chose: passer sur le Cloud.

Tags: devops cloud

Add a comment








If you have a bug/issue with the commenting system, please send me an email (my email is in the "About" section).

Top of page