Get best of the week

Conseils et sources pour créer des applications sans serveur


Bien que les technologies sans serveur aient rapidement gagné en popularité ces dernières années, de nombreuses idées fausses et préoccupations leur sont associées. Dépendance du fournisseur, outils, gestion des dépenses, démarrage à froid, surveillance et cycle de vie du développement - tous ces sujets sont activement discutés lorsqu'il s'agit de technologies sans serveur. Dans cet article, nous examinerons certains des sujets mentionnés et partagerons également des conseils et des liens vers des sources d'informations utiles, avec lesquelles les débutants peuvent créer des applications sans serveur puissantes, flexibles et économiques.

Idées fausses concernant les technologies sans serveur


Beaucoup pensent que l'absence de serveur et le traitement des données hors serveur ( Fonctions en tant que service , FaaS) sont presque la même chose. Donc, la différence n'est pas trop grande et cela vaut la peine d'introduire un nouveau produit. Bien qu'AWS Lambda ait été l'une des stars à l'apogée des technologies sans serveur et l'un des éléments les plus populaires de l'architecture sans serveur, cette architecture est plus que 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 l'infrastructure, vous ne payez que ce que vous utilisez. De nombreux services conviennent à ces critères - AWS DynamoDB, S3, SNS ou SQS, Graphcool, Auth0, Now, Netlify, Firebase et bien d'autres. En général, l'absence de serveur signifie utiliser toutes les capacités du cloud computing sans avoir besoin de gérer l'infrastructure et son optimisation dans un souci d'évolutivité. Cela signifie également que la sécurité au niveau de l'infrastructure n'est plus votre problème, mais un énorme avantage, étant donné la difficulté et la complexité de se conformer aux normes de sécurité. Enfin, vous n'avez pas besoin d'acheter l'infrastructure mise à votre disposition.

L'absence de serveur peut être considérée comme un "état d'esprit": une certaine mentalité dans la conception des solutions. Évitez les approches nécessitant la maintenance de toute infrastructure. Avec une approche sans serveur, nous passons du temps à résoudre des problèmes qui affectent directement le projet et apportent des avantages à nos utilisateurs: nous créons une logique commerciale durable, développons des interfaces utilisateur et développons des API adaptatives et fiables.

Par exemple, si vous pouvez éviter de gérer et de maintenir la plate-forme de recherche de texte gratuite, c'est ce que nous ferons. Cette approche de la création d'applications peut accélérer considérablement le lancement du produit sur le marché, car vous n'avez plus besoin de penser à la gestion d'infrastructures complexes. Éliminez les responsabilités et les coûts de gestion de votre infrastructure et concentrez-vous sur la création des applications et des services dont vos clients ont besoin. Patrick Debois a qualifié cette approche de «service utile», ce terme est adopté dans la communauté sans serveur. Les fonctions doivent être considérées comme un lien de connexion pour les services sous la forme de modules déployables (au lieu de déployer une bibliothèque ou une application Web entière). Cela fournit une granularité incroyable dans la gestion du déploiement et des changements dans 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 confus par la dépendance des fournisseurs dans le développement d'applications cloud. La même chose avec les technologies sans serveur, et ce n'est guère une conséquence de la confusion. D'après notre expérience, la création d'applications sans serveur sur AWS en combinaison avec la capacité d'AWS Lambda à intégrer d'autres services AWS - tout cela constitue en partie les avantages des architectures sans serveur. Il s'agit d'un bon exemple de synergie lorsque le résultat de la combinaison est plus que la simple somme des termes. En essayant d'éviter la dépendance du fournisseur, vous pouvez rencontrer des problèmes encore plus importants. Lorsque vous travaillez avec des conteneurs, il est plus facile de gérer votre propre niveau d'abstraction entre les fournisseurs de cloud. Mais quand il s'agit de solutions sans serveur, les efforts ne porteront pas leurs fruits, surtout si l'efficacité économique est prise en compte dès le début. Assurez-vous de savoir comment les fournisseurs fournissent des services.Certains services spécialisés dépendent de points d'intégration avec d'autres fournisseurs, et prêts à l'emploi, ils peuvent fournir une connectivité plug-and-play. Il est plus facile de fournir un appel Lambda à partir du point de terminaison de l'API de passerelle que de diriger la demande vers un conteneur ou une instance EC2. Graphcool fournit une configuration facile avec Auth0, ce qui est plus facile que d'utiliser une authentification tierce.

Choisir le bon fournisseur pour votre application sans serveur est une solution de niveau architectural. Lorsque vous créez une application, vous ne vous attendez pas à ce qu'un jour vous reveniez à 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 services sont fournis par les fournisseurs de cloud et comment les combiner à l'aide de la solution FaaS sélectionnée.
  • Quels sont les langages de programmation pris en charge (avec typage dynamique ou statique, compilés ou interprétés, quels sont les benchmarks, quelles sont les performances lors d'un démarrage à froid, quel est l'écosystème open source, etc.).
  • Quelles sont vos exigences de sécurité (SLA, 2FA, OAuth, HTTPS, SSL, etc.).
  • Comment gérer vos cycles de développement CI / CD et logiciels.
  • De quelles solutions d'infrastructure en tant que classe de code pouvez-vous profiter?

Si vous développez une application existante et ajoutez des fonctions sans serveur de manière incrémentielle, cela peut quelque peu limiter les options disponibles. Cependant, presque toutes les technologies sans serveur fournissent une sorte d'API (via REST ou files d'attente de messages) qui vous permet de créer des extensions quel que soit le noyau de l'application et avec une intégration simple. Recherchez des services avec des API claires, une bonne documentation et une communauté solide, et vous ne vous tromperez pas. La facilité d'intégration peut souvent être une mesure clé, et c'est probablement l'une des principales raisons du succès d'AWS depuis la sortie de Lambda en 2015.

Quand l'absence de serveur est utile


Les technologies sans serveur peuvent être appliquées presque partout. Cependant, leurs avantages ne sont pas limités à une seule application. Le seuil d'entrée dans le cloud est si bas aujourd'hui grâce aux technologies sans serveur. Si les développeurs ont une idée, mais ils ne savent pas comment gérer l'infrastructure cloud et optimiser les coûts, ils n'ont pas besoin de chercher une sorte d'ingénieur pour cela. Si une startup souhaite créer une plateforme, 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 un public de plusieurs millions de personnes. Les comptes sont mesurés non pas en euros, mais en cents. La location de l'instance la plus simple d'AWS EC2 (t1.micro) pendant un mois coûtera 15 €, même si vous n'en faites rien (qui n'a jamais oublié de l'éteindre?!). En comparaison, afin d'atteindre un tel niveau de dépenses déjà sur la même période de temps, vous devrez exécuter Lambda 512 Mo pendant 1 seconde environ 3 millions de fois. Et si vous n'utilisez pas cette fonction, 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 aux anciens systèmes. Par exemple, en utilisant AWS S3, Lambda et Kinesis, vous pouvez créer un service analytique pour un ancien système de vente au détail qui peut recevoir des données via l'API.

La plupart des plates-formes sans serveur prennent en charge différentes langues. Le plus souvent, ce sont Python, JavaScript, C #, Java et Go. Habituellement, dans toutes les langues, il n'y a pas de restrictions sur l'utilisation des bibliothèques, 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 fonctionnent de manière optimale et n'annulent pas les avantages de l'énorme évolutivité de vos applications sans serveur. Plus vous devez charger de colis dans le conteneur, plus le démarrage à froid prendra de temps.

Un démarrage à froid est lorsque vous devez d'abord initialiser le conteneur, le runtime et le gestionnaire d'erreurs avant de les utiliser. De ce fait, le retard dans l'exécution des fonctions peut atteindre 3 secondes, et ce n'est pas la meilleure option pour les utilisateurs impatients. Cependant, des démarrages à froid se produisent lors de la première utilisation après quelques minutes d'arrêt. Beaucoup de gens considèrent cela comme un inconvénient mineur qui peut être contourné en envoyant régulièrement une requête ping à une fonction pour la maintenir inactive. Ou même ignorer cet aspect.

Bien qu'AWS ait publié Serverless Aurora Serverless SQL DatabaseCependant, les bases de données SQL ne sont pas idéales pour une telle application, car lors de l'exécution de transactions, elles dépendent de connexions, qui peuvent rapidement devenir un goulot d'étranglement avec beaucoup de 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 comme DynamoDB sont bien meilleures pour les systèmes sans serveur . 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 telles que Docker-Lambda, DynamoDB Local et LocalStack, elles nécessitent cependant un travail minutieux et une quantité importante de configuration. Cependant, tous ces projets se développent activement, ce n'est donc qu'une question de temps avant que les outils n'atteignent 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 AWS CloudFormation . 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, lorsque CloudFormation vous laisse tomber, vous pouvez écrire votre propre ressource (fonction Lambda), ce qui comblera cet écart. De cette façon, vous pouvez tout faire, même configurer des dépendances en dehors de votre environnement AWS.

Étant donné que tout cela n'est qu'une configuration, vous pouvez paramétrer vos scripts de déploiement pour des environnements, des régions et des utilisateurs spécifiques, surtout si vous utilisez des solutions de classe d'infrastructure en tant que code comme CloudFormation. Par exemple, vous pouvez déployer une copie de l'infrastructure pour chaque branche dans le référentiel pour les tester complètement de manière isolée pendant le développement. Cela accélère considérablement les développeurs qui obtiennent des commentaires lorsqu'ils veulent comprendre si leur code fonctionne correctement dans un environnement en direct. Les gestionnaires n'ont pas à se soucier du coût de déploiement de nombreux environnements, car seule l'utilisation réelle est payante.

DevOps a moins de soucis car il suffit de 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 visuels très puissants comme Epsagon, Thundra, Dashbird et IOPipe. Ils vous permettent de surveiller l'état actuel des applications sans serveur, de fournir des journaux et un suivi, d'enregistrer des mesures de performances et des goulots d'étranglement d'architecture, d'effectuer une analyse des coûts et des prévisions, et bien plus encore. Ils donnent non seulement aux ingénieurs, développeurs et architectes DevOps une idée complète du fonctionnement des applications, mais permettent également aux gestionnaires de surveiller la situation en temps réel, avec des coûts de ressources par seconde et une prévision des coûts. Gérer cela avec une infrastructure gérée est beaucoup plus difficile.

La conception d'applications sans serveur est beaucoup plus simple, car vous n'avez pas besoin de déployer de serveurs Web, de gérer des machines ou conteneurs virtuels, des serveurs de correctifs, des systèmes d'exploitation, des passerelles Internet, etc. L'abstraction de toutes ces responsabilités permet à l'architecture sans serveur de se concentrer sur l'essentiel - la solution besoins des entreprises et des clients.

Bien que la boîte à outils puisse être meilleure (elle s'améliore chaque jour), les développeurs peuvent toutefois se concentrer sur la mise en œuvre de la logique métier et la meilleure distribution de la complexité des applications entre les différents services de l'architecture. Les applications sans serveur sont pilotées par les événements et résumées 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'à prescrire une logique métier pour répondre à certains événements, et vous n'avez pas à vous soucier de la meilleure façon de mettre en œuvre les bases de données et les files d'attente de messages, ou comment organiser le travail optimal avec les données dans des stockages matériels spécifiques.

Le code peut être exécuté et débogué localement, comme avec 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 faites attention à Google Cloud , Zeit et Firebase . Si vous utilisez AWS, le modèle d'application sans serveur (SAM) peut être recommandé comme approche de collecte des applications , en particulier lors de l'utilisation de C #, car Visual Studio est une excellente boîte à outils. SAM CLI peut tout faire de la même manière que Visual Studio, 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 langues, le Framework sans serveur est un excellent outil open source qui vous permet de configurer quoi que ce soit à l'aide de fichiers YAML de configuration très puissants. 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 plug-ins 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 sont encore à un stade précoce de développement, tout comme les outils pour elles, donc lors de la configuration de scénarios de test complexes, vous devrez transpirer. Cependant, l'extension de la pile dans l'environnement et les tests s'avèrent 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 le chargement.

Utilisez les langages de programmation appropriés pour des tâches spécifiques. Différentes langues ont leurs propres avantages et inconvénients. Il existe de nombreux benchmarks, mais JavaScript, Python et C # (.NET Core 2.1+) sont des leaders en termes de performances AWS Lambda. L'API Runtime est récemment apparue dans AWS Lambda, ce qui vous permet de spécifier la langue et le temps d'exécution souhaités, alors expérimentez.

Gardez la taille du package petite 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-unes. Si vous programmez en JavaScript, utilisez des outils de build comme Webpack pour optimiser votre build et n'inclure que ce dont vous avez vraiment besoin. .NET Core 3.0 a QuickJit et une compilation à plusieurs niveaux qui améliorent les performances et aident beaucoup lors des démarrages à froid.

La dépendance des fonctions sans serveur vis-à-vis des événements peut dans un premier temps compliquer la coordination de la logique métier. À cet égard, les files d'attente de messages et les machines d'état peuvent être extrêmement utiles. Les fonctions lambda sont capables de s’appeler les unes les autres, mais ne le faites que si vous ne vous attendez pas à recevoir une réponse («abattu et oublié») - vous ne voulez pas obtenir un compte pour attendre la fin d’une autre fonction. 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 des files d'attente FIFO). Les fonctions AWS Lambda peuvent être affectées aux files d'attente SQS en tant que files d'attente de messages bloqués qui suivent les messages ayant échoué pour une analyse ultérieure. Les fonctions d'étape AWS (machines à états) sont très utiles pour gérer des processus complexes qui nécessitent la création de chaînes de fonctions.Au lieu d'appeler une fonction Lambda une autre fonction, les fonctions Step peuvent coordonner les transitions d'état, transférer des données entre les fonctions et contrôler l'état global des fonctions. Cela vous permet de déterminer les conditions pour les tentatives, ou ce qui doit être fait lorsqu'une erreur spécifique se produit - dans certaines conditions, un outil très puissant.

Conclusion


Ces dernières années, les technologies sans serveur se sont développées à un rythme sans précédent. Il existe certaines idées fausses associées à ce changement de paradigme. En faisant abstraction de l'infrastructure et en gérant la mise à l'échelle, les solutions sans serveur offrent des avantages significatifs: du développement simplifié et des processus DevOps à des réductions importantes des coûts d'exploitation.
Bien que l'approche sans serveur ne soit pas sans inconvénients, il existe des méthodes fiables de modèles de conception qui peuvent être utilisées pour créer des applications sans serveur stables ou intégrer des éléments sans serveur dans les architectures existantes.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles