L’opportunité de l’edge computing : ce n’est pas ce que vous croyez

Cloudflare Workers® est l’une des plus grandes plates-formes d’edge computing (informatique périphérique) et l’une des plus utilisées. Il y a bientôt trois ans que nous l’avons lancée, et la plate-forme est largement disponible depuis deux ans. Au cours de cette période, des centaines de milliers de développeurs ont écrit des dizaines de millions de lignes de code qui s’exécutent actuellement sur le réseau de Cloudflare.

Au cours du dernier trimestre, 20 000 développeurs ont déployé pour la première fois une nouvelle application utilisant Cloudflare Workers. Plus de 10 % de toutes les requêtes qui transitent aujourd’hui par notre réseau le font via Cloudflare Workers. En outre, environ 20 % de nos plus gros clients ont adopté la solution Cloudflare Workers dans le cadre de leurs activités. Voir la plate-forme se développer fut une expérience unique.

Au cours de la semaine prochaine, que nous avons surnommée la « Semaine du sans serveur », nous allons annoncer une série d’améliorations apportées à la plate-forme Cloudflare Workers qui vous permettront de créer des applications beaucoup plus complexes, de réduire vos dépenses en informatique sans serveur, de rendre vos applications encore plus rapides et de prouver que la plate-forme Workers est sécurisée jusqu’au bout.

Avant que la semaine ne commence, je voudrais évoquer un peu ce que nous avons appris sur l’edge computing ces trois dernières années. Lorsque nous avons lancé Cloudflare Workers, nous pensions que la vitesse était un facteur décisif. Les Workers utilisent le réseau Cloudflare, au plus près des utilisateurs finaux, ce qui fait que leur temps de réponse est généralement plus rapide que celui des anciennes plates-formes sans serveur centralisées.

Cependant, en observant les développeurs utiliser Cloudflare Workers, nous nous sommes rendu compte qu’une plate-forme de développement doit présenter un certain nombre d’attributs qui sont bien plus importants que la simple vitesse. La vitesse est la cerise sur le gâteau, mais, pour la plupart des applications, elle ne constitue pas une exigence primordiale. Se focaliser uniquement sur la vitesse serait une erreur qui condamnerait les plates-formes d’edge computing à rester dans l’ombre.

Aujourd’hui, la plupart des discours sur les avantages de l’edge computing mettent encore l’accent sur la vitesse. C’est la direction qu’a suivie Akamai, qui a lancé sa plate-forme EdgeComputing en Java et en .NET en 2002, pour finalement la fermer en 2009, faute d’avoir trouvé suffisamment de clients pour lesquels une légère diminution de la latence justifiait à elle seule les coûts additionnels et les complications liées à l’exécution du code en périphérie. C’est une mise en garde que la plupart des acteurs du secteur ont oubliée.

Aujourd’hui, je suis convaincu que nous avions tort lorsque, au moment du lancement de Cloudflare Workers, nous considérions la vitesse comme le principal atout de l’edge computing, et que la plupart des autres acteurs du marché se fourvoient encore et risquent de manquer une occasion unique d’améliorer leurs services.

Pour moi, la liste des priorités des développeurs, toutes plates-formes confondues, et de la moins importante à la plus importante, serait : Vitesse < Stabilité < Coût < Facilité d’utilisation < Conformité. Appelons cela la hiérarchisation des besoins des développeurs selon Matthew. Si la plupart des louanges adressées à l’edge computing se focalisent sur sa vitesse, je crois que la stabilité, le coût, la facilité d’utilisation et surtout la conformité seront à terme bien plus importants. Je pense en fait que le véritable atout de l’edge computing ces trois prochaines années sera sa conformité à la réglementation, ce qui ne fait pas nécessairement rêver, mais qui revêt une importance capitale.

Ne vous méprenez pas sur mes propos : la vitesse est un formidable atout. Tout développeur expérimenté doit pouvoir développer une application rapide. Nous avons d’ailleurs conçu les Workers pour qu’ils soient extrêmement rapides. En rapprochant les tâches de calcul des utilisateurs d’une application, nous pouvons efficacement supprimer les limites. Le réseau de Cloudflare est présent dans plus de 200 villes et plus de 100 pays du monde entier. Nous poursuivons le développement de ce réseau de manière à ce qu’il ne soit qu’à quelques millisecondes de chaque humain sur terre.

Comme il est peu probable que nous parvenions à accélérer la vitesse de la lumière, la possibilité pour tout développeur d’écrire du code et de l’exécuter sur l’ensemble de notre réseau signifie que nous aurons toujours un avantage sur les solutions informatiques centralisées existantes en termes de performance, même celles qui se trouvent dans le cloud. Si vous devez choisir une « zone de disponibilité » où exécuter votre application, vous vous retrouvez toujours désavantagé en termes de performance par rapport à une application basée sur une plate-forme comme celle de Workers qui est disponible partout où s’étend le réseau de Cloudflare.

Selon nous, Cloudflare Workers est déjà la plate-forme sans serveur la plus rapide, et nous continuerons à développer notre réseau pour faire en sorte qu’elle le reste.

Soyons réalistes une seconde. Seule une poignée d’applications ont vraiment besoin que la latence soit inférieure à quelques centaines de millisecondes. Cela ne veut pas dire que la latence n’est pas si importante pour les grandes plates-formes sans serveur modernes, mais que seule une minorité d’applications exigent ces performances supplémentaires.

Les applications utilisées pour le traitement des transactions par carte de crédit, la diffusion de publicités, les jeux vidéo et les interactions homme-machine peuvent être très sensibles à la latence. Alexa et Google Home, par exemple, sont plus performantes que bon nombre de leurs concurrentes, en partie parce qu’elles peuvent profiter des réseaux périphériques de leurs sociétés mères pour gérer le traitement de la voix, ce qui leur permet d’avoir une latence plus faible et d’être plus réactives.

Pour les autres applications, la vitesse est beaucoup moins une priorité. Les personnes qui parlent souvent d’edge computing ont tendance à évoquer l’Internet des objets et les voitures autonomes. Je me souviens, non sans embarras, que c’était souvent mon cas lorsque nous avons lancé la plate-forme Workers. Je vous propose un petit jeu : lorsque vous parlez à un fanatique de l’edge computing, amusez-vous à chronométrer le temps qui s’écoule avant qu’il évoque l’Internet des objets et les voitures autonomes : vous n’aurez certainement pas à attendre bien longtemps.

Donald Knuth, le célèbre professeur d’informatique de Stanford, (ainsi que Tony Hoare, Edsgar Dijkstra et bien d’autres) a dit quelque chose comme « l’optimisation prématurée est la source de tous les maux de la programmation ». Il n’est donc pas surprenant que la vitesse ne soit pas, à elle seule, une raison suffisante pour que la plupart des développeurs choisissent d’utiliser une plate-forme d’edge computing. Le faire pour la plupart des applications relève de l’optimisation prématurée, autrement dit la « source de tous les maux ». Quel critère est donc plus important que la vitesse ?

Bien que la réduction de la latence ne suffise pas à convaincre la majorité des développeurs de passer à une nouvelle plate-forme, la plupart des plates-formes sans serveur sont confrontées à une source de latence quasi systématique : le temps de démarrage à froid. Le démarrage à froid correspond au temps qu’il faut pour lancer une application la première fois qu’elle s’exécute sur un serveur donné. Les démarrages à froid sont préjudiciables, car ils rendent les applications imprévisibles et instables. Parfois, les applications sans serveur peuvent être rapides, si elles atteignent un serveur où le code est chaud, mais d’autres fois, elles sont lentes lorsqu’il faut lancer un conteneur sur un nouveau serveur et charger le code du disque vers la mémoire. L’imprévisibilité nuit vraiment à l’expérience utilisateur, or il se trouvent que les humains préfèrent la stabilité à la vitesse.

Le problème des démarrages à froid n’est pas propre aux plates-formes d’edge computing. L’instabilité induite par les démarrages à froid est un fléau pour toutes les plates-formes sans serveur. Elle est le prix à payer pour ne pas avoir à gérer et à déployer ses propres structures. Toutefois, les plates-formes d’edge computing peuvent en réalité aggraver le problème du démarrage à froid, car elles répartissent la charge de travail sur un plus grand nombre de serveurs dans un plus grand nombre d’endroits. Par conséquent, il est moins probable que le code soit actif sur un serveur donné lorsqu’il reçoit une requête.

En d’autres termes, plus une plate-forme est distribuée, plus il est probable qu’elle soit confrontée à des problèmes de démarrage à froid. Pour y remédier sur la plupart des plates-formes sans serveur, les développeurs sont obligés d’avoir recours à des techniques assez barbares, comme l’envoi de requêtes superflues à leur propre application depuis le monde entier, afin que leur code reste actif. Pour couronner le tout, les anciens fournisseurs cloud font payer les requêtes rejetées, ou font payer encore plus cher leurs propres solutions de préchauffage et de réservation. C’est absurde !

Connaissant l’importance des démarrages à froid, nous avons veillé dès le début à ce qu’ils durent moins de 5 millisecondes dans Workers. Ce chiffre est bien meilleur que ce que peuvent obtenir d’autres plates-formes sans serveur telles qu’AWS Lambda sur laquelle les démarrages à froid peuvent atteindre 5 secondes (1 000 fois plus lents qu’avec Workers).

Nous ne voulions cependant pas nous contenter de cela. C’est pourquoi, cette semaine, nous annoncerons que les démarrages à froid sur Workers prendront désormais zéro nanoseconde. Comme il est impossible de prendre moins de temps que cela, à moins que quelqu’un n’invente une machine à accélérer le temps, nous pensons pouvoir dire que, parmi toutes les plates-formes sans serveur, Cloudflare Workers est celle dont les démarrages à froid sont les plus rapides, et qu’elle est donc la plus stable, faisant mieux que les anciennes plates-formes centralisées sans serveur.

Encore une fois, d’après la hiérarchisation des besoins des développeurs selon Matthew, si la stabilité est plus importante que la vitesse, d’autres facteurs sont encore plus importants à prendre en compte lors du choix d’une plate-forme informatique.

S’ils doivent choisir entre une plate-forme rapide et une plate-forme bon marché, sans autre différence, la plupart des développeurs choisiront une plate-forme bon marché. Les développeurs ne sont prêts à payer plus cher pour la vitesse que lorsqu’ils constatent que les utilisateurs subissent des désagréments tels que ceux-ci leur coûteraient encore plus cher que la mise en place d’un service plus rapide. Entre-temps, ils préfèrent les solutions bon marché.

Dans la plupart des cas, les plates-formes d’edge computing facturent un supplément pour les gains de vitesse. Par exemple, une requête traitée par AWS Lambda@Edge coûte environ trois fois plus qu’une requête traitée via AWS Lambda, et pourtant le service Lambda de base est déjà excessivement cher. Cela peut sembler cohérent à certains égards (nous admettons tous qu’il faille payer plus cher pour que tout aille plus vite), mais c’est une logique de tarification qui fera toujours de l’edge computing un produit de niche uniquement au service d’un nombre limité d’applications qui ne tolèrent pas les problèmes de latence.

Pourtant, l’edge computing ne doit pas nécessairement être plus coûteuse. C’est en fait plutôt l’inverse qui est vrai. Pour mieux comprendre, voyons combien coûte la prestation de services à partir de la périphérie. Si vous avez mis en place des partenariats solides avec les FAI locaux, comme c’est le cas du réseau de Cloudflare, il peut être moins coûteux de distribuer la bande passante localement que de la distribuer dans le monde entier. L’exécution en périphérie peut également permettre de réaliser des économies supplémentaires sur le coût de l’énergie et de la colocation. Ce sont ces économies qui nous permettent de maintenir le tarif abordable de la plate-forme Cloudflare Workers.

Mais c’est surtout grâce à une architecture plus performante que l’on peut réaliser de vraies économies. Au début des années 90, lorsque j’étais l’administrateur réseau de mon collège, nous devions commander un nouveau serveur chaque fois que nous voulions ajouter une application. (Nous achetions nos serveurs à Gateway, j’aimais bien leur carton d’expédition au motif de peau de vache.) Ensuite sont apparues les machines virtuelles (VM), qui permettent d’exécuter plusieurs applications sur un même serveur. De fait, la consommation par application a diminué, car il fallait moins de serveurs physiques par application.

Les VM ont donné naissance aux premiers clouds publics. Très vite, cependant, les fournisseurs cloud ont cherché des moyens de réduire davantage leurs frais généraux. Les conteneurs permettaient d’alléger la charge de travail de plusieurs clients sur une même machine, grâce à dotCloud, ensuite devenu Docker, qui a ouvert la voie et que presque tous les autres ont fini par suivre. Une fois de plus, la victoire des conteneurs sur les VM a permis de réduire les coûts par application.

Chez Cloudflare, nous savions que l’histoire ne s’arrête jamais. Quand nous avons commencé à développer Workers, nous nous sommes donc demandé : par quoi les conteneurs seront-ils remplacés ? La réponse : les isolats. Les isolats sont la technologie de bac à sable que votre navigateur utilise pour séparer les processus. Ils sont extrêmement rapides et légers. Ce sont eux qui permettent à votre navigateur de récupérer du code qu’il ne connaît pas et de l’exécuter quasi instantanément lorsque vous visitez un site web.

En utilisant des isolats plutôt que des conteneurs ou des machines virtuelles, nous parvenons à maintenir les calculs à un niveau bien inférieur à celui des plates-formes sans serveur classiques. Cela nous permet de traiter beaucoup plus efficacement les opérations de calcul. Ces gains d’efficacité se répercutent sur nos clients. Notre objectif n’est pas de proposer un tarif inférieur à celui de Lambda@Edge, mais un tarif inférieur à celui de Lambda. Nettement inférieur.

Au début, nous voulions que la tarification des Workers soit très simple et économique. Au lieu de faire payer les clients à la requête, au temps de calcul et selon leur consommation de bande passante, comme les autres fournisseurs de services sans serveur, nous avons juste facturé les clients selon le nombre de requêtes. Tout simplement. En échange, nous avons dû imposer des restrictions au niveau de la puissance de calcul, de la mémoire utilisée et de la taille des applications. Ces trois dernières années, nous avons constaté que les développeurs souhaitent développer des applications plus complexes et plus sophistiquées en utilisant Workers, dont certains ont repoussé les limites. Cette semaine, nous repoussons donc les limites.

Nous dévoilerons demain une nouvelle option de Workers qui vous permettra de gérer des tâches informatiques beaucoup plus complexes en suivant le même modèle de tarification que les autres fournisseurs de services sans serveur, mais à des tarifs beaucoup plus avantageux. Nous continuerons à proposer notre solution simplifiée aux utilisateurs qui peuvent se contenter des anciennes restrictions. Je suis particulièrement impatient de voir comment les développeurs exploiteront notre technologie pour créer des applications, le tout à un coût moindre et avec de meilleures performances que les autres plates-formes sans serveur centralisées.

Une plate-forme plus rapide, plus stable et moins chère, c’est bien, mais même ensemble, ces arguments ne suffisent pas à convaincre la plupart des développeurs. Alors, qu’est-ce qui est plus important que les coûts ?

Les développeurs sont des fainéants. Je suis bien placé pour le savoir car, lorsque je dois écrire un programme, j’utilise toujours un langage que je connais, par exemple Pearl (j’en vois un qui rit au fond), même s’il est lent et plus coûteux. Je ne suis pas le seul à faire ça.

C’est la raison pour laquelle, avec Cloudflare Workers, nous savions que nous devions faire sentir aux développeurs qu’ils étaient en terrain connu. Cela suppose d’abord de prendre en charge les langages que les développeurs connaissent et aiment. Nous avons déjà annoncé la prise en charge de JavaScript, C, C++, Rust, Go et même COBOL. Cette semaine, nous annoncerons la prise en charge de Python, Scala et Kotlin. Nous voulons être certains que vous n’aurez pas à apprendre un nouveau langage et à utiliser une nouvelle plate-forme pour bénéficier des avantages de Cloudflare Workers. (Je fais aussi tout mon possible pour obtenir la prise ne charge de Perl.)

Cette facilité, c’est aussi pouvoir consacrer moins de temps aux tâches techniques, par exemple. C’est là que les plates-formes sans serveur excellent. Pouvoir simplement diffuser du code et permettre à la plate-forme de l’adapter à toutes sortes d’appareils est tout simplement prodigieux. Nous l’avons constaté avec des utilisateurs de longue date de Cloudflare Workers comme Discord, dont la fréquentation a augmenté de plusieurs milliers de pour cent ces trois dernières années, et la plate-forme Workers s’est automatiquement adaptée à ses besoins.

Toutefois, les plates-formes sans serveur sont confrontées au problème du débogage. En tant que développeur, il peut être difficile de reproduire localement l’ensemble de la plate-forme sans serveur, et le débogage des applications peut être plus difficile. Ce problème est exacerbé lorsque le déploiement du code sur une plate-forme prend jusqu’à 5 minutes, comme c’est le cas avec Lamda@Edge d’AWS. Si vous êtes développeur, vous savez combien l’attente pour que votre code soit déployé et puisse être testé peut être pénible. C’est pour cette raison qu’il était essentiel pour nous que les modifications du code soient diffusées à l’échelle mondiale sur l’ensemble de notre réseau, dans plus de 200 villes, en moins de 15 secondes.

L’une des décisions les plus importantes que nous ayons prises en interne fut de mettre en œuvre ce que nous appelons la règle de Bezos. Elle implique deux conditions : 1) les nouvelles fonctionnalités créées par les ingénieurs de Cloudflare doivent être développées avec Workers dans la mesure du possible , et 2) les API ou les outils que nous créons nous-mêmes doivent être mis à la disposition de développeurs tiers utilisant Workers.

La mise en place d’un dispositif de test et de débogage efficace nécessite la contribution des développeurs. Ces trois dernières années, les outils de développement de Cloudflare Workers ont considérablement évolué grâce aux suggestions des centaines de milliers de développeurs qui utilisent notre plate-forme, y compris notre propre équipe qui a utilisé Workers pour créer rapidement des fonctionnalités innovantes telles que Cloudflare Access et Gateway. L’Histoire a montré que le premier et le meilleur client de toute plate-forme doit être l’équipe de développement de l’entreprise qui l’a développée.

Wrangler, l’outil en ligne de commande permettant de fournir, déployer et déboguer vos Workers Cloudflare, est devenu un outil de développement performant grâce aux observations détaillées de notre propre équipe. En plus d’être la plate-forme la plus rapide, la plus stable et la plus abordable, nous pouvons également dire que, grâce à de nombreuses contributions, Workers est devenue la plate-forme sans serveur la plus simple à utiliser.

En général, c’est la plate-forme la plus facile à utiliser qui l’emporte. Toutefois, il existe une chose qui prime sur la facilité d’utilisation et qui, à mon avis, s’avérera être le véritable atout de l’edge computing.

Si vous êtes un développeur individuel, le respect de la réglementation est sans doute le cadet de vos soucis. Cependant, cela est peut-être moins vrai si vous êtes développeur au sein d’une banque, d’une compagnie d’assurance, d’une société de soins de santé ou de toute autre entreprise renommée ayant accès à des données sensibles à grande échelle. Vous avez peut-être besoin d’une plate-forme spécifique parce qu’elle est rapide, stable, abordable et facile à utiliser, mais si votre directeur informatique, votre directeur de la technologie, votre directeur de la sécurité des systèmes d’information ou votre directeur des affaires juridiques vous dit « non », vous voilà revenu à la case départ.

La plupart des services informatiques exécutés sur des platesformes cloud, notamment les plates-formes sans serveur, sont créés par des développeurs travaillant pour des entreprises où le respect de la réglementation est une obligation absolue. Jusqu’à présent, cela signifiait qu’il fallait veiller à ce que les plates-formes respectent les réglementations gouvernementales, telles que le RGPD (réglementation européenne en matière de vie privée) ou aient obtenu des certifications attestant qu’elles respectent les réglementations propres au secteur, telles que PCI DSS (obligatoire si vous prenez les paiements par carte de crédit), FedRamp (exigences du gouvernement américain relatives aux marchés publics), ISO 27001 (gestion des risques de sécurité), SOC 1/2/3 (contrôles de sécurité, de confidentialité et de disponibilité) et bien d’autres.

Toutefois, il existe un nouveau risque lié aux obligations réglementaires que les solutions de cloud actuelles ne permettent pas de gérer. Les pays adoptent de plus en plus de réglementations visant à garantir que leurs lois s’appliquent aux données personnelles de leurs citoyens. Pour vous assurer que vous respectez ces lois, vous pouvez par exemple stocker et traiter les données des citoyens d’un pays entièrement à l’intérieur de ses frontières.

L’UE, l’Inde et le Brésil sont tous des marchés de premier plan qui ont mis en place ou envisagent de mettre en place une réglementation visant à renforcer la souveraineté juridique sur les données personnelles de leurs citoyens. La Chine a déjà adopté une réglementation concernant la localisation de nombreux types de données. Que vous soyez ou non convaincu(e) du bien-fondé des réglementations exigeant le stockage et le traitement locaux des données (pour moi, il s’agit de politiques néfastes qui seront un frein à l’innovation), elles suscitent tellement d’enthousiasme qu’il est difficile de faire comme si elles n’existaient pas à l’heure actuelle. Lorsque plusieurs pays exigeront la souveraineté des données, tous les autres voudront leur emboîter le pas et il sera difficile de les en empêcher.

Le risque est que ces réglementations privent les développeurs d’une grande partie des gains d’efficacité obtenus grâce à l’informatique sans serveur. Si des équipes entières doivent assurer la coordination entre différentes plates-formes de cloud et différentes législations pour veiller au respect de la réglementation, ce sera un cauchemar.

C’est là qu’intervient le principal avantage de l’edge computing. À mesure que les gouvernements adopteront de nouvelles réglementations en matière de souveraineté des données, les entreprises qui cherchent à conserver et à traiter localement leurs données devront impérativement disposer d’un réseau qui, grâce à une plate-forme unique, couvrira toutes les zones géographiques réglementées, afin de se conformer à ces nouvelles lois tout en restant efficaces.

Même si les réglementations commencent à peine à apparaître, les Workers de Cloudflare peuvent déjà fonctionner localement dans plus de 100 pays du monde entier. Cela nous permet d’aider les développeurs à répondre aux exigences en matière de souveraineté des données comme ils l’entendent. Nous continuerons à développer des outils permettant aux développeurs de satisfaire aux obligations de conformité, sans pour autant renoncer aux gains d’efficacité offerts par le cloud.

La promesse ultime de l’informatique sans serveur est de permettre à tout développeur de dire « Je me fiche de l’endroit où mon code s’exécute, à vous de l’adapter ». De plus en plus, il faudra qu’ils puissent dire : « Je me préoccupe de la manière dont mon code est exécuté et j’ai besoin de plus de moyens de contrôle pour satisfaire mon service de conformité. » Cloudflare Workers vous permet de bénéficier de tous les avantages, avec une évolutivité instantanée, des sites répartis dans plus de 100 pays et des possibilités de configuration très précises.

Le plus beau dans tout ça ? Tout ne fait que commencer. La semaine prochaine, nous vous expliquerons comment nous envisageons l’informatique sans serveur, et comment nous nous y prenons pour faire de Cloudflare Workers la plate-forme sans serveur la plus rapide, la plus économique, la plus sûre, la plus polyvalente, la plus fiable et la plus facile à utiliser. Nous vous présenterons également des témoignages de clients qui utilisent Cloudflare Workers pour créer et faire évoluer des applications comme jamais auparavant. Nous vous parlerons également des améliorations que nous avons apportées à la plate-forme pour la rendre encore plus performante pour les développeurs.

Nous avons vraiment parcouru beaucoup de chemin depuis trois ans passés à développer cette plate-forme, et j’ai hâte de voir toutes les nouvelles applications développées avec Cloudflare Workers. Vous pouvez commencer à l’utiliser gratuitement dès maintenant en vous rendant sur  workers.cloudflare.com.