Oltre monoliti
e microservizi.

01 / La scelta architetturale

Monoliti e microservizi risolvono problemi diversi.

Un monolite impacchetta un'applicazione come un'unica unità rilasciabile. Può essere modulare, testato con cura e replicato dietro un load balancer. Il suo vantaggio è pratico: chiamate locali, debugging semplice e meno componenti in movimento. I suoi limiti emergono spesso attorno ai rilasci condivisi, ai confini di responsabilità o a fabbisogni di risorse disomogenei.

I microservizi suddividono un'applicazione in servizi rilasciabili in modo indipendente. Sono utili quando domini e team hanno bisogno di propri cicli di rilascio, proprie politiche di scalabilità o propri confini operativi. Questa indipendenza ha un costo: chiamate di rete, contratti versionati, osservabilità, gestione dei guasti e spesso coerenza tra archivi dati separati.

Nessuno dei due è automaticamente più veloce o più scalabile. Un monolite ben progettato può servire un carico di lavoro elevato. Un sistema a microservizi partizionato male può distribuire i propri colli di bottiglia e renderli più difficili da individuare.

La distinzione è importante perché la distribuzione del deployment e la modularità di business sono decisioni separate. Si possono avere moduli senza servizi separati; si possono avere molti server senza frammentare il modello logico dell'applicazione.

02 / Un unico modello logico

Avvicinare database e backend.

Cygnus è la base pianificata di NatusAI per linguaggio, database e backend. Il design riunisce logica applicativa tipizzata, dati persistenti e funzioni esposte in un unico ambiente coerente. Invece di mantenere una mappatura separata a ogni confine, gli sviluppatori lavorano con oggetti connessi e con le funzioni che agiscono su di essi.

Questo è particolarmente rilevante per un gemello digitale o un'applicazione operativa. Una nave, un edificio o un asset industriale ha un'identità, relazioni, una posizione, misurazioni, documenti e una storia. Dividere ogni vista in un sistema scollegato significa ricostruire connessioni che nell'azienda esistono già.

Un modello unificato punta a preservare queste connessioni. Fornisce inoltre al runtime più informazioni su dati, query ed esecuzione: informazioni che possono supportare future decisioni di collocamento e coordinamento.

Un unico modello per l'applicazione.
Più opzioni su dove eseguirla.

È un principio di design, non la promessa che ogni carico di lavoro scali in modo trasparente. Chiavi di partizione, pattern di query, confini delle transazioni e latenza continuano a influenzare il modo in cui un'applicazione va costruita.

03 / Quattro modi di crescere

Scalare richieste e dati come esigenze distinte.

«Dobbiamo scalare» può significare più richieste simultanee, un dataset più grande, una maggiore disponibilità, o tutte e tre le cose. Replica e sharding affrontano parti diverse del problema. L'esploratore che segue illustra la direzione di design distribuito di Cygnus; non è un cluster attivo né una funzionalità di deployment rilasciata.

Partire da un nodo

Il profilo pianificato per la v1 parte da un unico server. Codice applicativo e dati convivono, rendendo il primo deployment accessibile. Backup, ripristino, permessi e limiti di risorse restano parte di una gestione responsabile.

Replicare per ridondanza e capacità di richiesta

Nel futuro modello distribuito, più nodi potrebbero portare lo stesso codice e una copia completa del dataset. Questo può creare più punti in cui servire le richieste adatte e permettere al sistema di tollerare alcuni guasti dei nodi. Il risultato dipende da instradamento, ritardo di replica, garanzie di coerenza e da quali operazioni possono essere eseguite su quali repliche.

Fare sharding per la capacità dei dati

Quando il dataset supera le dimensioni di un server, aggiungere copie complete non risolve il vincolo di storage. Lo sharding divide i dati tra i nodi. Un carico di lavoro potrebbe essere partizionato per geografia, intervallo temporale o intervallo di chiavi. Le query che attraversano queste partizioni richiedono instradamento e, talvolta, esecuzione distribuita.

Un semplice esempio di capacità: 30 TB di dati logici richiedono almeno otto server da 4 TB ciascuno, prima di repliche, indici, margine operativo o altri overhead. È aritmetica, non una misurazione della capacità di Cygnus.

Combinare le due cose

Ogni shard può avere repliche proprie. Gli shard forniscono capacità di dati aggregata; le repliche aggiungono ridondanza e possibilità di servire le richieste. Questa topologia combinata è spesso ciò che si intende quando si immagina un database distribuito su una flotta di server.

Crescere e ridursi con la domanda

La direzione di più lungo periodo è automatizzare queste scelte in base a policy di carico: aggiungere capacità quando la domanda cresce, spostare l'esecuzione insieme ai dati di cui ha bisogno e liberare capacità quando la domanda cala. L'obiettivo è preservare il modello logico dell'applicazione mentre il collocamento cambia.

Ridurre la scala richiede prima di esaurire il lavoro in corso e di rilocare o conservare in sicurezza le copie dei dati necessarie. Pianificazione, ribilanciamento, coerenza e ripristino richiedono regole esplicite e qualificazione. Lo scale-out e lo scale-in automatici sono obiettivi di design futuri per il cluster, fuori dalla v1 pianificata su singolo server.

04 / La responsabilità del runtime

Portare il coordinamento nella piattaforma.

L'esperienza Cygnus prevista mantiene un'unica base di codice applicativo e un unico database logico mentre il deployment evolve. Una distribuzione gestita dal runtime si farebbe carico di collocamento, instradamento, replica e dei meccanismi di coordinamento tra i nodi partecipanti.

Questi meccanismi non scompaiono. Le reti introducono latenza e partizioni. Gli aggiornamenti richiedono regole di coerenza. Le transazioni che coinvolgono più shard richiedono un protocollo definito. Il ripristino deve sapere cosa è stato confermato, e il ribilanciamento deve evitare di perdere la titolarità dei dati mentre li sposta.

L'opportunità è implementare queste responsabilità una sola volta nella piattaforma, con contratti espliciti e strumenti operativi, invece di costringere ogni applicazione ad assemblarne la propria versione. L'applicazione ha comunque bisogno di confini adatti al proprio carico di lavoro.

05 / I dati nel tempo

Un modello connesso ha bisogno di memoria.

Molte domande di business hanno una dimensione temporale, anche quando nessuno la esplicita. Dov'era questo asset prima di un incidente? Quale organizzazione lo controllava allora? Cosa sapeva il sistema quando ha formulato quella raccomandazione?

Il design di Cygnus collega relazioni a grafo, dati geospaziali, vettori, triple, serie temporali e ricerca full-text all'interno della stessa base logica. Sono modi diversi di esplorare un oggetto, non definizioni separate di ciò che quell'oggetto è.

Storico per i dati, provenienza per l'IA

I dati temporali possono descrivere come cambiano un asset, le sue letture o le sue relazioni. Una risposta storica dell'IA richiede di più: dipende anche dai documenti di origine, dagli embedding, dalla configurazione di recupero, dalla versione del modello e dal prompt usati per produrla.

Conservare lo storico dei dati non conserva automaticamente ogni indice vettoriale né riproduce una risposta passata di un modello. Un buon design collega queste versioni e ne registra deliberatamente la provenienza, così una risposta può rimandare alle evidenze e al contesto che l'hanno sostenuta.

Un'unica base per applicazioni e strumenti

Le capacità native di MCP e chat pianificate offrono modi per esporre funzioni consentite e interrogare la conoscenza connessa. Uno strumento o un'interfaccia conversazionale dovrebbe lavorare sullo stesso modello e con la stessa policy di accesso dell'applicazione. Una query storica può quindi interrogare un momento scelto, spiegando quali evidenze e quale configurazione IA sono disponibili per quella risposta.

È qui che un backend unificato diventa più di un deployment più semplice: può offrire una base condivisa per dati operativi, storia aziendale e lavoro assistito dall'IA.

06 / Scegliere i confini

Mantenere l'architettura allineata al lavoro.

I microservizi restano utili quando team indipendenti, confini di sicurezza distinti o requisiti operativi diversi li giustificano. Un monolite modulare resta utile quando un deployment condiviso mantiene produttivo il team. La direzione di Cygnus aggiunge un'altra opzione: un modello applicativo e di dati unificato, con la distribuzione gestita più in profondità nel runtime.

La scelta giusta parte dal carico di lavoro. Quali richieste prevalgono? Con quale rapidità gli aggiornamenti devono diventare visibili? Quali dati vanno tenuti insieme? Cosa succede durante un guasto di rete? Quali responsabilità richiedono una titolarità indipendente?

La nostra ambizione è permettere agli sviluppatori di dedicare più tempo a queste decisioni significative e meno tempo a ricostruire le connessioni tra i loro strumenti. Partite da un modello coerente. Mantenete intatte le relazioni di business. Fate crescere il deployment fisico quando il carico di lavoro e la piattaforma sono pronti.