Ud over monolitter
og mikrotjenester.

01 / Valget af arkitektur

Monolitter og mikrotjenester løser forskellige problemer.

En monolit pakker en applikation som én enhed, der udrulles samlet. Den kan være modulær, grundigt testet og replikeret bag en load balancer. Fordelene er praktiske: lokale kald, enkel fejlfinding og færre bevægelige dele. Begrænsningerne viser sig ofte omkring fælles frigivelser, ejerskabsgrænser eller ujævne ressourcebehov.

Mikrotjenester opdeler en applikation i tjenester, der kan udrulles uafhængigt. De er nyttige, når domæner og teams har brug for egne frigivelsescyklusser, skaleringspolitikker eller driftsgrænser. Den uafhængighed koster arbejde: netværkskald, versionerede kontrakter, observerbarhed, fejlhåndtering og ofte konsistens på tværs af separate datalagre.

Ingen af dem er automatisk hurtigere eller mere skalerbar. En veldesignet monolit kan håndtere en stor arbejdsbelastning. Et dårligt opdelt mikrotjenestesystem kan sprede sine flaskehalse og gøre dem sværere at få øje på.

Forskellen betyder noget, fordi distribution af udrulningen og forretningsmæssig modularitet er separate beslutninger. Du kan have moduler uden separate tjenester; du kan have mange servere uden at fragmentere applikationens logiske model.

02 / Én logisk model

Før database og backend tættere sammen.

Cygnus er NatusAI’s planlagte fundament for sprog, database og backend. Designet samler typet applikationslogik, persistente data og udstillede funktioner i ét sammenhængende miljø. I stedet for at vedligeholde en separat mapping ved hver grænse arbejder udviklerne med forbundne objekter og de funktioner, der handler på dem.

Det er særligt relevant for en digital tvilling eller en driftsapplikation. Et skib, en bygning eller et industrielt aktiv har identitet, relationer, placering, målinger, dokumenter og en historik. At dele hver visning op i et ikke-relateret system betyder, at man skal genopbygge forbindelser, som allerede findes i forretningen.

En samlet model sigter mod at bevare de forbindelser. Den giver også runtime mere information om data, forespørgsler og udførelse – information, der kan understøtte fremtidige beslutninger om placering og koordinering.

Én model for applikationen.
Flere muligheder for, hvor den kører.

Dette er et designprincip, ikke et løfte om, at alle arbejdsbelastninger skalerer transparent. Partitionsnøgler, forespørgselsmønstre, transaktionsgrænser og svartid påvirker stadig, hvordan en applikation bør bygges.

03 / Fire måder at vokse på

Skalér forespørgsler og data som særskilte behov.

»Vi skal skalere« kan betyde flere samtidige forespørgsler, et større datasæt, bedre tilgængelighed – eller alle tre. Replikering og sharding løser forskellige dele af problemet. Visningen nedenfor illustrerer Cygnus’ retning for distribueret design; det er hverken en kørende klynge eller en frigivet udrulningsfunktion.

Start på én node

Den planlagte v1-profil starter med én server. Applikationskode og data ligger sammen, så den første udrulning er til at gå til. Backup, gendannelse, rettigheder og ressourcegrænser er fortsat en del af en ansvarlig drift.

Replikér for redundans og kapacitet til forespørgsler

I den fremtidige distribuerede model kunne flere noder have den samme kode og en komplet kopi af datasættet. Det kan give flere steder at betjene egnede forespørgsler og gøre systemet i stand til at tåle, at nogle noder fejler. Resultatet afhænger af routing, replikeringsforsinkelse, konsistensgarantier og af, hvilke operationer der kan udføres på hvilke replikaer.

Shard for datakapacitet

Når datasættet vokser ud over en server, løser flere fulde kopier ikke begrænsningen i lagring. Sharding fordeler dataene på tværs af noder. En arbejdsbelastning kan partitioneres efter geografi, tidsinterval eller nøgleinterval. Forespørgsler, der krydser partitionerne, kræver routing og nogle gange distribueret udførelse.

Et enkelt kapacitetseksempel: 30 TB logiske data kræver mindst otte servere med 4 TB hver – før replikaer, indeks, driftsmæssig luft eller andet overhead. Det er aritmetik, ikke en måling af Cygnus’ kapacitet.

Kombinér de to

Hver shard kan have sine egne replikaer. Shards giver den samlede datakapacitet; replikaer tilføjer redundans og flere muligheder for at betjene forespørgsler. Denne kombinerede topologi er ofte det, folk forestiller sig, når de tænker på en database fordelt over en flåde af servere.

Vokse og skrumpe med efterspørgslen

Den langsigtede retning er at automatisere disse valg ud fra politikker for arbejdsbelastningen: tilføje kapacitet, når efterspørgslen stiger, flytte udførelsen sammen med de data, den har brug for, og frigive kapacitet, når efterspørgslen falder. Målet er at bevare applikationens logiske model, mens placeringen ændrer sig.

Nedskalering skal først afvikle igangværende arbejde og sikkert flytte eller bevare de nødvendige datakopier. Planlægning, rebalancering, konsistens og gendannelse kræver eksplicitte regler og kvalificering. Automatisk op- og nedskalering er fremtidige designmål for klynger, uden for den planlagte v1 på én server.

04 / Runtimens ansvar

Flyt koordineringen ind i platformen.

Den tilsigtede Cygnus-oplevelse bevarer én applikationskodebase og én logisk database, mens udrulningen udvikler sig. Distribution styret af runtime ville tage sig af placering, routing, replikering og mekanikken i at koordinere de deltagende noder.

Den mekanik forsvinder ikke. Netværk giver forsinkelse og partitioner. Opdateringer kræver konsistensregler. Transaktioner, der spænder over flere shards, kræver en defineret protokol. Gendannelse skal vide, hvad der blev committet, og rebalancering må ikke miste ejerskabet af data, mens de flyttes.

Muligheden er at implementere disse ansvarsområder én gang i platformen, med eksplicitte kontrakter og driftsværktøjer, i stedet for at hver applikation skal bygge sin egen udgave. Applikationen har stadig brug for grænser, der passer til dens arbejdsbelastning.

05 / Data gennem tiden

En forbundet model har brug for en hukommelse.

Mange forretningsspørgsmål har en tidsdimension, også når ingen siger det højt. Hvor var dette aktiv før en hændelse? Hvilken organisation havde kontrol over det dengang? Hvad vidste systemet, da det kom med den anbefaling?

Cygnus-designet forbinder grafrelationer, geodata, vektorer, tripler, tidsserier og fuldtekstsøgning i det samme logiske fundament. Det er måder at udforske et emne på – ikke separate definitioner af, hvad emnet er.

Historik for data – og oprindelse for AI

Temporale data kan beskrive, hvordan et aktiv, dets målinger eller dets relationer ændrer sig. Et historisk AI-svar kræver mere. Det afhænger også af de kildedokumenter, embeddings, den søgekonfiguration, den modelversion og den prompt, der blev brugt til at frembringe det.

At bevare en datahistorik bevarer ikke automatisk alle vektorindeks eller genskaber et tidligere modelsvar. Et nyttigt design forbinder disse versioner og registrerer bevidst deres oprindelse, så et svar kan pege tilbage på den dokumentation og den kontekst, der understøttede det.

Ét fundament for applikationer og værktøjer

De planlagte indbyggede MCP- og chatkapabiliteter giver mulighed for at udstille tilladte funktioner og forespørge forbundet viden. Et værktøj eller en samtalebrugerflade bør arbejde mod den samme model og adgangspolitik som applikationen. En historisk forespørgsel kan så spørge til et valgt tidspunkt og samtidig forklare, hvilken dokumentation og AI-konfiguration der er tilgængelig for svaret.

Her bliver en samlet backend mere end en enklere udrulningshistorie: Den kan give et fælles fundament for driftsdata, forretningshistorik og AI-assisteret arbejde.

06 / Valget af grænser

Hold arkitekturen i takt med arbejdet.

Mikrotjenester er fortsat nyttige, når uafhængige teams, særskilte sikkerhedsgrænser eller forskellige driftskrav berettiger dem. En modulær monolit er fortsat nyttig, når en fælles udrulning holder teamet produktivt. Cygnus’ retning tilføjer endnu en mulighed: en samlet applikations- og datamodel, hvor distributionen styres dybere i runtime.

Det rigtige valg begynder med arbejdsbelastningen. Hvilke forespørgsler dominerer? Hvor hurtigt skal opdateringer blive synlige? Hvilke data hører sammen? Hvad sker der ved en netværksfejl? Hvilke ansvarsområder kræver uafhængigt ejerskab?

Vores ambition er at lade udviklere bruge mere tid på de meningsfulde beslutninger og mindre tid på at genopbygge forbindelserne mellem deres værktøjer. Start med en sammenhængende model. Bevar forretningens relationer. Lad den fysiske udrulning vokse, når arbejdsbelastningen og platformen er klar.