Introduction

Remarque 1 : Voici la démo interactive hébergée : demo.saasconstruct.com

Remarque 2 : Ma facture mensuelle pour chaque configuration SaaS est de 3 à 5 $ par mois, et il s'agit principalement de coûts CI/CD.

Remarque 3 : Le modèle est ici : saasconstruct.com.

J'ai réalisé plusieurs PoC et MVP IA sur AWS, et c'est toujours des choses similaires :

• Hébergez le frontend quelque part
• Appelez le backend
• Le backend récupère/met à jour les données du stockage binaire/de la base de données
• Le backend exécute une logique d'IA ou appelle un autre service et renvoie le résultat
• Il existe deux comptes AWS isolés : dev et prod
• CI/CD pour les déploiements
• Infrastructure-as-Code pour la déclaration des ressources cloud

Donc, j'ai pensé créer une solution simple pour amorcer de telles choses sur AWS. Et écrivez un article de blog à ce sujet.

J'ai décidé d'ajouter quelques fonctionnalités, comme les paiements Stripe (et les paiements LemonSqueezy si vous ne voulez pas vous soucier de la taxe de vente/TVA) et la gestion des paiements, l'authentification, les alarmes de trafic et autres. Je pensais également qu'il devait être configurable, comme remplacer API Gateway et AWS Lambda par ELB et ECS pour des tâches plus longues.

L'extrémité avant

J'ai choisi le framework le plus simple communément déclaré pour commencer. Il s'agit de Vue et, d'après ce que j'ai compris, le deuxième framework le plus populaire. Je l'ai choisi parce que non seulement c'est le plus simple, mais aussi parce que j'en ai eu une certaine expérience.

Le site Web est une application SPA standard avec Vite comme outil de construction. Pour le style, j'utilise Bootstrap car il est également très simple à utiliser, et aussi parce qu'il ne pose pas beaucoup de problèmes lors de la migration d'une version du framework frontend à une autre.

Hébergement frontal

Il existe deux options :

• S3 et CloudFront (CDN)
• AWS Amplify Hosting, qui est un wrapper autour de S3 et CloudFront, facile à utiliser mais moins configurable. Par exemple, vous ne pouvez rien faire avec la distribution CloudFront, car elle n'est pas visible. Vous ne pouvez pas non plus géobloquer votre application, sauf en le faisant avec des redirections.

J'ai opté pour Amplify Hosting comme objectif principal d'AWS dans les solutions d'hébergement front-end et parce qu'il est facile à configurer, à attacher un domaine, etc.

Comme il s'agit d'un système de paiement à l'utilisation, j'ai mis en place une alarme de circulation : s'il y a plus d'un certain nombre d'appels toutes les 10 secondes, je reçois une notification.

Back-end

Le backend est la API Gateway, qui effectue la limitation du débit, et AWS Lambda (Python), qui s'occupe de la logique commerciale et générale :

• Vérifier si l'utilisateur est authentifié
• Traitement des paiements et gestion des abonnements (portail client)
• Envoi d'e-mails
• etc.

J'ai également une autre fonction AWS Lambda qui crée un utilisateur dans la base de données après s'être inscrit dans Cognito.

Il existe des utilitaires partagés dans lesquels j'installe certaines fonctionnalités partagées, par exemple l'envoi de courrier électronique. De plus, la fonctionnalité de journalisation, par exemple, un e-mail m'est envoyé en cas d'erreur de paiement.

Authentification

L'authentification est pénible, je le sais, et je ne voulais pas utiliser un service tiers. Je suis donc resté avec AWS Cognito. C'est assez bon marché.

Vous pouvez dire, utilisez simplement AWS Amplify Auth (qui est un wrapper autour d'AWS Cognito), mais j'ai eu quelques problèmes avec cela. J'ai même écrit un article sur Reddit :

Ma liste de problèmes avec Amplify pour l'authentification

Et il y a un autre message avec une liste encore plus longue provenant d'un utilisateur frustré (c'est un vieux message cependant).

ici

De plus, si vous utilisez uniquement Amplify, vous êtes coincé avec tout l'écosystème sans aucune possibilité de changer quelque chose. Par exemple, si vous souhaitez avoir accès à la distribution CloudFront (par exemple, lorsque vous souhaitez géo-bloquer certaines régions), pas de chance, vous ne pouvez pas le voir avec Amplify Hosting. J'ai également eu d'autres problèmes : l'un des exemples étant la création de CDK à partir des ressources Amplify, ce qui était un problème pour moi.

Donc, ce que j'ai fait est une approche hybride (qui est assez populaire selon Reddit) : la bibliothèque AWS Amplify JS vous permet d'importer des ressources cloud que vous créez vous-même, comme des pools d'utilisateurs, donc je les ai créées avec CDK, puis j'ai simplement utilisé la bibliothèque Amplify JS pour l'authentification.

Dans ce cas, je peux toujours modifier ce que je veux, échanger des ressources cloud (par exemple, je pourrais passer d'Amplify Hosting à CloudFront S3 si j'ai besoin d'accéder à la distribution CloudFront).

E-mails

AWS SES. Il s'agit du principal service de messagerie AWS. Il envoie tout, y compris les e-mails d'authentification Cognito, les demandes du formulaire de contact, etc. La seule chose que vous devez comprendre est que dans votre compte de développement AWS, vous devrez d'abord créer des identités vérifiées pour pouvoir envoyer (je l'ai automatisé via IaC), et dans le compte AWS de production, vous devrez demander un accès à la production (en quelques clics).

À l'aide d'AWS SES, les notifications par e-mail sont envoyées dans les scénarios suivants :

• Lorsque des erreurs de paiement se produisent.
• En cas de pics de trafic Web.
• Si le déploiement CI/CD échoue.
• Pour d'autres situations, telles que les e-mails d'authentification et les demandes du formulaire de contact, etc.

Stockage

DynamoDB en tant que base de données. Facile, rapide et géré. Oui, j'ai dû réfléchir aux modèles d'accès, mais en général, c'est bien de travailler avec et cela ne me coûte rien pendant que je valide/construis. Comme je prévois de travailler sur plusieurs produits et que je souhaite les garder isolés, je ne peux pas mettre RDS/DocumentDB dans les comptes de développement et de production par projet (cela coûte beaucoup trop cher).

Paiements

J'ai ajouté deux systèmes de paiement, et il est possible de choisir lequel utiliser car ils fonctionnent de manière similaire :

• Stripe est populaire et facile à intégrer, clair et simple. Lorsqu'un utilisateur achète un produit, j'utilise la caisse Stripe et pour gérer les abonnements, j'utilise le portail client Stripe.
• LemonSqueezy est très similaire à Stripe, mais c'est également un marchand officiel, ce qui signifie qu'il gère la taxe de vente/TVA pour vous. Il dispose également d'une caisse pour acheter un abonnement et d'un portail client pour les gérer.

J'ai écrit des points de terminaison pour les webhooks Stripe/LemonSqueezy, qui gèrent toute la logique.

L'infrastructure en tant que code

Il y a donc beaucoup de choses parmi lesquelles choisir :

• Quelque chose comme Terraform ou OpenTofu (alternative entièrement open source basée sur Terraform)
• Pulumi
• CDK
• CloudFormation

J'ai choisi AWS CDK, et voici mes raisons :

• Il est facile de travailler avec
• Il est populaire et assez mature
• C'est bien mieux qu'AWS CloudFormation, à mon avis
• C'est une bibliothèque AWS et j'utilise AWS
• Je peux l'écrire en Python, TypeScript ou d'autres langages. Puisque j'utilise Python sur le backend et TypeScript sur le frontend, c'est un bon choix.

La raison pour laquelle je n'ai pas choisi Terraform est que CDK est plus simple ; cela permet de créer des ressources de manière simple, du moins à mon avis. J'aime la POO et j'essaie de construire mon infrastructure cloud en conséquence. Un gros avantage est que CI/CD est inclus (pipelines CDK), donc je n'ai pas besoin d'inventer cela.

CI/CD

J'ai choisi pipelines CDK parce que c'est, encore une fois, simple. Connectez simplement le pipeline au référentiel GitHub et vous êtes prêt à partir. Git push vers la branche de développement -> il sera déployé sur le compte de développement. Git push vers le principal (ou pull request) -> déploiement en production.

Alarmes et limites de débit

J'ai configuré une limitation de débit pour éviter d'être spammé via la passerelle API. J'ai configuré deux alarmes CloudWatch :

• Pour m'avertir lorsque le site Web hébergé reçoit des demandes de spam.
• Pour m'avertir lorsque la passerelle API reçoit du spam avec des requêtes.

J'ai également configuré des alarmes de facturation pour m'informer si je suis sur le point de dépenser trop.

Enregistrement

CloudWatch enregistre les événements, vous pouvez les voir à la fois dans la console AWS et directement dans l'EDI via des extensions.

IA

Le choix était entre utiliser OpenAI (avec les modèles GPT) ou AWS Bedrock (avec les modèles Claude). Cette décision a été difficile car, même si AWS Bedrock with Claude s'intègre facilement à AWS, OpenAI est plus couramment utilisé. Les deux sociétés proposent des modèles d’IA de premier plan. Pour l'instant, j'ai choisi de m'en tenir à AWS Bedrock. Cela pourrait changer à l’avenir, mais pour l’instant, j’apprécie la simplicité. Pour la base de données vectorielles, j'utilise Pinecone, qui possède des index sans serveur.

Un exemple d'application d'IA que j'ai créée ici est un système RAG, qui est essentiellement un chatbot qui peut répondre à des questions basées sur vos données. Vous stockez des informations dans une base de données vectorielle et, sur la requête, vous effectuez une recherche de similarité, puis utilisez simplement LLM pour donner une réponse basée sur le résultat de cette recherche. J'utilise actuellement des modèles simples pour éviter les coûts, mais passer à différents modèles est aussi simple que de changer une ligne de code.

Langages de programmation

J'étais initialement développeur Java, puis je suis devenu développeur Python car j'ai développé des services d'apprentissage automatique et d'apprentissage profond. La plupart des bibliothèques de cet espace sont développées en Python ou comportent un wrapper Python. De plus, Python s'intègre parfaitement à AWS, que ce soit dans AWS Lambda (par exemple, en utilisant la bibliothèque AWS Lambda Powertools) ou dans CDK. Au final, l'infrastructure backend et cloud (via CDK) sont implémentées en Python.

Mon langage secondaire est TypeScript en raison de sa popularité auprès des frameworks frontend. Alors que je travaillais avec JavaScript, j'ai trouvé l'absence de types déroutante à mesure que la base de code s'agrandissait. Le typage statique de TypeScript offre la clarté et la sécurité indispensables pendant le développement, en particulier dans les grands projets.

Factures AWS

Comme je n'ai pas une charge de trafic élevée, mes coûts AWS sont très faibles, généralement 3 à 5 $ par mois, principalement en raison des dépenses CI/CD.

La configuration comprend un CDN (fourni par Amplify Hosting) et une petite couche de mise en cache dans AWS Lambda. De plus, certains services relèvent de l'offre gratuite AWS, ce qui réduit encore mes coûts.

À mesure que le produit évolue et gagne plus d'utilisateurs, je devrai peut-être optimiser les ressources en passant à DynamoDB provisionné et en implémentant DAX (DynamoDB Accelerator). Cependant, pour l'instant, cette configuration fonctionne parfaitement.

Conclusion

Cette solution répond efficacement à mes besoins actuels.

J'ai inclus l'intégralité de cette pile technologique en tant que passe-partout (que je développe et mets à jour activement) dans mon modèle AWS sur SaaSConstruct.

Je continuerai à explorer les fonctionnalités supplémentaires qui peuvent être intégrées à cette configuration pour améliorer ses capacités...