Qu'est-ce que l'informatique sans serveur et quand faut-il l'utiliser?

L'informatique sans serveur est un nouveau paradigme de codage qui vous permet d'exécuter du code sans configurer de serveurs. Il est proposé en tant que service par de nombreux fournisseurs de cloud, notamment Amazon et Google. De quoi parle tout ce battage médiatique?

Qu'est-ce que sans serveur?

«Sans serveur» est un peu abusif – votre code sera toujours exécuté sur un serveur quelque part. Vous n'aurez simplement pas à vous en soucier, car le métal sur lequel il s'exécute sera entièrement géré pour vous «dans le cloud», vous laissant vous concentrer uniquement sur les logiciels. C'est l'attrait des solutions sans serveur; réduire les coûts de gestion des serveurs vous permet d'économiser de l'argent, à la fois sur le coût de la main-d'œuvre des administrateurs système et sur le coût de fonctionnement d'un VPS, en particulier celui qui peut être plus que ce dont vous avez besoin.

Le sans serveur est une vaste catégorie, mais la plupart des services comprendront trois éléments principaux:

• Aucun serveur à gérer (évidemment).
• Mise à l'échelle automatique sans configuration supplémentaire. Le code étant exécuté dans de petits conteneurs, il est facile de lancer plusieurs conteneurs en parallèle.
• Facturation à l'utilisation. Cela peut rendre le code sans serveur moins cher qu’une solution VPS traditionnelle, car vous n’exploitez probablement pas ce VPS à la charge maximale tout le temps.

Cela fait du serveur sans serveur un modèle compétitif basé uniquement sur le coût. Pour un site comme Bustle, le passage à AWS Lambda leur a permis de réaliser des économies de 84% par rapport à leur ancienne architecture. La mise à l'échelle des solutions sans serveur est beaucoup plus linéaire, car vous n'aurez pas à payer pour des instances de serveur individuelles.

PaaS contre FaaS

Il est important de clarifier la différence entre les modèles PaaS et FaaS «sans serveur», car le marketing pour chaque type est en grande partie le même.

La plate-forme en tant que service (PaaS) supprime les serveurs, mais ne touche pas à votre code sous-jacent et n'applique aucune nouvelle pratique de codage. Cela se fait généralement via des conteneurs tels que Docker, où des instantanés de votre application peuvent être déployés très rapidement sur plusieurs serveurs. Avec certains services, comme AWS Fargate et Azure Container Instances, vous n'avez pas du tout à vous soucier des serveurs, ce qui les rend «sans serveur». Avec d'autres services, comme Heroku, vous êtes toujours facturé par serveur, mais vous n'avez pas à vous soucier de le configurer vous-même, et la mise à l'échelle sur plusieurs instances est facile.

La fonction en tant que service (FaaS) supprime complètement l'idée de serveurs. Au lieu de cela, votre code est déclenché, exécute une fonction rapide et vous facture la mémoire et le temps de calcul que vous avez utilisés. Les modèles FaaS renforcent l'idée de «microservices», décomposant votre application en ses composants et développant chacun d'entre eux individuellement. Cela ne fonctionne pas pour tout, mais quand c'est le cas, cela peut considérablement accélérer le développement et la maintenance par rapport aux conceptions d'applications «monolithiques» traditionnelles. AWS Lambda, Google Cloud Functions et Azure Functions sont tous des modèles FaaS.

FaaS est généralement considéré comme un calcul «sans serveur», bien que ce ne soit peut-être pas le terme le plus descriptif. «Microservices» est beaucoup plus représentatif des idées derrière FaaS et les modèles «sans serveur». Vous pouvez toujours créer des microservices avec des services PaaS, mais FaaS vous oblige à le faire.

Là où les microservices brillent

Imaginez que votre application est une grande application monolithique, avec de nombreuses pièces mobiles différentes.

Toutes ces parties de votre application se parlent et dépendent les unes des autres pour que tout fonctionne. Mais c'est compliqué, tout est entrelacé et la gestion des dépendances devient pénible. Si vous souhaitez que plusieurs équipes travaillent sur différentes parties de l'application, vous vous cognerez les épaules assez souvent.

Un modèle d'application basé sur des microservices divise tout en son propre service. Ceux-ci peuvent toujours fonctionner sur la même machine, mais peut-être voudrez-vous les empaqueter avec Docker pour les exécuter sur des serveurs séparés, ou les mettre à l'échelle sur un cluster avec Kubernetes. C’est beaucoup plus facile à faire lorsque vous pouvez mettre à l’échelle une pièce séparément des autres.

Cela peut être décomposé davantage avec les fournisseurs FaaS, où maintenant ces blocs de construction peuvent être des fonctions uniques au lieu de services entiers. Par exemple, vous pourriez avoir une fonction pour redimensionner automatiquement les images pour différents appareils, comme le Seattle Times utilise Lambda pour. Vous pouvez créer des fonctions distinctes pour chaque point de terminaison d'API REST et renoncer complètement à exécuter un serveur d'API.

De toute évidence, ce modèle ne fonctionne pas pour toutes les applications. Certaines choses ne sont pas conçues pour être séparées, et le faire rétroactivement peut être une énorme douleur. Mais quand cela fonctionne, vous pouvez vous retrouver avec une application très structurée qui est plus facile à réparer lorsqu'elle commence à se briser.

Les microservices ne sont pas toujours plus simples

Les microservices sont plus propres, et lorsque vous disposez de tout, ils ont l'air beaucoup plus beaux que la conception monolithique désordonnée que de nombreuses applications utilisent. Mais quelqu'un doit concevoir toute cette structure.

La création d'une application basée sur des microservices met beaucoup de pression sur votre cycle DevOps, en particulier lors de la planification de tout. Bien que vous puissiez démarrer une application monolithique et tout créer au fur et à mesure, les microservices nécessitent une planification minutieuse dès le départ. Cela nécessite de bons architectes et une bonne communication avec le reste de l'équipe sur la structure de l'application.

Et avec plus de services viennent plus de choses à surveiller, déboguer et maintenir. Si vous n'avez qu'une petite équipe de développement, essayer de créer et de réparer de nombreux services à la fois peut être écrasant.

FaaS force également spécifiquement le verrouillage des fournisseurs. Bien que vous puissiez généralement prendre une image Docker et la déployer sur un autre fournisseur, la création de votre application sur un service tel que Lambda vous oblige à n'utiliser Lambda que pour héberger votre application. Vous vous retrouvez enfermé dans l'écosystème et, tout à coup, vous n'écrivez pas de code JavaScript, vous écrivez du code Lambda. Vous avez toujours le contrôle sur ce que vous écrivez, il est donc possible de le porter vers un autre service, mais se détacher d'un service sur lequel vous comptez est généralement plus difficile qu'il n'y paraît.

En outre, les services FaaS ne sont généralement pas destinés à être exécutés 24h / 24 et 7j / 7. Si vous utilisez des fonctions Lambda pour créer une application qui déclenche constamment des fonctions Lambda, vous allez augmenter votre facture plus que simplement payer pour un VPS.

Quand et quand ne pas utiliser sans serveur

Les services PaaS comme AWS Fargate exécutent simplement des applications conteneurisées sans vous avertir du métal sur lequel elles fonctionnent. Vous pouvez basculer l'ensemble de votre infrastructure applicative vers un service comme celui-ci sans aucun problème. De plus, avec PaaS, le clustering est facile et l'adoption de quelques idéaux du modèle de microservices peut vous aider à améliorer l'évolutivité de votre application sans trop de restructuration.

Les services FaaS sont plus compliqués. Ils ne conviennent pas à tout mais sont très utiles lorsqu'ils sont utilisés correctement. Ils sont parfaits pour les services backend simples et légers qui n'ont pas besoin de beaucoup de configuration ou d'un VPS complet pour les exécuter. Vous pouvez les utiliser comme compléments à votre application existante, et bien que vous puissiez créer une application complète basée sur des microservices en utilisant uniquement des fonctions cloud sans serveur, cette décision est beaucoup plus complexe.

Mais l'argent est également un facteur majeur, et si les microservices et les modèles d'application sans serveur peuvent être plus difficiles à planifier, si vous parvenez à le faire, vous économiserez beaucoup d'argent.

AWS Lambda est également très utile en conjonction avec d'autres services AWS. Les fonctions Lambda peuvent être déclenchées en fonction d'actions dans votre infrastructure AWS, telles que l'exécution automatique d'une fonction lorsqu'un fichier est déposé dans un compartiment S3. Si vous utilisez déjà les services AWS, Lambda peut être un excellent outil d'automatisation.