Lambda, le service sans serveur phare d'AWS, permet d'exécuter du code sur différents environnements d'exécution. Cependant PHP n'est pas explicitement dans la description officielle du produit. Cela signifie-t-il que vous ne pouvez pas exécuter de code PHP sur Lambdas ? Non, ce n'est pas le cas !

Dans cette série (dérivée d'une conférence que j'ai donnée au groupe d'utilisateurs AWS de Poitiers), nous discuterons de ce qu'est le sans serveur et de la manière de faire fonctionner PHP (si c'est votre langage préféré) sur Lambda.

Qu'est-ce qui est sans serveur ?

Le sans serveur est un paradigme d'hébergement dans lequel le fournisseur de cloud fait évoluer de manière dynamique les ressources allouées à la charge de travail du client, tout en gérant non seulement l'infrastructure physique (serveurs, refroidissement de l'alimentation) mais également jusqu'au temps d'exécution (correctifs, ..).

Au sens strict, le calcul est alloué à chaque requête, ce qui conduit à un modèle de tarification « à zéro » (aucune ressource n'est payée à l'heure, mais uniquement proportionnellement à la demande réelle), tout en offrant un haut niveau de tarification. -disponibilité.

Cela s'ajoute à d'autres avantages du Cloud, principalement le fait que tout est livré avec une API, rendant l'automatisation possible.

La somme de ces avantages permet de disposer d'environnements éphémères de branches de fonctionnalités pratiquement gratuits, augmentant ainsi la productivité et les délais des développeurs.

Le sans serveur n'est pas seulement une question de calcul !

Il existe de nombreuses solutions dans l'écosystème sans serveur. Lorsque le calcul sans serveur (Lambda) est apparu, en 2014, les files d'attente gérées (SQS) existaient depuis une décennie et S3 depuis 8 ans.

Notez que dans la diapositive ci-dessus, Aurora ne correspond pas à notre définition stricte de Serverless car il ne s'adapte pas à zéro (la v1 est mise à l'échelle à zéro mais peut ensuite prendre quelques minutes pour démarrer, avec la v2, vous devez avoir à au moins 0,5 ACU sur vos instances d'écriture et de lecture pour que la base de données soit prête à répondre aux requêtes.

Vous trouverez ci-dessous une architecture type pour héberger une application web impliquant uniquement des services sans serveur. L'hébergement d'une telle application pourrait coûter moins de 1 $/an pour un nombre limité d'utilisateurs.

Le sans serveur est-il réservé aux microservices ?

Oui et non. Il a été conçu en pensant aux microservices, mais vous pouvez toujours déployer une architecture monolithique (tant que vous n'avez pas de séquence de démarrage de longue durée à chaque lancement d'un nouvel environnement).

Options sans serveur pour résoudre les défis courants liés aux microservices : orchestration et chorégraphie

L'architecture des microservices permet de réduire le couplage entre les composants des applications (en utilisant différents langages, via des modèles asynchrones, en améliorant l'évolutivité en supprimant le couplage au niveau de l'infrastructure).

Cependant, lorsque nous avons plusieurs fonctions à objectif unique, la mise en œuvre de la logique métier peut nécessiter une coordination entre les fonctions. Cette coordination peut être mise en œuvre à l'aide de deux modèles fondamentaux.

• Orchestration : dans ce modèle, nous contrôlons les invocations de la fonction de manière impérative. Ceci est souvent utilisé au sein d'un domaine d'activité, lorsque les fonctions sont fournies par une seule équipe de service. Une approche sans serveur pour cela est AWS StepFunction, un flux de travail/machine à états. Il existe un joli tutoriel sur la façon de coordonner les fonctions Lambda à l'aide de StepFunction ici.
• Chorégraphie : ce modèle est plus pertinent dans des scénarios cross-domaines métier, avec des équipes de service distinctes, pour maintenir un couplage très limité. Un bus d'événements permet à l'application de transmettre des événements et de s'abonner à des événements. Plusieurs consommateurs peuvent s'abonner au même événement et chaque consommateur peut filtrer les événements dont il a besoin. Le service AWS principal pour cela est EventBridge. Vous lirez un article de blog que j'ai écrit à ce sujet ici.

Apprendre à connaître Lambda

Lambda est la solution Function-as-a-Service d'AWS. Avec Lambda, vous pouvez déployer votre code et bénéficier d'une haute disponibilité et d'une évolutivité instantanées, sans vous soucier du déploiement des instances et des correctifs du système d'exploitation ou du runtime.

Lambda peut être utilisé avec des invocations synchrones (via une passerelle API, un Application Load Balancer ou une URL de fonction Lambda) ou des invocations asynchrones (en réponse à des événements générés par AWS ou par l'utilisateur).

Lorsque vous déployez un Lambda, vous choisissez la quantité de mémoire dont il a besoin pour s'exécuter. Le processeur alloué est proportionnel. Vous payez ensuite en fonction du nombre de millisecondes utilisées. Par exemple, un Lambda de 128 Mo coûte 1,7*10^-9$/ms. Cela représente 164 heures de calcul avant de dépenser votre premier dollar.

Et les balances Lambda. Rapide. Beaucoup plus rapide qu'autre chose. Fini les erreurs 429 (ou 500 si votre charge de travail n'est pas bien protégée) dues à une forte variation du trafic.

Résoudre le principal défi avec LambdaLiths : les démarrages à froid

Les environnements d'exécution Lambda ne traitent qu'une seule requête à un moment donné et sont réutilisés pour les requêtes ultérieures. Cela signifie que, pour qu'une fonction Lambda évolue, ou lorsqu'une fonction Lambda n'a pas été invoquée depuis un certain temps, Lambda devra démarrer un nouvel environnement d'exécution : c'est un démarrage à froid.

Si les démarrages à froid sont préjudiciables à votre application (encore une fois, c'est probablement mieux que tout le trafic soit lent ou atteigne 429), alors il existe quelques options. AWS propose un article intéressant sur l'utilisation des réchauffeurs Lambda ou la définition de la concurrence provisionnée pour y remédier. En plus de cela, pour les utilisateurs Java, les fonctionnalités Lambda SnapStart permettent d'offrir de bonnes performances de démarrage à froid, en prenant un instantané de la microVM après l'initialisation de la JVM.

Qu'en est-il du support PHP ?

La FAQ officielle du produit indique qu'il "prend en charge nativement le code Java, Go, PowerShell, Node.js, C#, Python et Ruby, et fournit une API d'exécution qui vous permet d'utiliser n'importe quel langage de programmation supplémentaire pour créer vos fonctions."

Dans les prochains articles de blog de cette série, nous expliquerons comment exécuter PHP sur Lambda en tirant parti de deux frameworks distincts, Bref et Lambda Web Adaptor, et comparerons les possibilités offertes par chacun d'eux.