Un moyen rapide et efficace d’adopter le framework SST
Je travaille actuellement sur l’architecture d’un nouveau projet pour mon entreprise. Ce nouveau projet doit être compatible avec un monolithe historique, puis le prolonger. C’est un cas courant de réécrire une application existante avec la boîte à outils moderne.
Martin Fowler décrivait dans un article en 2004 un moyen de remplacer petit à petit un monolithe par un nouveau produit : le Motif de figue étrangleur. Le principal avantage : une migration lente, un endpoint par un endpoint, pas un bigbang. Ce pattern est en fait largement utilisé lors de la refactorisation d’une application en micro-services par exemple.
SST est un framework sans serveur qui aide à créer des applications fullstacks. Sur mon nouveau projet, je veux profiter de ce framework (c’est un élément classique de notre boîte à outils de nos jours !), mais je veux remplacer une application, pas en créer une nouvelle. Ainsi, le Strangler Fit Pattern semble assez attrayant.
Basé sur Présentation d’AWS réinventer (Lien vidéo Youtube ici), j’ai été convaincu d’utiliser une API Gateway avec le ANY /{proxy+}
pour façade l’application :
A partir de là, j’ai essayé de simuler une application monolithe (représentée par un ApplicationLoadBalancedFargateService
Construction CDK dans mon projet). L’implémentation du monolithe n’est pas très importante, je me fie juste à l’Application Load Balancer (il y a 99% de chance que vous ayez un tel service si votre monolithe est hébergé sur AWS, soit sur EC2 soit sur ECS !).
Voici mon monolithe dans CDK :
const loadBalancedFargateService = new ApplicationLoadBalancedFargateService(
stack,ty
"Service",
{
propagateTags: PropagatedTagSource.SERVICE,
memoryLimitMiB: 1024,
desiredCount: 1,
cpu: 512,
taskImageOptions: {
image: ContainerImage.fromRegistry("nginxdemos/hello"),
},
publicLoadBalancer: false,
}
);
La démo, elle utilise une image docker très simple, nginxdemos/hello
.
Ensuite, SST me permet d’utiliser le même {proxy+}
dans les routes API :
const api = new Api(stack, "api", {
routes: {
"GET /": "functions/lambda.handler",
"ANY /{proxy+}": {
type: "alb",
cdk: {
albListener: loadBalancedFargateService.listener,
},
},
},
});
Et voilàje peux construire de nouvelles routes avec SST, et toutes les routes non spécifiées dans le routes
prop sera géré par l’ancienne application déclarée dans le ApplicationLoadBalancedFargateService
.
La route /
est répondu par mon lambda.handler
une fonction:
Tous les autres itinéraires sont répondus par mon monolithe :