2 articles tagués avec « architecture »

Il y a un réflexe dans notre métier, et je l'avais aussi : un nouveau domaine métier apparaît, et la main se tend vers « …donc c'est un nouveau microservice ». Ça fait moderne. Ça fait scalable. Ça fait ce que font les ingénieurs sérieux.

Sur le système d'information ktayl-solution — une plateforme Kubernetes à six nœuds faisant tourner tout le SI d'un assureur simulé — j'avais construit quatre domaines exactement ainsi : polices, sinistres, souscription, identité, chacun avec son dépôt, sa CI, sa base de données, son couloir de promotion. Puis je me suis arrêté et j'ai posé la question qui compte plus que n'importe quel choix de framework : est-ce la bonne architecture, ou seulement celle qui est à la mode ?

Cet article est la réponse à laquelle je suis arrivé — le monolithe modulaire d'abord — et, honnêtement, sa moitié la plus précieuse : la décision que je n'ai délibérément pas prise.

La plupart des tutoriels Kubernetes commencent par eksctl create cluster ou gcloud container clusters create. Un plan de contrôle managé, des groupes de nœuds à auto-scaling, des load balancers qui apparaissent avec une simple annotation. Le cloud abstrait entièrement le matériel.

Nous avons pris la direction opposée. Cinq machines physiques — quatre ThinkPads et un MacBook Pro de 2012 — exécutant k3s, avec chaque workload ordonnancé et exploité par nous. Pas de plan de contrôle managé. Pas de groupe de nœuds à auto-scaling. Pas de load balancer cloud. Juste Linux, containerd et Flannel sur du fer que l'on peut toucher.

Mais nous utilisons bien des services cloud. AWS achemine nos e-mails. Cloudflare se place devant chaque requête HTTP. Une instance Lightsail relaie le trafic UDP de nos appels vidéo. Tailscale nous connecte au cluster depuis n'importe où.

Cet article explique comment nous avons décidé ce qui va où, et pourquoi l'architecture résultante n'est pas un compromis — c'est une conception délibérée.