Les bases de l'infrastructure
Un application c'est du code, beaucoup de code mais c'est aussi une infrastructure lui permet de s'exécuter pour obtenir une application performante et sécurisée.
Commençons par expliquer le concept à ta grand-mère
Imagine une application web comme si c’était un restaurant :
La salle du restaurant est l’interface utilisateur où les clients (les utilisateurs) interagissent.
La cuisine, c’est le backend : elle prépare les plats (les fonctionnalités) à partir des commandes (les actions de l’utilisateur).
Le garde-manger, c’est la base de données où sont stockés tous les ingrédients (les données).
Toutes ces parties se combinent et permettent au restaurant de fonctionner. C’est la même chose avec les applications sauf que ces parties ce sont des couches d’infrastructure.
Let’s dive in !
Une infrastructure applicative, c’est le squelette sur lequel repose toute application. Elle garantit que les fonctionnalités visibles par l’utilisateur final soient opérationnelles, stables et évolutives. Dans cet article, nous allons déconstruire une infrastructure typique pour une application simple hébergée sur AWS.
Une infrastructure simple est composée de plusieurs couches :
Une couche réseau, qui permet à une requête d’arriver jusqu’au bon endroit de manière sécurisée.
Une couche front-end, qui correspond à toute la partie applicative affichée à l’utilisateur et avec laquelle il peut interagir.
Une couche back-end, qui contient toute la logique de l’application ainsi que les données.
La couche réseau : amener les utilisateurs jusqu’à notre application en toute sécurité
Amazon Route 53 agit comme un DNS (Domain Name System) et sert à traduire le nom de domaine saisi par l’utilisateur dans son navigateur en une adresse IP associée à l’application. Cela permet de s’assurer que le trafic est routé vers la ressource AWS appropriée.
La requête passe ensuite par le AWS Web Application Firewall (WAF), qui a pour rôle de filtrer et de surveiller le trafic entrant. Cette partie de l’infrastructure est primordiale car elle protège l’application contre de nombreuses attaques, comme les injections SQL, les attaques XSS ou les attaques DDoS (voir l’article sur l’OWASP Top 10 pour en savoir plus).
La couche front-end : délivrer le contenu à nos utilisateurs
L’objectif de cette couche est de fournir aux utilisateurs ce pour quoi ils sont venus sur l’application : le contenu qu’ils voient et avec lequel ils interagissent.
Un serveur web (comme Apache ou Nginx), fonctionnant sur une instance AWS EC2, a pour mission de traiter toutes les requêtes de l’utilisateur, telles que le chargement d’une page ou l’accès à un fichier.
Le contenu statique (images, vidéos, CSS, etc.) est stocké dans un bucket AWS S3, un service de stockage ultra-rapide conçu pour gérer de très grandes quantités de données.
Si votre application délivre du contenu à une large audience mondiale, votre couche front-end pourrait intégrer un CDN (Content Delivery Network) comme Amazon CloudFront pour accélérer la distribution des données.
La couche back-end : le cerveau de votre application
C’est dans cette couche que s’opère la magie, à l’abri des regards. Elle comprend tout ce qui permet de traiter les données, de faire fonctionner votre application et de stocker les informations des utilisateurs.
Les instances AWS EC2 hébergent le serveur d’applications, chargé de traiter la logique métier. Par exemple, si un utilisateur tente de se connecter, le serveur vérifie les informations d’identification et récupère des données personnalisées dans la base de données.
Les données sont stockées grâce au service Amazon RDS, qui permet de gérer des bases de données de manière fiable, en évitant toute perte et en assurant leur disponibilité grâce à des fonctionnalités de sauvegarde et de gestion des erreurs.
Pour accélérer le chargement de certaines données fréquemment consultées, on utilise Amazon ElastiCache, qui permet, par exemple, de mettre en place un cache Redis (voir l’article dédié à Redis). Ce cache réduit la sollicitation de la base de données et améliore considérablement le temps de réponse de l’application.
Enfin, le back-end peut également s’appuyer sur des buckets AWS S3 pour stocker certains fichiers, comme des sauvegardes.
Le chemin d’une requête utilisateur
Imaginons qu’un utilisateur visite votre application pour acheter un produit. Voici ce qu’il se passe :
Demande de l’utilisateur (couche réseau) :
La demande est reçue par Route 53, qui détermine vers quel serveur AWS elle doit être envoyée.
Le WAF vérifie que la demande est sûre et ne présente pas de menaces pour la sécurité.
Servir la page (couche front-end) :
Le serveur web (EC2) reçoit la requête.
Le contenu statique (images, fichiers CSS, etc.) est extrait du bucket S3 et livré rapidement.
Si des données dynamiques sont nécessaires (par exemple, une liste de produits), le serveur web transmet la demande au serveur d’applications.
Traitement de la logique (couche back-end) :
Le serveur d’applications traite la demande.
Si des données sont requises :
Il interroge d’abord ElastiCache pour obtenir une réponse rapide.
Si les données ne sont pas en cache, il interroge la base de données (RDS).
Le serveur d’applications renvoie le résultat traité au serveur web.
Réponse à l’utilisateur :
Le serveur web regroupe tous les éléments et envoie la réponse finale (par exemple, la page web) au navigateur de l’utilisateur.
Et d’un point de vue Product ?
Pourquoi parler de cela ? Après tout, personne ici n’a l’intention de se reconvertir en administrateur système ou en architecte logiciel. Néanmoins, je pense qu’il est important pour un PM (Product Manager) de comprendre les bases de l’infrastructure et de ne pas considérer son application comme un seul gros composant. Ces bases nous seront également utiles plus tard pour aborder des sujets ayant un fort impact sur le produit, comme la notion de scalabilité : comment mon application peut-elle rester réactive, quel que soit le nombre d’utilisateurs ?