Bortom monoliter
och mikrotjänster.

01 / Arkitekturvalet

Monoliter och mikrotjänster löser olika problem.

En monolit paketerar en applikation som en enda driftsättningsbar enhet. Den kan vara modulär, noggrant testad och replikerad bakom en lastbalanserare. Lockelsen är praktisk: lokala anrop, enkel felsökning och färre rörliga delar. Begränsningarna visar sig ofta kring gemensamma releaser, ägarskapsgränser eller ojämna resursbehov.

Mikrotjänster delar upp en applikation i tjänster som kan driftsättas var för sig. De är användbara när domäner och team behöver egna releasecykler, skalningspolicyer eller driftgränser. Det oberoendet kostar arbete: nätverksanrop, versionerade kontrakt, observerbarhet, felhantering och ofta konsistens mellan separata datalager.

Ingen av dem är automatiskt snabbare eller mer skalbar. En väldesignad monolit kan klara en stor arbetslast. Ett dåligt partitionerat mikrotjänstsystem kan sprida ut sina flaskhalsar och göra dem svårare att se.

Skillnaden spelar roll eftersom distribuerad driftsättning och verksamhetens modularitet är separata beslut. Du kan ha moduler utan separata tjänster, och du kan ha många servrar utan att splittra applikationens logiska modell.

02 / En logisk modell

För databas och backend närmare varandra.

Cygnus är NatusAI:s planerade grund för språk, databas och backend. Designen samlar typad applikationslogik, beständiga data och exponerade funktioner i en sammanhållen miljö. I stället för att underhålla en separat mappning vid varje gräns arbetar utvecklarna med sammankopplade objekt och de funktioner som verkar på dem.

Det är särskilt relevant för en digital tvilling eller en operativ applikation. Ett fartyg, en byggnad eller en industrianläggning har identitet, relationer, plats, mätvärden, dokument och en historik. Att dela upp varje vy i ett eget, orelaterat system innebär att man bygger upp kopplingar som redan finns i verksamheten på nytt.

En samlad modell syftar till att bevara de kopplingarna. Den ger också körmiljön mer information om data, frågor och exekvering – information som kan stödja framtida beslut om placering och samordning.

En modell för applikationen.
Fler alternativ för var den körs.

Det här är en designprincip, inte ett löfte om att varje arbetslast skalar transparent. Partitionsnycklar, frågemönster, transaktionsgränser och latens påverkar fortfarande hur en applikation bör byggas.

03 / Fyra sätt att växa

Skala anrop och data som separata behov.

”Vi behöver skala” kan betyda fler samtidiga anrop, en större datamängd, bättre tillgänglighet – eller alla tre. Replikering och sharding löser olika delar av problemet. Visualiseringen nedan illustrerar den distribuerade designriktningen för Cygnus; den är inte ett kluster i drift eller en släppt driftsättningsfunktion.

Börja på en nod

Den planerade profilen för v1 börjar med en server. Applikationskod och data finns tillsammans, vilket gör den första driftsättningen lätt att komma igång med. Säkerhetskopiering, återställning, behörigheter och resursgränser är fortfarande en del av en ansvarsfull drift.

Replikera för redundans och kapacitet för anrop

I den framtida distribuerade modellen skulle flera noder kunna ha samma kod och en fullständig kopia av datamängden. Det kan ge fler platser att besvara lämpliga anrop och låta systemet tåla att vissa noder fallerar. Resultatet beror på dirigering, replikeringsfördröjning, konsistensgarantier och vilka operationer som kan köras på vilka repliker.

Sharda för datakapacitet

När datamängden växer ur en server löser fler fullständiga kopior inte lagringsbegränsningen. Sharding delar upp data mellan noder. En arbetslast kan partitioneras efter geografi, tidsintervall eller nyckelintervall. Frågor som korsar partitionerna kräver dirigering och ibland distribuerad exekvering.

En enkel kapacitetsillustration: 30 TB logiska data kräver minst åtta servrar med 4 TB vardera, före repliker, index, driftmarginal eller annan overhead. Det är aritmetik, inte en kapacitetsmätning av Cygnus.

Kombinera de två

Varje shard kan ha egna repliker. Shards ger den samlade datakapaciteten; repliker ger redundans och fler möjligheter att besvara anrop. Den kombinerade topologin är ofta vad man menar när man föreställer sig en databas som är distribuerad över en hel serverflotta.

Väx och krymp med efterfrågan

Den långsiktiga riktningen är att automatisera de här valen utifrån policyer för arbetslasten: lägga till kapacitet när efterfrågan växer, flytta exekveringen till de data den behöver och frigöra kapacitet när efterfrågan minskar. Målet är att bevara applikationens logiska modell när placeringen ändras.

Att skala ned kräver först att pågående arbete avslutas och att de nödvändiga datakopiorna flyttas eller behålls på ett säkert sätt. Schemaläggning, ombalansering, konsistens och återställning kräver uttryckliga regler och kvalificering. Automatisk uppskalning och nedskalning är designmål för ett framtida kluster, utanför den planerade v1 för en enda server.

04 / Körmiljöns ansvar

Flytta samordningen in i plattformen.

Den avsedda upplevelsen i Cygnus behåller en kodbas för applikationen och en logisk databas medan driftsättningen utvecklas. Distribution som hanteras av körmiljön skulle ta över placering, dirigering, replikering och mekaniken i att samordna de deltagande noderna.

Den mekaniken försvinner inte. Nätverk ger latens och partitioner. Uppdateringar behöver konsistensregler. Transaktioner som spänner över flera shards behöver ett definierat protokoll. Återställningen måste veta vad som har committats, och ombalanseringen får inte tappa ägarskapet för data medan de flyttas.

Möjligheten ligger i att implementera det här ansvaret en gång i plattformen, med uttryckliga kontrakt och driftverktyg, i stället för att låta varje applikation bygga sin egen variant. Applikationen behöver fortfarande gränser som passar dess arbetslast.

05 / Data genom tiden

En sammankopplad modell behöver ett minne.

Många verksamhetsfrågor har en tidsdimension, även när ingen säger det högt. Var befann sig tillgången före en incident? Vilken organisation kontrollerade den då? Vad visste systemet när det gav den rekommendationen?

Designen i Cygnus kopplar ihop grafrelationer, geospatiala data, vektorer, tripletter, tidsserier och fulltextsökning i samma logiska grund. Det är sätt att utforska ett objekt, inte separata definitioner av vad objektet är.

Historik för data – och spårbarhet för AI

Temporala data kan beskriva hur en tillgång, dess mätvärden eller dess relationer förändras. Ett historiskt AI-svar kräver mer. Det beror också på de källdokument, inbäddningar, den hämtningskonfiguration, den modellversion och den prompt som användes för att ta fram det.

Att bevara en datahistorik innebär inte automatiskt att varje vektorindex bevaras eller att ett tidigare modellsvar kan återskapas. En bra design kopplar ihop versionerna och registrerar deras ursprung medvetet, så att ett svar kan peka tillbaka på de belägg och det sammanhang som stödde det.

En grund för applikationer och verktyg

De planerade inbyggda förmågorna för MCP och chatt gör det möjligt att exponera tillåtna funktioner och ställa frågor mot sammankopplad kunskap. Ett verktyg eller ett konversationsgränssnitt bör arbeta mot samma modell och åtkomstpolicy som applikationen. En historisk fråga kan då gälla en vald tidpunkt och samtidigt förklara vilka belägg och vilken AI-konfiguration som finns för svaret.

Här blir en samlad backend mer än en enklare driftsättning: den kan ge en gemensam grund för operativa data, verksamhetens historik och AI-stött arbete.

06 / Att välja gränserna

Låt arkitekturen följa arbetet.

Mikrotjänster är fortfarande användbara när oberoende team, tydliga säkerhetsgränser eller olika driftkrav motiverar dem. En modulär monolit är fortfarande användbar när en gemensam driftsättning håller teamet produktivt. Riktningen för Cygnus lägger till ett alternativ: en samlad applikations- och datamodell där distributionen hanteras djupare ned i körmiljön.

Rätt val börjar med arbetslasten. Vilka anrop dominerar? Hur snabbt måste uppdateringar bli synliga? Vilka data hör ihop? Vad händer vid ett nätverksfel? Vilka ansvarsområden behöver ett oberoende ägarskap?

Vår ambition är att utvecklare ska kunna lägga mer tid på de viktiga besluten och mindre tid på att bygga om kopplingarna mellan sina verktyg. Börja med en sammanhållen modell. Behåll verksamhetens relationer intakta. Låt den fysiska driftsättningen växa när arbetslasten och plattformen är redo.