Introduction

Le serverless a été le centre de l'attention dans le monde de l'infrastructure pendant près d'une décennie. La promesse est irrésistible : pas de serveurs à gérer, mise à l'échelle automatique à zéro, paiement uniquement pour ce que vous utilisez, et scalabilité infinie. Pour certaines charges de travail, le serverless tient ses promesses. Mais pour les applications Laravel, la réalité est nettement plus nuancée.

Contexte Technique

Il existe deux approches principales pour déployer des applications Laravel de manière serverless : Laravel Vapor et Bref. Laravel Vapor est une plate-forme de déploiement serverless conçue par l'équipe Laravel, qui déploie votre application sur AWS Lambda, utilise API Gateway pour le routage HTTP, SQS pour les files d'attente et intègre RDS pour les bases de données et ElastiCache pour Redis. Bref est un projet open-source qui fournit des runtime PHP pour AWS Lambda, vous permettant de déployer Laravel en utilisant le Serverless Framework ou AWS SAM.

Ces deux approches partagent la même infrastructure sous-jacente : des fonctions AWS Lambda qui se lancent à la demande, exécutent votre code PHP et s'arrêtent lorsqu'elles sont inactives. La promesse est convaincante : pas de serveurs à provisionner, patcher ou surveiller, mise à l'échelle automatique de zéro à plusieurs milliers de requêtes concurrentes, tarification pay-per-invocation qui coûte théoriquement rien lorsque votre application n'a pas de trafic, et infrastructure gérée par AWS avec une disponibilité de 99,99 %.

Analyse et Implications

Cependant, chaque promesse comporte des limitations qui ont un impact sur les applications Laravel. Les départs à froid sont le problème le plus discuté avec le serverless PHP, car ils ajoutent 500 millisecondes à 2 secondes à la première requête. Les coûts du serverless peuvent sembler magiques à faible trafic, mais la courbe de coût s'inverse à grande échelle. Les applications Laravel qui gèrent un volume raisonnable de trafic peuvent facilement dépasser 200 à 400 dollars par mois sur Lambda, alors qu'un serveur géré par DigitalOcean coûte environ 24 dollars par mois.

De plus, les fonctions Lambda sont conçues pour être sans état, ce qui signifie qu'il n'y a pas de mémoire partagée entre les requêtes, à moins d'utiliser des workers persistants comme Octane. Cela peut causer des problèmes avec les uploads de fichiers, la génération de fichiers et les workflows qui supposent une persistance du système de fichiers local.

Perspective

En fin de compte, le serverless peut être une bonne option pour les applications Laravel qui ont des besoins spécifiques, tels que des charges de travail faibles ou très irrégulières. Cependant, pour la plupart des applications, les avantages du serverless sont souvent compensés par les limitations et les coûts. Il est essentiel de comprendre les compromis et les coûts avant de choisir le serverless pour votre application Laravel.