Architecture Serverless-First

L'approche serverless-first convient mal aux processus de longue durée dépassant 15 minutes, aux charges de travail nécessitant des connexions WebSocket persistantes, aux applications avec un trafic constant à haut débit lorsque la capacité réservée est moins chère, et aux systèmes nécessitant une configuration de bas niveau du système d'exploitation (OS) ou du réseau. MicrocosmWorks évalue chaque charge de travail par rapport à ces contraintes lors de la conception de l'architecture et recommande des approches hybrides où le serverless gère les points de terminaison d'API et le traitement des événements, tandis que les conteneurs ou les VMs exécutent les charges de travail nécessitant une puissance de calcul persistante. Cette approche pragmatique évite l'erreur courante de forcer chaque composant vers le serverless lorsqu'il n'est pas adapté.

MicrocosmWorks atténue les cold starts de Lambda grâce à la provisioned concurrency pour les endpoints critiques, à la function bundle optimization pour réduire le temps d'initialisation, et à l'utilisation stratégique de Lambda SnapStart pour les workloads Java, ce qui réduit les cold starts de plusieurs secondes à quelques millisecondes. Nous architecturons également les applications de sorte que les chemins sensibles à la latence utilisent des runtimes légers comme Node.js ou Python avec des dépendances minimales, maintenant les cold starts en dessous de 200 ms même sans provisioned concurrency. Pour les endpoints où même cette latence est inacceptable, nous utilisons Lambda@Edge ou CloudFront Functions pour des réponses inférieures à 10 ms.

MicrocosmWorks met en place des environnements de développement locaux en utilisant des outils comme SST (Serverless Stack), LocalStack, ou le mode hors ligne du Serverless Framework qui émulent les services cloud sur la machine du développeur avec une fidélité proche de la production. Nous mettons en œuvre des suites de tests d'intégration qui s'exécutent sur des environnements cloud éphémères créés pour chaque pull request, afin que les développeurs puissent valider par rapport à de vrais services AWS sans partager un environnement de staging. Cette double approche permet des boucles d'itération locales rapides pour le développement tout en détectant les problèmes spécifiques au cloud avant que le code n'atteigne la production.

MicrocosmWorks a constaté que le serverless est considérablement moins cher pour les applications avec des modèles de trafic variables ou en pointe —souvent 70 à 90 % moins cher que des déploiements de conteneurs équivalents toujours actifs— mais l'avantage en termes de coût se réduit pour des débits soutenus supérieurs à 10-20 millions d'invocations par mois. Nous élaborons des modèles de projection de coûts lors de la conception de l'architecture qui comparent la tarification serverless par invocation par rapport à la capacité de conteneur réservée pour vos modèles de trafic spécifiques, y compris les coûts cachés tels que les frais de API Gateway et les frais de transfert de données. Notre service d'optimisation, disponible à des tarifs de conseil de 10 à 35 $/heure, examine régulièrement la facturation serverless pour identifier le gaspillage dû à une mémoire sur-provisionnée, des durées de fonction excessives ou une utilisation inutile de API Gateway.

MicrocosmWorks utilise des proxies de pool de connexions comme Amazon RDS Proxy ou PgBouncer, déployés comme une couche persistante entre les fonctions Lambda et la base de données, qui multiplexe des milliers de connexions Lambda en un pool gérable de connexions réelles à la base de données. Nous concevons également des applications serverless pour préférer DynamoDB ou d'autres bases de données sans connexion pour les charges de travail à haute concurrence où le pool de connexions créerait toujours des goulots d'étranglement. Pour les applications qui doivent utiliser des bases de données relationnelles, nous mettons en œuvre des limites de mise à l'échelle tenant compte des connexions qui plafonnent les invocations Lambda concurrentes pour correspondre à la capacité de connexion de la base de données.