10 ans de cloud, 10 enseignements à retenir

En dix ans, des centaines d’enseignements ont été tirés sur la meilleure façon de concevoir et gérer des services cloud. Voici quelques-unes de ces leçons.

Il y a 10 ans, le 14 mars 2006, le premier service de stockage dans le cloud naissait. Depuis cette date, des centaines d’enseignements ont été tirés sur la meilleure façon de concevoir et gérer des services cloud. Ces leçons  sont capitales car le cloud est aujourd’hui utilisé par des millions d’entreprises. Dans cet article vous verrez que ces 10 années d’expérience ont permis de développer une expertise précise en tirant les enseignements importants pour une amélioration permanente de l’utilisation des services cloud.

Voici donc quelques-unes de ces leçons dans l'espoir qu'elles puissent aussi vous être utiles.

1. Construire des systèmes évolutifs

Il n’est plus possible de mettre à jour les systèmes comme on le faisait traditionnellement auparavant, c’est-à-dire avec une interruption de service pour la maintenance. En effet, les entreprises du monde entier s’appuient sur le cloud pour sa disponibilité 24 heures sur 24 et 7 jours sur 7. Il a donc été nécessaire de créer une architecture dans laquelle il est possible d’intégrer de nouveaux composants logiciels sans interrompre le service. Pour illustrer ce besoin, Marvin Theimer, Ingénieur chez Amazon, a dit un jour que l’on pouvait comparer le développement du service Amazon S3 à un avion : c’était au début un monomoteur de type Cessna, qui avec le temps s’était transformé en Boeing 737, puis en groupe de Boeings 747, pour enfin devenir la flotte d’Airbus 380 qu’il est aujourd’hui. Le tout en se ravitaillant en plein vol et en faisant passer les clients d’un avion à l’autre, sans qu’ils ne s’en rendent compte.

2. Prévoir l’imprévisible

Nous le savons tous, des défaillances peuvent se produire et tout système finira par tomber en panne un jour ou l’autre : des routeurs aux disques durs, des systèmes d’exploitation aux unités de mémoire qui endommagent les protocoles TCP, des erreurs passagères aux erreurs permanentes… C’est un fait avéré, et cela que l’on utilise du matériel informatique de haute qualité ou des composants à plus faibles coûts.

C’est d’autant plus important lorsqu’on opère à grande échelle. Par exemple, certains services de stockage en ligne traitent des trillions et des trillions d’opérations de stockage, la probabilité qu’une erreur se produise devient alors une réalité. La plupart de ces scénarios de pannes peuvent être anticipés, mais beaucoup sont encore inconnus lors des phases de conception et de création.

Il a donc fallu bâtir des systèmes dans lesquels les pannes étaient considérées comme un phénomène naturel, et cela sans même en connaitre leur essence. Ce qui est primordial est, en effet, que les systèmes continuent de fonctionner, même si « la maison est en feu ». Il faut pouvoir  intervenir de manière spécifique sur les « zones sinistrées » sans avoir à interrompre l’ensemble du système. En 10 ans, la capacité à gérer et minimiser l’« effet de souffle » d’une panne est devenue indispensable pour assurer le bon fonctionnement du système.

3. Des fonctions primitives plutôt qu’une structure logicielle

Assez rapidement, il a fallu prendre conscience que les clients n’avaient pas toujours une vision arrêtée de leur projet. Quand les entreprises ont décidé de quitter le monde contraignant des datacenters physiques, elles ont développé leurs systèmes selon de nouveaux modèles d’utilisation que personne n’avait encore jamais vus. C’est pour cette raison qu’il était primordial de proposer un modèle plus agile dans le but de répondre aux besoins changeant et spécifiques des clients.

La première étape a été de proposer aux clients des outils et des fonctions primitives, plutôt qu’une seule et unique structure qu’ils auraient été forcés d’utiliser de A à Z. Cela leur a permis de choisir leur propre façon de se déployer dans le cloud. Face au succès de cette stratégie les nouveaux services sont construits sur ce même modèle, auxquels les clients se sont habitués.

Il est très difficile d’anticiper les priorités des clients avant qu’ils aient le service entre les mains et qu’ils commencent véritablement à l’utiliser. C’est pourquoi il faut continuer de construire et proposer des nouveaux services avec un minimum de fonctionnalités, puis de les enrichir en fonction des retours et des demandes spécifiques des clients.

4. L’automatisation est la clé

Développer des systèmes logiciels qui devront être opérés n’a rien à voir avec la création de logiciels qui seront envoyés aux clients. Gérer des systèmes logiciels à grande échelle requière un état d’esprit  radicalement différent, afin de répondre aux attentes de fiabilité, performance et d’évolutivité des clients.

La solution pour atteindre cet objectif est d'automatiser autant que possible la gestion, en supprimant les interventions manuelles, souvent sujettes à erreur. Pour ce faire, il a été nécessaire  de construire des interfaces de programmation (API), contrôlant les fonctions essentielles des opérations. En découpant les applications en composantes essentielles, chacune avec une API de gestion, il était possible d’appliquer des règles d'automatisation et maintenir ainsi à grande échelle un niveau prévisible et satisfaisant de fiabilité. Par exemple, si votre entreprise a encore besoin d’un accès SSH pour un serveur ou une instance, c’est qu’il faut continuer d’automatiser…

5. Les API sont prévues pour durer

Il y a 10 ans, certains retailers en avaient déjà conscience, mais cette leçon a vraiment pris tout son sens pour les fournisseurs de cloud aujourd’hui. Une fois que les clients commençaient à concevoir leurs applications et leurs systèmes en utilisant des interfaces de programmation, il était ensuite impossible de les modifier puisque cela aurait eu une incidence directe sur les activités des clients. Il nous a donc fallu apprendre que la conception des API était une tâche de la plus haute importance dans la mesure où il ne pouvait pas y avoir de deuxième essai.

6. Connaître l’utilisation de ses services

Lors de la création du modèle économique d’un service et du système de tarification adapté, il faut connaitre le coût prévisionnel du service et de ses opérations, notamment pour une activité à volume élevé et à marge faible. Les fournisseurs de cloud devaient être pleinement conscients des coûts de leurs services. L’objectif étant de pouvoir proposer des services aux clients tout en identifiant les domaines où il est possible d’améliorer l’efficacité opérationnelle, de réduire les coûts des services, et répercuter ces économies sur les clients.

Par exemple, lors du lancement de S3, les équipes d’Amazon Web Services n’étaient pas conscientes du type de ressource qui serait utilisé. Ils pensaient qu’il fallait facturer le stockage et la bande passante; après quelque temps, ils ont réalisé que le nombre de requêtes était une ressource tout aussi importante. Si les clients possèdent de nombreux mais très petits fichiers, alors le stockage et l’utilisation de bande passante ne sont pas très importants, même s’ils font des millions de requêtes. Il  a fallu adapter le modèle pour prendre en compte tous les aspects de l’utilisation des services pour que l’activité soit pérenne.

7. La sécurité comme base de travail

Protéger ses clients doit être la première des priorités, que cela soit sur le plan opérationnel comme lors de la création d’outils et de procédures.

Il a fallu rapidement comprendre que pour construire des services sécurisés, il était nécessaire d’intégrer la sécurité  dès la phase de conception du service. L’équipe sécurité ne peut pas donner son aval après la création d’un service. Ils doivent être intégrés au processus dès le départ et s’assurer de la sécurité du service de sa conception à sa réalisation. Il n’y a pas de compromis possible quand il s’agit de sécurité !

8. Le chiffrement des données n’est pas optionnel

Le chiffrement est un mécanisme essentiel pour que les clients puissent pleinement contrôler qui a accès à leurs données. Il y a dix ans, les outils et services de chiffrement étaient difficiles à utiliser et ce n’est que récemment que le chiffrement a pu être intégré aux services cloud.    

Tout a commencé par le chiffrement des serveurs de service de stockage cloud qui empêchait toute personne d’examiner les données  des datacenters. Puis de nouveaux services ont permis aux clients d’utiliser leurs propres clés de chiffrement, les fournisseurs de cloud n’avaient dès lors plus besoin de gérer ces clés.

La prise en charge du chiffrement est désormais intégrée dès la phase de conception de chaque nouveau service. Par exemple, chaque bloc de données est chiffré par défaut avec une clé aléatoire et l’ensemble de ces clés est à son tour chiffré avec une clé principale. La clé principale peut être fournie par les clients, permettant d’assurer qu’ils soient les seuls à pouvoir déchiffrer et avoir accès à leurs informations sensibles concernant leur activité ou leurs données personnelles.

Le chiffrement demeure une priorité essentielle pour les fournisseurs de services cloud. Il faut continuer de faciliter l’utilisation du chiffrement pour les clients afin qu’ils puissent mieux se protéger et mieux protéger eux-mêmes leurs clients.

9. L’importance du réseau

Le cloud est utilisé pour supporter des applications très différentes; du traitement de large volume de transactions à du transcodage vidéo à grande échelle, du calcul parallèle à haute performance à du trafic web très dense. Chacune de ces charges de travail a des exigences particulières en termes de ressources réseau.

Mais il a fallu  innover dans la configuration et la gestion des datacenters, afin d’avoir une infrastructure réseau flexible pouvant s’adapter aux besoins des clients en termes de charge de travail. Il ne fallait pas avoir peur de développer son propre hardware pour s’assurer que ses clients puissent réaliser leurs objectifs. Cela permet aujourd’hui de répondre à des exigences bien précises, telles que l’isolation de chaque client sur le réseau pour atteindre le meilleur niveau de sécurité possible. 

Ce fut par exemple le cas lors de la nécessaire amélioration de la performance des services grâce à une meilleure configuration du réseau matériel et logiciel. Il a fallu s’attaquer  à la surcharge de la virtualisation de l’accès au réseau depuis les machines virtuelles. Comme l’accès au réseau était une ressource partagée, les clients pouvaient ressentir de temps en temps une instabilité sur le réseau. Développer une carte d’interface réseau (NIC) soutenant une SR-IOV permettait par exemple d’attribuer une carte d’interface réseau propre à chaque machine virtuelle. Cela a permis de diviser les temps de latence par 2 et d’améliorer jusqu’à 10 fois la variabilité des temps de latence sur le réseau.

10. l’innovation ne connait plus de limite

Le premier pas pour les fournisseurs de cloud était de proposer de nombreux services et fonctionnalités au sein d’une plateforme globale. Mais il fallait aller au-delà du simple fait de proposer des services créés en interne ; il était nécessaire d’enrichir ce portfolio grâce au riche écosystème de services fournis par les partenaires, qui orientent la plateforme vers bien d’autres directions.

Les exemples ne manquent pas, comme l’entreprise Stripe qui fournit des services de paiement à Twilio, rendant la téléphonie programmable sur le cloud. Certaines entreprises conçoivent elles-mêmes des plateformes en parallèle de celle des fournisseurs de cloud afin de répondre à des besoins spécifiques de secteurs verticaux : Philips construit sa plateforme Healthsuite Digital pour la gestion des données de santé, Ohpen a construit une plateforme dans le cloud pour les banques du secteur de la distribution, Eagle Genomics a mis au point une plateforme de traitement de la génomique, et bien d’autres encore. Il est fondamental de ne pas limiter les possibilités d’actions des partenaires sur les plateformes cloud. L’absence de telles barrières permet de libérer le processus d’innovation et ouvre la voie à de nombreuses inventions inattendues.

Autour du même sujet