Comment les architectures sans serveur gèrent-elles les connexions aux bases de données?

10

On dit que le principal avantage de l'architecture sans serveur est que ces programmes n'ont pas besoin d'un serveur dédié pour fonctionner en continu. Ils sont ensuite invoqués sur une demande et s'arrêtent en quittant la fonction.

Cela signifie qu'un programme sans serveur devra être rapide à démarrer, pour être réactif. Comment gère-t-il alors les actions chronophages telles que la connexion à la base de données? Se connecte-t-il à la base de données à chaque fois ou gère-t-il la connexion à la base de données séparément pour effectuer des invocations comme cela se fait dans les applications serveur?

architecture server backend

— Utilisateur enregistré
source

9

Puisqu'une application sans serveur ne conserve aucun état entre les exécutions, elle ne peut pas conserver un pool de connexions à la base de données. Les applications sans serveur sont vraiment confrontées aux mêmes contraintes que les scripts CGI des années 90. En général, un processus serveur permanent pourra surpasser une architecture processus par demande ou conteneur par demande car le serveur effectue l'initialisation une fois, pas une fois par demande.

Les programmes sans serveur ne conviennent pas parfaitement aux tâches sensibles à la latence comme le service d'un site Web. Ils conviennent mieux aux tâches d'arrière-plan sporadiques que vous ne souhaitez pas exécuter sur votre serveur principal, sans avoir à gérer et équilibrer manuellement les serveurs d'applications supplémentaires. Ils peuvent également convenir si la productivité du développeur est beaucoup plus importante que les réponses à faible latence.

— amon
source

Excellents points. Je dirais également qu'un avantage majeur qui pousse les gens à se passer de serveur est le coût. Si vous payez un fournisseur (par exemple Amazon) basé uniquement sur le nombre de demandes et que vous ne payez pas pour garder un serveur inactif en cours d'exécution, vous économiserez de l'argent, en particulier pendant la phase de démarrage.

— Paul

2

@Paul Le principal avantage du sans serveur est la commodité (PaaS vs. IaaS). Administrer un serveur en toute sécurité est une compétence que la plupart des développeurs (moi y compris) n'ont pas. Je suis certain qu'il existe des scénarios où le serveur sans serveur est nettement moins cher. Mais les serveurs privés virtuels commencent à 5 $ / mois, ce qui est très compétitif, pour le dire légèrement. Surtout si l'on considère qu'un VPS a beaucoup moins de restrictions, vous permettant d'exécuter des logiciels arbitraires et des services permanents. C'est un peu une comparaison pomme-oranges. Dans un modèle, vous payez pour un serveur inactif, dans un autre, vous payez pour des temps de démarrage répétés.

— amon

4

Ça dépend.

L'implémentation en coulisses du lambda runner va affecter cela. Nous pouvons voir que dans AWS, le conteneur peut être réutilisé.

http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduction.html

Nous avons donc pu voir au moins la mise en commun / réutilisation des connexions pour certaines demandes. Nous devons également considérer la base de données elle-même et comment elle traite les demandes de connexion entrantes.

Ce genre de question pour moi souligne certains des problèmes avec «sans serveur», c'est encore très nouveau et immature, donc les détails n'ont pas été élaborés.

Nous devons toujours nous rappeler que sans serveur ne signifie pas sans serveurs. Si le taux auquel vous appelez un lambda est suffisamment élevé, vous pouvez effectivement avoir plusieurs serveurs ou «conteneurs» en cours d'exécution.

Dans la pratique, le temps de démarrage et les ressources telles que les adresses IP des lambdas peuvent être un vrai problème. Peut-être qu'au fur et à mesure qu'ils mûriront, un consensus sur la façon de les exécuter apparaîtra et ces problèmes obtiendront des réponses solides.

— Ewan
source