Žinutės

noted 🙂 daug projektų numatyta

+ skirtingus irankius gali skirtingi agentai gamint

tai kaip ir parallel kaip ir perzmones /komandas

microservice nebutinai turi kazkas labai mazai kodo 😄

tai gali but labai riebus irankis, kaip kad pvz libreoffice cli 🙂 kuris konvertuoja bet koki doka i pdf or so

toks planas, prijungiu viską ką turiu, skirtingus accountus, API, local, ir poto OS jau nusprendžia ką ir kaip toliau. Labai daug skirtingų agentų flotilių dirbančių prie skirtingų projektų vienu metu su kiek įmanoma mažiau Human approval gateų

arba va, whishper transcripcijos irankis irgi kaip microservice

ir microservice nebutinai gali but cli ir stdio , jis gali kabet ir kaip http and kokio nors porto 😉 kaip long running service'as

bet is principo - microservice turi but independent nuo "transport layer " ( stdio, http, mq etc. ) - turi galet iwrapint veliau

kitaip sakant, jeigu ta pati kalba, tai naudot kaip "package" viduje arba veliau iskist tik ta package ant http / mq jeigu kitam servery kodo gabala reik paleist 🙂

ta pati galima su monolitu, bet keli agentai negali to paties monolito write daryt, nes bus conflict 🙂

viską pasižymėjau, atsikoduosiu, ką tai reiškia ir susiintegruosiu 😄 ačiū!

scale'inasi lengviau siaip monolitas, nes pakeli toki pati koda antram serve, ir nukreipi tik kelis urlus i ji 🙂

microservice architektūra ne visada teisingas pasirinkimas.. būtų gerai suprasti tuos visus „siūlomus žodžius“ prieš naudojant :D

bet deveopment scale'inas geriau permicroservices

jo, bet gali būti gan fragile arba monitoringo chaosas production'e

vienas developina caddy/nginx, kitas php, trecias raso su php apsa

kaip paskirstytum jeigu tai nebutu microservice? 😄

tai čia ne microservice'ai, čia tiesiog layeriai

nu o kaip kitaip pasakyt kad tikras microservice yra pacakge 😄

kuriam uzmauni network layeri 😄

microservices yra tiesiog appsas dalimis suskaidytas

ir dažnai gali gyventi skirtinguose serveriuose

gali

monolitas irgi gali 🙂

jei negyvena skirtinguose, tai gal premature optimization, nžn. Čia, sakyčiau, kiekvienu atveju reikia atskirai žiūrėti, netaikyt absoliuto

ar 10 procesu 1 serve ar 100 per 10 php pvz nesvarbu

tik sesijos ir db ir failai turi but "tinklo resursas"

o ne local saugot 🙂

tai s3, pgsql, redis koks sesijom

mhm

"stateless" tai vadinasi 😄

o kai state apsas nesaugo o deda i tinklo resursa

tai ir aws lambda tinka ir t.t. 🙂

tai stdio minusas kad visada cold start kaip ir

bet turiu atveju kad sekmingai tas pats libreoffice forkinamas ant kiekvieno failo 😄

ant N serveriu

bet , taip reik ziuret

tai jeigu koda organizuosi i "pacakges" ( pvz golang ) teisingai

tai bet kuri pacakge galesi wrapint i http/mq ir imest kaip service i kita serva

velgi, jeigu viskas same language ir packages, tai gauni fizini monolita 😄

nes "sujungt" reik kazkur 😉 i vientisa 🙂

stdio minusas kad nestruktūrizuotas input'as dažniausiai – labai greitai tokie chain'ai daug cpu ant serialization'o suvalgo

kas kviecia tas zino struktura ka paduot ir ka gaus 😄

taip, bet perduodi ascii

stdio irgi yra transportas 🙂

serial console 🙂 (UART) gal net galima pavadint 😄

didelio boud tik

tai reikia serializint/unserializint, nebent visokius protobuf'us naudoji arba shell'as nu