Pour les non initiés, DynamoDB est un système de base de données réparti : les données sont conservées sur l'un des serveurs, en fonction d'une clef de répartition. La partition key (PK).
Les développeurs précédents ont mal choisi cette clef de répartition ; tout va sur le même serveur. Ils voudraient en changer aujourd'hui...
Sauf que c'est pas si simple. Long story short, faut changer le code, migrer les données qui utilisent l'ancienne PK, ou faire cohabiter les deux logiques.
On est face a une violation flagrande de la séparation logique vs. physique des données (un principe des années 60s).
Un problème de répartition physique des données ne devrait pas imposer de modifier le code applicatif. Le fait qu'il faille le changer est une preuve de couplage fort entre le fameux "code métier" et la couche de persistence.
Le truc, c'est qu'il est impossible de faire autrement avec DynamoDB. Ce couplage est "par design", il n'y a aucun mécanisme prévu pour l'éviter.
Prôner d'une part les microservices avec du NoSQL et d'autre part le couplage faible architectural est un bug de la pensée. Ou une imposture intellectuelle.
Je travaille pas perso sur ce projet ; je laisse donc la parole au CTO :
My experience with DynamoDB actually makes me avoid it in favor of an old-fashioned relational database. It may be scalable and cheap, but causes problems like this down the road.
Ben ouais.
#SoftwareEngineering #Databases