Bien que les technologies sans serveur aient rapidement gagné en popularité ces dernières années, de nombreuses idées fausses et craintes y sont encore associées. La dépendance vis-à-vis des fournisseurs, l'outillage, la gestion des coûts, le démarrage à froid, la surveillance et le cycle de vie du développement sont tous des sujets brûlants lorsqu'il s'agit de technologies sans serveur. Dans cet article, nous allons explorer certains des sujets mentionnés, ainsi que partager des conseils et des liens vers des sources d'informations utiles pour aider les débutants à créer des applications sans serveur puissantes, flexibles et économiques.
Idées fausses sur les technologies sans serveur
Beaucoup de gens pensent que le traitement sans serveur et sans serveur (, FaaS) sont presque la même chose. Cela signifie que la différence n'est pas trop grande et qu'il vaut la peine d'introduire une nouveauté. Bien qu'AWS Lambda ait été l'une des stars de l'apogée du sans serveur et l'un des éléments les plus populaires de l'architecture sans serveur, cette architecture est cependant bien plus que le FaaS.
Le principe de base des technologies sans serveur est que vous n'avez pas à vous soucier de la gestion et de la mise à l'échelle de votre infrastructure, vous ne payez que 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 général, sans serveur signifie utiliser toute la puissance du cloud computing sans avoir besoin de gérer l'infrastructure et de 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é du respect des normes de sécurité. Enfin, vous n'avez pas à acheter l'infrastructure mise à votre disposition.
Le serverless peut être considéré comme un « état d'esprit » : une certaine mentalité lors de la conception de solutions. Évitez les approches qui nécessitent l'entretien de toute infrastructure. Avec une approche sans serveur, nous passons du temps à résoudre des tâches qui affectent directement le projet et apportent des avantages à nos utilisateurs : nous créons une logique métier durable, développons des interfaces utilisateur et développons des API adaptatives et fiables.
Par exemple, s'il est possible d'éviter de gérer et de maintenir une plate-forme de recherche en texte libre, c'est ce que nous ferons. Cette approche de la création 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. Éliminez les responsabilités et les coûts de gestion de l'infrastructure et concentrez-vous sur la création des applications et des services dont vos clients ont besoin. Patrick Debois a appelé cette approche , le terme est adopté dans la communauté sans serveur. Les fonctions doivent être considérées comme un lien vers des services en tant que modules déployables (au lieu de déployer une bibliothèque entière ou une application Web). Cela offre une granularité incroyable pour la gestion du déploiement et des modifications apportées à l'application. Si vous ne pouvez pas déployer des fonctions de cette manière, cela peut indiquer que les fonctions effectuent trop de tâches et doivent être refactorisées.
Certains sont déconcertés par la dépendance vis-à-vis du fournisseur lors du développement d'applications cloud. Il en va de même pour les technologies sans serveur, et ce n'est pas une idée fausse. D'après notre expérience, la création d'applications sans serveur sur AWS, combinée à la capacité d'AWS Lambda à regrouper d'autres services AWS, fait partie de la force des architectures sans serveur. C'est un bon exemple de synergie, lorsque le résultat de la combinaison est plus que la simple somme des termes. Essayer d'éviter la dépendance vis-à-vis d'un fournisseur peut entraîner encore plus de problèmes. Lorsque vous travaillez avec des conteneurs, il est plus facile de gérer votre propre couche d'abstraction entre les fournisseurs de cloud. Mais lorsqu'il s'agit de solutions sans serveur, l'effort ne sera pas payant, surtout si la rentabilité est prise en compte dès le départ. Assurez-vous de savoir comment les fournisseurs fournissent des services. Certains services spécialisés s'appuient sur des points d'intégration avec d'autres fournisseurs et peuvent fournir une connectivité plug-and-play prête à l'emploi. Il est plus facile de fournir un appel Lambda à partir d'un point de terminaison d'API de passerelle que de transmettre la demande à un conteneur ou à une instance EC2. Graphcool fournit une configuration facile avec Auth0, ce qui est plus facile que d'utiliser des outils d'authentification tiers.
Choisir le bon fournisseur pour votre application sans serveur est une décision architecturale. Lorsque vous créez une application, vous ne vous attendez pas à revenir un jour à la gestion des serveurs. Choisir un fournisseur de cloud n'est pas différent de choisir d'utiliser des conteneurs ou une base de données, ou même un langage de programmation.
Considérer:
- De quels services avez-vous besoin et pourquoi.
- Quels sont les services fournis par les fournisseurs de cloud et comment vous pouvez les combiner avec la solution FaaS que vous avez choisie.
- Quels sont les langages de programmation supportés (avec typage dynamique ou statique, compilés ou interprétés, quels sont les benchmarks, quelles sont les performances sur un démarrage à froid, quel est l'écosystème open source, etc.).
- Quelles sont vos exigences en matière de sécurité (SLA, 2FA, OAuth, HTTPS, SSL, etc.).
- Comment gérer vos cycles de CI/CD et de développement logiciel.
- De quelles solutions d'infrastructure en tant que code pouvez-vous tirer parti.
Si vous étendez une application existante et ajoutez progressivement des fonctionnalités sans serveur, cela peut limiter quelque peu les fonctionnalités disponibles. Cependant, presque toutes les technologies sans serveur fournissent une sorte d'API (via REST ou des files d'attente de messages) qui vous permet de créer des extensions indépendantes du cœur de l'application et avec une intégration facile. Recherchez des services avec des API claires, une bonne documentation et une communauté forte, et vous ne pouvez pas vous tromper. La facilité d'intégration peut souvent être un indicateur clé, et c'est probablement l'une des principales raisons pour lesquelles AWS a connu un tel succès depuis la sortie de Lambda en 2015.
Quand le sans serveur est bon
Les technologies sans serveur peuvent être appliquées presque partout. Cependant, leurs avantages ne se limitent pas à un seul mode d'application. La barrière à l'entrée pour le cloud computing est aujourd'hui si faible grâce aux technologies sans serveur. Si les développeurs ont une idée, mais qu'ils 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 le faire. Si une startup souhaite créer une plate-forme mais craint que les coûts ne deviennent incontrôlables, elle peut facilement se tourner vers des solutions sans serveur.
En raison des économies de coûts et de la facilité de mise à l'échelle, les solutions sans serveur sont également applicables aux systèmes internes et externes, jusqu'à une application Web avec une audience de plusieurs millions. Les comptes sont mesurés non pas en euros, mais en centimes. Louer l'instance la plus simple d'AWS EC2 (t1.micro) pour un mois coûtera 15 €, même si vous ne faites rien avec (qui n'a jamais oublié de l'éteindre ?!). En comparaison, pour atteindre ce niveau de dépenses sur la même période, vous auriez besoin d'exécuter un Lambda de 512 Mo pendant 1 seconde environ 3 millions de fois. Et si vous n'utilisez pas cette fonctionnalité, vous ne payez rien.
Étant donné que le sans serveur est principalement piloté par les événements, il est assez facile d'ajouter une infrastructure sans serveur à des systèmes plus anciens. Par exemple, en utilisant AWS S3, Lambda et Kinesis, vous pouvez créer un service d'analyse pour un ancien système de vente au détail qui peut recevoir des données via une API.
La plupart des plates-formes sans serveur prennent en charge plusieurs langues. Il s'agit le plus souvent de Python, JavaScript, C#, Java et Go. Habituellement, il n'y a aucune restriction sur l'utilisation des bibliothèques dans toutes les langues, vous pouvez donc utiliser vos bibliothèques open source préférées. Cependant, il est conseillé de ne pas abuser des dépendances afin que vos fonctions s'exécutent de manière optimale et n'annulent pas les avantages de l'énorme évolutivité de vos applications sans serveur. Plus il y a de colis à charger dans le conteneur, plus le démarrage à froid prendra du temps.
Un démarrage à froid correspond au moment où vous devez d'abord initialiser le conteneur, l'environnement d'exécution et le gestionnaire d'erreurs avant de les utiliser. Pour cette raison, le retard dans l'exécution des fonctions peut aller jusqu'à 3 secondes, et ce n'est pas la meilleure option pour les utilisateurs impatients. Cependant, les démarrages à froid se produisent au premier appel après quelques minutes d'inactivité. Beaucoup considèrent cela comme une gêne mineure qui peut être contournée en cinglant régulièrement la fonction pour la maintenir au ralenti. Ou ils ignorent complètement cet aspect.
Bien qu'AWS ait publiéCependant, les bases de données SQL ne sont pas idéales pour cette application, car elles dépendent des connexions pour effectuer les transactions, ce qui peut rapidement devenir un goulot d'étranglement avec un trafic important sur AWS Lambda. Oui, les développeurs améliorent constamment Serverless Aurora, et vous devriez l'expérimenter, mais aujourd'hui, les solutions NoSQL comme. Cependant, il ne fait aucun doute que cette situation changera très bientôt.
La boîte à outils impose également de nombreuses restrictions, notamment dans le domaine des tests locaux. Bien qu'il existe des solutions comme Docker-Lambda, DynamoDB Local et LocalStack, elles nécessitent un travail acharné et une quantité importante de configuration. Cependant, tous ces projets sont activement développés, ce n'est donc qu'une question de temps avant que la boîte à outils n'atteigne le niveau dont nous avons besoin.
L'impact des technologies sans serveur sur le cycle de développement
Étant donné que votre infrastructure n'est qu'une configuration, vous pouvez définir et déployer du code à l'aide de scripts, tels que des scripts shell. Ou vous pouvez recourir à des solutions de classe de configuration en tant que code comme . Bien que ce service ne fournisse pas de configuration pour tous les domaines, il vous permet de définir des ressources spécifiques à utiliser en tant que fonctions Lambda. Autrement dit, là où CloudFormation vous échoue, vous pouvez écrire votre propre ressource (fonction Lambda) qui comblera cet écart. De cette façon, vous pouvez tout faire, même configurer des dépendances en dehors de votre environnement AWS.
Comme il ne s'agit que de configuration, vous pouvez personnaliser vos scripts de déploiement pour des environnements, des régions et des utilisateurs spécifiques, en particulier si vous utilisez des solutions d'infrastructure en tant que code telles que CloudFormation. Par exemple, vous pouvez déployer une copie de l'infrastructure pour chaque branche du référentiel afin de pouvoir les tester complètement de manière isolée pendant le développement. Cela accélère considérablement les commentaires des développeurs lorsqu'ils veulent comprendre si leur code fonctionne correctement dans un environnement réel. Les responsables n'ont pas à se soucier du coût du déploiement de plusieurs environnements, car ils ne paient que pour l'utilisation réelle.
Les DevOps ont moins de soucis car ils doivent seulement s'assurer que les développeurs ont la bonne configuration. Vous n'avez plus besoin de gérer des instances, des équilibreurs ou des groupes de sécurité. Par conséquent, le terme NoOps est de plus en plus utilisé, bien qu'il soit toujours important de pouvoir configurer l'infrastructure, en particulier en ce qui concerne la configuration IAM et l'optimisation des ressources cloud.
Il existe des outils de surveillance et de visualisation très puissants comme Epsagon, Thundra, Dashbird et IOPipe. Ils vous permettent de surveiller l'état actuel de vos applications sans serveur, de fournir une journalisation et un traçage, de capturer des mesures de performances et des goulots d'étranglement d'architecture, d'effectuer des analyses et des prévisions de coûts, etc. Ils offrent non seulement aux ingénieurs, développeurs et architectes DevOps une vue complète des performances des applications, mais permettent également aux responsables de surveiller la situation en temps réel, avec des coûts de ressources par seconde et des prévisions de coûts. Il est beaucoup plus difficile d'organiser cela avec une infrastructure gérée.
La conception d'applications sans serveur est beaucoup plus facile car vous n'avez pas à déployer de serveurs Web, à gérer des machines virtuelles ou des conteneurs, des serveurs de correctifs, des systèmes d'exploitation, des passerelles Internet, etc. En supprimant toutes ces responsabilités, une architecture sans serveur peut se concentrer sur le cœur - la solution aux besoins de l'entreprise et des clients.
Bien que la boîte à outils puisse être améliorée (elle s'améliore de jour en jour), les développeurs peuvent se concentrer sur la mise en œuvre de la logique métier et répartir au mieux la complexité de l'application sur différents services au sein de l'architecture. La gestion des applications sans serveur est basée sur les événements et abstraite par le fournisseur de cloud (par exemple, les événements SQS, S3 ou les flux DynamoDB). Par conséquent, les développeurs n'ont qu'à écrire une logique métier pour répondre à certains événements, et n'ont pas à se soucier de la meilleure façon d'implémenter des bases de données et des files d'attente de messages, ou d'organiser un travail optimal avec des données dans des stockages matériels spécifiques.
Le code peut être exécuté et débogué localement, comme pour tout processus de développement. Les tests unitaires restent les mêmes. La possibilité de déployer une infrastructure d'application complète avec une configuration de pile personnalisée permet aux développeurs d'obtenir rapidement des commentaires importants sans se soucier du coût des tests ou de l'impact sur les environnements gérés coûteux.
Outils et techniques pour créer des applications sans serveur
Il n'existe aucun moyen spécifique de créer des applications sans serveur. Ainsi qu'un ensemble de services pour cette tâche. AWS est aujourd'hui le leader des puissantes solutions sans serveur, mais regardez également , и . Si vous utilisez AWS, l'approche recommandée pour la collecte des applications est (SAM), en particulier lors de l'utilisation de C #, car Visual Studio dispose d'excellents outils. L'interface de ligne de commande SAM peut faire tout ce que Visual Studio peut faire, vous ne perdrez donc rien si vous passez à un autre IDE ou éditeur de texte. Bien sûr, SAM fonctionne également avec d'autres langues.
Si vous écrivez dans d'autres langages, le Serverless Framework est un excellent outil open source qui vous permet de configurer n'importe quoi avec des fichiers de configuration YAML très puissants. Le Serverless Framework prend également en charge divers services cloud, nous le recommandons donc à ceux qui recherchent une solution multi-cloud. Il a une énorme communauté qui a créé un tas de plugins pour tous les besoins.
Pour les tests locaux, les outils open source Docker-Lambda, Serverless Local, DynamoDB Local et LocalStack sont bien adaptés. Les technologies sans serveur en sont encore à leurs premiers stades de développement, tout comme les outils qui leur sont destinés. Par conséquent, lors de la configuration de scénarios de test complexes, vous devrez travailler dur. Cependant, le simple déploiement de la pile dans un environnement et les tests y sont incroyablement bon marché. Et vous n'avez pas besoin de faire une copie locale exacte des environnements cloud.
Utilisez les couches AWS Lambda pour réduire la taille des packages déployés et accélérer les téléchargements.
Utilisez les bons langages de programmation pour des tâches spécifiques. Différentes langues ont leurs propres avantages et inconvénients. Il existe de nombreuses références, mais JavaScript, Python et C# (.NET Core 2.1+) sont les leaders en termes de performances AWS Lambda. AWS Lambda a récemment introduit l'API Runtime, qui vous permet de spécifier la langue et l'environnement d'exécution souhaités, alors expérimentez.
Gardez des tailles de package petites pour le déploiement. Plus ils sont petits, plus ils se chargent rapidement. Évitez d'utiliser de grandes bibliothèques, surtout si vous en utilisez quelques fonctionnalités. Si vous programmez en JavaScript, utilisez un outil de construction comme Webpack pour optimiser votre construction et n'incluez que ce dont vous avez vraiment besoin. .NET Core 3.0 a QuickJit et Tiered Compilation qui améliore les performances et aide beaucoup lors des démarrages à froid.
La dépendance des fonctions sans serveur aux événements peut rendre difficile la coordination de la logique métier au début. À cet égard, les files d'attente de messages et les machines d'état peuvent être extrêmement utiles. Les fonctions Lambda peuvent s'appeler, mais ne le faites que si vous n'attendez pas de réponse ("fire and forget") - vous ne voulez pas être facturé pour avoir attendu qu'une autre fonction se termine. Les files d'attente de messages sont utiles pour isoler des parties de la logique métier, gérer les goulots d'étranglement des applications et traiter les transactions (à l'aide de files d'attente FIFO). Les fonctions AWS Lambda peuvent être attribuées aux files d'attente SQS en tant que files d'attente de messages bloqués qui gardent une trace des messages ayant échoué pour une analyse ultérieure. Les fonctions d'étape AWS (machines d'état) sont très utiles pour gérer des processus complexes qui nécessitent un chaînage de fonctions. Au lieu qu'une fonction Lambda appelle une autre fonction, les fonctions d'étape peuvent coordonner les transitions d'état, transmettre des données entre les fonctions et gérer l'état global des fonctions. Cela vous permet de définir des conditions de nouvelle tentative, ou ce qu'il faut faire lorsqu'une erreur particulière se produit - un outil très puissant dans certaines conditions.
Conclusion
Ces dernières années, les technologies sans serveur se sont développées à un rythme sans précédent. Certaines idées fausses sont associées à ce changement de paradigme. En faisant abstraction de la gestion de l'infrastructure et de la mise à l'échelle, les solutions sans serveur offrent des avantages significatifs, allant de processus de développement et DevOps simplifiés à des réductions massives des coûts d'exploitation.
Bien que l'approche sans serveur ne soit pas sans inconvénients, il existe des modèles de conception robustes qui peuvent être utilisés pour créer des applications sans serveur robustes ou intégrer des éléments sans serveur dans des architectures existantes.
Source: habr.com