Bien que les technologies sans serveur connaissent une popularité croissante ces dernières années, beaucoup de malentendus et d'inquiétudes y sont encore associés. La dépendance à un fournisseur, les outils, la gestion des coûts, le démarrage à froid, la surveillance et le cycle de développement - tous ces sujets sont activement discutés lorsqu'il s'agit de technologies sans serveur. Dans cet article, nous allons examiner certains des sujets mentionnés et partager des conseils ainsi que des liens vers des sources d'informations utiles qui permettront aux débutants de créer des applications sans serveur puissantes, flexibles et économiques.
Malentendus concernant les technologies sans serveur
Beaucoup pensent que l'absence de serveur et le traitement des données hors serveur (, FaaS) sont pratiquement équivalents. Cela signifie que la différence n'est pas très grande et qu'il vaut la peine d'adopter l'innovation. Bien qu'AWS Lambda ait été l'une des « étoiles » de l'apogée des technologies sans serveur et l'un des éléments les plus populaires de l'architecture sans serveur, cette architecture représente quelque chose de plus que le FaaS.
Le principe fondamental des technologies sans serveur est que vous n'avez pas à vous soucier de la gestion et de la mise à l'échelle de l'infrastructure, vous ne payez que pour ce que vous utilisez. De nombreux services répondent à ces critères - AWS DynamoDB, S3, SNS ou SQS, Graphcool, Auth0, Now, Netlify, Firebase et bien d'autres. En résumé, l'absence de serveur implique l'utilisation de toutes les capacités du cloud computing sans avoir à gérer l'infrastructure et à l'optimiser pour la mise à l'échelle. Cela signifie également que la sécurité au niveau de l'infrastructure n'est plus votre préoccupation, ce qui est un énorme avantage compte tenu de la difficulté et de la complexité de respecter les normes de sécurité. Enfin, vous n'avez pas besoin d'acheter l'infrastructure qui vous est mise à disposition.
L'absence de serveur peut être considérée comme un « état d'esprit » : une certaine mentalité lors de la conception de solutions. Évitez les approches nécessitant l'entretien d'une infrastructure quelconque. Avec une approche sans serveur, nous consacrons notre temps à résoudre des problèmes qui ont un impact direct sur le projet et qui apportent des avantages à nos utilisateurs : nous construisons une logique commerciale robuste, développons des interfaces utilisateur et concevons des API adaptatives et fiables.
Par exemple, si nous pouvons éviter la gestion et le support d'une plateforme de recherche en texte libre, c'est exactement ce que nous ferons. Cette approche de l'assemblage d'applications peut considérablement accélérer la mise sur le marché, car vous n'avez plus besoin de penser à la gestion d'une infrastructure complexe. Libérez-vous des responsabilités et des coûts associés à la gestion de l'infrastructure et concentrez-vous sur la création d'applications et de services dont vos clients ont besoin. Patrick Debois a qualifié cette approche , ce terme est accepté dans la communauté sans serveur. Les fonctions doivent être considérées comme un lien entre les services sous forme de modules déployables (plutôt que de déployer toute une bibliothèque ou une application web). Cela offre une granularité incroyable dans la gestion du déploiement et des modifications de l'application. Si vous ne pouvez pas déployer des fonctions de cette manière, cela peut indiquer que les fonctions accomplissent trop de tâches et doivent être refactorisées.
Certain people are concerned about vendor dependency when developing cloud applications. The same goes for serverless technologies, and it's unlikely this is a misconception. Based on our experience, creating serverless applications on AWS combined with the ability of AWS Lambda to integrate with other AWS services — all of this partly shapes the advantages of serverless architectures. It’s a good example of synergy, where the outcome of the combination is greater than just the sum of its parts. Trying to avoid vendor dependency may lead to even greater issues. When working with containers, it’s easier to manage your own level of abstraction between cloud providers. However, when it comes to serverless solutions, the effort won’t pay off, especially if economic efficiency is considered from the start. Make sure to find out how vendors deliver services. Some specialized services depend on points of integration with other vendors, and they might offer plug-and-play connectivity out of the box. It’s simpler to invoke Lambda from an API gateway endpoint than to proxy a request to some container or EC2 instance. Graphcool facilitates simple configuration with Auth0, which is easier than using third-party authentication tools.
Choosing the right vendor for your serverless application is an architectural level decision. When you build an application, you don’t expect to return to server management one day. Selecting a cloud vendor is no different from choosing to use containers or databases, or even a programming language.
Consider:
- What services you need and why.
- What services cloud providers offer and how you can combine them with your chosen FaaS solution.
- What programming languages are supported (whether dynamically or statically typed, compiled or interpreted, what benchmarks exist, performance on cold starts, what the open-source ecosystem is like, etc.).
- What your security requirements are (SLA, 2FA, OAuth, HTTPS, SSL, etc.).
- How to manage your CI/CD and software development cycles.
- What advantages you can leverage from infrastructure-as-code solutions.
Si vous étendez une application existante et que vous ajoutez progressivement des fonctionnalités sans serveur, cela peut limiter quelque peu les capacités disponibles. Cependant, presque toutes les technologies sans serveur offrent des API (via REST ou des files d'attente de messages), permettant de créer des extensions indépendamment du noyau de l'application et avec une intégration facile. Recherchez des services avec des API claires, une bonne documentation et une communauté solide, et vous ne serez pas déçu. La simplicité d'intégration peut souvent être une métrique clé, et c'est probablement l'une des principales raisons du succès d'AWS depuis la sortie de Lambda en 2015.
Quand la technologie sans serveur est-elle utile?
Les technologies sans serveur peuvent être appliquées presque partout. Cependant, leurs avantages ne se limitent pas seulement aux cas d'utilisation. Le seuil d'entrée pour le cloud computing est aujourd'hui si bas en grande partie grâce aux technologies sans serveur. Si des développeurs ont une idée mais ne savent pas comment gérer l'infrastructure cloud et optimiser les coûts, ils n'ont pas besoin de chercher un ingénieur pour cela. Si une startup souhaite créer une plateforme mais craint que les coûts puissent devenir incontrôlables, elle peut facilement se tourner vers des solutions sans serveur.
Grâce aux économies réalisées et à la simplicité de la mise à l'échelle, les solutions sans serveur s'appliquent aussi bien aux systèmes internes qu'externes, jusqu'aux applications web avec des millions d'utilisateurs. Les factures sont plutôt mesurées non pas en euros, mais en centimes. La location de l'instance AWS EC2 la plus simple (t1.micro) pendant un mois coûtera 15 €, même si vous ne l'utilisez pas (qui n'a jamais oublié de l'éteindre ?!). Pour mettre en perspective, pour atteindre un niveau de dépenses similaire sur la même période, vous auriez besoin d'exécuter Lambda, avec 512 Mo, pendant environ 3 millions de fois pendant 1 seconde. Et si vous n'utilisez pas cette fonction, vous ne payez rien.
Étant donné que la technologie sans serveur dépend principalement des événements, il est assez facile d'ajouter une infrastructure sans serveur à d'anciens systèmes. Par exemple, avec AWS S3, Lambda et Kinesis, vous pouvez créer un service d'analyse pour un ancien système de vente au détail, capable de recevoir des données via une API.
La plupart des plateformes sans serveur prennent en charge différents langages. Il s'agit le plus souvent de Python, JavaScript, C#, Java et Go. En général, il n'y a pas de restrictions sur l'utilisation de bibliothèques dans ces langages, vous pouvez donc utiliser vos bibliothèques open source préférées. Cependant, il est préférable de ne pas abuser des dépendances afin que vos fonctions s'exécutent de manière optimale et préservent les avantages de l'énorme évolutivité de vos applications sans serveur. Plus il faut charger de paquets dans le conteneur, plus le démarrage à froid prendra du temps.
Le démarrage à froid consiste à initialiser le conteneur, l'environnement d'exécution et le gestionnaire d'erreurs avant de pouvoir les utiliser. Cela peut entraîner un retard d'exécution des fonctions pouvant atteindre 3 secondes, ce qui n'est pas idéal pour les utilisateurs impatients. Cependant, les démarrages à froid se produisent lors de la première demande après quelques minutes d'inactivité de la fonction. Beaucoup considèrent donc cela comme un inconvénient mineur qu'on peut contourner en pingant régulièrement la fonction pour la maintenir en attente. Ou bien, ils ignorent tout simplement cet aspect.
Bien qu'AWS ait lancé, les bases de données SQL ne sont pas idéales pour ce type d'application, car lors des transactions, elles dépendent de connexions qui peuvent rapidement devenir un goulet d'étranglement avec un grand trafic sur AWS Lambda. Oui, les développeurs améliorent constamment Serverless Aurora, et vous devriez l'expérimenter, mais aujourd'hui, les solutions NoSQL commesont beaucoup mieux adaptées aux systèmes sans serveur. Cependant, il est indéniable que cette situation changera très bientôt.
Les outils imposent également de nombreuses restrictions, notamment en matière de tests locaux. Bien qu'il existe des solutions comme Docker-Lambda, DynamoDB Local et LocalStack, celles-ci nécessitent un travail minutieux et une configuration importante. Cependant, tous ces projets sont en développement actif, donc ce n'est qu'une question de temps avant que les outils atteignent le niveau dont nous avons besoin.
L'impact des technologies sans serveur sur le cycle de développement
Étant donné que votre infrastructure est simplement une configuration, vous pouvez déployer et gérer le code à l'aide de scripts, comme des scripts shell. Ou bien vous pouvez recourir à des solutions de type configuration-as-code comme . Bien que ce service ne propose pas de configurations pour tous les domaines, il permet de définir des ressources spécifiques à utiliser en tant que fonctions Lambda. Autrement dit, là où CloudFormation vous fait défaut, vous pouvez écrire votre propre ressource (fonction Lambda) pour combler cette lacune. Ainsi, vous pouvez faire tout ce que vous voulez, même configurer des dépendances en dehors de votre environnement AWS.
Puisque tout cela est simplement une configuration, vous pouvez paramétrer vos scripts de déploiement pour des environnements, régions et utilisateurs spécifiques, surtout si vous appliquez des solutions d'infrastructure en tant que code comme CloudFormation. Par exemple, vous pouvez déployer une copie de l'infrastructure pour chaque branche dans le dépôt, afin de les tester de manière totalement isolée pendant le développement. Cela accélère radicalement la récupération des retours des développeurs, lorsqu'ils souhaitent comprendre si leur code fonctionne correctement dans un environnement réel. Les responsables n'ont pas à s'inquiéter du coût de déploiement de nombreux environnements, puisqu'ils ne paient que pour l'utilisation réelle.
Les préoccupations des DevOps diminuent, car ils doivent simplement s'assurer que les développeurs ont la bonne configuration. Il n'est plus nécessaire de gérer des instances, des équilibres de charge ou des groupes de sécurité. C'est pourquoi le terme NoOps est de plus en plus utilisé, même s'il reste important de savoir configurer l'infrastructure, notamment quand il s'agit de la configuration IAM et de l'optimisation des ressources cloud.
Il existe des outils très puissants pour le monitoring et la visualisation, tels que Epsagon, Thundra, Dashbird et IOPipe. Ils permettent de surveiller l'état actuel des applications serverless, fournissent des journaux et des traces, enregistrent des métriques de performance et des goulets d'étranglement architecturaux, effectuent des analyses et des prévisions de coûts, et bien plus encore. Ils ne donnent pas seulement aux ingénieurs DevOps, aux développeurs et aux architectes une vision complète du fonctionnement des applications, mais permettent également aux responsables de suivre la situation en temps réel, avec des coûts de ressources calculés à la seconde et des prévisions de dépenses. Organiser cela avec une infrastructure gérée est bien plus difficile.
Il est beaucoup plus simple de concevoir des applications sans serveur, car vous n'avez pas à déployer des serveurs Web, à gérer des machines virtuelles ou des conteneurs, à patcher des serveurs, des systèmes d'exploitation, des passerelles Internet, etc. L'abstraction de toutes ces tâches permet à l'architecture sans serveur de se concentrer sur l'essentiel : répondre aux besoins des entreprises et des clients.
Bien que les outils puissent encore s'améliorer (ils progressent chaque jour), les développeurs peuvent se concentrer sur l'implémentation de la logique métier et sur la distribution optimale de la complexité de l'application entre différents services au sein de l'architecture. La gestion des applications sans serveur est basée sur des événements et est abstraite par le fournisseur de cloud (par exemple, SQS, événements S3 ou flux DynamoDB). Ainsi, les développeurs n'ont qu'à coder la logique métier pour réagir à des événements spécifiques, sans se soucier de la meilleure façon de gérer les bases de données et les files d'attente de messages, ou d'organiser le traitement optimal des données dans des stockages matériels spécifiques.
Le code peut être exécuté et débogué localement, comme pour n'importe quel processus de développement. Les tests unitaires restent inchangés. La capacité de déployer toute l'infrastructure d'une application à l'aide d'une configuration de pile personnalisée permet aux développeurs de recevoir rapidement des retours importants, sans se soucier du coût des tests ou de l'impact sur des environnements gérés coûteux.
Outils et méthodologies pour la construction d'applications sans serveur
Il n'existe pas de méthode spécifique pour construire des applications sans serveur, ni de jeu de services dédiés à cette tâche. Aujourd'hui, AWS est le leader parmi les solutions puissantes sans serveur, mais n'oubliez pas de considérer également , et . Si vous utilisez AWS, une approche recommandée pour assembler des applications est (SAM), surtout avec C#, car Visual Studio offre d'excellents outils. SAM CLI peut faire tout ce que fait Visual Studio, donc vous ne perdrez rien si vous passez à un autre IDE ou éditeur de texte. Bien sûr, SAM fonctionne aussi avec d'autres langages.
Si vous codez dans d'autres langages, le Serverless Framework est un excellent outil open source qui vous permet de configurer n'importe quoi à l'aide de fichiers de configuration YAML très puissants. De plus, le Serverless Framework prend en charge différents services cloud, donc nous le recommandons à ceux qui recherchent une solution multi-cloud. Il possède une grande communauté qui a créé de nombreux plugins pour tous les besoins.
Pour des tests locaux, les outils open source tels que Docker-Lambda, Serverless Local, DynamoDB Local et LocalStack sont bien adaptés. Les technologies sans serveur sont encore à un stade précoce de développement, tout comme les outils associés, donc lors de la configuration de scénarios de test complexes, vous devrez vous battre un peu. Cependant, déployer simplement une pile dans un environnement et y effectuer des tests est incroyablement bon marché. Et vous n'avez pas besoin de créer une copie locale exacte des environnements cloud.
Pour réduire la taille des paquets déployés et accélérer le chargement, utilisez AWS Lambda Layers.
Utilisez les bons langages de programmation pour des tâches spécifiques. Différents langages ont leurs avantages et inconvénients. Il existe de nombreux benchmarks, mais JavaScript, Python et C# (.NET Core 2.1+) sont les leaders en termes de performance dans AWS Lambda. Récemment, AWS Lambda a introduit l'API Runtime qui permet de spécifier le langage souhaité et l'environnement d'exécution, donc expérimentez.
Maintenez une petite taille de paquets pour le déploiement. Plus ils sont petits, plus ils se chargent rapidement. Évitez d'utiliser de grandes bibliothèques, surtout si vous n'utilisez que quelques fonctionnalités d'entre elles. Si vous programmez en JavaScript, utilisez des outils de construction comme Webpack pour optimiser le build et n'inclure que ce dont vous avez réellement besoin. Dans .NET Core 3.0, il existe QuickJit et Tiered Compilation, qui améliorent les performances et aident beaucoup lors des démarrages à froid.
La dépendance des fonctions sans serveur aux événements peut initialement compliquer la coordination de la logique métier. À cet égard, les files d'attente de messages et les automates d'état peuvent être incroyablement utiles. Les fonctions Lambda peuvent s'appeler mutuellement, mais faites-le uniquement si vous ne vous attendez pas à une réponse (« tiré et oublié ») — vous ne voulez pas être facturé pour avoir attendu qu'une autre fonction se termine. Les files de messages sont utiles pour isoler des parties de la logique métier, gérer les goulets d'étranglement des applications et traiter les transactions (à l'aide de files d'attente FIFO). Les fonctions AWS Lambda peuvent être associées à des files SQS pour servir de files de « messages bloqués », qui suivent les messages échoués pour une analyse ultérieure. Les fonctions AWS Step (automates d'état) sont très utiles pour gérer des processus complexes nécessitant la création de chaînes de fonctions. Plutôt qu'une fonction Lambda qui appelle une autre fonction, les fonctions Step peuvent coordonner les transitions d'état, transmettre des données entre les fonctions et gérer l'état global des fonctions. Cela permet de définir les conditions de réessai, ou ce qu'il faut faire en cas d'erreur spécifique — un outil très puissant dans des conditions particulières.
Conclusion
Ces dernières années, les technologies sans serveur se développent à un rythme sans précédent. Ce changement de paradigme est associé à certaines idées reçues. Grâce à l'abstraction de l'infrastructure et à la gestion de l'évolutivité, les solutions sans serveur offrent des avantages significatifs : de la simplification du développement et des processus DevOps à une forte réduction des coûts opérationnels.
Et bien que l'approche sans serveur ne soit pas sans défauts, il existe des méthodologies fiables et des modèles de conception qui peuvent aider à créer des applications sans serveur robustes ou à intégrer des éléments sans serveur dans des architectures existantes.
Source : habr.com
