🇸🇮 Ko ti infrastruktura pokaže pot

Včasih arhitektura ne nastane iz diagrama, ampak ti pot pokaže infrastruktura sama.

Ko sem začel razmišljati o CM Ecosystemu, sem se bolj podrobno ozrl tudi na računalnike, na katerih naj bi dejansko tekle posamezne CM instalacije. Eden od njih je moj DEMO strežnik — skoraj neverjetno skromna konfiguracija, na kateri pa brez težav deluje presenetljivo zmogljiva CM Free instalacija.

In pojavilo se je preprosto vprašanje:

Če lahko majhna CM instalacija že sama opravlja svoje delo, zakaj bi Ekosistem potreboval en velik centralni strežnik, ki bi opravljal delo vseh drugih?

Morda ga sploh ne potrebuje.

Od centralnega sistema do skupne infrastrukture

Prvotni namen CM Ecosystema nikoli ni bil ustvariti še ene centralne platforme, od katere bi bili odvisni vsi udeleženci.

Vsaka CM instalacija že ima svoje podatke, svojo poslovno logiko in svoj vir resnice.

Zato sem se začel spraševati, ali lahko posamezna instalacija Ekosistemu ponudi nekaj več kot samo svoje podatke.

Lahko ponudi majhen košček infrastrukture.

Vsaka sodelujoča CM instalacija ima lahko svoja AI Docking Port vrata.

AI agent lahko potrka na katerakoli od njih.

Toda za temi vrati AI ne vstopi v notranjo strukturo konkretnega CM. Doseže le skupen koncept:

Recepcijo.

Recepcija sprejme zahtevo, razume, kam je zahteva usmerjena, in poskrbi za komunikacijo z okoliškimi CM nodi.

AI ni treba poznati strukture omrežja.

Preprosto vpraša.

Recepcija ni nujno strežnik

To je morda najbolj zanimiv del ideje.

Ko govorimo o »Recepciji«, si je zelo lahko predstavljati centralni strežnik nekje v oblaku.

To ni tisto, kar imam v mislih.

Recepcija je skupen protokol in funkcija, ne nujno centralni računalnik.

Ena CM instalacija lahko to funkcijo opravlja za določeno zahtevo.

Druga instalacija lahko naredi enako.

Obremenitev se lahko skozi omrežje premika glede na zahtevo in njen geografski cilj.

Rezultat zato ni ena velika centralna Recepcija, ki streže tisočim CM instalacijam.

Rezultat je lahko veliko majhnih Recepcij, razpršenih med udeleženci.

Zakaj je geografija pomembna

Iskanje nastanitev je redko abstraktno.

Gost običajno išče nekaj, kar je povezano z določeno lokacijo:

*apartma v Ljubljani,* *sobo pri Bledu,* *nastanitev v okolici Radovljice,* *nekaj v radiju 20 kilometrov od določene lokacije.*

Zato je geografija naraven princip usmerjanja.

CM, ki prejme zahtevo, ni nujno blizu iskane lokacije.

Zahteva lahko vstopi skozi CM v Radovljici, cilj pa je Ljubljana.

Lokalna Recepcija lahko zato zahtevo usmeri proti geografsko relevantnim sosednjim vozliščem.

Če prvi sklop vozlišč ne najde dovolj rezultatov, se lahko zahteva širi globlje v omrežje.

Iskanje se širi, vendar z določenimi omejitvami.

Posameznemu AI agentu tega usmerjanja ni treba izvajati.

Komunicira samo z Recepcijo.

Vsak udeleženec nekaj prispeva

S tem se spremeni tudi odnos med udeleženci in Ekosistemom.

Udeleženec ni samo ponudnik podatkov, povezan v neko centralno storitev.

Lahko prispeva:

* svoje nastanitvene podatke, * svojo razpoložljivost, * svoje lokalno znanje, * in majhen del računske ter omrežne zmogljivosti.

Z drugimi besedami:

Udeleženci infrastrukture samo ne uporabljajo. Skupaj jo ustvarjajo.

To je precej drugačen model.

Prav DEMO strežnik mi je pomagal, da sem si to idejo lažje predstavljal.

Ni treba, da je vsak strežnik zmogljiv cloud strežnik, da bi bil koristen.

Če lahko med veliko skromnih računalnikov vsak opravi majhen del dela, lahko skupaj ustvarijo precej zmogljivejši sistem, ne da bi en sam centralni strežnik moral vedeti vse ali obdelovati vse.

CM ostane vir resnice

Ob tem je pomembna še ena posledica.

Razpršeno omrežje ne sme postati nova centralna baza, v kateri bi bile shranjene rezervacije vseh.

CM ostane vir resnice.

Če Recepcija potrebuje podatek o razpoložljivosti drugega vozlišča, to vozliščr vpraša svoj CM in vrne tisto, kar je dovoljeno izpostaviti.

Omrežje prenaša vprašanje in odgovor.

Ne nadomešča sistemov, ki so že lastniki podatkov.

S tem lahko Ekosistem ostane relativno tanek.

Inteligenca je v komunikaciji in usmerjanju, ne v kopiranju celotnega sveta v eno centralno bazo.

Majhen začetek

Tega ni treba začeti kot ogromno distribuirano omrežje.

Pravzaprav mislim, da ne bi smeli.

Prva različica je lahko skoraj neprijetno majhna:

AI → Docking Port → Recepcija → lokalni CM

Nato:

AI → Docking Port → Recepcija → sosednji CM

In šele nato:

AI → Docking Port → Recepcija → sosednja vozlišča → globlja vozliščai

Vsak korak lahko preverimo, preden dodamo naslednjega.

Zato je tudi trenutni razvoj CM AI Docking Port namerno zasnovan na obstoječi funkcionalnosti CM in ne na ustvarjanju novega AI sistema.

CM že zna odgovoriti na vprašanja, kot je razpoložljivost.

Docking Port mu samo omogoči, da ga AI vpraša na standardiziran način.

Morda je prav to Ekosistem

Na začetku sem razmišljal predvsem o tem, kako bi lahko AI komuniciral s CM.

Infrastruktura me je pripeljala do nekoliko drugačnega vprašanja.

Morda pravo vprašanje ni:

Kako zgraditi boljši centralni sistem za vse te CM instalacije?

Ampak:

Kako lahko vse te obstoječe instalacije same postanejo del infrastrukture?

Če ima vsak CM svoja vrata in lahko vsaka vrata ponudijo Recepcijo, potem Ekosistema ni treba zgraditi v celoti nad udeleženci.

Lahko ga zgradimo z udeleženci.

In morda je prav to bolj zanimiva smer za CM Ecosystem:

Ne en velik sistem, ki povezuje množico majhnih sistemov, ampak množica majhnih sistemov, ki skupaj ustvarjajo nekaj večjega.