Cloudflare vient de gagner en rapidité et en sécurité grâce à Rust

Cloudflare met tout en œuvre pour développer et exploiter le réseau le plus rapide du monde. Nous suivons et publions des rapports sur les performances de notre réseau depuis 2021 : vous pouvez consulter la dernière mise à jour ici.

Développer le réseau le plus rapide demande des efforts dans de nombreux domaines. Nous investissons beaucoup de temps dans nos équipements, afin de disposer de machines efficaces et rapides. Nous investissons dans des accords de peering, afin de nous assurer de pouvoir communiquer, avec un délai minimal, avec toutes les parties d'Internet. Enfin, nous devons également investir dans le logiciel dont dépend l'exécution de notre réseau, d'autant plus que chaque nouveau produit est susceptible d'entraîner une augmentation des délais de traitement.

Quelle que soit la vitesse à laquelle les messages arrivent, nous créons un goulet d'étranglement si ce logiciel réfléchit trop longuement à la manière de traiter et de répondre aux requêtes. Aujourd'hui, nous sommes heureux de vous annoncer une mise à niveau importante de notre logiciel, qui réduit de 10 ms le temps médian de réponse et offre une amélioration de 25 % des performances, mesurée par des tests de performances de réseau CDN tiers.

Nous avons passé l'année dernière à reconstruire des composants essentiels de notre système, et nous venons de réduire considérablement la latence du trafic transitant sur notre réseau pour des millions de nos clients. Dans le même temps, nous avons renforcé la sécurité de notre système et réduit le temps nécessaire au développement et au lancement de nouveaux produits. 

Chaque requête qui parvient à Cloudflare commence un parcours à travers notre réseau. Une requête peut provenir d'un navigateur chargeant une page web, d'une application mobile appelant une API ou du trafic automatisé provenant d'un autre service. Ces requêtes sont d'abord traitées au niveau de nos couches HTTP et TLS, puis transmises à un système que nous appelons FL, avant d'être finalement acheminées vers Pingora, qui recherche les données dans le cache ou récupère les données depuis le serveur d'origine, si nécessaire.

FL est le cerveau de Cloudflare. Lorsqu'une demande parvient à FL, nous exécutons les différentes fonctionnalités de sécurité et d'amélioration des performances de notre réseau. FL applique la configuration et les paramètres uniques de chaque client, de l'application des règles de pare-feu WAF à la protection contre les attaques DDoS, puis au routage du trafic vers la plateforme pour développeurs et R2. 

Développé il y a plus de 15 ans, FL est au cœur du réseau de Cloudflare. Il nous permet de proposer une vaste gamme de fonctionnalités ; au fil du temps, toutefois, cette flexibilité est devenue un défi. À mesure que nous avons ajouté des produits, la maintenance de FL est devenue plus difficile, le traitement des requêtes est devenu plus lent et l'évolutivité est devenue plus complexe. Chaque nouvelle fonctionnalité nécessitait des vérifications minutieuses de la logique existante, et chaque ajout introduisait un peu plus de latence, rendant de plus en plus difficile le maintien des performances souhaitées.

Vous comprenez à quel point FL est essentiel à notre système ; nous l'avons souvent appelé le « cerveau » de Cloudflare. Il s'agit également de l'une des plus anciennes composantes de notre système : le premier commit de la base de code a été effectué par l'un de nos fondateurs, Lee Holloway, bien avant notre lancement initial. Nous fêtons cette semaine notre 15e anniversaire, et ce système a été lancé 9 mois avant cela !

commit 39c72e5edc1f05ae4c04929eda4e4d125f86c5ce
Author: Lee Holloway <q@t60.(none)>
Date:   Wed Jan 6 09:57:55 2010 -0800

    nginx-fl initial configuration

Comme l'indique le commit, le déploiement de la première version de FL a été effectué sur la base du serveur web NGINX, la logique produit étant déployée en PHP.  Au bout de trois ans, le système était devenu trop complexe pour être géré efficacement et répondait trop lentement, et une réécriture presque complète du système en cours d'exécution a été effectuée. Cette réécriture a conduit à un autre commit important, effectué cette fois par Dane Knecht, notre actuel directeur de la technologie.

commit bedf6e7080391683e46ab698aacdfa9b3126a75f
Author: Dane Knecht
Date:   Thu Sep 19 19:31:15 2013 -0700

    remove PHP.

Le déploiement de FL a dès lors été effectué avec NGINX, l'infrastructure OpenResty et LuaJIT.  Si cela a très bien fonctionné pendant longtemps, ces dernières années, le système a commencé à montrer des signes de vieillissement. Nous avons été contraints de consacrer de plus en plus de temps à corriger ou à contourner des bugs obscurs dans LuaJIT. La nature très dynamique et non structurée de notre code Lua, qui jouait en notre faveur lors de nos premières tentatives de déploiement rapide de logique, est devenue une source d'erreurs et de retards lorsque nous avons essayé d'intégrer de grandes quantités de logique produit complexe. Chaque fois qu'un nouveau produit était lancé, nous devions passer en revue tous les autres produits existants afin de vérifier s'ils seraient affectés par la nouvelle logique.

Il était clair que nous devions repenser notre approche. C'est pourquoi, en juillet 2024, nous avons supprimé un commit initial en faveur d'une mise en œuvre nouvelle et radicalement différente. Pour éviter de passer trop de temps à chercher un nouveau nom, nous l'avons simplement appelé « FL2 », et nous avons évidemment commencé à appeler le système FL original « FL1 ».

commit a72698fc7404a353a09a3b20ab92797ab4744ea8
Author: Maciej Lechowski
Date:   Wed Jul 10 15:19:28 2024 +0100

    Create fl2 project

Nous ne partions pas de zéro. Nous avons déjà publié un article de blog consacré à la manière dont nous avons remplacé un autre de nos systèmes existants par Pingora, développé dans le langage de programmation Rust, avec l'environnement d'exécution Tokio. Nous avons également publié un article de blog consacré à Oxy, notre framework interne de développement de proxys en Rust. Nous codons beaucoup en Rust, et nous sommes devenus plutôt bons dans ce domaine.

Nous avons développé FL2 en Rust, sur Oxy, et nous avons développé un cadre de modules strict afin de structurer toute la logique dans FL2.

Lorsque nous avons entrepris de développer FL2, nous savions que nous ne faisions pas que remplacer un ancien système ; nous reconstruisions les fondations de Cloudflare. Cela signifiait que nous avions besoin de plus qu'un simple proxy ; nous avions besoin d'une infrastructure capable d'évoluer avec nous, de gérer l'immensité de notre réseau et de permettre aux équipes d'avancer rapidement, sans sacrifier la sécurité ou les performances. 

Oxy offre une puissante combinaison de performances, de sécurité et de flexibilité. Développé en Rust, ce framework élimine des pans entiers de bugs qui affectaient FL1, basé sur NGINX/LuaJIT, notamment les problèmes de sécurité mémoire et les phénomènes de concurrence sur les données, tout en offrant des performances comparables à celles du langage C. À l'échelle de Cloudflare, ces garanties ne sont pas de simples agréments ; elles sont essentielles. Chaque microseconde économisée par requête se traduit par des améliorations perceptibles de l'expérience utilisateur, et chaque défaillance ou incident périphérique évité contribue à préserver le bon fonctionnement d'Internet. Les garanties strictes qu'offre Rust lors de la compilation s'accordent également parfaitement avec l'architecture modulaire de FL2, dans laquelle nous imposons des contrats d'interface rigoureux entre les modules du produit et leurs entrées et sorties.

Toutefois, le choix ne concernait pas uniquement le langage. Oxy est l'aboutissement de nombreuses années d'expérience du développement de solutions de proxy hautes performances. Il permet déjà l'exécution de plusieurs services importants de Cloudflare, de notre passerelle Zero Trust Gateway au service iCloud Private Relay d'Apple. Nous savions donc qu'il était capable de gérer les différents modèles de trafic et combinaisons de protocoles que FL2 allait rencontrer. Son modèle d'extensibilité nous permet d'intercepter, d'analyser et de manipuler le trafic de la couche 3 jusqu'à la couche 7, et même de désencapsuler et de retraiter le trafic sur différentes couches. Cette flexibilité est essentielle à l'architecture de FL2, car elle nous permet de traiter de manière cohérente tout type de trafic, du trafic HTTP au trafic IP brut, et de faire évoluer la plateforme afin de prendre en charge de nouveaux protocoles et fonctionnalités sans devoir réécrire les composants fondamentaux.

Oxy dispose également d'un vaste ensemble de fonctionnalités intégrées, qui nécessitaient auparavant de grandes quantités de code sur mesure. Les fonctionnalités telles que la surveillance, les rechargements sans interruption, le chargement dynamique et le remplacement de la configuration font toutes partie intégrante du framework. Ceci permet aux équipes produit de se concentrer sur la logique opérationnelle unique de leur module, plutôt que d'en réinventer les rouages à chaque fois. Cette fondation solide nous permet d'effectuer des modifications en toute confiance, de les appliquer rapidement et d'avoir la certitude qu'elles se comporteront comme prévu, une fois déployées.

L'une des améliorations les plus significatives apportées par Oxy concerne le traitement des redémarrages. Tout logiciel faisant l'objet d'un développement et d'une amélioration continus doit, tôt ou tard, être mis à jour. Dans un logiciel de bureau, l'opération est simple : vous fermez le programme, vous installez la mise à jour, puis vous redémarrez le programme. Sur le web, la procédure est beaucoup plus difficile. Notre logiciel est utilisé en permanence, et ne peut pas simplement être arrêté. Une requête HTTP abandonnée peut entraîner l'échec du chargement d'une page, et une connexion interrompue peut vous exclure d'un appel vidéo. La fiabilité n'est pas facultative.

Dans FL1, les mises à niveau exigeaient de redémarrer le processus de proxy. Le redémarrage d'un proxy nécessitait l'arrêt complet du processus, ce qui interrompait immédiatement toutes les connexions actives. Cet aspect était particulièrement problématique pour les connexions de longue durée, telles que les sessions WebSocket, les sessions de streaming et les API en temps réel. Même les mises à niveau planifiées pouvaient entraîner des interruptions visibles par les utilisateurs, et les redémarrages imprévus en cas d'incident pouvaient être encore plus problématiques.

Oxy change la donne à cet égard : le framework inclut un mécanisme intégré de redémarrage en douceur, qui nous permet de déployer de nouvelles versions sans interrompre les connexions, dans la mesure du possible. Lorsqu'une nouvelle instance d'un service basé sur Oxy démarre, l'ancienne arrête d'accepter de nouvelles connexions, mais continue à servir les connexions existantes, permettant à ces sessions de se poursuivre sans interruption jusqu'à ce qu'elles se terminent naturellement.

Cela signifie que si une session WebSocket est en cours lorsque nous déployons une nouvelle version, cette session peut se poursuivre sans interruption jusqu'à ce qu'elle se termine naturellement, au lieu d'être interrompue par le redémarrage. À l'échelle du parc de Cloudflare, les déploiements sont orchestrés sur plusieurs heures, permettant d'assurer que le déploiement, dans son ensemble, se déroule de manière fluide et presque imperceptible pour les utilisateurs finaux.

Nous allons encore plus loin en utilisant l'activation de socket de systemd. Au lieu de laisser chaque proxy gérer ses propres sockets, nous laissons systemd les créer et en assurer la propriété. Cette approche permet de dissocier la durée de vie des sockets de celle de l'application Oxy elle-même. Si un processus Oxy redémarre ou subit une défaillance, les sockets restent ouverts et prêts à accepter de nouvelles connexions, qui seront servies dès l'exécution du nouveau processus. Ceci permet d'éliminer les erreurs de type « connexion refusée » qui pouvaient se produire lors des redémarrages dans FL1, et améliore la disponibilité globale pendant les mises à niveau.

Nous avons également développé nos propres mécanismes de coordination en Rust, afin de remplacer les bibliothèques Go telles que tableflip par shellflip. shellflip utilise un socket de coordination de redémarrage, qui valide la configuration, génère de nouvelles instances et s'assure que la nouvelle version fonctionne correctement avant d'autoriser l'arrêt de l'ancienne version. Cette approche améliore les boucles de collecte d'informations et permet à nos outils d'automatisation de détecter les défaillances et d'y réagir immédiatement, au lieu de dépendre de redémarrages « à l'aveugle » basés sur des signaux.

Pour éviter les problèmes que nous rencontrions dans FL1, nous voulions créer une architecture dans laquelle toutes les interactions au sein de la logique produit étaient explicites et faciles à comprendre. 

Ainsi, sur les fondations fournies par Oxy, nous avons créé une plateforme qui sépare l'ensemble de la logique développée pour nos produits en modules bien définis. Au terme de quelques expérimentations et recherches, nous avons conçu un système de modules qui impose certaines règles strictes :

• Aucune IO (entrée ou sortie) ne peut être exécutée par le module.

• Le module fournit une liste de phases.

• Les phases sont évaluées dans un ordre strictement défini, qui est le même pour chaque requête.

• Chaque phase définit un ensemble d'entrées qui lui est fourni par la plateforme, ainsi qu'un ensemble de sorties qu'elle peut émettre.

Voici un exemple de définition de phase de module :

Phase {
    name: phases::SERVE_ERROR_PAGE,
    request_types_enabled: PHASE_ENABLED_FOR_REQUEST_TYPE,
    inputs: vec![
        InputKind::IPInfo,
        InputKind::ModuleValue(
            MODULE_VALUE_CUSTOM_ERRORS_FETCH_WORKER_RESPONSE.as_str(),
        ),
        InputKind::ModuleValue(MODULE_VALUE_ORIGINAL_SERVE_RESPONSE.as_str()),
        InputKind::ModuleValue(MODULE_VALUE_RULESETS_CUSTOM_ERRORS_OUTPUT.as_str()),
        InputKind::ModuleValue(MODULE_VALUE_RULESETS_UPSTREAM_ERROR_DETAILS.as_str()),
        InputKind::RayId,
        InputKind::StatusCode,
        InputKind::Visitor,
    ],
    outputs: vec![OutputValue::ServeResponse],
    filters: vec![],
    func: phase_serve_error_page::callback,
}

Cette phase concerne notre produit de page d'erreur personnalisée.  Elle nécessite quelques informations en entrée : l'adresse IP du visiteur, des informations d'en-tête et d'autres informations HTTP, ainsi que certaines « valeurs de module ». Les valeurs de module permettent à un module de transmettre des informations à un autre, et elles sont essentielles pour assurer la fonctionnalité des propriétés strictes du système de modules. Par exemple, ce module nécessite certaines informations qui sont produites par la sortie de notre produit d'erreurs personnalisées basé sur des ensembles de règles (l'entrée « MODULE_VALUE_RULESETS_CUSTOM_ERRORS_OUTPUT »). Ces définitions d'entrée et de sortie sont appliquées lors de la compilation.

Bien que ces règles soient strictes, nous avons constaté que nous pouvons mettre en œuvre l'ensemble de notre logique produit dans ce framework. L'avantage de cette approche est qu'elle nous permet de déterminer immédiatement quels autres produits pourraient s'influencer mutuellement.

Développer un framework, c'est une chose. Développer toute la logique produit et la peaufiner de sorte que les clients ne remarquent rien d'autre qu'une amélioration des performances, c'en est une autre.

La base de code de FL assure la prise en charge de 15 ans de produits de Cloudflare, et elle évolue tout le temps. Nous ne pouvions pas arrêter le développement. Une de nos premières tâches a donc consisté à trouver des moyens de rendre la migration plus facile et plus sûre.

La reconstruction de la logique des produits en Rust est déjà une distraction bien suffisante pour détourner notre attention de la livraison de produits aux clients. Il était excessif de demander à toutes nos équipes de gérer deux versions de leur logique produit et de réimplémenter chaque modification une seconde fois jusqu'à la fin de notre migration.

Nous avons donc implémenté, dans notre ancien FL basé sur NGINX et OpenResty, une couche permettant d'exécuter les nouveaux modules. Au lieu d'assurer la maintenance d'une implémentation parallèle, les équipes pouvaient déployer leur logique dans Rust et remplacer leur ancienne logique Lua par celle-ci, sans attendre le remplacement complet de l'ancien système.

Par exemple, voici une partie de l'implémentation de la phase du module de page d'erreur personnalisée précédemment définie (nous avons supprimé certains détails moins intéressants, donc ce code n'est pas compilé tel qu'il est présenté ici) :

pub(crate) fn callback(_services: &mut Services, input: &Input<'_>) -> Output {
    // Rulesets produced a response to serve - this can either come from a special
    // Cloudflare worker for serving custom errors, or be directly embedded in the rule.
    if let Some(rulesets_params) = input
        .get_module_value(MODULE_VALUE_RULESETS_CUSTOM_ERRORS_OUTPUT)
        .cloned()
    {
        // Select either the result from the special worker, or the parameters embedded
        // in the rule.
        let body = input
            .get_module_value(MODULE_VALUE_CUSTOM_ERRORS_FETCH_WORKER_RESPONSE)
            .and_then(|response| {
                handle_custom_errors_fetch_response("rulesets", response.to_owned())
            })
            .or(rulesets_params.body);

        // If we were able to load a body, serve it, otherwise let the next bit of logic
        // handle the response
        if let Some(body) = body {
            let final_body = replace_custom_error_tokens(input, &body);

            // Increment a metric recording number of custom error pages served
            custom_pages::pages_served("rulesets").inc();

            // Return a phase output with one final action, causing an HTTP response to be served.
            return Output::from(TerminalAction::ServeResponse(ResponseAction::OriginError {
                rulesets_params.status,
                source: "rulesets http_custom_errors",
                headers: rulesets_params.headers,
                body: Some(Bytes::from(final_body)),
            }));
        }
    }
}

La logique interne de chaque module est assez clairement séparée du traitement des données. La conception du langage Rust encourage en effet une gestion très claire et explicite des erreurs.

La plupart de nos modules les plus activement développés ont été traités de cette manière, ce qui a permis aux équipes de maintenir le rythme des modifications qu'elles apportaient pendant notre migration.

Pour couvrir une telle migration, il est essentiel de disposer d'un framework de test extrêmement puissant.  Nous avons développé un système, que nous avons baptisé Flamingo en interne, qui nous permet d'exécuter simultanément des milliers de requêtes de test de bout en bout sur nos systèmes de production et de préproduction. Les mêmes tests sont exécutés avec FL1 et FL2, ce qui nous donne l'assurance que nous ne modifions pas les comportements.

Chaque fois que nous déployons une modification, cette dernière est mise en oeuvre progressivement, en une multitude d'étapes, avec des volumes de trafic croissants. Chaque étape est évaluée automatiquement et n'est validée que lorsque l'ensemble complet des tests a été effectué avec succès et que les mesures globales de performances et d'utilisation des ressources sont conformes à des limites acceptables. Ce système est entièrement automatisé, et suspend ou annule les modifications en cas d'échec des tests.

L'avantage est que nous sommes en mesure de développer et de livrer de nouvelles fonctionnalités produit dans FL2 en moins de 48 heures, là où cela aurait demandé plusieurs semaines dans FL1. D'ailleurs, au moins une des annonces faites cette semaine impliquait ce type de modification !

Plus de 100 ingénieurs ont travaillé sur FL2, et nous disposons de plus de 130 modules. Et nous n'avons pas encore tout à fait terminé. Nous sommes encore en train de peaufiner le système, afin de nous assurer qu'il reproduit tous les comportements de FL1.

Alors, comment envoyons-nous du trafic vers FL2 sans qu'il soit capable de tout gérer ? Si FL2 reçoit une requête (ou une partie de la configuration d'une requête) qu'il ne sait pas traiter, il abandonne et exécute ce que nous appelons une fonction de secours : il transmet l'ensemble à FL1. Cela se déroule au niveau du réseau, c'est-à-dire que FL2 transmet simplement les octets à FL1.

En plus de nous permettre d'envoyer du trafic à FL2 sans que ce dernier soit complètement terminé, cette solution présente un autre avantage considérable. Lorsque nous avons implémenté une nouvelle fonctionnalité dans FL2, mais que nous voulons vérifier qu'elle s'exécute de la même manière que dans FL1, nous pouvons évaluer la fonctionnalité dans FL2, puis déclencher une fonction de secours. Nous sommes en mesure de comparer le comportement des deux systèmes, ce qui nous permet d'être parfaitement certains que notre implémentation s'est correctement déroulée.

Nous avons commencé à acheminer le trafic client par FL2 au début de l'année 2025, et nous avons progressivement augmenté le volume de trafic traité tout au long de l'année. Concrètement, nous avons observé deux graphiques : un premier représentant l'augmentation de la part de trafic acheminé vers FL2, et un second représentant la diminution de la part de trafic n'ayant pas pu être traité par FL2 et renvoyé à FL1 par la fonction de secours.

Nous avons lancé ce processus en acheminant le trafic de nos clients gratuits par le système. Nous avons pu démontrer que le système fonctionnait correctement, et nous avons pu réduire les taux d'utilisation de la fonction de secours pour nos principaux modules. Les superstars de la communauté Cloudflare ont joué le rôle de système d'alerte précoce, en effectuant des tests de vérification rapide et en signalant les incidents lorsqu'ils soupçonnaient que la nouvelle plateforme pouvait être à l'origine d'un nouveau problème signalé. Leur soutien a été déterminant en permettant à notre équipe de rapidement mener l'enquête, d'appliquer des correctifs ciblés ou de confirmer que la migration vers FL2 n'était pas en cause.

Nous avons ensuite poursuivi la mise en œuvre du système pour nos clients payants, en augmentant progressivement le nombre de clients utilisant le système. Nous avons également travaillé en étroite collaboration avec certains de nos plus importants clients, qui souhaitaient bénéficier des avantages qu'offre FL2 en termes de performances, et nous les avons intégrés dès le début, en échange de nombreux commentaires sur le système.

À l'heure actuelle, la plupart de nos clients utilisent FL2. Il nous reste encore quelques fonctionnalités à finaliser, et nous ne sommes pas tout à fait prêts à accueillir tous nos utilisateurs, mais notre objectif est de désactiver FL1 d'ici quelques mois.

Comme nous l'avons décrit au début de cet article, FL2 est considérablement plus rapide que FL1. La principale raison tient simplement au fait que FL2 effectue moins de tâches. Peut-être avez-vous remarqué, dans l'exemple de définition du module, la présence d'une ligne :

    filters: vec![],

Chaque module est capable de fournir un ensemble de filtres qui déterminent s'il est exécuté ou non. Cela signifie que nous n'exécutons pas la logique pour chaque produit et pour chaque requête ; nous pouvons très facilement sélectionner uniquement l'ensemble de modules requis. Le coût supplémentaire lié au développement de chaque nouveau produit a disparu.

Il existe une autre raison majeure expliquant l'amélioration des performances : FL2 est une base de code unique, mise en oeuvre dans un langage priorisant les performances. En comparaison, FL1 était basé sur NGINX (écrit en C), associé à LuaJIT (Lua et couches d'interface C) et contenait également de nombreux modules Rust.  Dans FL1, nous avons consacré beaucoup de temps et de mémoire à convertir les données d'une représentation nécessaire à un langage vers une représentation nécessaire à un autre.

En conséquence, nos mesures internes indiquent que FL2 utilise moins de la moitié des ressources de FL1, et bien moins de la moitié de la mémoire. C'est un énorme avantage : nous pouvons utiliser les ressources processeur pour offrir encore plus de fonctionnalités à nos clients !

Avec nos propres outils et des indicateurs de référence indépendants, tels que CDNPerf, nous avons mesuré l'impact de FL2 lors de son déploiement sur l'ensemble du réseau. Les résultats sont sans équivoque : les sites web répondent en moyenne 10 ms plus rapidement, ce qui représente une amélioration de 25 % des performances.

Par ailleurs, FL2 est intrinsèquement plus sécurisé que FL1. Aucun système logiciel n'est parfait, mais le langage Rust nous offre d'immenses avantages par rapport à LuaJIT. Rust dispose de contrôles mémoire puissants lors de la compilation, ainsi que d'un système de types permettant d'éviter de nombreuses catégories d'erreurs. Ajouté à notre système de modules rigides, il nous permet d'effectuer la plupart des modifications avec une grande confiance.

Bien entendu, aucun système n'est sécurisé s'il est incorrectement utilisé. En Rust, il est facile d'écrire du code entraînant une corruption de la mémoire. Pour réduire les risques, nous effectuons des analyses statiques et des contrôles rigoureux lors de la compilation, et nous appliquons des normes de codage, ainsi que des processus de test et de révision stricts.

Nous avons depuis longtemps adopté une politique selon laquelle toute défaillance inexpliquée de nos systèmes doit faire l'objet d'un examen prioritaire. Nous n'avons pas l'intention d'assouplir cette politique, bien que la cause principale des nouveaux incidents dans FL2 soit, jusqu'à présent, une défaillance matérielle. La diminution considérable de la fréquence de ces incidents nous laissera le temps de mener à bien ces enquêtes.

Nous allons consacrer le reste de l'année 2025 à la migration de FL1 vers FL2, et nous désactiverons FL1 au début de l'année 2026. Nous constatons déjà les avantages en termes de performances pour les clients et de rapidité de développement, et nous sommes impatients de les mettre à la disposition de tous nos clients.

Il reste un dernier service dont nous devons accomplir la migration complète. La case « HTTP & TLS Termination » du diagramme figurant au tout début de cet article est également un service NGINX, et nous sommes en train de le réécrire en Rust. Nous progressons bien dans cette migration, et nous prévoyons de la finaliser au début de l'année prochaine.

Ensuite, lorsque tout sera modulaire, codé en Rust, testé et mis à l'échelle, nous pourrons vraiment commencer à optimiser ! Nous réorganiserons et simplifierons la manière dont les modules se connectent les uns aux autres, nous développerons la prise en charge du trafic non HTTP tel que RPC et les flux, et bien davantage. 

Si vous souhaitez participer à l'aventure, consultez les postes vacants sur notre page d'offres d'emploi. Nous sommes toujours à la recherche de nouveaux talents pour nous aider à bâtir un Internet meilleur.