Premiers pas avec Lambda

Lambda aws est le service FaaS d’Amazon (function as a service), c’est un service d’exécution de code qui impose son environnement (taille max, durée d’exécution). Il est tarifé à l’utilisation et est le pilier des architecture serverless.

Plusieurs langages sont possible (NodeJS, python, Go, Java, Ruby), l’aspect évenementiel de NodeJS me plait et je l’ai donc choisi pour débuter ici. A noter que Rust semble se démarquer du lot niveau légèreté et donc performance, et qui dit rapide dit moins cher avec du FaaS.

Pour suivre ce tutoriel il vous faut d’abord un compte AWS, je vous invite à le créer si ce n’est pas le cas. Nous utiliserons ici uniquement la console web (clicouille).

Vous pouvez utiliser Lambda sans compte AWS depuis un hébergement Netlify en quelques clics, c’est très pratique mais je le trouve un peu réducteur car l’intérêt pour le sysadmin est surtout de pouvoir s’interconnecter avec les différents services AWS (Cloudwatch, ELB, API Gateway, Alexa, Step Functions, etc).

Nous allons faire ici quelque chose de useless mais intéressant quand même, à savoir une simple API Rest avec un GET qui retourne des informations sur notre adresse IP publique.

Création de notre fonction Lambda

Dans vos services Amazon sélectionnez Lambda dans la catégorie Calcul puis cliquez sur créer une fonction.

Sélectionnez “créer à partir de zéro”, nous allons la nommer monIP, choisir Node.js 8.10 pour l’exécution et sélectionner le rôle existant lambda_basic_execution. Cliquez maintenant sur “Créer une fonction”.

Sur la nouvelle page vous pouvez visualiser le code de la fonction, normalement il est pré-remplis, on va d’abord le laisser comme ça tester son exécution sans risque d’erreur.

La page vous propose d’ajouter différents déclencheurs, nous n’allons en sélectionner aucun pour l’instant nous y reviendrons plus tard.

Test de notre fonction Lambda

Tout simple : cliquez sur “Tester”, vous aller pouvoir simuler l’évenement de votre choix, prenez celui qui vous plait le plus, par exemple j’ai choisi “Amazon Alexa Start Session”, pris comme nom “Alexa”, laissez le json ainsi (notez tous les arguments auxquels vous pourrez accéder plus dans votre fonction lambda) puis cliquez sur “Créer”.

En vous avez crée un test que vous pouvez maintenance lancer à souhait, recliquez sur “Tester” et vous aurez le résultat de votre test en détail. Notez bien que vous avez la durée d’exécution et la durée facturée qui est mentionné, dans mon cas 11ms de durée d’exécution pour 100ms facturé, c’est bien arrondi au dessus !

Maintenant relancez encore une fois le même test, et comparez la durée d’exécution. Dans mon cas j’ai le deuxième coup 0.53ms et toujours 100ms de facturé.

Pourquoi ? C’est le démarrage à froid, la première fois notre applicatif est chargé en mémoire ce qui prend environ 10ms, la deuxième fois il est déjà chargé.

Déploiement de notre fonction Lambda à travers une API

Pour tester notre fonction Lambda depuis l’extérieur nous allons devoir maintenant l’associer à un déclencheur, pour commencer on va la connecter au service Amazon “API Gateway”.

Choisissez “Créer une API”, sélectionnez REST - Nouvelle API et précisez le nom de l’API dans notre cas “monIP” avec comme point d’extrémité régional (permettra un accès public, le Edge est une optimisation via les points de connexion optimisés basé sur Cloudfront inutile dans notre cas).

Maintenant que votre API est crée vous pouvez créer une méthode d’accès que l’on va connecter à notre fonction Lambda : Ressources -> Action -> Créer une méthode “GET”.

Type d’intégration vous choisissez bien sûr “Fonction Lambda” puis saisissez le nom de votre fonction Lambda “monIP”.

Maintenant il ne vous reste plus qu’a déployé l’API, pour ce faire cliquez sur “action” et sélectionnez “deploy”, créez votre étape, par exemple test et déployez votre code, vous aurez alors enfin une URL externe pour pouvoir tester votre fonction Lambda :

1 2	curl https://XXXXXXXXXXX.execute-api.eu-west-3.amazonaws.com/test {"statusCode":200,"body":"\"Hello from Lambda!\""}

Et voilà, nous avons enfin notre Hello world remarquez que finalement tout ça était plutôt intuitif mais maintenant que l’essentiel est fait on va pouvoir mettre un tout petit peu les mains dans le camboui.

Récupérer l’ip utilisé pour contacter API Gateway

Voici toutes les variable de contexte disponible pour API Gateway : Doc AWS

Nous ce qui nous intéresse c’est ceci :

1
2
3

$context.identity.sourceIp 	

The source IP address of the TCP connection making the request to API Gateway.

Super exactement ce qu’il nous faut ! Cependant tous ces paramètres ne sont pas transmis directement à la fonction Lambda car le contexte de la fonction Lambda ne sera plus le même et concernera la fonction Lambda en elle même (durée d’exécution, arn de la fonction, etc).

Pour cela nous allons un modèle de mappage dans la section “demande d’intégration” de notre fonction Lambda, créez y un modèle avec le contenu json suivant :

1
2
3

{
    "source_ip" : "$context.identity.sourceIp"
}

Enregistrez et allons maintenant modifier notre fonction Lambda ainsi :

exports.handler = async (event) => {
    console.log('Source IP' + event.source_ip);
    const response = {
        ip: `${event.source_ip}`
    };
    return response;
};

Redéployer vos modifications

Maintenant pensez bien à rédéployer votre méthode GET d’API Gateway et relancez votre curl de test :

1 2	curl https://XXXXXXXXXXX.execute-api.eu-west-3.amazonaws.com/test {"ip":"90.118.158.37"}

Conclusion

J’espère que ce petit tour d’horizon vous motivera à aller plus loin, n’hésitez pas à laisser vos suggestions en commentaire !

Pour la suite j’aimerai faire un example plus complet avec une utilisation de librairies NodeJS puis une automatisation des exécutions via python sur des instances EC2. Qui vivra verra !

Liens utile

Votre fonction Lambda avec Rust (en)
Démarrer avec aws lambda et nodejs (en)

Bienvenue sur ce blog serverless fr ! Tout d’abord un petit post pour présenter rapidement le serverless et donner le ton de ce blog.

Pourquoi useless sysadmin

Je suis convaincu que le métier de sysadmin est en train de disparaitre au profit du serverless, la transition sera longue et aura le mérite de combler la pénurie actuelle de profil compétents. Cette transition s’annonce passionnante et doit, je pense, donner un objectif aux sysadmins actuels : devenir inutile !

Cela vous donnera le temps de vous consacrer à d’autre tâches comme la veille technique autour des services serverless et surtout guider votre entourage dans cette transition que vous serez les mieux placer pour accompagner et motiver.

Qu’est ce que le serverless ?

Comme son nom l’indique, un service serverless ne s’appuie sur aucun serveur mais il faut nuancer ce propos car vous vous doutez bien qu’il y a bien quelques serveurs quelque part qui font tourner le service. L’idée c’est d’utiliser uniquement des services externe (tarifés à l’utilisation) et aucun serveur que nous aurions à administrer nous même.

Comment ce blog est serverless ?

La première étape consiste à avoir un blog statique, pour cela j’utilise Hexo, un projet NodeJS de génération de blog.
Ensuite je stocke les fichiers statiques de ce dernier sur un bucket (sorte de répertoire) S3, et j’utilise CloudFront pour le publier et faire l’offloading SSL. Pour la partie hébergement DNS j’utilise le service route53 d’AWS.

Deux gros avantages

Le coût

En cas d’absence de trafic sur votre service vous n’aurez aucun coût car vous êtes facturé à l’utilisation du service. Très rassurant pour un petit blog ou un site qui de toute façon ne génèrera que très peu de trafic, par contre si d’aventure votre site rencontre le succès alors il va falloir surveiller attentivement le coût de votre hébergement.

La haute disponibilité

On se décharge de toutes les contraintes de haute disponibilité sur les services, ce n’est plus notre affaire on va enfin pouvoir dormir tranquille !

La scalabilité

Pareil que pour la haute disponibilité, si notre site ou service rencontre d’un coup beaucoup de succès nous n’auront rien à faire, le serverless tiendra la charge. Par contre attention au porte monnaie 😉

Les moins

Nécessité d’adapter ses méthode de développement

Si vous ne pouvez pas vous appuyer sur des micro services externes et que vous avez besoin d’apporter des fonctionnalitées dynamique qui vous sont propre vous aller devoir vous appuyer sur Lambda, le projet d’exécution de fonction d’Amazon.

Même si Lambda est disponible dans de nombreux langages vous aurez rapidement besoin d’un langage évenementiel et donc de NodeJS. De plus de nombreuse limites en terme de taille et de durée d’exécution vont vous forcer à multiplier les fonctions et vous organiser en micro service.

Disparition du métier de sysadmin

Beaucoup de missions habituellement affecté aux sysadmin vont certainement disparaitre avec le développement de l’autonomie du développeur/webmaster. La gestion des problématiques en Haute dispo et de tenu de charge pourra être faite simplement depuis l’interface. Attention toutesfois de nombreuses actions et décision d’architecture auront toujours besoin d’un sysadmin qui deviendra au fil du temps plus un architecte du déploiement.

Dépendance aux fournisseur

En toute logique avec l’utilisation maximale de service externe vous augmentez votre dépendance par rapport à ces fournisseurs. Vous êtes donc vulnérable à une modification technique ou tarifaire d’un service pas suffisament concurentiel.

On ne peut pas tout rendre serverless

L’hébergement traditionnel garde pour l’instant son utilité, on ne peut pas par exemple héberger un blog wordpress en full serverless car vous aurez besoin de composants (exécution php, gestion de sessions, base de donnée).

Prenons pour exemple l’hébergement de la base de donnée, si vous pouvez vous passer de gérer vous même votre serveur en utilisant par exemple un serveur MySQL managé vous serez obligé de payer un coût récurrent correspondant à votre serveur.

L’offre MySql serverless d’Aurora aws ne fait pas exception avec un coût horaire à payer : même pour un site avec une très faible audience et quelques dizaine de requêtes par jour vous aurez rapidement une facturation importante de l’ordre de deux dollars par jours. Notons tout de même qu’il fournit un système de pause, avec une suspension du service MySQL suite à une période d’inactivité. Belle tentative, mais il faut 25s pour relancer le service quand une requête arrive, trop long pour l’affichage d’un site web donc pas vraiment utilisable !

L’arrivé des fonctions Lambda AWS (on y reviendra dans un prochain post) met un gros coup de pied dans la fourmilière mais est loin de proposer autant d’applications que l’hébergement traditionnel et pour l’instant reste réservé aux développeurs aventureux.

Bel avenir

Les perspectives d’économies, de simplicité et de haute disponibilité sont des atouts majeurs qui propulse le serverless sur le devant de la scène et rendront d’ici peu le dernier buzz world, à savoir les containers(docker, k8s) obsolète.

En attendant je vais continuer mon exploration du serverless et essayer de faire quelques tutoriels sur le sujet.

Liens utiles

6 things I’ve learned in my first 6 months using serverless

Serverless : les pour et les contre