Refonte d'un vieux système de 10 ans : le dev propose des « microservices », est-ce le bon choix pour un petit produit ?

Votre dev cherche surtout à blinder son CV avec des technos à la mode. 1 200 utilisateurs tournent sans aucun problème sur un seul serveur bien optimisé avec une base relationnelle classique. Se mettre à gérer des microservices à 3 va juste doubler vos délais de livraison.

On a fait exactement la même connerie l'an dernier avec une équipe de 4 personnes. On a découpé le système en cinq microservices : on a passé les 6 premiers mois à débugger la communication entre les briques. Nos factures cloud ont explosé, passant de 400 dollars à 2.300 dollars par mois. On a fini par revenir à un monolithe modulaire et notre vitesse de dév a fait x3.

Passer aux microservices, ce n'est pas juste écrire du code. Il faut mettre en place le service discovery, les files de messages, le logging distribué et gérer les transactions distribuées. En découpant la base, une simple jointure SQL devient une cascade d'appels API entre services. Sans expert DevOps dédié à temps plein, le système ne sera pas plus rapide, bien au contraire.

Pour votre refonte, suivez ces 3 étapes : 1) Nettoyez le schéma de la base de données et reliez-le proprement à la logique métier, 2) Structurez vos dossiers avec la rigueur des microservices mais au sein d'un seul projet (monolithe modulaire), 3) Écrivez de solides tests unitaires et d'intégration pour sécuriser la mise en prod.

on s'est chauffés pour la même chose il y a deux ans. du coup un service qui plante et ça faisait tomber tout le reste en cascade, éplucher les logs c'était un enfer sans nom mais avec une petite équipe le monolithe c'est la vie, partez pas dans des délires pareils.

Mais si on monte un monolithe, est-ce qu'on sera obligés de tout jeter à la poubelle si on passe à 10 000 ou 50 000 utilisateurs plus tard ? Est-ce qu'on ne bride pas notre croissance ?

Même 50 000 utilisateurs peuvent tourner à l'aise sur une seule machine bien configurée. Des SaaS mondiaux énormes qui brassent des millions de requêtes tournent toujours sur des monolithes modulaires. Plus tard, si un module précis sature, vous pourrez l'isoler en service dédié. Aucun intérêt de partir sur du distribué dès maintenant.

Au vu de votre budget et de vos effectifs actuels, le monolithe modulaire est le choix le plus rationnel pour maîtriser les risques. Vous concentrer sur les fonctionnalités métier plutôt que sur la complexité d'infrastructure maximisera directement votre retour sur investissement.

Laissez-moi détailler l'aspect technique. Les décisions hâtives finissent par être corrigées six mois plus tard.

Corrigez-moi si je me trompe.

c'est globalement vrai, mais il manque un point. les décisions hâtives finissent par être corrigées six mois plus tard.

ce sujet est archivé.

C'est noté, merci. Ce que tout le monde fait ne signifie pas que c'est la bonne chose.

Je suis aussi curieux de savoir si d'autres font autrement.

c'est noté, merci.

Il y a aussi un aspect mesure à considérer. Tout va bien les trois premiers mois, les problèmes arrivent au quatrième.

Si vous avez des questions, écrivez-moi je répondrai au mieux.

Je ne savais pas ça.

J'ai vécu la même chose.

Je parle du point de vue du fournisseur, c'est mon côté. Ce que tout le monde fait ne signifie pas que c'est la bonne chose.

Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois. Corrigez-moi si je me trompe.

Je vais résumer ce qui a été dit jusqu'ici. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

C'est confirmé par l'expérience.