Žinutės

:)))

per daug visko irgi negerai

microservices harness 🙂

ne viską iškart, bet noriu nusimatyt, kad poto nereiktų stipriai refaktorint ateityje. iki v1 labai paprastai, poto sudėtingės

ok, pasianalizuosiu 🙂

siaip rimti zmones sako kad microservices kaip choreografija ne kaip orchestravimas ;]

bet siaip manau geriausia su AI tai kept "cli irankius"

stdio

na pvz convertdocxtopdf i kurio stdin paduodi blob ir pasiimi is stdout blob, pvz cat file | cdoctopdf —stdio > out.pdf arba kad butu ir zmogui tinkamas - cdoctopdf -i file.doc -o out.pdf

tada skirtinguose projektuose gali reusint 😉

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 🙂

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