NatusAI
Le débat monolithe contre microservices commence souvent par le schéma de déploiement. Une seule boîte, ou plusieurs ? Mais la question la plus utile se pose plus tôt : quelle complexité votre équipe doit-elle assumer, et laquelle la plateforme doit-elle gérer ?
Une petite équipe a besoin d’un modèle clair et d’un chemin court entre une idée et une application qui fonctionne. Une organisation en croissance a aussi besoin de capacité, de résilience et de marge pour que ses équipes travaillent de manière autonome. Ces besoins sont liés, mais ce ne sont pas les mêmes.
Cygnus explore un autre équilibre : garder la logique applicative et les données dans un modèle logique unique, puis faire évoluer la façon dont ce modèle est placé et exécuté. L’objectif est de réduire le travail d’intégration que les développeurs reconstruisent sans cesse autour de bases de données, de services et d’outils d’IA distincts.
01 / Le choix d’architecture
Monolithes et microservices ne résolvent pas les mêmes problèmes.
Un monolithe regroupe une application en une seule unité déployable. Il peut être modulaire, soigneusement testé et répliqué derrière un répartiteur de charge. Son attrait est pratique : appels locaux, débogage simple et moins de pièces mobiles. Ses limites apparaissent souvent autour des mises en production partagées, des frontières de responsabilité ou de besoins en ressources inégaux.
Les microservices découpent une application en services déployables indépendamment. Ils sont utiles lorsque des domaines et des équipes ont besoin de leurs propres cycles de publication, politiques de montée en charge ou frontières opérationnelles. Cette indépendance a un coût : appels réseau, contrats versionnés, observabilité, gestion des défaillances et souvent cohérence entre des bases de données séparées.
Aucune des deux approches n’est automatiquement plus rapide ou plus évolutive. Un monolithe bien conçu peut servir une charge importante. Un système de microservices mal découpé peut distribuer ses goulets d’étranglement et les rendre plus difficiles à voir.
Monolithe
Un seul déploiement. Les frontières internes dépendent de la conception du code.
Microservices
Des services et des responsabilités indépendants. Des contrats réseau relient les parties.
Conception de Cygnus
Un modèle de développement unifié. Le déploiement distribué est une orientation au-delà de la v1.
La distinction compte, car la distribution du déploiement et la modularité métier sont des décisions distinctes. On peut avoir des modules sans services séparés ; on peut avoir de nombreux serveurs sans fragmenter le modèle logique de l’application.
02 / Un modèle logique unique
Rapprocher la base de données et le backend.
Cygnus est le socle prévu par NatusAI pour le langage, la base de données et le backend. Sa conception réunit logique applicative typée, données persistantes et fonctions exposées dans un environnement cohérent. Au lieu de maintenir une correspondance distincte à chaque frontière, les développeurs travaillent avec des objets connectés et les fonctions qui agissent sur eux.
C’est particulièrement pertinent pour un jumeau numérique ou une application opérationnelle. Un navire, un bâtiment ou un actif industriel possède une identité, des relations, une localisation, des mesures, des documents et un historique. Répartir chaque vue dans un système sans lien oblige à reconstruire des connexions qui existent déjà dans l’activité.
Un modèle unifié vise à préserver ces connexions. Il donne aussi à l’environnement d’exécution davantage d’informations sur les données, les requêtes et l’exécution, des informations qui pourront éclairer de futures décisions de placement et de coordination.
Un modèle pour l’application.
Plus de choix pour son lieu d’exécution.
Il s’agit d’un principe de conception, pas de la promesse que toute charge de travail passera à l’échelle de façon transparente. Clés de partitionnement, schémas de requêtes, frontières transactionnelles et latence continuent d’influer sur la façon de construire une application.
03 / Quatre façons de grandir
Faire évoluer requêtes et données comme des besoins distincts.
« Nous devons passer à l’échelle » peut signifier davantage de requêtes simultanées, un jeu de données plus volumineux, une meilleure disponibilité, ou les trois. Réplication et sharding répondent à des aspects différents de ce problème. L’explorateur ci-dessous illustre l’orientation de conception distribuée de Cygnus ; ce n’est ni un cluster en fonctionnement ni une fonctionnalité de déploiement publiée.
01 · Nœud unique
Commencer par une application cohérente
La logique applicative et l’ensemble des données résident ensemble sur un seul serveur. C’est le périmètre du profil de déploiement prévu pour Cygnus v1.
Le modèle d’exploitation le plus simple. Capacité et disponibilité dépendent d’un serveur et de ses procédures de restauration.
02 · Répliques
Copier le modèle sur plusieurs nœuds
Dans l’orientation de conception distribuée, les nœuds portent le même code applicatif et une copie complète des données. La réplication peut apporter redondance et capacité de requêtes supplémentaire, selon le modèle de cohérence et de routage des écritures.
Les copies doivent coordonner les mises à jour. Davantage de répliques ne multiplie pas automatiquement le débit d’écriture.
03 · Shards
Diviser les données, conserver le modèle
Le code applicatif reste partagé, tandis que chaque nœud détient une partition des données. Le placement pourrait suivre la géographie, des plages temporelles ou des plages de clés, selon la charge de travail.
Le routage et les requêtes inter-partitions exigent des règles explicites. Des données ou des accès inégalement répartis peuvent créer des points chauds.
04 · Les deux
Répliquer chaque partition
Associer la capacité répartie sur les shards à la redondance au sein de chaque shard. L’expérience de développement visée reste celle d’une base de données et d’un backend logiques uniques, tandis que l’environnement d’exécution gère une topologie physique plus complexe.
Placement des répliques, basculement, rééquilibrage et transactions distribuées exigent une qualification. Il s’agit d’une orientation de conception au-delà de la v1.
copie complète des données une partition des données · Illustration uniquement : ni cluster en fonctionnement, ni fonctionnalité de déploiement publiée.
Commencer sur un nœud
Le profil v1 prévu commence avec un serveur. Code applicatif et données résident ensemble, ce qui rend le premier déploiement abordable. Sauvegardes, restauration, autorisations et limites de ressources font toujours partie d’une exploitation responsable.
Répliquer pour la redondance et la capacité de requêtes
Dans le futur modèle distribué, plusieurs nœuds pourraient porter le même code et une copie complète du jeu de données. Cela peut multiplier les points capables de servir les requêtes adaptées et permettre au système de tolérer certaines pannes de nœuds. Le résultat dépend du routage, du retard de réplication, des garanties de cohérence et des opérations exécutables sur chaque réplique.
Le sharding pour la capacité de données
Lorsque le jeu de données dépasse la capacité d’un serveur, ajouter des copies complètes ne résout pas la contrainte de stockage. Le sharding répartit les données entre les nœuds. Une charge de travail peut être partitionnée par géographie, plage temporelle ou plage de clés. Les requêtes qui traversent ces partitions exigent un routage et parfois une exécution distribuée.
Une illustration simple de capacité : 30 To de données logiques exigent au moins huit serveurs de 4 To chacun, avant répliques, index, marge opérationnelle ou autres surcoûts. C’est de l’arithmétique, pas une mesure de capacité de Cygnus.
Combiner les deux
Chaque shard peut avoir ses propres répliques. Les shards apportent la capacité de données agrégée ; les répliques ajoutent redondance et possibilités de servir les requêtes. Cette topologie combinée est souvent ce que l’on imagine en pensant à une base de données distribuée sur une flotte de serveurs.
Grandir et se réduire selon la demande
L’orientation à plus long terme consiste à automatiser ces choix selon des politiques de charge : ajouter de la capacité quand la demande augmente, déplacer l’exécution avec les données dont elle a besoin et libérer de la capacité quand la demande baisse. L’objectif est de préserver le modèle logique de l’application lorsque le placement change.
Réduire la capacité suppose d’abord de vider le travail en cours et de déplacer ou conserver en toute sécurité les copies de données nécessaires. Planification, rééquilibrage, cohérence et restauration exigent des règles explicites et une qualification. L’extension et la réduction automatiques sont des objectifs de conception futurs pour le cluster, hors du périmètre de la v1 prévue sur serveur unique.
04 / La responsabilité de l’environnement d’exécution
Confier la coordination à la plateforme.
L’expérience Cygnus visée conserve une seule base de code applicative et une seule base de données logique à mesure que le déploiement évolue. Une distribution gérée par l’environnement d’exécution prendrait en charge le placement, le routage, la réplication et la mécanique de coordination des nœuds participants.
Cette mécanique ne disparaît pas. Les réseaux introduisent latence et partitions. Les mises à jour exigent des règles de cohérence. Les transactions qui couvrent plusieurs shards exigent un protocole défini. La restauration doit savoir ce qui a été validé, et le rééquilibrage doit éviter de perdre la responsabilité des données pendant leur déplacement.
L’idée est de mettre en œuvre ces responsabilités une seule fois dans la plateforme, avec des contrats explicites et des outils d’exploitation, au lieu d’obliger chaque application à assembler sa propre version. L’application a toujours besoin de frontières adaptées à sa charge de travail.
05 / Les données dans le temps
Un modèle connecté a besoin d’une mémoire.
Beaucoup de questions métier comportent une dimension temporelle, même quand personne ne l’énonce. Où se trouvait cet actif avant un incident ? Quelle organisation le contrôlait alors ? Que savait le système lorsqu’il a formulé cette recommandation ?
La conception de Cygnus relie relations de graphe, données géospatiales, vecteurs, triplets, séries temporelles et recherche plein texte au sein d’un même socle logique. Ce sont des façons d’explorer un sujet, et non des définitions distinctes de ce qu’est ce sujet.
- Graphe et triplets
Qu’est-ce qui est relié, et comment ?
- Géospatial
Où se trouvait-il à un moment donné ?
- Séries temporelles
Comment ses relevés ont-ils évolué ?
- Plein texte et vecteurs
Quels enregistrements correspondent, ou signifient quelque chose de proche ?
Modèle conceptuel. Les réponses historiques exigent aussi de conserver les versions des sources ainsi que la provenance de la recherche, du modèle et du prompt.
Un historique pour les données, une provenance pour l’IA
Les données temporelles peuvent décrire l’évolution d’un actif, de ses relevés ou de ses relations. Une réponse d’IA historique exige davantage. Elle dépend aussi des documents sources, des plongements vectoriels, de la configuration de recherche, de la version du modèle et du prompt utilisés pour la produire.
Conserver l’historique des données ne conserve pas automatiquement chaque index vectoriel et ne reproduit pas une réponse passée d’un modèle. Une conception utile relie délibérément ces versions et consigne leur provenance, pour qu’une réponse puisse renvoyer aux éléments probants et au contexte qui l’ont étayée.
Un socle pour les applications et les outils
Les capacités natives MCP et chat prévues permettent d’exposer des fonctions autorisées et d’interroger les connaissances connectées. Un outil ou une interface conversationnelle devrait s’appuyer sur le même modèle et la même politique d’accès que l’application. Une requête historique peut alors porter sur un moment choisi, tout en indiquant quels éléments probants et quelle configuration d’IA sont disponibles pour cette réponse.
C’est là qu’un backend unifié devient plus qu’un déploiement simplifié : il peut offrir un socle commun pour les données opérationnelles, l’historique de l’activité et le travail assisté par l’IA.
06 / Choisir les frontières
Garder l’architecture alignée sur le travail.
Les microservices restent utiles lorsque des équipes indépendantes, des frontières de sécurité distinctes ou des exigences d’exploitation différentes les justifient. Un monolithe modulaire reste utile lorsqu’un déploiement partagé préserve la productivité de l’équipe. L’orientation de Cygnus ajoute une autre option : un modèle unifié d’application et de données, avec une distribution gérée plus profondément dans l’environnement d’exécution.
Le bon choix part de la charge de travail. Quelles requêtes dominent ? En combien de temps les mises à jour doivent-elles devenir visibles ? Quelles données vont ensemble ? Que se passe-t-il lors d’une panne réseau ? Quelles responsabilités exigent une propriété indépendante ?
Notre ambition est de permettre aux développeurs de consacrer plus de temps à ces décisions qui comptent, et moins à reconstruire les liens entre leurs outils. Partir d’un modèle cohérent. Préserver les relations métier. Étendre le déploiement physique quand la charge de travail et la plateforme sont prêtes.
Pour aller plus loin
- Martin Fowler : Monolith First (site externe) : comment une architecture peut évoluer à mesure que l’on comprend mieux les frontières des domaines.
- PostgreSQL : Warm Standby (site externe) : un exemple de réplication, de fonctionnement en veille et des arbitrages entre mises à jour synchrones et asynchrones.
- Microsoft Azure Architecture Center : modèle Sharding (site externe) : clés de partitionnement, routage et points d’attention pour distribuer les données.
- Périmètre de Cygnus v1 et profils ultérieurs : le périmètre public et le statut qui sous-tendent ce point de vue de conception.