Fargate vs Lambda, quand utiliser lequel?
Je suis plutôt nouveau dans le paysage sans serveur et j'essaie de comprendre quand utiliser Fargate vs Lambda.
Je suis conscient que Fargate est un sous-ensemble d’ECS sans serveur et que Lambda est également sans serveur mais qu’il dépend d’événements. Mais j'aimerais pouvoir expliquer les deux paradigmes en termes simples à d'autres personnes familiarisées avec les conteneurs mais pas tant qu'avec AWS et sans serveur.
Nous disposons actuellement de deux serveurs physiques chargés de recevoir les fichiers texte, de les analyser et de renseigner plusieurs tables de la base de données avec les résultats. D'après ce que j'ai compris, je pense que ce serait un cas d'utilisation mieux adapté à Lambda car le processus qui analyse les fichiers texte est déclenché par une planification, ne dure pas longtemps et ralentit lorsqu'il n'est pas utilisé.
Cependant, si nous portions l'un de nos serveurs recevant des appels d'API, nous voudrions probablement utiliser Fargate, car nous aurions toujours besoin d'au moins une instance de l'image opérationnelle.
En termes de conteneurs, et de manière très générale, peut-on dire sans danger que si le conteneur est conçu pour faire:
docker run <some_input>
Ensuite, c’est un travail pour Lambda.
Mais si le conteneur est conçu pour faire quelque chose comme:
docker run --expose 80
Ensuite, c'est un travail pour Fargate.
Est-ce une bonne analogie?
C'est le début d'une bonne analogie. Cependant, Lambda a également des limites en termes de CPU et de RAM disponibles et une durée d'exécution maximale de 15 minutes par appel. Donc, tout ce qui a besoin de plus de ressources, ou qui doit durer plus de 15 minutes, conviendrait mieux à Fargate.
De plus, je ne suis pas sûr de savoir pourquoi vous dites que quelque chose convient mieux à Fargate, car vous "devez toujours exécuter au moins une instance". Lambda + API Gateway convient parfaitement aux appels d'API. API Gateway est toujours prête à recevoir l'appel de l'API. Elle appelle ensuite une fonction Lambda pour le traiter (si la réponse n'est pas déjà mise en cache).
Il est important de noter qu'avec Lambda, vous n'avez pas besoin de construire, sécuriser ou entretenir un conteneur. Vous vous inquiétez juste pour le code. Comme déjà mentionné, Lambda a une limite de temps d'exécution maximale et une limite de mémoire de 3 Go (la CPU augmente proportionnellement). De plus, s'il est utilisé de manière sporadique, il peut être nécessaire de le préchauffer (sur une base horaire) pour optimiser les performances.
Fargate gère les conteneurs Docker que vous devez définir, gérer et sécuriser. Si vous avez besoin de plus de contrôle sur ce qui est disponible dans l'environnement où votre code est exécuté, vous pouvez éventuellement utiliser un conteneur (ou un serveur), mais cela vient encore avec la gestion. Vous avez également plus d’options sur la taille de la mémoire/du processeur et la durée de votre exécution.
Même pour un serveur d'API tel que vous l'avez mentionné, vous pouvez placer la passerelle d'API devant et appeler Lambda.
Comme Mark l’a déjà mentionné, vous pouvez utiliser Lambda + API Gateway pour exposer votre fonction lambda en tant qu’API. Mais lambda a des limitations significatives en termes d’exécution de fonctions. Il existe des limitations concernant les langages de programmation pris en charge, la consommation de mémoire et le temps d'exécution (il a été augmenté récemment à 15 minutes par rapport aux 5 minutes précédentes). C'est ici qu'AWS Fargate peut apporter son aide en offrant à la fois les avantages du monde du conteneur et du monde Serverless (FaaS). Ici, vous ne vous occupez que du conteneur (son processeur, ses besoins en mémoire, ses stratégies IAM, etc.) et laissez le reste à Amazon ECS en choisissant le type de lancement Fargate. ECS choisira le bon type d'instance, gérera votre cluster, sa mise à l'échelle automatique et son utilisation optimale.
C'est la bonne analogie, mais ce n'est pas une liste exhaustive pour pouvoir expliquer les deux paradigmes.
En général, Lambda est plus adapté aux applications sans serveur. Sa nature est une fonction en tant que service (FaaS). Il ne fait que les tâches simples et c’est tout. Ne vous attendez pas à beaucoup plus.
Il devrait être considéré comme la première option pour le module sans serveur. Mais il a plus de limitations et de restrictions. Architecture de module élaborée à partir d'exigences fonctionnelles et non fonctionnelles, d'infrastructure encapsulée et de nombreux autres facteurs.
Pour prendre une décision minimale, vous devez consulter la liste des restrictions telles que:
- Portabilité
- Contrôle de l'environnement
- Type de déclencheur
- Temps de réponse
- Taille de la réponse
- Temps de traitement
- Utilisation de la mémoire
Ce sont les principaux facteurs. Mais la liste ne couvre pas tous les facteurs et restrictions à prendre en compte entre ces deux technologies sans serveur.
En savoir plus sur cet article https://medium.com/greenm/aws-lambda-or-aws-fargate-the-step-by-step-guide-to-choosing -the-right-technology-925ebcf89b7c