A belinkelt projekt nem orchestration réteg. Ha komolyan gondolod (értsd: éles alkalmazást akarsz futtatni), akkor fog kelleni mellé (alája) valami orchestration is. Namost lehet pl. Docker Swarmozni, de ha igazi mikroservice architektúrás valamit csinálsz, meg többszáz gépes nagyságrendű DC-d van (ez nekem azt mondja, hogy nem 3-4 gépben meg 5-10 konténerben gondolkodsz), akkor elég hamar el fogsz oda jutni, hogy Kubernetest akarsz orchestrationnek, mert hiába egyszerű a Swarm, mint a kő, az a cipő hamar szorítani fog. Javaslom az ismerkedést.
Ezek a tételek pl. alapból "kezelve vannak" orchestration szinten, ha k8s-re építed az architektúrádat:
- 100% on-prem futtatási lehetőség, lehetőleg csak ingyenes open source eszközökkel, de burst terheléseket Azure-ba lehessen küldeni (muszáj Azure-t használni)
- Elég rugalmasan átkonfigurálható mikroszerviz hálózat kell nekünk (pl kiderülhet hogy egy gépen belülre kell költöztetni eddig különélő szerviz komponenseket stb)
Maximális számolási teljesítmény a lényeg - itt azért lehetnek gondjaitok az on-prem vs public cloud szolgáltatók terén. Persze nagyban függ ez attól is, hogy most milyen CPU-kat használtok. Ha throughputra gyúrtok, és masszívan párhuzamosítható a feladat, akkor gond egy szál se. Ha viszont a single thread teljesítmény is fontos (latencyre is gyúrtok), akkor a nagy cloud szolgáltatók által használt CPU-fajták nem biztos, hogy a legjobb eredményt adják, vagy legalábbis meglepődés lehet a vége.
A belinkelt cucc mindenképpen érdekesen hangzik. Viszont nálam a vörös fény ott gyullad fel, hogy ez egy 100% MS-projektnek látszik. A top10 contributor MS-alkalmazott. Szóval a "hozott koloncokat" meg kell alaposabban vizslatni, nehogy az egyik mancs beengedése után érkezzen a szokásos MS-only világ (.NET/C#/stb), mint a viccben, amikor "akárhogy raktam össze, végül mindig tank jött ki belőle".
semmit nem kell tárolni, legfeljebb statisztikákat, logokat
Valójában a legfontosabb dolog egy microservice architektúrájú alkalmazás üzemeltethetőségében az observability: metrics/(performance) monitoring, logging, tracing.
Update: kicsit megnéztem közelebbről ezt a belinkelt cuccot. A funkciók egy része úgy működik benne, hogy az adott feladatra (pl. pub/sub, stateful tárolás, secretek elérése, stb) elérhető elterjedtebb cloud és on-prem megoldásokra megpróbáltak ráhúzni valamit generikus interfészt, neked az alkalmazásodban csak azt kell használni, és így az implementációt cserélgetheted az alkalmazásod alatt, nem kell belenyúlni az alkalmazásba. Ez nagyon jól hangzik, de az ördög mindig a részletekben van: mennyire csereszabatosak az eltérő implementációk, mennyire bugos az egész, mekkora meló ez pl. az alkalmazásoddal együtt tesztelni. Vannak kétségeim, hogy ez tényleg ennyire jól használható, mint ahogy elsőre tűnik.
Meg érdemes megnézni, hogy mi az, ami GA:
https://docs.dapr.io/reference/components-reference/supported-state-sto…
https://docs.dapr.io/reference/components-reference/supported-pubsub/