Serveur d'impression

Architectures sans serveur – Bien choisir son serveur d impression

Le 22 juillet 2019 - 30 minutes de lecture

À 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:

  1. Nous avons supprimé la logique d’authentification dans l’application d’origine et remplacé
                avec un service BaaS tiers (par exemple, Auth0.)
  2. 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.
  3. 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.
  4. 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.
  5. 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.

  6. 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).

  1. 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).
  2. 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.

  3. 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).
  4. 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.

  5. 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.
  6. 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.
  7. 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.

  8. 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).
  9. 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

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:

  1. Nécessite souvent un langage spécifique au fournisseur, ou du moins spécifique à un fournisseur
                frameworks / extensions d'un langage
  2. Sont difficiles à tester car ils doivent être exécutés dans le contexte d’une
                base de données
  3. 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.)

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.