SAM, pour ServerlessLe terme serverless se dit d'un traitement qui ne nécessite pas de serveur (à comprendre ici : dont on ne s'occupe pas du serveur) ApplicationC'est un programme conçu pour effectuer une ou plusieurs tâches. Réaliser des applications, c'est notre cœur de métier chez AXOPEN ! Model, est un FrameworkUn framework est un ensemble d'outils permettant de cadrer la façon dont on conçoit une application. mis à disposition par AWSLe Cloud AWS (Amazon WebServices) est une plateforme de services cloud développée par le géant américain Amazon. depuis fin 2018. Cet outil fournit un écosystème simplifié, basé sur CloudLe Cloud consiste à accéder à des ressources informatiques, à partir d'internet, via un fournisseur. Formation, qui permet de créer, organiser et tester facilement ses fonctions avant de les déployer sur Lambda, le service serverless d'AWS.
Cet outil permet également d'interconnecter très facilement des services annexes à Lambda comme APIUne API est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données. Gateway, DynamoDB, SNS ou autres, le tout en seulement quelques lignes ! La liste des services compatibles est d'ailleurs disponible dans la documentation de SAM.
SAM peut être considéré comme une simplification ou une abstraction de Cloud Formation dédiée exclusivement au serverless. Là où Cloud Formation se veut accessible uniquement par des experts AWS, SAM fournit aux développeurs une syntaxe simplifiée de CloudFormation qui rend beaucoup plus accessible le service aux personnes qui ne sont pas des experts absolus sur AWS. SAM s'occupe ensuite de faire la transformation en modèle Cloud Formation pour provisionner l'infrastructure nécessaire au projet.
Attention tout de même, une bonne connaissance d'AWS et des principaux services reste nécessaire pour ne pas avoir de surprise lors des déploiements !
Comme expliqué juste au-dessus, SAM se concentre exclusivement sur le service serverless d'AWS. Là où avec Terraform vous allez pouvoir configurer une architecture complète sur AWS et avoir la main sur quasiment tout, SAM va se concentrer sur le service Lambda et les services qui gravitent autour. Néanmoins, ces deux services ne sont pas incompatibles et peuvent au contraire se combiner pour améliorer le développement de fonctions en local. Le CLI SAM peut lire les ressources disponibles dans le projet Terraform et lancer la fonction dans un conteneur Docker.
L'implémentation est disponible sur la doc SAM d'AWS : https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/terraform-support.html
AWS SAM fournit deux composants pour créer des applications serverless :
Vu qu'un exemple vaut mieux que 1024 mots 😁
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html
Une fois l'installation terminée, rendez-vous dans le dossier de votre projet, ouvrez une invite de commande et lancez simplement la commande suivante : sam init
Une fois l'installation terminée, rendez-vous dans le dossier de votre projet, ouvrez un invite de commande et lancer simplement la commande suivante: sam init
La commande va alors vous proposer de générer une application basée sur un modèle existant ou d'utiliser un modèle personnalisé. Choisissez la première option.
Vous avez ensuite le choix entre 16 modèles différents, du simple "Hello World" au "Machine Learning". Nous allons choisir le "Hello World Example" pour commencer notre exemple.
Pour la suite, répondez comme ceci aux questions suivantes :
Use the most popular runtime and package type? (python3.13 and zip) [y/N]: Yes
Would you like to enable X-Ray tracing on the function(s) in your application? No
Ce service permet de débugger en production mais il est assez coûteux
Ce service service pourra être activé plus tard
Pas d'authentification prévue sur cette fonction
Une fois l'installation terminée, un projet prêt à être déployé est chargé dans notre dossier "hello_world".
Les principaux fichiers qui nous intéressent sont le suivants :
C'est le fichier clé de configuration qui va nous permettre de configurer l'infrastructure de notre fonction ainsi que tous les services interconnectés.
Ci-dessous, l'explication des propriétés :
#...
Resources:
HelloWorldFunction: #Déclaration de la ressource
Type: AWS::Serverless::Function #Type de ressource
CodeUri: hello_world/ #Localisation du code
Handler: app.lambda_handler
Runtime: python3.13
Architectures:
- x86_64
Events:
HelloWorld: #Evenement joué par la fonction
Type: Api
Properties:
Path: /hello #Route et méthode de la fonction
Method: get
#Valeurs affichées après le déploiement
Outputs:
HelloWorldApi:
Description: "API Gateway endpoint URL for Prod stage for Hello World function"
Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
HelloWorldFunction:
Description: "Hello World Lambda Function ARN"
Value: !GetAtt HelloWorldFunction.Arn
HelloWorldFunctionIamRole:
Description: "Implicit IAM Role created for Hello World function"
Value: !GetAtt HelloWorldFunctionRole.Arn
Pour notre fonction HelloWorld, nous n'utilisons aucun autre service. Cependant, pour ajouter un service supplémentaire, il suffit de le spécifier sous l'attribut Resources
. Par exemple, pour intégrer une API Gateway devant notre fonction :
Resources:
ServerlessRestApi:
Type: AWS::Serverless::Api
Properties:
Name: "api-hello-world"
StageName: Prod
HelloWorldFunction:
Type: AWS::Serverless::Function
#...
Ce fichier permet de simuler une requête HTTP qui appelle notre fonction. Très utile pour invoquer localement la fonction et lui passer ce fichier en guise de requête.
Exemple d'utilisation :
sam local invoke HelloWorldFunction --event events/event.json
Cette commande va permettre d'invoquer la fonction dans un container docker, en simulant la requête contenue dans le fichier event.json et ensuite retourner le résultat dans la console !
Fichier de configuration du CLI SAM. Utilisé pour configurer les commandes et sauvegarder les paramètres de build et deploy.
Dossier contenant les fichiers de code de notre fonction.
Dans tous les modèles, AWS nous fournit une base pour réaliser des tests sur notre fonction.
L'énorme force de l'outil d'AWS, c'est la possibilité de pouvoir lancer les fonctions en local ! Nous pouvons invoquer la fonction en passant en paramètre un évènement comme nous l'avons vu plus haut mais nous pouvons également en faire une API ! Idéal pour développer la fonction en local sans la déployer sur AWS 😎
Pour lancer notre API contenant notre fonction, il suffit simplement de lancer la commande sam local start-api
. Notre API sera ensuite disponible sur le port 3000 !
Un curl de notre fonction nous permet de tester le fonctionnement de notre fonction
curl http://localhost:3000/hello
{"message": "hello world"}
Réalisons maintenant le premier déploiement de notre super application HelloWorld (il faut un début à tout !).
Mais on peut déployer sans rien configurer ? Et oui Jamy, ce modèle est livré prêt à l'emploi ! SAM se base sur notre environnement AWS local et c'est parti 🚀.
Avant de déployer, assurez-vous d'avoir renseigné des identifiants AWS qui permettent de créer un service lambda & API Gateway et d'avoir Docker installé sur votre poste.
https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html
Lancez la commande sam build --use-container
, cette commande va télécharger une image python3.13 et compiler la fonction dans cette image.
Une fois le build effectué, un nouveau dossier .aws-sam a été créé. Ce dossier contient l'ensemble des dépendances python, votre code ainsi qu'un fichier "build.toml" qui contient les informations nécessaires au déploiement.
Tout est prêt pour notre premier test de déploiement !
sam deploy --guided
Une fois notre déploiement et notre test effectués avec succès, nous allons pouvoir détruire notre environnement. Pour cela, rien de plus simple ! Il nous suffit de lancer la commande sam delete. SAM va vous demander de confirmer la suppression de la pile Cloudformation et du S3 et ensuite, comme le déploiement, SAM s'occupe de tout ! (un vrai IaC 😍).
Là où la configuration d'un déploiement de fonctions aurait été plus laborieuse avec Cloudformation et des IaC comme Terraform, SAM nous permet de déployer une ou plusieurs fonctions beaucoup plus rapidement tout en offrant la possibilité d'une configuration assez poussée.
Cet outil peut être idéal pour des fonctions en complément d'un site web statique, pour un projet exclusivement composé de fonctions serverless ou en marge d'une architecture Terraform comme spécifié plus haut !
De plus, depuis le changement de politique du célèbre Framework Serverless, qui impose dans sa dernière version, l'utilisation de leur cloud pour pouvoir déployer les fonctions (et avec une utilisation trop intense de votre application, de vous facturer en plus de votre infrastructure AWS), AWS SAM peut devenir une alternative cohérente à Serverless.
Alors convaincu ?
Découvrez la planche #40 !
L’obsolescence d’un certain nombre de produits et d’applications maintenant trop anciens ou ne répondant plus aux besoins actuels, conduit le plus souvent les entreprises à changer d’environnement.
Découvrez la planche #11 !