- Unkey, qui fournit un service d’authentification d’API, a quitté une architecture serverless basée sur Cloudflare Workers pour des serveurs avec état en Go, afin de résoudre des problèmes de performances et de complexité architecturale
- La nouvelle architecture offre des temps de réponse 6 fois plus rapides tout en éliminant les contournements complexes de cache et la surcharge des pipelines de données
- Dans un environnement serverless, l’absence de mémoire persistante garantie entre les invocations de fonctions imposait une requête réseau pour chaque lecture de cache, avec une latence p99 du cache supérieure à 30 ms
- En passant d’un système distribué à une architecture applicative plus simple, Unkey a rendu le self-hosting possible, gagné en indépendance vis-à-vis de la plateforme et nettement amélioré l’expérience développeur
- Le serverless reste adapté aux charges de travail irrégulières ou aux schémas simples requête/réponse, mais lorsqu’il faut une faible latence constante ou une gestion d’état persistante, des serveurs avec état sont plus efficaces
Limites du serverless et goulets d’étranglement de performance
- Chez Unkey, l’authentification API se trouvait sur le chemin critique des requêtes, où quelques millisecondes de latence avaient un impact direct sur l’expérience utilisateur
- Le déploiement edge mondial et l’auto-scaling de Cloudflare Workers étaient séduisants, mais l’absence de persistance du cache et la latence des requêtes réseau se sont révélées problématiques
-
Problème de cache
- Les fonctions serverless ne disposent pas de mémoire persistante entre les invocations, ce qui impose une requête réseau externe à chaque consultation du cache
- La latence p99 des consultations du cache Cloudflare a été mesurée à plus de 30 ms
- Même en empilant plusieurs couches de cache (SWR, Redis, etc.), on ne peut fondamentalement pas être plus rapide que “0 requête réseau”
- En conséquence, l’objectif de réponses en moins de 10 ms n’a pas pu être atteint
-
Problème de couplage au SaaS
- Le serverless réduit la charge de gestion d’infrastructure, mais en pratique il rend indispensables des outils SaaS supplémentaires
- cache → Redis, traitement batch → Queue, logs → Durable Objects, etc.
- Chaque service ajoute de la latence, des coûts et des points de défaillance
- Malgré l’usage combiné de Cloudflare Durable Objects, Queues, Workflows, etc., la complexité réelle a au contraire augmenté
-
Problème de pipeline de données
- Comme l’environnement serverless est éphémère, il faut flush les données immédiatement à chaque appel
- Pour traiter les événements, logs et métriques, Unkey a dû construire lui-même des services complexes de buffering et de relais
- Exemples :
- envoi batch des logs vers ClickHouse via
chproxy
- mise en place d’un serveur de buffering séparé pour contourner les limites de débit (rate limit) lors de l’envoi des logs vers Axiom
- Au final, même une simple fonction d’analytics a entraîné une complexité digne d’un système distribué de traitement d’événements
Passage à des serveurs avec état
- Avec l’introduction du serveur avec état v2 basé sur Go, le batching en mémoire et les flush périodiques sont devenus possibles
- Plus besoin de services supplémentaires ni de pipelines complexes
- La maintenabilité, le débogage et les tests en local ont été grandement simplifiés
-
Résultats de performance
- La comparaison entre
/v1/keys.verifyKey et /v2/keys.verifyKey montre une latence divisée par 6
- Malgré une infrastructure plus réduite que les 300 POP mondiaux de Cloudflare, les performances perçues par les utilisateurs se sont nettement améliorées
Avantages au-delà des performances
-
Self-hosting
- Comme Unkey dépendait du runtime Cloudflare, les clients ne pouvaient pas auto-héberger Unkey
- Le runtime Workers est techniquement open source, mais son exécution en local (même en mode développement) est extrêmement difficile
- Le passage à un serveur Go standard a grandement simplifié le self-hosting
- exécution possible avec la simple commande
docker run -p 8080:8080 unkey/api
- aucun runtime spécial ni configuration complexe nécessaires
- Les développeurs peuvent désormais lancer l’ensemble de la stack Unkey en local en quelques secondes, ce qui facilite fortement le débogage et les tests
- La vitesse du développement et du débogage en local a fortement progressé
-
Amélioration de l’expérience développeur
- Limites rencontrées en serverless :
- nécessité de tenir compte des contraintes d’exécution des fonctions
- difficulté à conserver un état entre les invocations
- débogage complexe des logs distribués
- environnement de test local peu pratique
- Le passage à des serveurs avec état a supprimé cette taxe de complexité (Complexity Tax)
-
Indépendance vis-à-vis de la plateforme
- Plus de dépendance à l’écosystème Cloudflare
- déploiement possible n’importe où
- utilisation possible de n’importe quelle base de données
- intégration de services tiers sans se soucier de la compatibilité du runtime
Stratégie de migration et enseignements
- La migration a aussi servi d’occasion pour corriger des problèmes de conception d’API accumulés au fil du temps
- La nouvelle API v2 fonctionne aux côtés de la v1, et les clients peuvent utiliser les deux versions pendant la période de dépréciation
- Un avantage du maintien du serverless est que même lorsque l’usage tombe à zéro, le coût d’exécution de l’API v1 reste faible, ce qui laisse le temps d’une migration gratuite
-
Ce qui a été conservé
- Tout n’a pas été abandonné dans l’approche serverless
- déploiement edge mondial : utilisation d’AWS Global Accelerator pour conserver une faible latence à l’échelle mondiale
- auto-scaling : Fargate gère la montée en charge sans les contraintes du serverless
-
Amélioration des performances du rate limiter
- Dans le modèle serverless, il fallait faire des compromis importants entre vitesse, précision et coût, et la nature distribuée du système rendait presque impossible d’obtenir les trois à la fois
- Avec des serveurs avec état et un état en mémoire, Unkey a pu construire un rate limiter plus rapide, plus précis et moins coûteux à exploiter
Quand le serverless est adapté (et quand il ne l’est pas)
-
Cas où le serverless est adapté
- charges de travail irrégulières : quand l’exécution n’est pas continue, l’économie du scale-to-zero est excellente
- schémas simples requête/réponse : lorsqu’un état persistant ou des pipelines de données complexes ne sont pas nécessaires
- architectures orientées événements : très efficace pour réagir à des événements sans gérer l’infrastructure
-
Cas où le serverless n’est pas adapté
- quand une faible latence constante est nécessaire : les dépendances au réseau externe dégradent les performances
- quand un état persistant est nécessaire : contourner l’absence d’état ajoute de la complexité
- charges de travail à haute fréquence : le modèle de facturation par appel devient peu économique
- quand un contrôle fin est nécessaire : l’abstraction de la plateforme peut devenir une contrainte
-
Coût de la complexité
- Le principal enseignement de la migration a été de comprendre le coût de complexité induit par les contournements des contraintes de plateforme
-
Ce qui avait été construit en serverless
- une bibliothèque de cache sophistiquée pour contourner l’absence d’état
- plusieurs services auxiliaires pour le traitement batch des données
- un pipeline de logs complexe pour la collecte de métriques
- des contournements élaborés pour le développement local
-
Avec des serveurs avec état
- tout cela a disparu
- passage d’un système distribué avec de nombreuses pièces en mouvement à une architecture applicative simple
- parfois, choisir une autre base est la meilleure solution plutôt que de contourner les contraintes
Prochaines étapes
- Aujourd’hui, Unkey s’exécute sur AWS Fargate derrière Global Accelerator, mais ce n’est qu’une solution provisoire
- L’an prochain, l’entreprise prévoit de lancer sa propre plateforme de déploiement, « Unkey Deploy », qui permettra aux clients — et à Unkey lui-même — d’exécuter Unkey où ils le souhaitent
- Le passage à des serveurs Go avec état constitue la première étape pour rendre Unkey réellement portable et auto-hébergeable
- Les détails d’implémentation sont publiés en open source dans le dépôt GitHub
3 commentaires
Moi aussi, à une époque, j’étais presque un adepte inconditionnel du serverless et j’appliquais des architectures serverless à tout-va, mais ces temps-ci je préfère davantage une structure construite avec une seule instance EC2 et une seule base RDS. Et ensuite, j’en détache progressivement les éléments nécessaires un par un. L’adoption du serverless est devenue quelque chose que j’examine mûrement avant de la faire.
Il y a plusieurs raisons à cela, mais j’ai constaté que s’il y a ne serait-ce qu’une seule personne dans l’équipe qui n’a pas de connaissances en serverless, les coûts de communication et de maintenance augmentent considérablement. Et en remettant des serveurs en service, j’ai de nouveau réalisé que le serverless n’était ni aussi économique ni aussi pratique que je l’avais imaginé.
Avis Hacker News
En tant que personne ayant utilisé des environnements serverless pendant des années, principalement Amazon Lambda mais pas seulement, je suis tout à fait d’accord avec l’auteur.
Le serverless allège certaines choses, mais en contrepartie il crée du travail ailleurs, car il faut résoudre tout un tas de « problèmes artificiels ».
Dans mon cas, un exemple concret concernait la limite de taille des uploads.
Quand nous avons migré une application existante vers le serverless, je pensais qu’il suffirait de créer un endpoint API pour l’import de gros volumes de données client et d’y adosser un worker en arrière-plan.
Mais sur « api gateway » — le proxy qui invoque le code — il était impossible d’uploader plus de 100 MB, et quand nous avons demandé s’il était possible de relever cette limite, on nous a simplement répondu de demander aux clients de découper leurs fichiers en plus petits morceaux avant l’upload.
Techniquement, cela peut sembler raisonnable, mais dans la vraie vie, aucun client ne va changer sa manière d’uploader pour ça.
C’est un peu le genre de chose qui « marche dans le vide » : en théorie, ça a l’air élégant, mais en pratique, le temps et l’argent économisés en passant au serverless finissent par être réinvestis dans la résolution de problèmes propres au serverless.
Pour résoudre ça, il faut fournir des URL S3 présignées.
On peut intégrer cela en laissant l’utilisateur uploader directement vers S3 puis renvoyer le résultat de l’upload, ou en distinguant les fichiers par un request id dans leur nom, par exemple.
Après des années sur AWS, je trouve ça pénible, mais je comprends aussi la limite de 100 MB, car laisser un endpoint d’upload de fichiers arbitraires ouvert expose fortement au risque d’attaque DoS.
Cela dit, vu les débits Internet actuels, ce seuil de 100 MB paraît un peu daté.
Malgré tout, je pense qu’une limite finit toujours par être nécessaire.
Mon entreprise a un temps été l’un des plus gros clients du service de certificats SSL d’AWS.
Pour prendre en charge des Vanity URL, donc des domaines personnalisés, il fallait un certificat SSL par domaine, et il nous en fallait plusieurs milliers.
L’outil de gestion des certificats d’AWS n’était vraiment confortable que jusqu’à quelques centaines, donc il a fallu environ trois mois pour régler ce problème.
J’ai été surpris de voir que certains services AWS ne savaient pas répondre rapidement aux besoins d’un tout petit nombre de clients atypiques.
Au départ, Lambda semblait extrêmement prometteur, donc nous l’avons adopté, mais au final nous avons abandonné tous nos projets Lambda et sommes revenus à des environnements conteneurisés quand c’était nécessaire.
Avec Lambda aussi, il faut mettre à jour le runtime Node tous les un à deux ans, tandis qu’avec des conteneurs on choisit soi-même le rythme, ce qui offre plus de souplesse.
Le problème le plus difficile en informatique, c’est de copier un fichier d’un ordinateur à un autre.
Je laisse une référence pour les lecteurs du futur.
Avec l’uploader et l’endpoint « tus », on dispose de fonctions comme le découpage ou la reprise d’upload, ce qui est bien adapté pour contourner ce genre de limites.
https://tus.io/
Comme l’explique l’article, le serverless a clairement sa place dans certains cas.
Mais je pense qu’il ne convient pas à la plupart des applications.
Sauf cas particulier, je ne prévois pas d’utiliser le serverless comme infrastructure principale.
En pratique, j’ai plutôt l’impression que cela rend la gestion de l’infrastructure plus pénible.
Chaque plateforme a ses propres exigences, ses propres méthodes de test et de développement, tout reste flou et les tests locaux sont difficiles.
Chaque couche d’abstraction a ses pièges selon la plateforme, et il n’existe pas de véritable standard.
Emballer un exécutable dans une image Docker me paraît plus simple, et cela permet aussi d’abstraire raisonnablement la configuration d’environnement, donc c’est un environnement de développement plus naturel pour moi.
J’ai le sentiment que l’abstraction minimale au niveau de Linux et du système de fichiers est la plus efficace.
Si besoin, on peut ensuite lancer cette image sur un serveur, à la demande ou en permanence.
Quand on regarde les modes techniques de ces dix dernières années, on voit souvent des technologies devenir populaires alors qu’elles ont d’abord servi à résoudre des problèmes qui n’existent réellement qu’à l’échelle de très grandes entreprises.
GraphQL, react, Tailwind, NextJS en sont quelques exemples.
Aucun outil n’est universel, et le plus important est de choisir en fonction de sa situation et de ses problèmes réels, avec de l’expérience et de la compréhension.
J’aimerais bien montrer à quel point j’essaie de faire tourner une app amazon lambda en local de manière « amusante ».
La tester avant déploiement, c’est un défi en soi.
Knative, le serverless pour Kubernetes, accepte directement les conteneurs.
Comme il s’agit d’un format de packaging standard, on peut passer facilement d’une plateforme à une autre.
Cette équipe développait en réalité non pas une application, mais une bibliothèque destinée à être intégrée dans une application serveur avec état.
L’avantage en performance venait aussi du fait que l’authentification était traitée près de l’environnement client, pas du serverless en lui-même.
En réalité, est-ce qu’aujourd’hui presque toutes les plateformes « serverless » n’acceptent pas des images Docker ?
Il me semble que Cloud Run le permet.
En fait, l’inquiétude porte surtout sur le fait que les « serverless function » abstraient beaucoup trop de choses.
ClickHouse n’aime pas les milliers de petits insert, donc nous regroupons les événements via un service Go appelé chproxy avant de les envoyer en gros batch.
Chaque Cloudflare Worker envoie ses événements analytiques à chproxy, puis chproxy les agrège et les transmet en masse à ClickHouse.
Comme il existait aussi une fonction d’insert asynchrone, je me demande pourquoi ils n’ont pas utilisé cela au lieu de créer un service séparé uniquement pour les données ClickHouse.
https://clickhouse.com/docs/optimize/asynchronous-inserts
J’ai l’impression que les développeurs sont ensevelis sous des outils censés « simplifier les choses ».
En réalité, la plupart des problèmes se résolvent très bien avec les outils les plus fondamentaux : compilateur, scripts bash, bibliothèques.
Cette obsession pour les outils finit parfois par nuire autant aux entreprises qu’aux développeurs.
À mon avis, Docker en 2013 a été le dernier outil à avoir apporté un changement vraiment général et positif.
Depuis, il y a beaucoup d’outils qui peuvent aider certaines entreprises, mais qu’on essaie d’appliquer partout, au point de casser la productivité ou d’abîmer les systèmes.
Aujourd’hui, des acteurs comme Cloudflare présentent les v8 isolates comme si c’était le « Docker de nouvelle génération », mais c’est adapté à certaines charges, pas à tout.
Le modèle consistant à « prendre une image docker et la mettre sur Internet » est tellement puissant qu’à mon avis, ce sera encore la méthode dominante en 2040.
Le problème, c’est aussi qu’il devient rare de trouver des gens qui maîtrisent les fondamentaux.
Le travail consiste de plus en plus à externaliser l’essentiel de la stack à des services tiers, et ce qu’on construit soi-même se limite à une partie du cœur applicatif.
Et même cela pourrait finir par être écrit par l’IA.
Tout le secteur est en train de cultiver une forme d’« impuissance apprise ».
Beaucoup plus de gens qu’on ne l’imagine connaissent mal les compilateurs, les scripts bash et les bibliothèques.
AWS lambda est presque trop bon marché.
C’est utile pour se faire remarquer !
Je n’ai jamais vu quelqu’un atteindre le grade de Staff grâce à un script bash.
J’aimerais poser une question au « vercel security checkpoint ».
Quand je me connecte sur iPhone avec Proton VPN et Firefox Focus en passant par des nœuds de sortie en Californie ou au Canada, j’obtiens constamment l’erreur code 99 « Failed to verify your browser ».
Quel est le problème ?
Ce fil renforce ma conviction.
Le terme serverless est si flou dans sa définition que le nom lui-même me paraît absurde.
Les serveurs existent toujours.
C’est un peu comme dire « sans électricité » alors qu’on utilise bel et bien de l’électricité.
On a juste changé le nom, sans vraiment expliquer ce qui se passe concrètement.
Je ne pense pas que la seule conclusion soit « le serverless est mauvais ».
La leçon la plus importante, c’est que lorsqu’un service a des dépendances, déplacer le service plus près du client sans déplacer aussi ces dépendances peut dégrader de façon inattendue l’expérience de bout en bout.
Il vaut donc mieux construire au plus près des dépendances ; et si cela ne suffit pas, il faut déplacer ou synchroniser toutes les dépendances près du client, mais en pratique cela devient souvent extrêmement complexe.
Cela dépend de la manière dont on utilise les dépendances et de leur fréquence d’utilisation ; pour une base de données, par exemple, faut-il être plus proche du serveur ou du client, cela varie selon l’usage.
Certains scénarios exigent une réponse rapide, d’autres tolèrent la latence.
On peut aussi découper différemment selon ce qu’il est possible de mettre en cache côté serveur ou côté client.
Je ne pense pas qu’il faille raisonner de façon strictement binaire.
Si l’on veut le meilleur rapport performance/prix, la bonne réponse est de configurer soi-même ses instances et de gérer directement ce dont on a besoin.
Inutile de laisser les fournisseurs cloud jouer les magiciens de la surfacturation.
Le « local maximum » actuel, c’est d’utiliser des conteneurs Docker comme environnement et artefact de déploiement standard, puis d’injecter seulement les secrets si nécessaire.
Cela facilite les tests en local et permet de conserver la plupart des avantages importants : automatisation de l’infrastructure, reproductibilité, etc.
Le serverless est excessif pour la plupart des applications, mais il convient bien à certaines.
En particulier, il peut être plus adapté aux utilitaires simples sans infrastructure propre, aux services à la demande, ou aux grandes applications stateless.
Cela ne veut pas dire que le serverless se limite forcément aux usages simples ; je pense surtout qu’il existe une contradiction fondamentale entre le modèle de « web app traditionnelle » et les plateformes serverless.
Je crois que je suis prêt à recevoir misterio.
https://github.com/daitangio/misterio
C’est un simple wrapper de cluster Docker stateless.
Ça a commencé dans mon homelab, puis ça a pris de l’ampleur.
Docker ressemble un peu aux microservices.
C’est adapté à certaines applications, mais la tendance a été de le survendre comme un standard universel.
L’abus de Docker crée une charge de patching de sécurité et d’exploitation ; l’utiliser partout sans discernement revient à mal gérer le risque.
Les problèmes de dépendances sont désormais résolus par la plupart des développeurs autrement qu’avec des installations globales.
Docker n’est plus aussi indispensable qu’avant, mais il reste dominant.
Du point de vue des hébergeurs, j’imagine que l’adoption de Docker augmente les marges d’au moins 10 %.
J’ai aussi l’impression que Docker fait partie de cette « obsession pour les outils » mentionnée plus bas.
Le vrai sujet, ce n’est pas que le serverless ne fonctionne pas, mais que les auteurs ne comprenaient pas bien la base qu’ils étaient en train de construire.
Héberger une API sensible à la latence sur un edge runtime stateless, c’est une erreur de débutant, et la souffrance qui en a résulté était tout à fait prévisible.
D’après mon expérience, la plupart des problèmes dans le cloud viennent d’un mauvais usage ou d’une mauvaise compréhension de l’architecture.
Ce sont des problèmes humains qu’une conception plus prudente aurait permis d’éviter.
Le vrai souci, en revanche, c’est que les fournisseurs cloud font beaucoup de marketing séduisant tout en cachant les chiffres réels de performance.
Impossible de savoir avant test si des Lambdas seront vraiment assez rapides pour ma charge, ou si la réplication externe d’AWS RDS conviendra.
J’ai appris par expérience qu’il faut benchmarker soi-même les performances réelles d’AWS.
Le point n’est pas que les auteurs n’aient pas compris, mais que l’information partagée par quelqu’un a de la valeur en soi.
Je ne pense pas qu’on puisse réduire cela à une « erreur de débutant ».
En réalité, les ingénieurs savent souvent qu’une approche donnée n’est pas adaptée au terrain, mais des managers l’imposent facilement sous prétexte que « c’est comme ça qu’on fait aujourd’hui ».
Ou bien les contraintes de temps et de budget obligent à faire un « moins bon choix ».
Il est aussi possible que l’équipe d’implémentation ne maîtrisait vraiment pas bien le sujet au départ, mais quoi qu’il en soit, partager ce genre d’histoire aide beaucoup toute la communauté à progresser.
D’après mon expérience, si j’ai besoin d’une garantie forte — auto-scaling rapide, faible latence, CPU, disque, débit réseau, etc. — le plus sûr reste de gérer directement des instances EC2.
Dès qu’on abandonne le contrôle en espérant des gains de performance, on finit par se heurter à des goulots d’étranglement impossibles à corriger.
Au fond, les auteurs reconnaissent simplement qu’ils sont « l’un des 10 000 d’aujourd’hui ».
https://xkcd.com/1053/
Personnellement, je leur suis reconnaissant d’avoir partagé cette information et ces erreurs.
L’ingénierie est toujours une bataille de coûts
Au début, on l’utilise pour réduire le temps consacré au prototypage ou à la construction du business
Plus tard, il faut réduire les coûts en optimisant
Ce genre d’article prouve en soi à quel point son auteur n’est pas un ingénieur
C’est n’importe quoi