Cloudflare Workers : Crée des applications qui scale de manière rapide et facile

Bonjour Antoine, Customer Engineer chez Cloudflare. Aujourd'hui ensemble on va se parler de la Developer Platform de Cloudflare et plus spécifiquement l'une de nos pierres angulaires qui sont les Cloudflare Workers. Donc vous connaissez peut-être comment fonctionne une application web classique avec par exemple du Node.js. Donc ici dans cet exemple, j'ai une application express, un serveur express extrêmement basique avec deux routes, une route pour récupérer un utilisateur, la route ici que j'ai en GET et une route en POST pour aller par exemple, imaginons, insérer un utilisateur dans une base de données. Ici en fait on voit que ce serveur express, cette API, elle écoute sur le port 3000. Donc ce qui veut dire que lorsque je fais tourner mon serveur, mon application express, elle doit tourner en permanence, elle doit tout le temps attendre et écouter des requêtes qui peuvent lui arriver. Donc maintenant que j'ai ça et que je souhaite publier mon application, que je souhaite la déployer, j'ai besoin que ce processus Node, ce serveur continue à tourner 24-24, 7 sur 7. Alors j'ai deux choix en fait pour faire ça. Le premier choix, l'option A qui est à gauche, c'est de prendre mon application, de la containeriser avec du Docker par exemple et d'orchestrer ces containers si j'ai besoin avec du Kubernetes. L'option B qui est une option plus simple pour des cas avec peut-être un peu moins de trafic dans un premier temps, alors je peux décider de faire tourner mon application sur une VM avec un process manager comme par exemple PM2 où juste lancer mon serveur. Donc ça, option A ou option B, ça doit soit tourner dans une VM ou dans un cluster. Alors c'est un modèle qui marche bien, mais là où ça se complique, c'est au niveau du scaling. Donc ici, dans notre exemple, imaginons qu'on ait déployé l'application sur une seule VM et que je me mets à avoir beaucoup d'utilisateurs, mon application, au bout d'un moment, va commencer à être lente et à les renvoyer des erreurs. Donc pour résoudre ce problème, c'est pas un sorcier, c'est quelque chose qu'on a tous en tête, on pourrait décider de multiplier les serveurs et d'ajouter un load balancer. Donc ici, dans ce cas, j'ajoute un load balancer qui peut être par exemple Cloudflare avec des réplicas qui sont plusieurs serveurs qui contiennent la même application. Alors c'est un système qui fonctionne bien, qui nous a servi plutôt correctement depuis des années. Mais maintenant que ce problème un petit peu technique est résolu, il existe en fait un autre problème qui lui n'est pas forcément technique, c'est que dans le cas où j'utilise un load balancer avec des réplicas, je vais payer pour de la capacité et pas pour l'utilisation réelle de mon application. Alors, quelle est la solution que Cloudflare propose ? Alors notre solution, c'est les Cloudflare Workers. Et je vais vous présenter la base des Cloudflare Workers. En fait, un Cloudflare Workers, c'est juste un fetch handler, donc du code qui peut être écrit en TypeScript, en Python, la majorité du temps, ça va être écrit en TypeScript. Et ici, vous pouvez voir que je n'ai pas de HTTP Create Server, ou je n'écoute pas sur un port, je n'écoute pas sur le port 3000. Et puisque c'est du serverless, l'application n'a pas besoin de tourner 24 heures sur 24, car c'est du serverless. Alors, je vais vous éclairer, je vais vous montrer comment ça se passe quand une requête arrive sur un worker et sur Cloudflare pour exécuter notre application. Donc, l'utilisateur fait une requête vers notre application que l'on a déployée avec un worker. La requête est dirigée vers le POP, le Point of Presence, le serveur de Cloudflare le plus proche de l'utilisateur. Donc, la requête arrive sur Cloudflare et Cloudflare va trouver le workers, le code à exécuter. Et ensuite, la réponse est retournée à l'utilisateur. Et le gros intérêt, c'est lorsqu'il n'y a pas de requête sur ce worker, eh bien, vous n'êtes pas facturé. Si le code ne tourne pas, il n'y a pas de plate frais. Donc, ce qu'on aime bien dire, c'est qu'on est une plateforme qui scale à zéro. Puisqu'en opposition, vous déployez quelque chose avec du Kubernetes, vous avez toujours un fond qui tourne, un control plane, etc. Et même si vous n'avez aucun utilisateur, ça vous coûte quand même. La différence de Cloudflare avec les Cloudflare workers, vous n'avez pas de trafic, vous ne payez rien. Alors, quelque chose que j'entends souvent, c'est, oui, mais le serverless, historiquement, c'est quelque chose d'assez lent. Mais Cloudflare a énormément optimisé ce système-là. Et aujourd'hui, le call start n'est vraiment pas un problème sur cette plateforme. Si vous souhaitez en apprendre plus sur la façon dont on gère le call start, on a écrit des articles sur notre blog. Mais historiquement, on utilisait le TLS on-check qui se faisait sur Cloudflare et en parallèle, on allait démarrer le worker. Aujourd'hui, on a optimisé ce process et on va beaucoup plus loin. Je vous laisserai aller jeter un oeil dans nos articles techniques si vous voulez en apprendre plus sur ce point-là. La technologie que le Cloudflare utilise sont les V8 Isolate, issus du moteur de Chrome. Et l'un des gros points forts de notre plateforme, je l'ai déjà dit tout à l'heure, c'est que lorsque vous déployez du code sur Cloudflare, le code est déployé sur l'ensemble des points de présence de notre réseau. Donc, vous déployez dans plus de 337 points de présence dans le monde et vous n'avez pas à choisir de région. Historiquement, chez des hyperscalers, vous choisissez par exemple de déployer votre code sur AU Europe West 1 ou US East 1. Quand vous déployez sur Cloudflare, vous déployez ce qu'on appelle Region Earth, c'est-à-dire que vous déployez partout dans le monde. Donc, vous n'avez plus à vous soucier de problématiques de multirégion et vous avez une application qui est extrêmement rapide et performante puisque vous avez 95% de la population connectée à Internet à moins de 50 millisecondes d'un datacenter Cloudflare. Aujourd'hui, Cloudflare sert plus de 2,5 millions de requêtes via les workers par seconde et énormément de produits Cloudflare que vous utilisez et que vous aimez, j'imagine, tournent avec ce système et cette architecture. Maintenant, je vous ai présenté la pierre angulaire. Moi, ce que j'adore dans les Cloudflare workers, c'est les produits et ce qu'on peut rattacher, en fait, à ces workers. Avec les workers et la développeur plateforme de Cloudflare, il n'y a quasiment rien que vous ne pouvez pas faire. Vous pouvez, par exemple, automatiser un navigateur, lancer un Playwright ou un Puppetier. Ça, c'est des choses qu'on peut faire. Vous avez besoin d'exécuter du code en C++ pour, par exemple, transcoder une vidéo. Ce n'est pas une chose qu'on va pouvoir faire dans un worker qui est du TypeScript avec une mémoire limitée. Mais un worker va être capable, par exemple, de démarrer un container pour exécuter le code que vous souhaitez. Au niveau de la gestion du state, les workers sont stateless, puisqu'on est sur du serverless. Donc, quelque chose qui est stocké en mémoire par rapport à un appel sur un autre n'existe plus. Mais pour manager le state, on a un produit qui s'appelle les Durable Objects pour maintenir cet état entre différents... S'ils ont besoin de sandbox pour exécuter du code généré par un LLM, du code qui n'est pas trusté, ou même par un utilisateur, vous pouvez aussi démarrer un worker et utiliser les workers comme une sandbox. Si vous avez besoin de faire des longues tâches, de faire des tâches asynchrones, on est tout à fait capable de le faire avec la developer platform et les workers, avec notamment des queues, notamment des workflows, de la gestion d'événements comme Kafka. Maintenant, au niveau du stockage, si vous avez besoin de stockage, vous avez par exemple D1, qui est une base de données à Ledge, répliquée à Ledge, SQLite. Vous avez la possibilité d'utiliser Artifact. Si vous avez besoin d'un agent qui a besoin de comités à haute vitesse, on vous propose un stockage compatible Git à Ledge. On a une data plateforme, vous pouvez faire de l'ETL, Extract, Transform, Load. Et si vous avez besoin d'une base de données plus véloce, vous avez besoin d'utiliser par exemple du Postgre ou du MySQL, il est tout à fait possible de connecter Workers avec une base de données existante, avec notre système Hyperdrive, qui permet de maintenir une connexion active entre votre base de données et Cloudflare. Comme ça, lorsqu'une requête arrive sur Cloudflare et a besoin de connecter la base de données, Cloudflare est déjà connecté à votre base de données et on n'a pas de call start. Si vous avez besoin de faire du stockage objet pour par exemple stocker des images, des vidéos, des assets, ou laisser des utilisateurs uploader des choses, Cloudflare R2 est le stockage objet avec 0 egress fees, donc pas de coût d'egress directement sur Cloudflare. Et sur la partie AI, Cloudflare est l'une des meilleures plateformes pour construire des agents. Vous pouvez notamment créer des agents avec le framework Flu directement sur Cloudflare. On a le Agent SDK pour créer des expériences agentiques modernes. La partie AI Gateway pour faire du routing dynamique entre différents modèles, rajouter de la sécurité, du rate limiting et autres. Si vous avez besoin par exemple d'avoir une base de données vectorielle, c'est quelque chose qui existe aussi sur Cloudflare. Si vous avez besoin d'exécuter, faire de l'inférence, c'est quelque chose qui existe aussi avec Worker's AI directement sur Cloudflare. Moi ce que je préfère sur la plateforme Cloudflare, c'est la facilité d'interconnexion entre les services avec un concept qui s'appelle les bindings. Je vous montre. Ici, si j'ai besoin d'utiliser Kavistore, si j'ai besoin par exemple d'utiliser un équivalent de Redis, ce que je vais pouvoir faire, c'est d'importer dans mon worker, d'importer dans mon application, la fonctionnalité, le produit Kavistore. et je n'ai pas de clé compliquée à intégrer à mon application, de clé d'API, de secret, etc. Je le fais directement en définissant ici un binding que je peux faire en CLI et directement de mon code, j'ai une variable d'environnement avec un objet et des méthodes qui lui sont associées. Ici, pareil, si j'ai besoin de m'interconnecter avec une base de données, je crée une base de données SQLite sur Cloudflare, je crée cette base de données, je l'intégrer à mon projet via le binding, je dis à mon worker, voilà, tu peux communiquer avec cette base, pas de clé d'API, de secret, compliquée à gérer, j'ai directement l'instance de ma base de données disponible avec une variable d'environnement. Et même chose pour Postgre, puisque tous les projets ne vont pas fonctionner avec SQLite, bien évidemment, mais tout à fait possible de le faire avec Hyperdrive pour gérer cette connexion, ce pooling de connexion dont j'ai parlé de l'instant. Avec la développeur plateforme de Cloudflare, il n'y a pas d'application impossible. Tout est possible de faire sur notre développeur plateforme. Et l'énorme avantage, la facilité d'utilisation, le scaling qui est automatique, le déploiement mondial, ainsi que la gestion des coûts. Je vous encourage à découvrir la développeur plateforme de Cloudflare. Et si vous avez des questions, un petit peu d'aide, tenez mon courant. À bientôt. Sous-titrage Société Radio-Canada