NatusAI
Spór „monolit czy mikrousługi” zaczyna się zwykle od diagramu wdrożenia. Jeden prostokąt czy wiele? Ważniejsze pytanie pada jednak wcześniej: za którą złożoność powinien odpowiadać Państwa zespół, a którą powinna zarządzać platforma?
Mały zespół potrzebuje jasnego modelu i krótkiej drogi od pomysłu do działającej aplikacji. Rosnąca organizacja potrzebuje też pojemności, odporności i przestrzeni, by zespoły mogły pracować niezależnie. Te potrzeby są powiązane, ale nie są tożsame.
Cygnus szuka innej równowagi: logika aplikacji i dane pozostają w jednym modelu logicznym, a zmienia się sposób jego rozmieszczenia i wykonania. Celem jest ograniczenie pracy integracyjnej, którą programiści wciąż na nowo wykonują wokół odrębnych baz danych, usług i narzędzi AI.
01 / Wybór architektury
Monolity i mikrousługi rozwiązują różne problemy.
Monolit pakuje aplikację w jedną wdrażalną jednostkę. Może być modułowy, starannie przetestowany i replikowany za load balancerem. Jego zalety są praktyczne: wywołania lokalne, proste debugowanie i mniej ruchomych części. Ograniczenia ujawniają się często przy wspólnych wydaniach, granicach odpowiedzialności lub nierównych potrzebach zasobowych.
Mikrousługi dzielą aplikację na niezależnie wdrażalne usługi. Sprawdzają się, gdy domeny i zespoły potrzebują własnych cykli wydań, zasad skalowania lub granic operacyjnych. Ta niezależność ma swoją cenę: wywołania sieciowe, wersjonowane kontrakty, obserwowalność, obsługa awarii i często spójność między odrębnymi magazynami danych.
Żadne z tych podejść nie jest automatycznie szybsze ani bardziej skalowalne. Dobrze zaprojektowany monolit poradzi sobie z dużym obciążeniem. Źle podzielony system mikrousług może rozproszyć swoje wąskie gardła i sprawić, że trudniej je dostrzec.
Monolit
Jedno wdrożenie. Granice wewnętrzne zależą od projektu kodu.
Mikrousługi
Niezależne usługi i odpowiedzialność. Części łączą kontrakty sieciowe.
Projekt Cygnus
Ujednolicony model programowania. Wdrożenie rozproszone to kierunek wykraczający poza v1.
To rozróżnienie jest ważne, ponieważ rozproszenie wdrożenia i modułowość biznesowa to odrębne decyzje. Można mieć moduły bez odrębnych usług; można mieć wiele serwerów bez rozbijania modelu logicznego aplikacji.
02 / Jeden model logiczny
Baza danych i backend bliżej siebie.
Cygnus to planowany przez NatusAI fundament łączący język, bazę danych i backend. Projekt łączy typowaną logikę aplikacji, trwałe dane i udostępniane funkcje w jednym spójnym środowisku. Zamiast utrzymywać osobne mapowanie na każdej granicy, programiści pracują z połączonymi obiektami i funkcjami, które na nich działają.
Ma to szczególne znaczenie w przypadku cyfrowego bliźniaka lub aplikacji operacyjnej. Statek, budynek czy zasób przemysłowy ma tożsamość, powiązania, lokalizację, pomiary, dokumenty i historię. Rozdzielenie każdego z tych widoków do niezwiązanego systemu oznacza odtwarzanie powiązań, które w firmie już istnieją.
Ujednolicony model ma zachować te powiązania. Daje też środowisku uruchomieniowemu więcej informacji o danych, zapytaniach i wykonaniu – informacji, które mogą wspierać przyszłe decyzje o rozmieszczeniu i koordynacji.
Jeden model aplikacji.
Więcej możliwości, gdzie ją uruchomić.
To zasada projektowa, a nie obietnica, że każde obciążenie skaluje się w przezroczysty sposób. Klucze partycjonowania, wzorce zapytań, granice transakcji i opóźnienia nadal wpływają na to, jak należy budować aplikację.
03 / Cztery drogi wzrostu
Skalowanie żądań i skalowanie danych to różne potrzeby.
„Musimy się skalować” może oznaczać więcej równoczesnych żądań, większy zbiór danych, wyższą dostępność – albo wszystko naraz. Replikacja i sharding odpowiadają na różne części tego problemu. Poniższa wizualizacja ilustruje kierunek projektu rozproszonego Cygnus; nie jest to działający klaster ani wydana funkcja wdrożeniowa.
01 · Jeden węzeł
Start od jednej spójnej aplikacji
Logika aplikacji i pełny zbiór danych znajdują się razem na jednym serwerze. Taki jest zakres planowanego profilu wdrożenia Cygnus v1.
Najprostszy model eksploatacji. Pojemność i dostępność zależą od jednego serwera i jego procedur odtwarzania.
02 · Repliki
Kopia modelu na wielu węzłach
W kierunku projektu rozproszonego węzły mają ten sam kod aplikacji i pełną kopię danych. Replikacja może wspierać redundancję i dodatkową przepustowość żądań – w zależności od modelu spójności i kierowania zapisów.
Kopie muszą koordynować aktualizacje. Więcej replik nie zwielokrotnia automatycznie przepustowości zapisu.
03 · Shardy
Podział danych, zachowany model
Kod aplikacji pozostaje wspólny, a każdy węzeł odpowiada za partycję danych. Rozmieszczenie może zależnie od obciążenia odpowiadać geografii, przedziałom czasu lub zakresom kluczy.
Routing i zapytania między partycjami wymagają jawnych reguł. Nierówny rozkład danych lub dostępu może tworzyć gorące punkty.
04 · Oba podejścia
Replikacja każdej partycji
Pojemność wielu shardów połączona z redundancją w każdym z nich. Docelowe doświadczenie programisty to nadal jedna logiczna baza danych i backend, a bardziej złożoną topologią fizyczną zajmuje się środowisko uruchomieniowe.
Rozmieszczenie replik, przełączanie awaryjne, równoważenie i transakcje rozproszone wymagają kwalifikacji. To kierunek projektowy wykraczający poza v1.
pełna kopia danych jedna partycja danych · Wyłącznie ilustracja: nie działający klaster ani wydana funkcja wdrożeniowa.
Start na jednym węźle
Planowany profil v1 zaczyna się od jednego serwera. Kod aplikacji i dane są razem, dzięki czemu pierwsze wdrożenie pozostaje przystępne. Kopie zapasowe, odtwarzanie, uprawnienia i limity zasobów nadal są częścią odpowiedzialnej eksploatacji.
Replikacja dla redundancji i przepustowości żądań
W przyszłym modelu rozproszonym kilka węzłów mogłoby mieć ten sam kod i pełną kopię zbioru danych. Daje to więcej miejsc do obsługi odpowiednich żądań i pozwala systemowi przetrwać awarię części węzłów. Efekt zależy od routingu, opóźnienia replikacji, gwarancji spójności i tego, które operacje mogą być wykonywane na których replikach.
Sharding dla pojemności danych
Gdy zbiór danych przerasta serwer, dodawanie pełnych kopii nie rozwiązuje problemu pojemności. Sharding dzieli dane między węzły. Obciążenie można partycjonować według geografii, przedziałów czasu lub zakresów kluczy. Zapytania przekraczające te partycje wymagają routingu, a czasem wykonania rozproszonego.
Prosty przykład pojemności: 30 TB danych logicznych wymaga co najmniej ośmiu serwerów po 4 TB – przed uwzględnieniem replik, indeksów, zapasu operacyjnego i innych narzutów. To arytmetyka, a nie pomiar pojemności Cygnus.
Połączenie obu podejść
Każdy shard może mieć własne repliki. Shardy zapewniają łączną pojemność danych, repliki dodają redundancję i możliwości obsługi żądań. Taka połączona topologia to często właśnie to, co ludzie mają na myśli, wyobrażając sobie bazę danych rozproszoną na całej flocie serwerów.
Wzrost i redukcja zależnie od zapotrzebowania
Długoterminowym kierunkiem jest automatyzacja tych wyborów na podstawie zasad dla obciążeń: dodawanie pojemności, gdy zapotrzebowanie rośnie, przenoszenie wykonania razem z potrzebnymi danymi i zwalnianie pojemności, gdy zapotrzebowanie spada. Celem jest zachowanie modelu logicznego aplikacji przy zmianach rozmieszczenia.
Zmniejszanie skali wymaga najpierw wygaszenia pracy i bezpiecznego przeniesienia lub zachowania potrzebnych kopii danych. Planowanie, równoważenie, spójność i odtwarzanie wymagają jawnych reguł i kwalifikacji. Automatyczne zwiększanie i zmniejszanie skali to przyszłe cele projektu klastrowego, poza planowanym jednoserwerowym v1.
04 / Odpowiedzialność środowiska uruchomieniowego
Koordynacja przeniesiona do platformy.
Docelowe doświadczenie Cygnus to jedna baza kodu aplikacji i jedna logiczna baza danych, niezależnie od ewolucji wdrożenia. Rozproszenie zarządzane przez środowisko uruchomieniowe przejęłoby rozmieszczenie, routing, replikację i mechanikę koordynacji węzłów.
Ta mechanika nie znika. Sieci wprowadzają opóźnienia i podziały. Aktualizacje wymagają reguł spójności. Transakcje obejmujące wiele shardów wymagają zdefiniowanego protokołu. Odtwarzanie musi wiedzieć, co zostało zatwierdzone, a równoważenie nie może gubić własności danych w trakcie ich przenoszenia.
Szansa polega na tym, by zaimplementować te zadania raz – w platformie, z jawnymi kontraktami i narzędziami operacyjnymi – zamiast kazać każdej aplikacji składać własną wersję. Aplikacja nadal potrzebuje granic dopasowanych do jej obciążenia.
05 / Dane w czasie
Połączony model potrzebuje pamięci.
Wiele pytań biznesowych ma wymiar czasowy, nawet jeśli nikt nie mówi tego głośno. Gdzie był ten zasób przed incydentem? Która organizacja go wtedy kontrolowała? Co system wiedział w chwili, gdy formułował rekomendację?
Projekt Cygnus łączy powiązania grafowe, dane geoprzestrzenne, wektory, trójki, szeregi czasowe i wyszukiwanie pełnotekstowe w tym samym fundamencie logicznym. To sposoby badania danego obiektu, a nie odrębne definicje tego, czym on jest.
- Graf i trójki
Co jest połączone – i jak?
- Dane geoprzestrzenne
Gdzie był w danym momencie?
- Szeregi czasowe
Jak zmieniały się jego odczyty?
- Pełny tekst i wektory
Które zapisy pasują lub znaczą coś podobnego?
Model koncepcyjny. Odpowiedzi historyczne wymagają też zachowanych wersji źródeł oraz informacji o pochodzeniu wyszukiwania, modelu i promptu.
Historia danych – i pochodzenie odpowiedzi AI
Dane temporalne mogą opisywać, jak zmienia się zasób, jego odczyty czy powiązania. Historyczna odpowiedź AI wymaga więcej. Zależy też od dokumentów źródłowych, osadzeń, konfiguracji wyszukiwania, wersji modelu i promptu, które posłużyły do jej wygenerowania.
Zachowanie historii danych nie oznacza automatycznie zachowania każdego indeksu wektorowego ani odtworzenia dawnej odpowiedzi modelu. Dobry projekt świadomie łączy te wersje i zapisuje ich pochodzenie, tak by odpowiedź mogła wskazać dowody i kontekst, na których się opierała.
Jeden fundament dla aplikacji i narzędzi
Planowane natywne funkcje MCP i czatu pozwalają udostępniać dozwolone funkcje i odpytywać połączoną wiedzę. Narzędzie lub interfejs konwersacyjny powinny działać na tym samym modelu i według tych samych zasad dostępu co aplikacja. Zapytanie historyczne może wtedy dotyczyć wybranego momentu, a przy tym wyjaśniać, jakie dowody i jaka konfiguracja AI są dostępne dla tej odpowiedzi.
Właśnie tu ujednolicony backend staje się czymś więcej niż prostszym wdrożeniem: może być wspólnym fundamentem dla danych operacyjnych, historii firmy i pracy wspieranej przez AI.
06 / Wybór granic
Architektura dopasowana do pracy.
Mikrousługi pozostają przydatne, gdy uzasadniają je niezależne zespoły, odrębne granice bezpieczeństwa lub różne wymagania operacyjne. Modułowy monolit pozostaje przydatny, gdy wspólne wdrożenie pozwala zespołowi pracować wydajnie. Kierunek Cygnus dodaje kolejną opcję: ujednolicony model aplikacji i danych, z rozproszeniem zarządzanym głębiej w środowisku uruchomieniowym.
Właściwy wybór zaczyna się od obciążenia. Które żądania dominują? Jak szybko aktualizacje muszą być widoczne? Które dane należą do siebie? Co dzieje się podczas awarii sieci? Które obszary wymagają niezależnej odpowiedzialności?
Chcemy, by programiści mogli poświęcać więcej czasu tym istotnym decyzjom, a mniej – odtwarzaniu połączeń między swoimi narzędziami. Zacząć od spójnego modelu. Zachować relacje biznesowe. Rozbudowywać wdrożenie fizyczne, gdy obciążenie i platforma będą na to gotowe.
Dalsza lektura
- Martin Fowler: Monolith First (strona zewnętrzna) – jak architektura może ewoluować wraz z lepszym zrozumieniem granic domen.
- PostgreSQL: Warm Standby (strona zewnętrzna) – przykład replikacji, pracy w trybie standby i kompromisów między aktualizacjami synchronicznymi i asynchronicznymi.
- Microsoft Azure Architecture Center: Sharding pattern (strona zewnętrzna) – klucze partycjonowania, routing i kwestie związane z rozpraszaniem danych.
- Zakres Cygnus v1 i późniejsze profile – publiczny zakres i status, na których opiera się ta perspektywa projektowa.