Pour un site ecommerce, je peux avoir un microservice pour les commandes, un microservices pour les produits et un microservice pour les utilisateurs.

Un utilsateur passe des commandes et les commandes contiennent des produits.

Dans ce cas comment est assuré la relation entre plusieurs base de données si chaque microservice à sa base de donné indépendante ?

tu passes quand meme des cles externes a tes requetes

D'accord

Dans une architecture monolithique j'ai tout dans une même base de données avec mes relations

Dans une architecture orienté microservies est-ce que je vais avoir un table = une base de données = un microservice.
A quel moment je peux me permettre de mettre une relation dans une base de données ?

J'ai lu que Uber avait commencer sur une architecture monolithique quand ils ont commencé dans le ville de base puis ensuite ils ont des problèmes de lenteur et ils ont switchés en microservices.
Est-il possible de casser une base de données conçue pour du monolithique en "microservice" ?

Le 11 avril 2023 à 07:56:22 :
D'accord

Dans une architecture monolithique j'ai tout dans une même base de données avec mes relations

Dans une architecture orienté microservies est-ce que je vais avoir un table = une base de données = un microservice.
A quel moment je peux me permettre de mettre une relation dans une base de données ?

J'ai lu que Uber avait commencer sur une architecture monolithique quand ils ont commencé dans le ville de base puis ensuite ils ont des problèmes de lenteur et ils ont switchés en microservices.
Est-il possible de casser une base de données conçue pour du monolithique en "microservice" ?

"Une table = une base de données = un microservice". Non. Déjà tu pourrais avoir la même base de données et privilégier une séparation en schémas (tout dépend de tes besoins). Ensuite, pourquoi te limiter à une seule table par microservice? Il faut que ton microservice reste cohérent mais il peut gérer plus d'une table. Prenons les utilisateurs: tu peux avoir la table "utilisateur" ainsi que la table "coordonnées" et avoir une relation entre ces deux tables. Vu que c'est ton microservice "utilisateur" qui gère les deux, y a pas de problème (à moins que t'aies un autre microservice qui gère les coordonnées).

Comme l'a dit godrik, quand il s'agit de microservices, pour gérer les relations entre des entrées découplées car gérées par des services différents, on travaille avec des références/clés externes. Ces références ne sont soumises à aucune contrainte relationnelle. En gros, la base de données ne t'aidera pas à garantir l'intégrité de tes relations, c'est à toi de gérer correctement tes transactions (et les erreurs qui pourraient survenir). C'est pour ça que ce genre d'architecture, bien que performant, n'est pas tout le temps approprié. Il faut une infrastructure adéquate et des systèmes robustes. Il faut aussi être pointilleux dans la définition des processus, si non ton archi microservice va partir dans tous les sens. Tous les services vont finir par communiquer n'importe comment entre eux et tu n'auras plus la maîtrise sur la question "qui fait quoi" ce qui est essentiel dans ce genre d'archis.

Oui il est possible de "casser" une base de données conçue pour du monolithique afin de découpler les tables qui doivent être gérées séparément. Comme tu l'as dit, il s'agit de "casser", ça ne se fera pas en douceur. Grosso modo, il s'agira de refaire tes schémas et de migrer tes données en les adaptant pour qu'elles correspondent au nouveau schéma. Potentiellement beaucoup de problèmes surtout à la migration vu qu'il y aura de la transformation de données. C'est un gros job.

Merci pour cette réponse

Etant seule sur un projet perso, je peux très bien commencer par du monoithique et si mon projet intéresse des sociétés et que le produit grandit, casser ma base de données et construire une architecture plus adapté au traffic du site ? On est alors pas "bloqué" avec une architecture monolithique ?

Pour aller vite je voulais faire une application web fullstack avec Next Prisma PlanetScale. Je peux aller plus vite comme ça et ça m'évite d'avoir un front + back en plusieurs microservices. Qu'en pensez-vous ?

Le 11 avril 2023 à 11:11:06 :
Merci pour cette réponse

Etant seule sur un projet perso, je peux très bien commencer par du monoithique et si mon projet intéresse des sociétés et que le produit grandit, casser ma base de données et construire une architecture plus adapté au traffic du site ? On est alors pas "bloqué" avec une architecture monolithique ?

Pour aller vite je voulais faire une application web fullstack avec Next Prisma PlanetScale. Je peux aller plus vite comme ça et ça m'évite d'avoir un front + back en plusieurs microservices. Qu'en pensez-vous ?

Clairement. Si tu es seule et que tu n'as pas l'habitude de travailler avec ce genre d'archi, tu risques de galérer et de ne pas toujours t'y prendre de la bonne manière.

Si ton but c'est de vendre un produit, c'est les fonctionnalités qui importent et c'est sur ça que tu dois mettre l'effort. Bien sûr, si les fondements techniques sont bons en plus de ça, ce sera un autre argument de vente. Mais crois-moi, c'est secondaire. Personne ne te dira: non on ne peut pas partir sur votre produit parce que c'est du monolithe. Une architecture monolithe moderne n'empêche pas d'implémenter les couches d'intégration et autres principes qui rendront ton produit attractif car intégrable. Les seules impacts notables seront au niveau de la scalabilité et la disponibilité de ton service. On peut aussi noter l'impact sur la maintenabilité/évolutivité mais ça, ça dépend beaucoup des développeurs aussi. Crois-moi, je suis tombé sur des gros monolithes bien plus faciles à maintenir et à faire évoluer que toutes les architectures microservices sur lesquelles j'ai travaillé qui étaient des spaghettis indémêlables (avec en prime des transactions mal gérées, des états incohérents partout en base de données et ça c'est CLAIREMENT le pire).

En résumé, si t'as une bonne idée de produit et que la demande est tangible, focalise-toi sur les fonctionnalités! Essaie de respecter les principes de qualité du code et de robustesse au changement (tests unitaires / intégration) et ce sera déjà mieux que 95% des produits informatiques existants qui pourtant rapportent des millions à leurs éditeurs.

Désolé j'ai zappé une de tes questions : non on est jamais réellement bloqués si les choses ont été bien faites. Alors oui, je te cache pas, ce genre de migration c'est un gros morceau.

Mais le plus important, c'est la maîtrise des processus. Si tu sais exactement comment fonctionne ton produit, que tout est documenté et bien testé, alors n'importe quel changement sera abordable. Le problème majeur avec les migrations structurelles massives se manifestent surtout quand on ne connaît pas le produit, p.ex les questions qui reviennent souvent pour ce qui est de la base de données:

"On ne sait pas pourquoi cette colonne se trouve ici, pourquoi cet index a été mis là, pourquoi il existe une relation entre la table A et B, etc."

Quand les développeurs ne sont plus capables d'expliquer le produit et les processus y relatifs, ces migrations entraînent énormément de problèmes.

Top tes réponses merci !

Comment on casse une bdd monolithe et comment on la migre vers une orienté microservices ?
Faut un script qui va copier la bdd pour la répartir dans les différents services ?
Comment s'assurer que les données migrer soient cohérentes ?

Le 12 avril 2023 à 16:57:42 :
Top tes réponses merci !

Comment on casse une bdd monolithe et comment on la migre vers une orienté microservices ?
Faut un script qui va copier la bdd pour la répartir dans les différents services ?
Comment s'assurer que les données migrer soient cohérentes ?

J'ai pas lu mais ne jamais partir sur du micro-services si t'as pas genre centaines de milliers d'users.

Tu peux créer un monolithe avec plusieurs bases comme en micro-services. Sinon, pour switcher en gros tu utilises simplement j'injection de dépendances.

Même en monolithiques tu as de la marges niveau perf, part pas sur du microservices si tu n’en as pas vraiment l’utilité

IMHO, à moins d'avoir une grande quantité d'utilisateurs rapidement (1m+), tu devrais surtout te concentrer sur une architecture monolithe.

Vaut mieux commencer petit, et ensuite migrer/changer si vraiment tu en as le besoin. Je ne suis pas spécialiste de ce genre d'architecture, mais il y a quelques articles sympas sur le sujet, dont quelques-uns par Shopify, qui explique que par exemple c'est un "handicap" pour eux (les microservices) mais que dans leurs contexte c'est la meilleure solution.

Et pareil pour la DB, aujourd'hui, le plus important c'est de sortir un projet vite, itérer rapidement sur ton projet, comprendre les besoins réel et ce que tu cherches à résoudre, surtout que si tu finis par dégager de l'argent, et en bonne quantité, tu finiras par avoir du monde avec toi et certainement des personnes plus à même de résoudre ce genre de soucis technique.
Et tu peux toujours voir du côté des DBaaS avec leurs free-tier/low-tier pour commencer, et continuer chez eux quand tu pourras grossir ton projet. Un exemple tout con, chez Planetscale(MySQL) t'as 1 milliard de lecture et 10 million d'écriture gratuite par mois, et ce n'est pas les seuls à faire ça, et pas que pour les DBs. (Supabase[Postgre], MongoDB Atlas, Firebase, Cassandra, etc)

Vaut mieux commencer vite, itérer vite et faire petit, puis faire des changements quand le besoin s'en fait sentir que de prévoir trop gros, se fatiguer et perdre du temps voir ne pas reussir son projet.

Le 12 avril 2023 à 16:57:42 :
Top tes réponses merci !

Comment on casse une bdd monolithe et comment on la migre vers une orienté microservices ?
Faut un script qui va copier la bdd pour la répartir dans les différents services ?
Comment s'assurer que les données migrer soient cohérentes ?

Il n'y a pas de recette précise, ça dépendra beaucoup de ton modèle de données. Mais oui, en gros c'est reprendre tes données, les adapter pour qu'elles correspondent à tes nouveaux schémas "découplés", les réinsérer (via script ou consommation de queue, y a deux écoles) et espérer que tout se passe bien (bon au pire si tu fais les choses bien t'auras des backups et autre ).

La garantie que tout se soit bien passé ça n'existe pas dans ce cadre. Il faut bien tester et à différentes échelles (test insertion nouvelles entrées, migration d'un échantillon de données existantes + tests automatisés, modification/suppression d'entrées et vérification de l'intégrité des relations, etc.). C'est que de la préparation et du blindage pour se prévenir de tout. Comme je l'ai dit, aucune recette miracle.