Pourquoi j'ai migré mon application Laravel vers AWS Serverless (et pourquoi je pourrais vous faire économiser du temps et de l'argent)

Cet article explore les avantages du déploiement d'une application Laravel sur AWS Server sans serveur, en le contrastant avec l'hébergement EC2 traditionnel. L'auteur partage leur expérience en migration d'une configuration EC2 à forte intensité de ressources vers une architecture de serveur rentable et évolutive.

---

---

spoiler : Il ne s'agit pas seulement d'économiser de l'argent - bien que mon portefeuille ne se plaint pas.

---

Imaginez ceci: vous avez construit une brillante application Laravel - votre chef-d'œuvre, un couteau à armée suisse numérique avec des fonctionnalités si utiles qu'ils pourraient couper du beurre ... ou des commentaires des utilisateurs. Mais il y a une prise. Chaque mois, vous payez pour une instance EC2 sous-utilisée. La mise à l'échelle ressemble à un bateau de croisière dans un ouragan.

Cela semble familier? Ça m'a fait.

Il y a trois ans, j'ai fait ce que la plupart des développeurs appelleraient fou: j'ai déployé PHP à AWS Lambda. «PHP? Sur Serverless? C'est comme mettre l'ananas sur la pizza! », Ont-ils dit.

Mais je suis ici, trois ans plus tard, en mangeant fièrement ma pizza d'ananas. Permettez-moi de vous dire pourquoi Laravel sur Serverless est la mise à niveau du cloud dont vous ne saviez pas que vous aviez besoin.

---

1. Le problème traditionnel d'hébergement de Laravel

(ou: pourquoi mes instances EC2 avaient une crise existentielle)

Avant le serveur sans serveur, mon application Laravel résidait sur EC2. Pour les non-initiés, EC2 est la version d'Amazon d'un serveur privé virtuel, où vous louez une tranche d'une machine pour exécuter votre code. Ça a l'air génial, non? Jusqu'à ce que la réalité frappe plus fort qu'un voyou composer update.

a) Premièrement: le coût de l'existence

Exécuter une instance EC2, c'est comme posséder une Tesla, vous laissez en marche 24/7, juste au cas où vous voudriez conduire. Ma demande n'était pas toujours occupée, mais cela n'a pas arrêté le compteur. Entre les instances EC2, les équilibreurs de chargement et le stockage partagé, je dépensais environ 110 $ / mois sur une pile de serveurs qui a passé la plupart de son temps inactif. Mon portefeuille? Coulé comme le Titanic.

Je sais, ce n'est pas beaucoup dans le grand schéma des choses, mais en tant que développeur / entrepreneur en solo, chaque dollar compte.

b) Ensuite: mise à l'échelle des cauchemars

Les instances EC2 sont comme cet ami qui réagit de manière excessive à tout.

• Spike de trafic? "Je m'écrase maintenant, merci!"
• pas de trafic? "Je vais toujours brûler votre argent!"

La gestion de l'automate avait envie d'enseigner un poisson à jongler - possible, mais à quel prix? Ajuster manuellement les groupes de mise à l'échelle, configurer des équilibreurs de charge et prier que vous ne surprovisiez pas ressemblant à un deuxième emploi que je n'ai jamais postulé.

c) Et enfin: DevOps, le stagiaire impayé

Personne ne m'a dit que le développement de Laravel est venu avec un côté des responsabilités sysadmin:

• appliquer des correctifs de sécurité.
• Débogage des configurations Nginx / Apache à 3 heures.
• chuchotant des notants doux aux commandes sudo, en espérant qu'ils fonctionneraient cette fois.

Je ne me suis pas inscrit à cette vie.

---

C'est à ce moment-là que j'ai commencé à explorer des alternatives, et sans serveur s'est démarqué comme la solution parfaite à ces maux de tête.

---

2. AWS Server sans: la résurgence de PHP dans le cloud

Clarifions un mythe: Serverless ne signifie pas «pas de serveurs». Cela signifie simplement que les serveurs sont le problème de quelqu'un d'autre. Dans ce cas, AWS gère le levage de lourds pendant que je me concentre sur ce que j'apprécie vraiment: le codage.

a) Lambda: le sorcier motivé en événement

AWS Lambda est comme un super-héros qui ne se présente que lorsque vous en avez besoin. Il exécute votre code en réponse aux événements - requêtes HTTP, messages SQS, tâches planifiées, vous l'appelez. Et lorsque le travail est terminé, il disparaît plus rapidement que la pizza gratuite lors d'une rencontre de développeur.

• pas de coûts de ralenti : Vous ne payez que pour le temps d'exécution (mesuré en millisecondes).
• Magic de mise à l'échelle automatique : Vous avez un pic de 100 000 demandes? Lambda le gère sans transpirer (ou vider votre compte bancaire).
• sans état par conception : C'est comme un nouveau départ à chaque fois, un design qui vous oblige à penser modulaire.

b) Services gérés: les héros méconnus

Serverless n'est pas seulement Lambda - c'est un écosystème. AWS remplace votre infrastructure de bricolage par des services gérés qui "travaillent juste":

• Base de données : Options comme Aurora Serverless (MySQL / Postgres) pour les amateurs de SQL.
• S3 : Stockez vos fichiers sans vous soucier de manquer d'espace disque.
• sqs : Découplez les travaux de longue durée et traitez-les de manière asynchrone.

c) Le paradoxe PHP

Je l'admets: PHP n'était pas né pour le serveur sans serveur. C'est comme demander à un poisson de gravir un arbre - il se plaindra, mais il finira par le faire. Laravel, traditionnellement dépendant du PHP-FPM, avait besoin de quelques ajustements pour prospérer dans le monde éphémère de Lambda:

• Sessions : Déplacez-les vers une base de données externe comme MySQL ou Redis.
• Stockage de fichiers : Redirigez toutes les opérations de stockage vers S3, en utilisant la façade de Laravel Storage.
• Gestion des files d'attente : Configurez SQS comme pilote par défaut pour l'exécution de la tâche asynchrone.
• CACHING : Tirez parti des services externes comme Redis ou DynamoDB au lieu du stockage local.
• Optimisation du temps de démarrage : minimiser le froid commence par couper la graisse (dépendances inutilisées).
• Variables d'environnement : Remplacez .env Fichiers par AWS Secrets Manager ou Paramètre Store pour la gestion de la configuration centralisée et sécurisée.

---

N'oubliez pas que Serverless ne consiste pas seulement à remplacer les serveurs par des fonctions lambda. Il s'agit de repenser votre architecture - ce que AWS gère les points de douleur opérationnels pendant que vous vous concentrez sur la construction.

---

3. comment le serveur déverrouille le plein potentiel de Laravel

Ainsi, Laravel sur Serverless tient-il réellement ses promesses?

Serverless n'est pas seulement un mot à la mode, c'est un changement transformateur. La beauté de Laravel sur le sans serveur réside dans sa capacité à résoudre les faiblesses de l'hébergement traditionnel tout en permettant des solutions plus rapides, plus évolutives et rentables. Mais la vraie magie se produit lorsque vous vous plongez sur la façon dont ces avantages se combinent. Décomposons-le.

a) Démarrage du froid: séparer le mythe de la réalité

Le froid démarre se produit lorsque Lambda initialise une nouvelle instance. Considérez-le comme PHP se réveillant d'une sieste. Les critiques les traitent comme l'apocalypse, mais ils sont gérables:

• réalité : Le froid typique commence par PHP Laravel est d'environ ~ 3-5 secondes.
• Solutions :
  • Laravel Octane : maintient l'application en vie entre les demandes, en réduisant les temps de démarrage. Les demandes ultérieures sont traitées dans ~ 200 ms ou moins.
  • Concurrence provisoire : AWS pré-téléchaume pour les points de terminaison critiques (coûte supplémentaire, mais valable pour les points de terminaison clés) .

Pour la plupart des applications, les retards inférieurs à la 3 seconde pendant le faible trafic sont acceptables. La plupart des utilisateurs ne remarqueront pas un démarrage à froid, en particulier pendant les pointes de la circulation lorsque Lambda reste "au chaud".

b) Échelle indolore

La mise à l'échelle de l'hébergement traditionnel ressemble souvent à une bataille sans fin. Avec sans serveur, la mise à l'échelle devient sans effort: plus de réglages d'autoscalités ou de traverser les doigts pendant une augmentation soudaine de la circulation. AWS Lambda supprime la conjecture, mise à l'échelle horizontalement par défaut.

Voici un exemple:

• Scénario : Votre application devient virale? yay!
• Old EC2 Configuration : Vous commencez à ressentir la latence, vous précipitez pour vous connecter à AWS, ajustez manuellement le nombre d'instances et priez pour le meilleur ?. Oh, et n'oubliez pas d'équilibrer correctement ces instances sur les zones de disponibilité.
• Nouvelle configuration de lambda : AWS crée automatiquement autant d'instances que nécessaire, en manipulant des milliers de demandes simultanées sans que vous leviez un doigt. Vous prenez du pop-corn et regardez des métriques CloudWatch comme une série Netflix ?.

Ce n'est pas seulement la commodité, c'est la tranquillité d'esprit. Alors que vous vous concentrez sur la célébration du succès de votre application, Lambda fait le gros du travail. Et la meilleure partie? Vous ne payez que pour le temps de calcul que vous utilisez, pas pour la capacité inactive dont vous pourriez avoir besoin "au cas où."

c) CONTACK-CONCICATION: le MVP

Serverless n'économise pas seulement de l'argent, c'est comme avoir un buffet à volonté où vous ne payez que pour ce que vous consommez.

• mon ancienne configuration EC2: ~ 110 $ / mois.
  • 4x T3.Small EC2 Instances: 60,00 $
  • 1x équilibreur de charge: 16,40 $
  • 1x EBS (stockage partagé entre les instances EC2): 7,80 $
  • 1x instance MySQL RDS (db.t4g.medium): ~ 26,00 $
• lambda: ~ 34 $ / mois (une économie de 60%!) .
  • lambda, passerelle API ~ demandes de 2,5 m (~ 500 ms / 512 Mo de mémoire) / mois: 4,80 $
  • Services gérés (S3, SQS, CloudWatch): ~ 2,90 $
  • RDS MySQL Instance (db.t4g.medium): ~ 26,00 $

**Resource**	**EC2 Cost**	**Lambda Cost**
Compute	.00	.50
Networking (LB, API Gateway)	.40	.30
Storage	.80	.90
Database	.00	.00
**TOTAL**	**0.20**	**~.70**

En bref, sans serveur économise non seulement de l'argent, mais libère la bande passante mentale. Moins je gaspille les ressources que je me soucie de la surdivision, plus je peux me concentrer sur la construction de quelque chose d'incroyable.

À ce stade, j'utilisais toujours une instance MySQL comme moteur de base de données. Les messages futurs exploreront la migration vers DynamoDB pour réduire davantage les coûts.

d) Liberté de maintenance: Dites adieu aux cauchemars opérationnels

SERVER M'a libéré des chaînes de la maintenance du serveur. Voici comment:

• Plus de mises à jour manuelles : AWS gère les correctifs de sécurité, les mises à jour du système d'exploitation et les améliorations d'exécution, ce qui signifie que vous utilisez toujours des infrastructures sécurisées et à jour.
• Configurations simplifiées : Avec des services comme la passerelle API et S3, la complexité de la gestion des configurations Nginx et des déploiements personnalisés devient une chose du passé.
• Capacité élastique : Oubliez le débit supplémentaire pour les ressources du serveur inutilisées ou la brouillage pour provisionner davantage pendant les pointes de trafic. Lambda évolue automatiquement pour répondre à la demande et arrête la facturation lorsque le ralenti.
• Focus sur les fonctionnalités, pas la lutte contre les incendies : Le temps que j'ai passé auparavant à appliquer des correctifs ou à déboguer les problèmes de production est désormais investi dans la création de fonctionnalités et l'amélioration de l'expérience utilisateur.

Serverless ne réduit pas seulement la maintenance, il élimine les distractions opérationnelles qui vous empêchent de coder.

---

4. mais Laravel est-il sans serveur pour tout le monde?

Aussi révolutionnaire que Laravel sur Serverless, ce n'est pas une solution universelle. Pour certaines applications, la nature apatride et axée sur les événements de Serverless peut sembler être un rêve devenu réalité. Pour d'autres, cela pourrait avoir l'impression d'essayer d'adapter une cheville carrée dans un trou rond. Avant de sauter dans le train sans serveur, prenons du recul et évaluons si cela convient à votre projet.

a) La nature apatride: une épée à double tranchant

Laravel aime les opérations qui préservent les informations entre les interactions, comme le stockage des fichiers localement et l'enregistrement des sessions au système de fichiers. Pour devenir sans serveur, vous devez changer:

• Sessions : Utilisez des bases de données (MySQL / Postgres) ou Redis; Plus de dépendance du système de fichiers.
• fichiers : rediriger les téléchargements de fichiers vers S3, ou éviter complètement Laravel et utiliser les URL pré-signées S3.
• Journaux : Configurez Laravel pour les diffuser sur CloudWatch.
• Configuration : Déplacer .env Variables vers AWS Secrets Manager ou Paramètre Store pour la gestion centralisée.
• files d'attente : migrer les travaux vers AWS SQS pour la manipulation de file d'attente et de messages évolutifs.

b) Considérations de verrouillage des fournisseurs

Les services AWS sont magiques, mais ils sont également propriétaires:

• Vous voulez migrer de SQS vers Redis files d'attente? Préparez-vous à réécrire le code.
• Vous voulez passer de Lambda à Docker? Prenez un café: ce sera une longue nuit.

c) Quand ne pas choisir de serveur sans serveur

Serverless n'est pas une solution miracle pour toutes les charges de travail. Évitez-le si:

• Vous avez besoin de WebSockets : Bien que réalisable avec des services comme API Gateway WebSocket API ou outils tiers comme habilement, il ajoute de la complexité.
• Votre application a des charges de calcul lourdes : des tâches comme l'inférence AI / ML ou le codage vidéo peuvent toucher le délai de 15 minutes de Lambda.
• Vous comptez sur Services avec état : Les applications qui supposent un disque ou un état de serveur persistant peuvent être coûteux à refactor.

---

5. Quelle est la prochaine étape?

Laravel sur Serverless a le potentiel de transformer la façon dont vous créez et déployez des applications, mais la vraie magie est dans l'implémentation. Prêt à faire le saut et à donner à votre application Laravel le traitement sans serveur? Restez à l'écoute pour la partie 2, où je vais vous guider à travers les étapes exactes pour donner vie à cette architecture.

---

Une question pour vous : Quelle est votre plus grande crainte à propos du serveur sans serveur? Partagez-le ci-dessous, et j'adresserai au top 3 de la partie 2!

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!