Architectures sans serveur – Bien choisir son serveur d impression

À l’instar de nombreuses tendances en matière de logiciels, il n’existe aucune vision claire de ce que Serverless est. Pour       Pour commencer, il englobe deux domaines différents mais qui se chevauchent: Dans cet article, nous nous concentrerons principalement sur FaaS. Non seulement est-ce le domaine de Serverless       plus récent et suscitant beaucoup de battage médiatique, mais il a des différences importantes dans la façon dont nous       pense généralement à l'architecture technique. BaaS et FaaS sont liés dans leurs attributs opérationnels (par exemple, aucune gestion de ressources)       et sont fréquemment utilisés ensemble. Les grands fournisseurs de cloud disposent tous de «portefeuilles sans serveur»       comprenant à la fois les produits BaaS et FaaS, par exemple, voici       Amazon Serverless page de produit. La base de données Firebase BaaS de Google contient des informations explicites sur FaaS.       soutien par Fonctions Google Cloud pour       Base de feu. Il existe des liens similaires entre les deux zones et les plus petites entreprises. Auth0 a commencé avec un produit BaaS qui implémentait de nombreuses facettes d’utilisateur       gestion, puis a créé le Webtask du service FaaS associé. La société a poussé cette idée encore plus loin avec Extend, qui permet à d’autres sociétés SaaS et BaaS d’ajouter facilement une       FaaS permet aux produits existants de créer un produit unifié Serverless.

Quelques exemples

Applications pilotées par l'interface utilisateur Pensons à un système traditionnel à trois niveaux, orienté client, avec une interface côté serveur.           logique. Un bon exemple est une application de commerce électronique typique — oserais-je dire un magasin pour animaux de compagnie en ligne? Traditionnellement, l’architecture ressemblera au schéma ci-dessous. Disons           implémenté en Java ou Javascript côté serveur, avec un code HTML + Javascript           composant en tant que client:

Avec cette architecture, le client peut être relativement inintelligent, avec une grande partie de la           logique dans le système – authentification, navigation dans les pages, recherche, transactions – implémentée           par l'application serveur. Avec une architecture sans serveur, cela peut ressembler davantage à ceci:

Ceci est une vue simplifiée massivement, mais même ici, nous voyons un certain nombre de           changements:

Nous avons supprimé la logique d’authentification dans l’application d’origine et remplacé             avec un service BaaS tiers (par exemple, Auth0.) En utilisant un autre exemple de BaaS, nous avons donné au client un accès direct à un sous-ensemble de             notre base de données (pour les listes de produits), elle-même entièrement hébergée par un tiers             (Google Firebase, par exemple). Nous avons probablement un profil de sécurité différent pour le client.             accéder à la base de données de cette manière que pour les ressources du serveur qui accèdent au             base de données. Ces deux points précédents impliquent un tiers très important: une logique qui était dans le             Le serveur Pet Store se trouve maintenant dans le client, par exemple, en gardant une trace d’une session utilisateur,             comprendre la structure UX de l’application, lire à partir d’une base de données et             traduire cela en une vue utilisable, etc. Le client est en passe de devenir un             Application d'une seule page. Nous voudrons peut-être conserver certaines fonctionnalités liées à l'UX sur le serveur si, par exemple,             Il nécessite beaucoup d’informatique ou nécessite l’accès à une quantité importante de données. Dans notre animal de compagnie             magasin, un exemple est "recherche". Au lieu d’avoir un serveur toujours en fonctionnement, comme cela existait dans             l’architecture originale, nous pouvons implémenter une fonction FaaS qui répond à             Requêtes HTTP via une passerelle API (décrite plus loin). Le client et le serveur             Fonction de «recherche» lue dans la même base de données pour les données de produit. Si nous choisissons d’utiliser AWS Lambda comme plate-forme FaaS, nous pouvons transférer le code de recherche à partir de             le serveur Pet Store original à la nouvelle fonction de recherche de magasin pour animaux sans             réécrire, puisque Lambda prend en charge Java et Javascript, notre implémentation originale             langues. Enfin, nous pouvons remplacer notre fonctionnalité «achat» par un autre logiciel FaaS distinct.             fonction, en choisissant de le garder côté serveur pour des raisons de sécurité plutôt que             réimplémentez-le dans le client. Il est également fronté par une passerelle API. Briser différents             exigences logiques en composants déployés séparément est une approche très commune lorsque             en utilisant FaaS.

Un peu en arrière, cet exemple montre un autre point très important à propos de           Architectures sans serveur. Dans la version d'origine, tous les flux, le contrôle et la sécurité étaient           géré par l’application du serveur central. Dans la version sans serveur, il n'y a pas de central           arbitre de ces préoccupations. Au lieu de cela, nous voyons une préférence pour chorégraphie sur           orchestration, chaque composant jouant un rôle plus conscient sur le plan architectural: une idée           également commun dans une approche de microservices. Une telle approche présente de nombreux avantages. Comme le note Sam Newman dans son Création de microservices livre, systèmes construits de cette façon           sont souvent «plus souples et plus aptes au changement», à la fois dans leur ensemble et par le biais de           mises à jour des composants; la division des préoccupations est meilleure; et il y a aussi des           Les avantages de coûts fascinants, un point que Gojko Adzic discute dans cet excellent discours. Bien entendu, une telle conception est un compromis: elle nécessite une meilleure surveillance distribuée           (plus sur cela plus tard), et nous comptons plus significativement sur les capacités de sécurité du           plate-forme sous-jacente. Plus fondamentalement, il y a un plus grand nombre de pièces en mouvement à           ne nous préoccupons pas de l’application monolithique que nous avions à l’origine.           Si les avantages de la flexibilité et du coût valent la complexité supplémentaire de multiples           composants backend est très dépendant du contexte.

Applications pilotées par message Un autre exemple est un service backend de traitement de données. Dites que vous écrivez une application centrée sur l'utilisateur qui doit répondre rapidement à l'interface utilisateur           demandes, et, secondairement, il doit capturer tous les différents types d'activité de l'utilisateur           qui se produisent, pour un traitement ultérieur. Pensez à un système de publicité en ligne:           lorsqu'un utilisateur clique sur une annonce, vous souhaitez très rapidement la rediriger vers la cible de celle-ci.           un d. Dans le même temps, vous devez collecter le fait que le clic est arrivé afin que vous           peut facturer l'annonceur. (Cet exemple n’est pas hypothétique. Mon ancienne équipe de           Intent Media avait exactement ce besoin, qu'il a mis en place           de manière sans serveur.) Traditionnellement, l'architecture peut ressembler à celle ci-dessous. Le «serveur publicitaire» de manière synchrone           répond à l'utilisateur (non affiché) et publie également un «message de clic» sur un canal. Ce           Le message est ensuite traité de manière asynchrone par une application de traitement de "clic" qui met à jour une           base de données, par exemple, pour décrémenter le budget de l’annonceur.

Dans le monde sans serveur, cela ressemble à:

Pouvez-vous voir la différence? Le changement d’architecture est beaucoup plus petit ici par rapport à           notre premier exemple – c’est pourquoi le traitement de messages asynchrone est un cas d’utilisation très populaire           pour les technologies sans serveur. Nous avons remplacé un consommateur de messages de longue date application avec un FaaS une fonction. Cette fonction s’exécute dans la fenêtre événementielle.           contexte fourni par le fournisseur. Notez que le fournisseur de la plateforme de cloud fournit à la fois le message           courtier et l’environnement FaaS – les deux systèmes sont étroitement liés. L’environnement FaaS peut également traiter plusieurs messages en parallèle en instanciant           plusieurs copies du code de fonction. Selon la façon dont nous avons écrit le processus original, cette           peut être un nouveau concept que nous devons considérer.

Déballage "Fonction en tant que service" Nous avons déjà beaucoup parlé de FaaS, mais il est temps de bien comprendre ce que cela signifie. Faire         cela, regardons la description d'ouverture         pour le produit FaaS d'Amazon: Lambda. J'ai ajouté quelques jetons, que je développerai plus en détail.

AWS Lambda vous permet d'exécuter du code sans provisionner ni gérer les serveurs. (1) …         Avec Lambda, vous pouvez exécuter du code pour pratiquement tout type d’application ou d’arrière-plan.         un service (2) – tous avec zéro administration. Il suffit de télécharger votre code et Lambda prend         soin de tout le nécessaire pour courir (3) et échelle (4) votre code avec high         disponibilité. Vous pouvez configurer votre code pour qu'il se déclenche automatiquement à partir d'autres serveurs AWS.         prestations de service (5) ou appelez-le directement depuis n'importe quelle application web ou mobile (6).

Fondamentalement, FaaS consiste à exécuter du code d’arrière-plan sans gérer votre propre serveur.           systèmes ou vos propres applications serveur de longue durée. Cette deuxième clause – de longue durée           applications serveur – est une différence essentielle par rapport aux autres architectures modernes           les tendances telles que les conteneurs et la PaaS (plate-forme en tant que service). Si nous revenons à notre exemple de traitement des clics de précédemment, FaaS remplace le           serveur de traitement des clics (éventuellement une machine physique, mais certainement une           application) avec quelque chose qui n'a pas besoin d'un serveur provisionné, ni d'une application           cela fonctionne tout le temps. Les offres FaaS ne nécessitent pas de codage pour un framework ou une bibliothèque spécifique. FaaS           les fonctions sont des applications régulières en matière de langage et d’environnement. Pour           Par exemple, les fonctions AWS Lambda peuvent être implémentées «première classe» en Javascript, python, aller, etc.           n’importe quel langage JVM (Java, Clojure, Scala, etc.), ou n’importe quel langage .NET. Cependant votre Lambda           fonction peut également exécuter un autre processus qui est fourni avec son artefact de déploiement, afin           vous pouvez utiliser n'importe quel langage capable de compiler un processus Unix (voir Apex, plus tard           dans cet article). Les fonctions FaaS ont cependant d'importantes restrictions architecturales, surtout quand           vient à l'état et la durée d'exécution. Nous y reviendrons bientôt. Reprenons notre exemple de traitement des clics. Le seul code qui doit changer           lors du passage à FaaS, le code de la «méthode principale» (de démarrage) est supprimé, et probablement           le code spécifique qui correspond au gestionnaire de messages de niveau supérieur (l '"interface d'écoute de message")           implémentation), mais il pourrait ne s'agir que d'un changement de signature de méthode. Le reste du code           (par exemple, le code qui écrit dans la base de données) n’est pas différent dans un monde FaaS. Le déploiement est très différent des systèmes traditionnels car nous n’avons pas de serveur           applications pour nous exécuter. Dans un environnement FaaS, nous téléchargeons le code de notre fonction.           au fournisseur FaaS, et le fournisseur fait tout le nécessaire pour le provisionnement           ressources, instanciation de machines virtuelles, gestion de processus, etc. La mise à l'échelle horizontale est complètement automatique, élastique et gérée par le fournisseur. Si           votre système doit traiter 100 demandes en parallèle, le fournisseur traitera cette           sans aucune configuration supplémentaire de votre part. Les «conteneurs de calcul» exécutant votre           les fonctions sont éphémères, le fournisseur FaaS les créant et les détruisant simplement           par besoin d'exécution. Plus important encore, avec FaaS le fournisseur gère toutes les ressources sous-jacentes           approvisionnement et allocation—Pas de gestion de cluster ou de machine virtuelle requise par l'utilisateur à           tout. Revenons à notre processeur de clics. Dites que nous passions une bonne journée et clients           cliquaient dix fois plus d'annonces que d'habitude. Pour l'architecture traditionnelle, serait           notre application de traitement des clics peut-elle gérer cela? Par exemple, avons-nous développé notre           application pour pouvoir gérer plusieurs messages à la fois? Si nous le faisions, est-ce qu'on courrait           instance de l'application suffira-t-elle à traiter la charge? Si nous sommes en mesure d'exécuter plusieurs           processus, le calibrage automatique est-il automatique ou devons-nous reconfigurer cela manuellement? Avec un           L’approche FaaS a déjà répondu à toutes ces questions. Vous devez écrire la fonction.           à l'avance pour assumer le parallélisme à l'échelle horizontale, mais à partir de ce point sur le FaaS           fournisseur gère automatiquement tous les besoins en mise à l'échelle. Les fonctions dans FaaS sont généralement déclenchées par des types d'événement définis par le fournisseur. Avec           Ces stimuli Amazon AWS incluent les mises à jour S3 (fichier / objet), l'heure (tâches planifiées) et           messages ajoutés à un bus de messages (par exemple, Kinesis). La plupart des fournisseurs permettent également aux fonctions d'être déclenchées en réponse à HTTP entrant.           demandes; Dans AWS, cela est généralement possible grâce à une passerelle API. Nous avons utilisé une API           passerelle dans notre animalerie exemple pour nos fonctions «recherche» et «achat». Les fonctions peuvent           également être invoqués directement via une API fournie par la plate-forme, de manière externe ou interne.           même environnement en nuage, mais il s’agit d’une utilisation relativement rare.

Etat Les fonctions FaaS ont des restrictions importantes en matière de communication locale           (lié à la machine / à l’instance), c’est-à-dire les données que vous stockez dans des variables en mémoire, ou des données.           que vous écrivez sur le disque local. Vous avez un tel stockage disponible, mais vous n'avez pas           garantir que cet état persiste lors de multiples invocations et, plus fortement,           vous ne devriez pas supposer que l'état d'un appel d'une fonction sera disponible pour           une autre invocation de la même fonction. Les fonctions FaaS sont donc souvent décrites comme           apatride, mais il est plus exact de dire que tout état d’une fonction FaaS qui est           doit être persistant doit être extériorisé en dehors de la FaaS           instance de fonction. Pour les fonctions FaaS qui sont naturellement apatrides, c’est-à-dire celles qui fournissent une           transformation fonctionnelle de leur contribution à leur production – cela ne pose aucun problème. Mais pour           d’autres peut avoir un impact important sur l’architecture des applications, même si ce n’est pas unique.           l'un – le concept de «l'application à douze facteurs» a précisément la même restriction. De telles fonctions orientées vers les états           utilise généralement une base de données, un cache inter-applications (comme Redis) ou un réseau           magasin de fichiers / objets (comme S3) pour stocker l’état des demandes ou pour fournir des informations supplémentaires           nécessaire pour traiter une demande.

Durée d'exécution Les fonctions FaaS sont généralement limitées dans le temps pendant lequel chaque appel est autorisé à s'exécuter. À           présenter le «délai d'attente» pour qu'une fonction AWS Lambda réponde à un événement d'au plus cinq           minutes, avant d'être terminé. Microsoft Azure et Google Cloud Functions ont des fonctions similaires.           limites. Cela signifie que certaines classes de tâches de longue durée ne sont pas adaptées aux fonctions FaaS           sans ré-architecture – vous devrez peut-être créer plusieurs FaaS coordonnés           fonctions, alors que dans un environnement traditionnel, vous pouvez avoir une tâche de longue durée           effectuer à la fois la coordination et l'exécution.

Latence de démarrage et «démarrages à froid» Il faut un certain temps à une plate-forme FaaS pour initialiser une instance de fonction avant           chaque événement. Cette latence de démarrage peut varier considérablement, même pour une fonction spécifique,           dépend d’un grand nombre de facteurs et peut aller de quelques millisecondes à           plusieurs secondes. Cela semble mauvais, mais soyons un peu plus spécifiques, avec AWS Lambda           par exemple. L’initialisation d’une fonction Lambda sera soit un «démarrage à chaud», soit la réutilisation d’une instance.           d'une fonction Lambda et de son conteneur hôte à partir d'un événement précédent ou d'un «démarrage à froid»           – création d'une nouvelle instance de conteneur, démarrage du processus hôte de la fonction, etc.           Sans surprise, lorsque l’on considère la latence de démarrage, ce sont ces démarrages à froid qui apportent la           le plus préoccupant. La latence de démarrage à froid dépend de nombreuses variables: le langage que vous utilisez, le nombre de bibliothèques           vous utilisez, combien de code vous avez, la configuration de l’environnement de la fonction Lambda           lui-même, si vous devez vous connecter aux ressources VPC, etc.           Bon nombre de ces aspects sont sous le contrôle du développeur, il est donc souvent possible de réduire           la latence de démarrage générée dans le cadre d'un démarrage à froid. La fréquence de démarrage à froid est tout aussi variable que la durée de démarrage à froid. Par exemple, si un           la fonction traite 10 événements par seconde, chaque événement prenant 50 ms pour être traité,           Lambda n’a sans doute qu’un démarrage à froid avec 100 000 à 200 000 événements environ. Si, sur           D'autre part, vous traitez un événement une fois par heure, vous verrez probablement un démarrage à froid pour           chaque événement, puisque Amazon supprime les instances Lambda inactives après quelques minutes. Connaissance           cela vous aidera à comprendre si les démarrages par le froid vous affecteront globalement, et           si vous souhaitez effectuer des opérations «Keep Alives» de vos instances de fonctions pour les éviter           être mis au pâturage. Les débuts froids sont-ils une préoccupation? Cela dépend du style et de la forme du trafic de votre           application. Mon ancienne équipe chez Intent Media a un Lambda de traitement des messages asynchrone           application implémentée en Java (généralement le langage avec le temps de démarrage le plus lent) qui           traite des centaines de millions de messages par jour et ne craint pas le démarrage           latence pour ce composant. Cela dit, si vous écrivez un trading à faible latence           vous ne voudriez probablement pas utiliser les systèmes FaaS hébergés dans le cloud pour le moment,           quelle que soit la langue que vous utilisiez pour la mise en œuvre. Que vous pensiez ou non que votre application puisse avoir de tels problèmes, vous devriez tester           performances avec une charge de production. Si votre cas d'utilisation ne fonctionne pas maintenant, vous voudrez peut-être           réessayez dans quelques mois, car il s'agit d'un domaine majeur d'amélioration continue par FaaS           vendeurs. Pour plus de détails sur les démarrages à froid, veuillez consulter mon           article sur le sujet.

Passerelles API

L’un des aspects de Serverless sur lequel nous avons déjà travaillé précédemment est une «passerelle d’API».           la passerelle est un serveur HTTP où les itinéraires et les points de terminaison sont définis dans la configuration, et           chaque route est associée à une ressource pour gérer cette route. Dans un sans serveur           l'architecture de tels gestionnaires sont souvent des fonctions FaaS. Lorsqu'une passerelle API reçoit une demande, elle trouve la configuration de routage correspondant à la           demande, et, dans le cas d’une route asservie par FaaS, appellera la fonction FaaS correspondante           avec une représentation de la demande initiale. En règle générale, la passerelle API permet           mappage des paramètres de requête HTTP vers une entrée plus concise pour la fonction FaaS, ou           permettra à toute la requête HTTP d'être transmise, généralement en tant qu'objet JSON. le           La fonction FaaS exécutera sa logique et renverra un résultat à la passerelle API, qui à son tour           va transformer ce résultat en une réponse HTTP qu'il repasse à l'original           votre interlocuteur. Amazon Web Services dispose de sa propre passerelle d’API (appelée «passerelle d’API», ce qui prête à confusion), et d’autres fournisseurs proposent des fonctionnalités similaires.           La passerelle API d’Amazon est un service BaaS (oui, BaaS!) À part entière, en ce sens qu’elle est un           service externe que vous configurez, mais que vous n'avez pas besoin d'exécuter ou de configurer vous-même. Au-delà des demandes de routage, les passerelles d’API peuvent également effectuer une authentification, une           validation, mappage du code de réponse, etc. (Si vos sens spidey picotent pendant que vous           Déterminez si c'est vraiment une bonne idée, retenez cette pensée! Nous allons considérer cela           plus tard.) Un cas d’utilisation d’une passerelle d’API avec des fonctions FaaS est la création d’un serveur HTTP.           microservices sans serveur avec tous les avantages en matière de dimensionnement, de gestion et autres           qui viennent des fonctions FaaS. Lorsque j’ai écrit cet article pour la première fois, l’outillage de l’API Gateway d’Amazon était, au moins,           douloureusement immature. Ces outils se sont considérablement améliorés depuis lors. Des composants comme AWS           Les API Gateway ne sont pas tout à fait «grand public», mais heureusement, elles sont un peu moins douloureuses que           ils étaient autrefois et ne feront que continuer à s’améliorer.

Outillage Le commentaire ci-dessus sur la maturité de l'outillage s'applique également à Serverless FaaS en général.           En 2016, les choses étaient plutôt difficiles. d’ici 2018, nous avons constaté une nette amélioration et nous prévoyons           des outils pour aller encore mieux. Quelques exemples notables de bons «développeurs UX» dans le monde de FaaS méritent d’être mentionnés.           en dehors. Tout d’abord, Auth0 Webtask, qui accorde une grande importance           priorité sur le développeur UX dans son outillage. Deuxièmement, Microsoft, avec son produit Azure Functions. Microsoft a toujours mis Visual Studio, avec           ses boucles de rétroaction serrées, à la pointe de ses produits pour développeurs, et Azure Functions           ne fait pas exception. La possibilité offerte de déboguer des fonctions localement, à partir d’une entrée d’un           événement déclenché par le nuage, est assez spécial. La surveillance est un domaine qui nécessite encore des améliorations significatives. J'en discute plus tard           sur.

Open source Jusqu’à présent, j’ai surtout parlé de produits et d’outils propriétaires. La majorité des           Les applications sans serveur utilisent de tels services, mais il existe des projets open-source dans           ce monde aussi. Les utilisations les plus courantes de l’open source dans Serverless sont les outils et les frameworks FaaS,           en particulier le populaire Serverless Framework, qui vise à           simplifier l'utilisation de AWS API Gateway et de Lambda plutôt que d'utiliser les outils fournis par AWS.           Il fournit également une quantité d'abstraction d'outils croisés, que certains utilisateurs trouvent           de valeur. Claudia et Zappa sont des exemples d’outils similaires. Apex est un autre exemple.           particulièrement intéressant car il permet de développer des fonctions Lambda dans des langages           autres que ceux directement pris en charge par Amazon. Les grands vendeurs eux-mêmes ne sont pas laissés pour compte dans la fête des outils open source           bien que. Le propre outil de déploiement d’AWS, SAM, le Application sans serveur           Modèle– est également open source. L’un des principaux avantages de FaaS propriétaire est de ne pas avoir à s’inquiéter de la           infrastructure de calcul sous-jacente (machines, machines virtuelles, voire conteneurs). Mais si vous vouloir se préoccuper de telles choses? Peut-être que vous avez des besoins de sécurité qui           ne peut pas être satisfait par un fournisseur de cloud, ou peut-être que vous avez quelques racks de serveurs que vous avez           déjà acheté et que vous ne voulez pas jeter. Peut ouvrir l'aide source dans ces scénarios,           vous permettant d'exploiter votre propre plate-forme «Serverful» FaaS? Oui, et il y a eu beaucoup d’activités dans ce domaine. Une des initiales           IBM (avec OpenWhisk, désormais un des principaux           Apache) et étonnamment – du moins pour moi! – Microsoft, qui a ouvert une grande partie de ses           Plateforme Azure Functions. Beaucoup d'autres FaaS auto-hébergés           implémentations utilisent une plate-forme de conteneur sous-jacente, fréquemment Kubernetes, qui           fait beaucoup de sens pour de nombreuses raisons. Dans ce domaine, il vaut la peine d’explorer des projets tels que           Brouillard Galactique, Fission et           OpenFaaS. C’est un monde vaste et en évolution rapide, et je recommande           observez le travail effectué par le groupe de travail sans serveur de la fédération de l’informatique en nuage (CNCF) pour en assurer le suivi.

Qu'est-ce qui n'est pas Serverless? Jusqu'à présent, dans cet article, j'ai décrit Serverless comme étant l'union de deux idées: Backend         en tant que service et fonctionne en tant que service. J'ai aussi exploré les capacités de ce dernier.         Pour plus de précision sur ce que je considère comme les attributs clés d’un service Serverless (et pourquoi         même des services plus anciens, comme S3, sans serveur), je vous renvoie à un autre article de         le mien: Définir sans serveur. Avant de commencer à examiner le domaine très important des avantages et des inconvénients, je voudrais         passer un autre moment rapide sur la définition. Définissons ce que Serverless n’est pas.

Comparaison avec PaaS Étant donné que les fonctions Serverless FaaS sont très similaires à Douze Facteur           applications, sont-ils juste une autre forme de "Plate-forme en tant que           Un service" (PaaS) comme Heroku? Pour une réponse brève je me réfère           à Adrian Cockcroft

Si votre PaaS peut démarrer efficacement des instances en 20 ms qui durent une demi-seconde,             appelez-le sans serveur. – Adrian Cockcroft

En d’autres termes, la plupart des applications PaaS ne sont pas conçues pour apporter des solutions complètes.           applications de haut en bas en réponse à un événement, alors que les plates-formes FaaS ne exactement ce. Si je suis un bon développeur d’applications Twelve-Factor, cela n’affectera pas nécessairement la           programme et architecte mes applications, mais cela fait une grande différence dans mon fonctionnement           leur. Puisque nous sommes tous de bons ingénieurs connaissant bien DevOps, nous pensons autant aux opérations           car nous pensons au développement, non? La principale différence opérationnelle entre FaaS et PaaS est mise à l'échelle. Généralement avec           PaaS, vous devez encore réfléchir à la manière de l’échelonner – par exemple, avec Heroku, combien de Dynos           est-ce que tu veux courir? Avec une application FaaS, cela est complètement transparent. Même si vous           configurez votre application PaaS pour une mise à l’échelle automatique; vous ne le ferez pas au niveau de           demandes individuelles (sauf si vous avez un profil de trafic de forme très spécifique),           L'application FaaS est beaucoup plus efficace en termes de coûts. Compte tenu de cet avantage, pourquoi utiliseriez-vous toujours un PaaS? Il y a plusieurs raisons, mais           l'outillage est probablement le plus gros. De plus, certaines personnes utilisent des plateformes PaaS telles que Cloud Foundry pour fournir une expérience de développement commune.           sur un cloud hybride public et privé; au moment de l'écriture, il n'y a pas d'équivalent FaaS           aussi mature que cela.

Comparaison avec les conteneurs Une des raisons d'utiliser Serverless FaaS est d'éviter de gérer des applications           processus au niveau du système d'exploitation. Les services PaaS, comme Heroku, fournissent également cette           J'ai décrit ci-dessus en quoi PaaS est différent de Serverless FaaS. Un autre           abstraction populaire des processus sont des conteneurs, avec Docker           étant l'exemple le plus visible d'une telle technologie. Systèmes d'hébergement de conteneurs tels que           Mesos et Kubernetes, qui           applications individuelles abstraites du déploiement au niveau du système d'exploitation, sont de plus en plus populaires. Même           plus loin sur cette voie, nous voyons des plates-formes de conteneur d'hébergement cloud telles que Amazon ECS et EKS, et           Google Container Engine qui, comme Serverless           FaaS, laissez les équipes éviter de gérer leurs propres hôtes serveurs. Compte tenu de l'élan           autour des conteneurs, est-il toujours utile de considérer Serverless FaaS? L’argument que j’ai avancé pour PaaS est toujours valable pour les conteneurs – pour Serverless           FaaS la mise à l'échelle est automatiquement gérée, transparente et à grain fin, et c'est           lié à l'approvisionnement et l'allocation automatiques de ressources que j'ai mentionné plus tôt.           Les plates-formes de conteneurs ont toujours eu besoin de vous pour gérer la taille et la forme des           vos grappes. Je dirais aussi que la technologie des conteneurs n’est pas encore mature et stable, bien qu’elle soit           de plus en plus près de l'être. Cela ne veut pas dire que Serverless FaaS est mature, de           Bien sûr, mais choisir les aspérités que vous aimeriez rester à l’ordre du jour. Il est également important de mentionner que des grappes de conteneurs à mise à l'échelle automatique sont désormais disponibles.           dans les plates-formes de conteneurs. Kubernetes a intégré cela dans la fonction de «mise à l'échelle automatique des pods horizontaux», et des services comme AWS Fargate font également la promesse de «conteneurs sans serveur». Comme nous constatons l’écart de gestion et d’adaptation entre Serverless FaaS et hébergé           les conteneurs sont plus étroits, le choix entre eux peut simplement dépendre du style et du type de           application. Par exemple, il se peut que FaaS soit considéré comme un meilleur choix pour un           style piloté par les événements avec peu de types d'événements par composant d'application, et les conteneurs sont vus           comme meilleur choix pour les composants pilotés par une demande synchrone avec plusieurs points d'entrée. je           attendre dans un laps de temps assez court que de nombreuses applications et équipes utiliseront à la fois           approches architecturales, et il sera fascinant de voir les modèles d’une telle utilisation           émerger.

#NoOps Serverless ne signifie pas "No Ops" – bien que cela puisse vouloir dire "No sysadmin" selon la manière dont           vous allez au fond du trou du lapin sans serveur. «Ops» signifie beaucoup plus que l'administration de serveur. Cela signifie aussi, au moins, la surveillance,           déploiement, sécurité, mise en réseau, support, et souvent une certaine quantité de débogage de production           et mise à l'échelle du système. Ces problèmes existent toujours avec les applications sans serveur et vous êtes toujours           avoir besoin d'une stratégie pour y faire face. À certains égards, Ops est plus difficile dans un serveur sans serveur.           monde parce que beaucoup de cela est si nouveau. L’administrateur système est toujours actif. Vous ne faites que l’externaliser avec Serverless. Ce n'est pas           nécessairement une mauvaise (ou bonne) chose – nous sous-traitons beaucoup, et sa bonté ou sa méchanceté dépend           sur ce que vous essayez précisément de faire. De toute façon, à un moment donné, l'abstraction sera           probable, et vous aurez besoin de savoir que les administrateurs systèmes, quelque part, soutiennent votre           application. Majeures de charité a donné un grand           parler à ce sujet au premier Serverlessconf. (Vous pouvez aussi lire ses deux           des écrits à ce sujet: WTF est une opération? et meilleures pratiques opérationnelles.)

Procédures stockées en tant que service Un autre thème que j’ai vu est que Faune sans serveur est «Procédures stockées en tant que service».           pense que cela vient du fait que de nombreux exemples de fonctions FaaS (y compris certaines           utilisés dans cet article) sont de petits morceaux de code qui sont étroitement intégrés à un           base de données. Si c’est tout ce que nous pourrions utiliser FaaS, je pense que le nom serait utile, mais           parce qu’il s’agit en réalité d’un sous-ensemble des capacités de FaaS, je ne pense pas qu’il soit utile           Pensez à FaaS en ces termes. Cela étant dit, il convient de se demander si FaaS est doté des mêmes caractéristiques.           problèmes de procédures stockées, y compris le problème de la dette technique que Camille mentionne dans           le tweet mentionné ci-dessus. L'utilisation de procédures stockées permet de tirer plusieurs enseignements           qui méritent d’être examinés dans le contexte de FaaS et de voir s’ils s’appliquent. Considérer           que les procédures stockées:

Nécessite souvent un langage spécifique au fournisseur, ou du moins spécifique à un fournisseur             frameworks / extensions d'un langage Sont difficiles à tester car ils doivent être exécutés dans le contexte d’une             base de données Sont difficiles à contrôler les versions ou à traiter comme une application de première classe

Bien que tous ne s’appliquent pas nécessairement à toutes les implémentations de processus stockés,           ce sont certainement des problèmes que l’on pourrait rencontrer. Voyons si elles pourraient s’appliquer à           FaaS: (1) n’est définitivement pas un problème pour les implémentations FaaS que j’ai vu           loin, donc nous pouvons rayer celui-ci de la liste tout de suite. Pour (2) puisque nous traitons avec "juste du code", le test unitaire est définitivement           aussi facile que n'importe quel autre code. Le test d'intégration est différent (et légitime)           question cependant, et que nous discuterons plus tard. Pour (3), encore une fois puisque les fonctions FaaS sont “juste du code”, le contrôle de version est correct. Jusqu'à ce que           l’emballage des applications était également une préoccupation, mais nous commençons à voir la maturité           ici, avec des outils comme le modèle d’application sans serveur d’Amazon           (SAM) et le Framework sans serveur que j'ai mentionné plus tôt. Au début de 2018           Amazon a même lancé un «référentiel d'applications sans serveur» (SAR)           fournir aux organisations un moyen de distribuer des applications et des composants d'applications,           construit sur les services AWS Serverless. (Pour en savoir plus sur le SAR, consultez l'article intitulé Examiner le référentiel d'applications AWS Serverless.)

Click to rate this post! [Total: 0 Average: 0]