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.
Sommaire
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. - 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.
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.
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). - 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). - 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. - 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.
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 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.
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.
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.)
Commentaires
Laisser un commentaire