Division du monolithe

Dans ce module, vous allez diviser l’application node.js en plusieurs services interconnectés et envoyer l’image de chaque service vers un référentiel Amazon ECR. Commencer la construction

L'architecture finale de l'application utilise Amazon Elastic Container Service et l'équilibreur de charge d'application. 

a. Client
Le client envoie des demandes de trafic sur le port 80.

b. Équilibreur de charge
L’Application Load Balancer (ALB) achemine le trafic externe vers le service correspondant. L’ALB inspecte la requête du client et se base sur les règles de routage pour l’acheminer vers une instance et un port du groupe cible.

c. Groupes cibles
Chaque service possède un groupe cible qui répertorie les instances et les ports de chaque conteneur en cours d’exécution pour ce service.

d. Services conteneurisés
Amazon Elastic Container Service (Amazon ECS) déploie chaque service dans un conteneur sur un cluster EC2. Chaque conteneur gère uniquement une seule fonctionnalité.

Isolement des pannes
Il arrive même aux meilleures entreprises d’ingénierie de souffrir de graves pannes de production. En plus de toutes les bonnes pratiques standard permettant de corriger les pannes de manière convenable, la création de microservices constitue l’une des approches pouvant limiter l’impact de telles défaillances. Si vous disposez d’une bonne architecture de microservices, lorsqu’un microélément de votre service tombe en panne, seul cet élément cessera de fonctionner. Le reste de votre service continuera de fonctionner correctement.

Isolement pour la sécurité
Dans une application monolithique, si une fonctionnalité de l’application souffre d’une faille de sécurité (par exemple une vulnérabilité permettant l’exécution de code à distance), vous devez alors supposer qu’un pirate pourrait également avoir accès à toutes les autres fonctionnalités du système. Ceci peut être dangereux si, par exemple, votre fonctionnalité de chargement d’avatar souffre d’un problème de sécurité qui finit par compromettre votre base de données et les mots de passe des utilisateurs. La séparation des fonctionnalités en microservices à l’aide d’Amazon ECS vous permet de sécuriser l’accès aux ressources AWS en conférant à chaque service son propre rôle IAM. Lorsque vous suivez les meilleures pratiques en matière de microservices, si un pirate compromet un service donné, il peut alors uniquement accéder aux ressources de ce dernier et n’aura accès aux ressources d’autres services qu’en s’y infiltrant également.

Dimensionnement indépendant
Lorsque les fonctionnalités sont divisées en microservices, il est alors possible d’augmenter ou de réduire de manière indépendante la quantité d’infrastructures et le nombre d’instances utilisées par chaque classe de microservice. Il devient alors plus facile d’évaluer le coût d’une fonctionnalité particulière, d’identifier les fonctionnalités à optimiser en priorité ou encore de préserver la fiabilité des performances des autres fonctionnalités au cas où l’une d’entre elles dépasserait excessivement ses besoins en ressources.

Rapidité de développement
Les microservices réduisent les risques au cours du développement, ce qui peut permettre à une équipe de développer plus rapidement. Dans un monolithe, l’ajout d’une nouvelle fonctionnalité peut potentiellement avoir un impact sur toutes les autres fonctionnalités qu’il contient. Les développeurs doivent étudier soigneusement l’impact de tout code qu’ils ajoutent et s’assurer de ne rien casser. D’un autre côté, une architecture de microservices correcte se compose d’un nouveau code pour chaque nouvelle fonctionnalité intégrée à un nouveau service. Les développeurs peuvent être certains qu’aucun des codes qu’ils écrivent ne pourra avoir d’impact sur le code existant, sauf s’ils écrivent explicitement une connexion entre deux microservices.