Apres une annee complete a faire tourner une application Laravel a fort trafic sur Vapor (AWS Lambda), voici les lecons apprises en toute honnetete -- les avantages comme les defis.

Ce qui a bien fonctionne

Mise a l'echelle automatique. Les pics de trafic qui auraient necessite une intervention manuelle sur des serveurs traditionnels sont geres de maniere transparente. Lambda monte et descend en charge sans modification de configuration.

Reduction de la charge operationnelle. Plus de patchs serveur, plus de mises a jour du systeme d'exploitation, plus de planification de capacite. L'equipe se concentre sur le code applicatif plutot que sur la gestion de l'infrastructure.

Previsibilite des couts a charge variable. La tarification a la requete signifie que les periodes calmes ne coutent presque rien, tandis que la capacite de pointe est toujours disponible sans sur-provisionnement.

Simplicite de deploiement. Les deploiements via Vapor sont rapides et atomiques. Le retour en arriere est simple si des problemes surviennent.

Defis rencontres

Demarrages a froid. La limitation la plus discutee du serverless est reelle mais gerable. Le prechauffage resout la plupart des problemes de demarrage a froid a un cout negligeable. Les conteneurs Lambda reutilisent les connexions apres la premiere requete, donc seule l'invocation initiale d'un nouveau conteneur subit un delai.

Connexions a la base de donnees. Chaque conteneur Lambda ouvre sa propre connexion a la base de donnees. A l'echelle, cela peut epuiser les limites de connexions de la base. Les solutions incluent RDS Proxy pour le pooling de connexions ou l'utilisation de bases de donnees concues pour les charges de travail a haute concurrence.

Complexite du debogage. Les fonctions serverless distribuees sont plus difficiles a deboguer qu'un serveur unique. CloudWatch fournit des logs, mais le tracage des problemes entre les invocations Lambda necessite des outils d'observabilite plus sophistiques.

Limitations du systeme de fichiers. Lambda ne fournit qu'un repertoire temporaire /tmp avec un stockage limite. Les applications qui s'appuient sur le stockage local de fichiers doivent utiliser S3 ou des services similaires a la place.

Limites de temps d'execution. Lambda a un temps d'execution maximum de 15 minutes. Les processus de longue duree comme les imports de donnees ou le traitement video doivent etre decoupes en morceaux plus petits ou deplaces vers d'autres services de calcul.

Enseignements de performance

Avec un prechauffage adequat et une bonne gestion des connexions a la base de donnees, les temps de reponse sont comparables aux deploiements sur serveur traditionnel. La surcharge de l'environnement d'execution Lambda est minimale pour les applications bien optimisees.

Les plus grands gains de performance sont venus de :

La mise en place du prechauffage pour eliminer les demarrages a froid
L'utilisation du pooling de connexions pour la base de donnees
L'exploitation agressive du cache CDN pour les ressources statiques
Le passage a Laravel Octane pour les connexions persistantes au sein des conteneurs Lambda

Analyse des couts

Pour les applications a trafic variable (nuits calmes, journees chargees, pics occasionnels), Vapor coute generalement moins cher que le provisionnement de serveurs traditionnels pour la capacite de pointe. Pour les applications avec un trafic eleve constant 24h/24, la comparaison des couts se resserre, et les serveurs traditionnels peuvent etre plus economiques.

Verdict apres un an

Laravel Vapor est excellent pour les equipes qui souhaitent eliminer la charge de gestion de l'infrastructure et ont des applications avec des schemas de trafic variables. Ce n'est pas une solution universelle -- certaines charges de travail sont mieux servies par des conteneurs ou des serveurs traditionnels. Mais pour le bon cas d'usage, il reduit significativement la complexite operationnelle tout en fournissant une infrastructure fiable et evolutive.