L'informatique sans serveur offre un certain nombre d'avantages aux développeurs web, notamment l'évolutivité, une mise sur le marché plus rapide et des dépenses réduites. Toutefois, dans certains cas, ces avantages peuvent être contrebalancés par d'autres préoccupations.
Cet article s'articule autour des points suivants :
Contenu associé
Qu'est-ce que le serverless ?
Serverless Vs Containers
Informatique serverless et Javascript
Informatique de périphérie
Function as a Service (FaaS)
Abonnez-vous à theNET, le récapitulatif mensuel de Cloudflare des idées les plus populaires concernant Internet !
Copier le lien de l'article
L'informatique sans serveur offre un certain nombre d'avantages par rapport aux infrastructures traditionnelles basées sur le cloud ou centrées sur les serveurs. Pour de nombreux développeurs, les architectures sans serveur offrent une plus grande évolutivité, une plus grande flexibilité et un délai de mise en production plus court, le tout à un coût réduit. Avec les architectures sans serveur, les développeurs n'ont pas à se soucier de l'achat, du dimensionnement et de la gestion des serveurs backend. Cependant, l'informatique sans serveur n'est pas une solution miracle pour tous les développeurs d'applications web.
L'informatique sans serveur est une architecture dans laquelle un fournisseur assure les services backend au fur et à mesure des besoins. Pour en savoir plus sur l'informatique sans serveur, voir Qu'est-ce que l'informatique sans serveur ?
Bien que l'informatique "sans serveur" se déroule en fait sur des serveurs, les développeurs n'ont jamais à s'occuper des serveurs. Ils sont gérés par le fournisseur. Cela peut réduire l'investissement nécessaire dans les DevOps, ce qui diminue les dépenses, et cela permet également aux développeurs de créer et d'étendre leurs applications sans être limités par la capacité des serveurs.
Comme dans le cas d'un forfait téléphonique à la carte, les développeurs ne sont facturés que pour ce qu'ils utilisent. Le code ne s'exécute que lorsque les fonctions de backend sont nécessaires à l'application sans serveur, et le code s'adapte automatiquement en fonction des besoins. L'approvisionnement est dynamique, précis et en temps réel. Certains services sont si précis qu'ils décomposent leurs coûts par tranches de 100 millisecondes. En revanche, dans une architecture traditionnelle "à serveur complet", les développeurs doivent prévoir à l'avance la capacité du serveur dont ils auront besoin et l'acheter, qu'ils l'utilisent ou non.
Imaginez que la poste puisse, comme par magie, ajouter et retirer des camions de livraison à volonté, augmenter la taille de sa flotte en fonction des pics de courrier (par exemple, juste avant la fête des mères) et réduire sa flotte pour les périodes où moins de livraisons sont nécessaires. C'est essentiellement ce que les applications sans serveur sont capables de faire.
Les applications construites avec une infrastructure sans serveur s'adapteront automatiquement à la croissance de la base de l'utilisateur ou à l'augmentation de l'utilisation. Si une fonction doit être exécutée à plusieurs reprises, les serveurs du fournisseur la démarrent, l'exécutent et la terminent au fur et à mesure des besoins, souvent à l'aide de conteneurs. (les fonctions démarrent plus rapidement si elles ont été exécutées récemment – voir « Les performances peuvent être affectées » ci-dessous). Par conséquent, une application sans serveur sera capable de traiter un nombre exceptionnellement élevé de demandes tout comme elle le ferait pour une demande unique émanant d'un seul utilisateur. Une application traditionnellement structurée avec une quantité fixe d'espace serveur peut être dépassée par une augmentation soudaine de l'utilisation.
Grâce à une infrastructure sans serveur, il n'est pas nécessaire de télécharger du code sur les serveurs ou de procéder à une quelconque configuration de backend afin de publier une version fonctionnelle d'une application. Les développeurs peuvent très rapidement télécharger des bouts de code et lancer un nouveau produit. Ils peuvent charger le code en une seule fois ou une fonction à la fois, puisque l'application n'est pas une simple pile monolithique mais plutôt un ensemble de fonctions mises à disposition par le fournisseur.
Cela permet également de mettre à jour, de réparer, de corriger ou d'ajouter rapidement de nouvelles fonctionnalités à une application. Il n'est pas nécessaire d'apporter des modifications à l'ensemble de l'application ; au contraire, les développeurs peuvent mettre à jour l'application une fonction à la fois.
Comme l'application n'est pas hébergée sur un serveur d'origine, son code peut être exécuté de n'importe où. Il est donc possible, selon le fournisseur utilisé, d'exécuter les fonctions de l'application sur des serveurs proches de l'utilisateur final. Cela permet de réduire la latence car les requêtes de l'utilisateur n'ont plus à parcourir tout le chemin jusqu'à un serveur d'origine. Cloudflare Workers permet ce type de réduction de latence sans serveur.
Il est difficile de reproduire l'environnement sans serveur afin de voir comment le code se comportera réellement une fois déployé. Le débogage est plus compliqué parce que les développeurs n'ont pas de visibilité sur les processus backend, et parce que l'application est divisée en fonctions séparées et plus petites. Le terrain de jeu Cloudflare Workers est un bac à sable qui permet de réduire les frictions lors des tests et du débogage
Lorsque les fournisseurs gèrent l'ensemble du backend, il peut ne pas être possible de vérifier entièrement leur sécurité, ce qui peut notamment poser un problème pour les applications qui traitent des données personnelles ou sensibles.
Comme les entreprises ne se voient pas attribuer leurs propres serveurs physiques distincts, les fournisseurs sans serveur exécutent souvent le code de plusieurs de leurs clients sur un seul serveur à un moment donné. Ce problème de partage de machines avec d'autres parties est connu sous le nom de « multi-location », pensez à plusieurs entreprises qui essaient de louer et de travailler dans un seul bureau en même temps. La multi-location peut affecter les performances des applications et, si les serveurs multi-locataires ne sont pas configurés correctement, ils peuvent entraîner une exposition des données. La multi-location n'a que peu ou pas d'impact sur les réseaux dont le bac à sable fonctionne correctement et dont l'infrastructure est suffisamment puissante. Par exemple, Cloudflare exploite un réseau de 15 Tbps avec une capacité excédentaire suffisante pour atténuer la dégradation du service, et toutes les fonctions sans serveur hébergées par Cloudflare fonctionnent dans leur propre bac à sable (via le moteur Chrome V8).
Cela limite les types d'applications qui peuvent fonctionner de manière économique dans une architecture sans serveur. Étant donné que les fournisseurs sans serveur font payer le temps d'exécution du code, il peut être plus coûteux d'exécuter une application avec des processus de longue durée dans une infrastructure sans serveur que dans une infrastructure traditionnelle.
Comme il ne fonctionne pas en permanence, le code sans serveur peut avoir besoin de "démarrer" lorsqu'il est utilisé. Ce temps de démarrage peut dégrader les performances. Toutefois, si un code est utilisé régulièrement, le fournisseur de services sans serveur le gardera prêt à être activé – une demande de ce code prêt à l'emploi est appelée "démarrage à chaud". Une demande de code qui n'a pas été utilisé depuis un certain temps est appelée "démarrage à froid".
Cloudflare Workers évite largement le problème du démarrage à froid en utilisant le moteur Chrome V8, qui, dans la plupart des cas, est capable de démarrer et d'exécuter du code JavaScript en moins de 5 millisecondes. Si le code est déjà en cours d'exécution, le temps de réponse est inférieur à une milliseconde. En savoir plus sur les performances des différentes plateformes serverless.
Permettre à un fournisseur de proposer tous les services backend d'une application augmente inévitablement le confinement auprès de ce fournisseur. La mise en place d'une architecture sans serveur avec un seul fournisseur peut rendre difficile le changement de fournisseur si nécessaire, d'autant plus que chaque fournisseur offre des fonctionnalités et des flux de travail légèrement différents. (Cloudflare Workers est plus facile à migrer parce qu'il est écrit en JavaScript et écrit en regard de l'API largement utilisée des Service Workers).
Les développeurs qui souhaitent réduire leur délai de mise sur le marché et créer des applications légères et flexibles, pouvant être étendues ou mises à jour rapidement, peuvent tirer un grand profit de l'informatique sans serveur.
Les architectures sans serveur permettront de réduire les coûts des applications dont l'utilisation est irrégulière, les périodes de pointe alternant avec des périodes de faible ou d'absence de trafic. Pour de telles applications, l'achat d'un serveur ou d'un bloc de serveurs qui fonctionnent en permanence et sont toujours disponibles, même lorsqu'ils ne sont pas utilisés, peut constituer un gaspillage de ressources. Une structure sans serveur réagira instantanément en cas de besoin et n'entraînera pas de coûts lorsqu'elle sera au repos.
En outre, les développeurs qui souhaitent rapprocher certaines ou toutes leurs fonctions d'application des utilisateurs finaux pour réduire la latence auront besoin d'une architecture au moins partiellement sans serveur, car cela nécessite de déplacer certains processus hors du serveur d'origine.
Dans certains cas, il est plus logique, tant du point de vue des coûts que de l'architecture du système, d'utiliser des serveurs dédiés qui sont soit autogérés, soit proposés en tant que service. Par exemple, les grandes applications avec une charge de travail assez constante et prévisible peuvent nécessiter une configuration traditionnelle, et dans ce cas, la configuration traditionnelle est probablement moins coûteuse.
En outre, il peut être extrêmement difficile de migrer les applications existantes vers une nouvelle infrastructure dont l'architecture est totalement différente.
Cloudflare Workers est un produit qui permet aux développeurs d'écrire des fonctions JavaScript et de les déployer à la périphérie du réseau Cloudflare. Il est ainsi possible d'exécuter du code d'application dans une architecture sans serveur aussi près que possible de l'utilisateur final, ce qui réduit au minimum la latence.