Za hranicí monolitů
a mikroslužeb.

01 / Volba architektury

Monolity a mikroslužby řeší různé problémy.

Monolit balí aplikaci jako jednu nasaditelnou jednotku. Může být modulární, pečlivě otestovaný a replikovaný za load balancerem. Jeho přitažlivost je praktická: lokální volání, přímočaré ladění a méně pohyblivých částí. Jeho omezení se často projeví u společných vydání, hranic vlastnictví nebo nerovnoměrných nároků na zdroje.

Mikroslužby rozdělují aplikaci na nezávisle nasaditelné služby. Hodí se, když domény a týmy potřebují vlastní cykly vydávání, pravidla škálování nebo provozní hranice. Tato nezávislost s sebou nese práci: síťová volání, verzované kontrakty, pozorovatelnost, zpracování selhání a často i konzistenci napříč oddělenými úložišti dat.

Ani jedno není automaticky rychlejší nebo lépe škálovatelné. Dobře navržený monolit zvládne velkou zátěž. Špatně rozdělený systém mikroslužeb může svá úzká hrdla rozprostřít a ztížit jejich odhalení.

Toto rozlišení je důležité, protože distribuce nasazení a modularita byznysu jsou samostatná rozhodnutí. Můžete mít moduly bez samostatných služeb; můžete mít mnoho serverů, aniž byste rozdrobili logický model aplikace.

02 / Jeden logický model

Přiblížit databázi a backend.

Cygnus je plánovaný jazykový, databázový a backendový základ NatusAI. Návrh spojuje typovanou aplikační logiku, perzistentní data a zpřístupněné funkce do jednoho uceleného prostředí. Místo udržování samostatného mapování na každé hranici pracují vývojáři s propojenými objekty a funkcemi, které s nimi pracují.

To je důležité zejména u digitálního dvojčete nebo provozní aplikace. Loď, budova nebo průmyslové zařízení má identitu, vztahy, polohu, měření, dokumenty a historii. Rozdělit každý pohled do nesouvisejícího systému znamená znovu skládat propojení, která ve firmě už existují.

Jednotný model se snaží tato propojení zachovat. Zároveň dává runtimu víc informací o datech, dotazech a provádění – informací, které mohou podpořit budoucí rozhodování o umisťování a koordinaci.

Jeden model pro aplikaci.
Víc možností, kde poběží.

Jde o princip návrhu, ne o slib, že každá zátěž bude škálovat transparentně. Klíče oddílů, vzorce dotazů, hranice transakcí a latence stále ovlivňují, jak by aplikace měla být postavená.

03 / Čtyři způsoby růstu

Škálování požadavků a dat jako dvě odlišné potřeby.

„Potřebujeme škálovat“ může znamenat víc souběžných požadavků, větší datovou sadu, vyšší dostupnost – nebo všechno najednou. Replikace a sharding řeší různé části tohoto problému. Následující průvodce ilustruje směr distribuovaného návrhu Cygnus; nejde o živý cluster ani o vydanou funkci nasazení.

Začít na jednom uzlu

Plánovaný profil v1 začíná jedním serverem. Aplikační kód a data jsou pohromadě, takže první nasazení zůstává zvládnutelné. Zálohy, obnova, oprávnění a limity zdrojů zůstávají součástí odpovědného provozu.

Replikovat kvůli redundanci a kapacitě pro požadavky

V budoucím distribuovaném modelu by několik uzlů mohlo nést stejný kód a úplnou kopii datové sady. Vznikne tak víc míst, která mohou obsluhovat vhodné požadavky, a systém může ustát výpadek některých uzlů. Výsledek závisí na směrování, zpoždění replikace, zárukách konzistence a na tom, které operace lze provádět na kterých replikách.

Shardovat kvůli kapacitě dat

Když datová sada přeroste jeden server, přidávání úplných kopií problém s úložištěm nevyřeší. Sharding rozděluje data mezi uzly. Zátěž lze rozdělit podle geografie, časového rozsahu nebo rozsahu klíčů. Dotazy, které tyto oddíly překračují, potřebují směrování a někdy i distribuované provádění.

Jednoduchá ilustrace kapacity: 30 TB logických dat potřebuje alespoň osm serverů po 4 TB, a to ještě bez replik, indexů, provozní rezervy a další režie. Jde o aritmetiku, ne o změřenou kapacitu Cygnus.

Kombinovat obojí

Každý shard může mít vlastní repliky. Shardy zajišťují celkovou kapacitu dat; repliky přidávají redundanci a možnosti obsluhy požadavků. Tuto kombinovanou topologii lidé obvykle myslí, když si představují databázi rozprostřenou přes flotilu serverů.

Růst a zmenšování podle poptávky

Dlouhodobým směrem je automatizovat tyto volby podle pravidel pro zátěž: přidat kapacitu, když poptávka roste, přesouvat provádění spolu s daty, která potřebuje, a uvolnit kapacitu, když poptávka klesá. Cílem je zachovat logický model aplikace i při změnách umístění.

Zmenšení musí nejdřív dokončit rozpracovanou práci a bezpečně přesunout nebo zachovat potřebné kopie dat. Plánování, rebalancování, konzistence a obnova potřebují explicitní pravidla a kvalifikaci. Automatické zvětšování a zmenšování clusteru jsou budoucí cíle návrhu clusteru, mimo plánovanou v1 pro jeden server.

04 / Odpovědnost runtimu

Přesunout koordinaci do platformy.

Zamýšlená zkušenost s Cygnus zachovává jednu kódovou základnu aplikace a jednu logickou databázi i při vývoji nasazení. Distribuce řízená runtimem by převzala umisťování, směrování, replikaci a mechaniku koordinace zapojených uzlů.

Tato mechanika nezmizí. Sítě přinášejí latenci a výpadky spojení. Aktualizace potřebují pravidla konzistence. Transakce přes více shardů potřebují definovaný protokol. Obnova musí vědět, co bylo potvrzeno, a rebalancování nesmí při přesunu dat ztratit přehled o jejich vlastnictví.

Příležitost spočívá v tom, implementovat tyto odpovědnosti jednou v platformě – s explicitními kontrakty a provozními nástroji – místo toho, aby si každá aplikace skládala vlastní verzi. Aplikace přesto potřebuje hranice, které odpovídají její zátěži.

05 / Data v čase

Propojený model potřebuje paměť.

Mnoho obchodních otázek má časový rozměr, i když ho nikdo nevysloví. Kde bylo toto zařízení před incidentem? Která organizace ho tehdy řídila? Co systém věděl, když vydal toto doporučení?

Návrh Cygnus propojuje grafové vztahy, geoprostorová data, vektory, triply, časové řady a fulltextové vyhledávání v rámci jednoho logického základu. Jsou to způsoby, jak zkoumat určitý subjekt, ne samostatné definice toho, čím tento subjekt je.

Historie pro data – a původ pro AI

Časová data mohou popsat, jak se mění zařízení, jeho naměřené hodnoty nebo jeho vztahy. Historická odpověď AI vyžaduje víc. Závisí také na zdrojových dokumentech, embeddinzích, konfiguraci vyhledávání, verzi modelu a promptu, s nimiž vznikla.

Uchování historie dat automaticky neuchová každý vektorový index ani nezopakuje dřívější odpověď modelu. Užitečný návrh tyto verze záměrně propojuje a zaznamenává jejich původ, aby odpověď mohla odkázat zpět na doklady a kontext, o které se opírala.

Jeden základ pro aplikace i nástroje

Plánované nativní schopnosti MCP a chatu umožňují zpřístupnit povolené funkce a dotazovat se na propojené znalosti. Nástroj nebo konverzační rozhraní by mělo pracovat se stejným modelem a stejnými přístupovými pravidly jako aplikace. Historický dotaz se pak může ptát na zvolený okamžik a zároveň vysvětlit, které doklady a jaká konfigurace AI jsou pro danou odpověď k dispozici.

Tady se jednotný backend stává něčím víc než jen jednodušším nasazením: může poskytnout sdílený základ pro provozní data, historii firmy i práci s pomocí AI.

06 / Volba hranic

Architektura má odpovídat práci.

Mikroslužby zůstávají užitečné tam, kde je ospravedlňují nezávislé týmy, odlišné bezpečnostní hranice nebo rozdílné provozní požadavky. Modulární monolit zůstává užitečný tam, kde společné nasazení udržuje tým produktivní. Směr Cygnus přidává další možnost: jednotný aplikační a datový model s distribucí řízenou hlouběji v runtimu.

Správná volba začíná zátěží. Které požadavky převažují? Jak rychle musí být aktualizace viditelné? Která data k sobě patří? Co se stane při výpadku sítě? Které odpovědnosti potřebují nezávislé vlastnictví?

Naší ambicí je umožnit vývojářům věnovat víc času těmto podstatným rozhodnutím a méně času opakovanému propojování jejich nástrojů. Začněte uceleným modelem. Nechte vztahy, které ve firmě existují, nedotčené. Fyzické nasazení rozšiřte, až na to bude zátěž i platforma připravená.