Oracle vs. Java

HUP cikkturkáló

ma a Google Now ajánlott egy ilyet: http://arstechnica.com/information-technology/2016/07/how-oracles-busin…

gondoltam feldobom, érdekelnek a vélemények.

  • 10559 megtekintés

( laja | 2016. 07. 04., h – 09:16 )

Tipikus hatásvadász cím :) amúgy engem személy szerint nem érdekel, hogy mi lesz a Java EE-vel, az arra való hogy oktatásokat tartsanak róla, meg bonyolult rendszereket állítsanak elő az architectek sok zséért.

( Quain | 2016. 07. 04., h – 10:03 )

A Java EE mar egy jo ideje a Spring mogott kullog, ez az elso szog a koporsoba igazan idoszeru volt.

Nem tudok, de nem vagyok szakerto a temaban.
Annak a puszta tenyet kerdojelezed meg, hogy ilyet ossze lehet hozni springgel, vagy szerinted ez a belepo a "jo enterprise technologia"-klubba?
A facebookot php-ben irtak, a youtube python-t hasznal.
Mindketto tarol es hasznal tobb-kevesebb state-et, masszivan elosztott, megsem jut az ember eszebe eloszor a php vagy python, amikor a kovetkezo enterprise webappon elkezd filozni...

omlesztve:

http://docs.spring.io/spring-boot/docs/current/reference/html/boot-feat…
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframewo…
https://spring.io/guides/gs/routing-and-filtering/
https://en.wikipedia.org/wiki/CAP_theorem
https://en.wikipedia.org/wiki/Speed_of_light
http://a.te.ervelesi.hibad.hu/szalmabab

--
NetBSD - Simplicity is prerequisite for reliability

( mn3monic v | 2016. 07. 04., h – 10:05 )

Azt hiszem ezt a topicot öröm lesz olvasni. Popcorn bekészítve :D

( uid_720 | 2016. 07. 04., h – 11:01 )

Én .NET-esként nem szeretném, ha a Java fejlesztése leállna vagy lelassulna.
Szerintem mindkét technológiának jót tesz, hogy létezik a másik.

Fuszenecker Róbert

Java (SE) != Java EE
A Java EE leginkabb egy specifikacio halmaz, meg egy adag api, ami enterprise (web) alkalmazas-fejlesztest tesz (elvileg :-)) konnyebbe:

Itt tessek a 4. slide-ot megnezni:
http://www.slideshare.net/reza_rahman/java-ee-and-spring-sidebyside-343…

A bal oldali (kek) halmaznal zarjak el a penzcsapot:

http://i.imgur.com/2OGsz9y.png

( uid_4263 v | 2016. 07. 04., h – 12:23 )

Nyugi, a cim hatásvadász (a magyar sajtó egyenesen megirta, hogy nagy baj van, meg fog halni a Java).
Az az igazság hogy a Java EE elvesztette a versenyt az üzleti alkalmazások piacán, elsősorban a Spring kárára. Nem kár érte.
De ez magát a Java -t nem érinti.

--
arch,debian,osmc,android,windows

> Az az igazság hogy a Java EE elvesztette a versenyt az üzleti alkalmazások piacán, elsősorban a Spring kárára.

Tehát dobozos szoftvert el tudok adni a piacon most úgy, hogy Springben van írva. Nem hiányolják hozzá (üzemeltetési, megrendelői oldalról) mondjuk a WebLogic admin consolját, ahol azért millió dolgot be lehet állítani - vagy van ilyesmi Springhez is (én a config fájlokkal indulnék el most, de nem olvastam még ennek utána, megvallom)

Mert magamnak én is Springben fognék neki valaminek - de hogy szoftverfejlesztőként eladható-e egy Springes alkalmazás? Vagy egyből én üzemeltetem, és akkor nincs ilyen kérdés?
--
blogom

Nem igazán értem a kérdés.

A megrendelő kap egy terméket valamilyen formátumban. Ez lehet egy war/ear file, amit csak bedob a szállító által támogatott containerbe, vagy egy jar file, ami tartalmaz minden függőséget (web servertől kezdve jdbc driveren keresztül) vagy az is előfordul, hogy egy előre összerakott docker file-t/virtuális gépet/stb.

Ezen rendszer konfigurációja többféleképp történhet, amit leírnak egy telepítési/üzemeltetési kézikönyvbe. Normális esetben ezt egyszer kell megcsinálni (és az üzleti szerződésben legtöbbször a telepítés is szerepel) és nem kell semmit sem konfigurálgatni alatta. Ha probléma van (akár teljesítmény, akár más) akkor a support szerződés keretében értesíteni kell a beszállítót, aki ezt javítja.

"csak bedob a szállító által támogatott containerbe" latom nem erted tenyleg :) nem dob az be semmit sehova. Foleg nem a "szállító által támogatott" akarmibe. A megrendelo nem egy war filert fizet, vesz egy termeket, es a war/ear/jar az nem egy termek ilyen ertelemben, a termek a hasznalhato szoftver, amire be tudja tanitani az embereket.

-
Big Data trendek 2016

Dobozos szoftverrol beszelunk. a formatum a doboz, nem "valamilyen". Sok enterprise kornyezetben elvart, hogy teljes kontroll legyen a dolgok felett, es kattintomunkas is elboldoguljon az uzemeltetessel, lehessen szep screenshotokat tenni a doksiba. Azt kerdezte a kollega, hogy Springhez letezik-e olyan admin felulet, ahol a kontenert tudod pocogtetni finomhangolni, vagy a beanek lifecycleit tudod managelni, vagy datasourcekat tudsz allitani, vagy listenereket, vagy ujra tudsz appokat deployolni, vagy loggolast tudod modositani, vagy ... kismillio dolog, amit az EE kontenerek admin feluleten meg lehet altalaban csinalni. Szoval lehet ilyen dobozos termeket Spring alapokon epiteni? Aminek egy darab kimenete van a telepitheto es hasznalhato termek, plusz a termeket egy UI-on lehet adminisztralni.

-
Big Data trendek 2016

+1

alapvetően ez a kérdésem, hogy el lehet-e adni ma ilyen terméket itthon, nagyvállalati környezetben, ami Springes?
vagy milyen ügyfélnek adsz el Springes terméket (én csak olyat tudok elképzelni, ahol az üzemeltetést is én viszem majd), s mennyi van ilyen ügyfélből, ma itthon?
--
blogom

Értem. Jó kérdés, mi nem használunk Spring-et, de ahogy nézem, ennél sokkal egyszerűbb a történet:

http://docs.spring.io/spring-boot/docs/1.3.6.RELEASE/reference/htmlsing…

Illetve létezik külsős projekt, amivel lehet állítgatni:

https://github.com/codecentric/spring-boot-admin

aha, én ahogy néztem a spring boot-ot, azt csinálták, hogy megfordították a történetet: nem egy war (ear, stb.) file-t csinálsz, amit bedobsz egy tomcat/glassfish/etc-be,
hanem egy jar file-t generálnak, amibe belecsomagolják a webszerver-t meg ami kell, és mint "microservice"-t futtatják az alkalmazást.

ezért kérdeztem vissza...

mármint én eredetileg valami olyat akartam kérdezni, hogy el lehet-e adni Springes alkalmazást ott, ahol EE alkalmazást igen.
erre jött a válasz, hogy írnék-e Springben atomerőművet.
mivel én EE-ben sem írnék atomerőművet, így kíváncsi lennék, ez hogyan kapcsolódik ide.
--
blogom

"Az az igazság hogy a Java EE elvesztette a versenyt az üzleti alkalmazások piacán, elsősorban a Spring kárára."

Ööö... izé... ez így volt 5-10 éve. Zöldmezős beruházást már csak az a cég kezd Spring alapokon, ahol erős vagy csak kizárólag Spring kompetencia van. Rettenő sok hátránya van a Spring-nek és minden előnye eltűnt a JavaEE 7 óta (azaz több mint két éve).

Nem divat a stateful elosztott tranzakció? Ó, mennyi, de mennyi rendszert láttam, ahol ezzel a felkiáltással kezdtek fejleszteni, aztán a korlátnál szomorúan nézték, hogy nincs tovább... a Spring legnagyobb bűne egyszerűen az, hogy elhitette a skálázhatóság illúzióját a fejlesztőkben, aztán amikor tényleg skálázni kell és nem lehet tovább vertikálisan, akkor jönnek a nagy kompromisszumok és a még nagyobb gányolások.

Emlékszem, hogy a JEE kezdetben (inkább) szar volt (megvalósítás és programozási szempontból is) - emiatt tudott a Spring lendületet venni és egy könnyebben, jobban használható alternatíva lenni. De azóta sokat fejlődött a világ és a határok nagyon kitolódtak. Nyilván most is beléjük lehet ütközni, csak azóta kicsit jobban tudjuk, hogy mi tud működni nagy, naGY, NAGY méretekben. Szóval, rossz rendszer tervezésből adódó gondokat a Spring nyakába varrni... hát... :D

"Emlékszem, hogy a JEE kezdetben (inkább) szar volt (megvalósítás és programozási szempontból is) - emiatt tudott a Spring lendületet venni és egy könnyebben, jobban használható alternatíva lenni."

Igen, ez volt 10 évvel ezelőtt... aztán 2006 május 11-én kijött a Java EE 5, ami azonos szintre hozta az egyszerűséget, csak közben megőrizte a Java EE meglévő előnyeit.

"De azóta sokat fejlődött a világ és a határok nagyon kitolódtak."

Igen. De ahogy látom, sokan még mindig a (sokszor nem létező) 10 évvel ezelőtti ismereteikből és az alap nélküli iparági legendákból szövögetik az érveiket arra, hogy egy technológia miért üdvözítő.

"Nyilván most is beléjük lehet ütközni, csak azóta kicsit jobban tudjuk, hogy mi tud működni nagy, naGY, NAGY méretekben."

Igen. Például tudjuk, hogy a Spring erre alkalmatlan, nem is nagyon tudsz mutatni Spring alapú stateful skálázható rendszert... csak olyat, amit körbeszögeltek minden egyéb technológiával, középen ott marad egy kevéske Spring... de akkor miért Spring? Mert csak ahhoz van kompetencia?

"Szóval, rossz rendszer tervezésből adódó gondokat a Spring nyakába varrni... hát... :D"

Ez akkor egy rossz rendszer tervezéséből adódó gond, ha Spring alapokon futsz neki egy projektnek, amiben benne van az, hogy stateful skálázni kell majd.

Ha nem kell stateful skálázni, akkor meg miért a Spring? Csak? Mert van sok-sok egyéb megoldás, amelyik mindegyike kényelmesebb egy adott feladatra, mint a Spring és ugyanúgy nem skálázható stateful.

Évről évre erősödik bennem, hogy csak azok használnak Spring keretrendszert, akik semmi mást nem ismernek, csak ehhez értenek, illetve sokszor ehhez sem, csak felületesen. Remek megerősítés volt ez a szál ebben... :/

Én értem és igazat is adok neked abban, hogy tök jó, hogy a modern JEE sok mindent ad oob, amit más megoldásokkal a te szavaiddal élve "gányolni" kell. Azt is elhiszem és megértem, hogy nagyon szomorú vagy, hogy sok Spring alapú rendszerrel találkoztál, ahol rosszul tervezték vagy kinőtték a rendszer teljesítményét.

Én eddigi fejlesztői pályafutásom (16 év) során csak olyan rendszerekkel találkoztam, ahol annyira heterogén volt a technológiai, kompetencia, budget és "politikai" környezet, hogy soha nem lehetett volna bevezetni valamilyen megoldást elosztott tranzakcióra például. Egy esetben volt komoly alternatívája egy másik megoldásnak.
Mi minden esetben JEE alapon működtünk, és biztos jó lett volna, ha ... de nem volt rá alkalom.

Jó lett volna olyan rendszereket is készíteni, ahol csak magunkkal kell törődnünk, megvetetjük a csillió dolláros megoldást, ami szépen skálázódik maga, és mi csak a babokat faragjuk, meg konfigoljuk az adatforrást! :)
A mi melóink és megrendelőink nem ilyenek. Elfelejtetted mondani, hogy ezek az általad emlegetett dolgok komoly pénzbe kerülnek. Mifelénk az soha nem volt elfogadható, hogy a költségek jelentős részét viszi egy dobozos cucc.

Próbáltam arra is utalni, hogy a világ se arra ment/megy, amerre te szeretnéd illetve vicces, hogy nem vagy hajlandó elfogadni, hogy problémákra több megoldás is létezhet - amelyeknek van előnye-hátránya. :)

"Elfelejtetted mondani, hogy ezek az általad emlegetett dolgok komoly pénzbe kerülnek. Mifelénk az soha nem volt elfogadható, hogy a költségek jelentős részét viszi egy dobozos cucc."

Komoly pénzekbe? Most erősen körülnéztem, hogy az a sok Wildfly 10.0.0 mennyibe került, amit éppen használok, de valahogy nem találom a számlát, ja, jut eszembe: ingyen van.

Nehogy már egy szál Tomcat konténerben futó függőséghalmazt vagy Tomcat konténeren kívül futó Springboot függőséghalmazt vessünk össze egy WAS ND költségével, mert befonom a szakállamat... vagy dobjuk mellé a Spring esetén is (akár egy 3rd party) support költségét is, ami azért szintén öt számjegyű, dollárban és évente...

"Próbáltam arra is utalni, hogy a világ se arra ment/megy, amerre te szeretnéd illetve vicces, hogy nem vagy hajlandó elfogadni, hogy problémákra több megoldás is létezhet - amelyeknek van előnye-hátránya."

Ó, én elfogadom, hogy van a problémákra több megoldás, még azt is elfogadom, ha az a megoldás nem Java alapú, és mint mondottam volt már, éppen Spring projekttel (is) dolgozom... de van itt néhány Spring kiddie, akik úgy köpködnek minden más megoldásra, hogy közben egyáltalán nem ismernek más megoldást vagy 10-15 éves emlékekből irtóznak minden mástól.

Tevednek, ha azt mondom, hogy state szigoruan adatbazisba valo?
(Amit aztan a kliensek (UI, vagy mas service) cache-elessel, vagy anelkul ernek el)

Mondom ezt, mert ha: 10m user folyon valtoztatja a maga state-jet (pl. facebook, kep feltoltes, commenteles). Ha ezt mind replikalni kell az osszes kliensre/UI-serverre +a backendre, az nem fog skalazodni.

Ha a replikalas viszont csak a backendre korlatozodik (vagy annak is csak egy reszere, ha megfelelo kulcs alapjan van szetdobalva az adat db slave-ek kozott), akkor joval kisebb adatmennyiseget kell atmasolni backend node-ok kozott, az UI node-ok pedig csak azt kerdezik le, amire a felhasznalo kivancsi, ergo a szumma adatforgalom a clusteren belul kevesebb -> konnyebb skalazodas.

"Tevednek, ha azt mondom, hogy state szigoruan adatbazisba valo?"

Igen, tévednél.

"Mondom ezt, mert ha: 10m user folyon valtoztatja a maga state-jet (pl. facebook, kep feltoltes, commenteles). Ha ezt mind replikalni kell az osszes kliensre/UI-serverre +a backendre, az nem fog skalazodni."

Ööö... izé... nem kell minden state-et replikálni, nem kell minden state-et perzisztálni és nem kell minden state-et tranzaktáltan kezelni. De ezeknek a különböző kombinációit tudni kell kezelni, ebből a Spring egyet se tud elosztottan, ezért mindenféle workaround kell, ezért aztán különféle eszközök léteznek arra, hogy valamennyire működjön, viszont minél több eszközt hozol be, annál inkább illúzió lesz a lightweight konténer, annál lassabb és problémásabb a működés és annál több üzemeltetési kockázatot görgetsz magad előtt, amikor ezeket az összevadászott komponenseket frissíteni kell.

"Ha a replikalas viszont csak a backendre korlatozodik (vagy annak is csak egy reszere, ha megfelelo kulcs alapjan van szetdobalva az adat db slave-ek kozott), akkor joval kisebb adatmennyiseget kell atmasolni backend node-ok kozott, az UI node-ok pedig csak azt kerdezik le, amire a felhasznalo kivancsi, ergo a szumma adatforgalom a clusteren belul kevesebb -> konnyebb skalazodas."

Csináltál már ilyet? Több kontinens között is? :)

Csináltál már ilyet? Több kontinens között is? :)
Nem, nem csinaltam ilyet, es ez nem a springnek, mint keretrendszernek a feladata, viszont lehet, hogy a jovoben lesz ilyen project a spring cloud vagy a spring data-n belul, vagy maven dependency behuzassal integralhato lesz.

Azt hiszem abban a tevhitben elsz, hogy a spring onmagat mindenre megoldaskent hirdeti:
Az talan kozelebb all a valosaghoz, hogy sok mindenre ad out-of-the-box jol mukodo megoldast, es konnyuve teszi az integraciot barmihez.

Semmi sem zarja ki azt, hogy egy spring-app J2EE-kontenerben fusson, es kihasznalja az altala nyujtott szolgaltatasokat.

Viszont ha kijon egy uj technologia, ahhoz jo esellyel lesz spring-integracio, mig a J2EE-szabvanyt lassan fejlesztik, majd ha a szabvany vegleges, johetnek a szabvanyt implementalo webapp-kontenerek.

Kb. mintha scrum vs waterfall osszehasonlitas lenne...

"Nem, nem csinaltam ilyet, es ez nem a springnek, mint keretrendszernek a feladata."

Hát mégis minek a feladata, ha nem a keretrendszernek?! Baszki.

"vagy maven dependency behuzassal integralhato lesz"

Ó, persze. Simán. Aztán amikor jönnek a misztikus üzemeltetési problémák, akkor tárod szét a kezed... aztán amikor nekimentél a falnak, akkor majd az utódod megoldja...

"Kb. mintha scrum vs waterfall osszehasonlitas lenne..."

Úgy bizony... amúgy Te hány nagyobb Java EE 6 és 7 projektet láttál közelről? Mert én most is egy Spring alapú projekten dolgozom, nem a levegőbe beszélek, a Te részedről viszont azt látom, hogy még a Spring-et se ismered, nemhogy a Java EE 7 lehetőségeit... a hiányosságokat pedig azzal palástolod, hogy magabiztosan hülyeségeket írsz. :/

Ahogy mondtam, a springnek ez nem feladata, hiszen nem nem implementalja a java EE-t.

Java EE-vel szerencsere nem foglalkoztam.
Csak annyit mondhatok, hogy egy Seattle-i, travel industry-ban utazo ceg webalkalmazasat fejlesztettem, amivel lehet autot, hotelt, repjegyet, es egyeb dolgokat foglalni, mint pl. budapesti hop-on, hop-off...

Spring + freemarker volt az egesznek a lelke, microservice-nek nevezheto architekturaval. State nem volt a ui-ban, DB-bol jott, a cachelesre mar nem nagyon emlekszem...

A szemelyeskedesed pedig betudom annak, hogy veszelyben erzed a megelhetesed... :-P

"Ahogy mondtam, a springnek ez nem feladata, hiszen nem nem implementalja a java EE-t."

Nem kell implementálnia a Java EE-t, hanem tudnia kellene azokat, amiket nem tud.

"Java EE-vel szerencsere nem foglalkoztam."

Tehát nincs összehasonlítási alapod? Remek. Fogalmad nincs, hogy milyen a Java EE, de sommás véleményed azért van róla. Látom, hogy Ön szakember.

"Spring + freemarker volt az egesznek a lelke, microservice-nek nevezheto architekturaval. State nem volt a ui-ban, DB-bol jott, a cachelesre mar nem nagyon emlekszem..."

Összesen hány gépen futott Spring komponens? Hogy kezelted le az egyes microservice hibákat, ha külön gépen futott a két szolgáltatás?

"A szemelyeskedesed pedig betudom annak, hogy veszelyben erzed a megelhetesed... :-P"

Az én megélhetésem addig nincs veszélyben, amíg lesznek Spring-ben megírt szoftverek, amelyeket aztán át kell migrálni Java EE platformra, mert a sok Spring kiddie nem gondolt bele abba, hogy a későbbiekben túl nagy lesz a terhelés és a Spring skálázhatatlan horizontálisan, a hardverek pedig nem bővíthetőek korlátlanul, aztán csak állnak tanácstalanul, hogy a brossurában erről szó nem volt.

Mert mindent nem lehet stateless megoldani... és ha bejön egy probléma, amit stateful kényelmes lenne megoldani, akkor Spring esetén ott állsz letolt gatyával a futóversenyen vagy elkezdesz gányolni mindenféle elosztott cache bevezetésével, aztán külön tranzakció kezeléssel, aztán a kettő közötti szinkronizálással, aztán a szinkronizálás szinkronizálásával, aztán elkezdesz nézelődni más állás után, ahol kezdődik az egész elölről...

Na jo, de ahogy lentebb irtam, en meg csak most kezdem a kisujjam belemartani ebbe a temaba, es orultem is a hetekben, hogy "jajj de jo, eddig amiket best practiceket tanultam szoftverfejlesztes teren, azok a helyukre kattantak, mert mostmar latom es ertem, hogy miert is igy kell irni a szoftvert". Na ezt dontitek epp sarba :) Regeltem mar az AWS Free tier-be, hogy picit kiprobalgassak dolgokat, hogy kell konfigolni, milyen toolok leteznek, mit lehet automatizalni es hogy, stb, hogy ha oda kerulok, ez se legyen gond. Emiatt tenyleg erdekel, hogy milyen esetekre gondolod javallni a Java EE hasznalatat, es milyenekre a Springes rendszereket.

Tegnap mobilról írtam, ezért túl rövid és nem egyértelmű lett.

A kibővített válaszom:
Igen, mindenre van stateless, elosztott tranzakciómentes megoldás.
Ilyenkor horizontálisan nagyon skálázható lesz a rendszer, de sok időpillanatban nem lesz konzisztens.
Példát találhatsz a Tranzakció vs Saga blogomban.

Stateful, elosztott tranzakciós rendszer konzisztens lesz, viszont horizontálisan nem jól skálázható.

"Igen, mindenre van stateless, elosztott tranzakciómentes megoldás."

Nincs. Éppen azért nincs minden problémára stateless és elosztott tranzakció mentes megoldás, amit írtál: "Ilyenkor horizontálisan nagyon skálázható lesz a rendszer, de sok időpillanatban nem lesz konzisztens. Stateful, elosztott tranzakciós rendszer konzisztens lesz, viszont horizontálisan nem jól skálázható."

Az nem megoldás egy problémára, hogy nem oldjuk meg, mert a választott technológia képtelen rá.

"Tranzakció vs Saga blogomban"

Tök fasza a SAGA, csak sok esetben nem a bölcsek köve... sőt.

Lásd:
T1: A forrás számláról levonjuk az összeget, ha lehet. Ha nem, akkor probléma van, lezárjuk a Saga-t (nincs mit kompenzálni)
T2: A cél számlára ráírjuk az összeget. Ha probléma merül fel, akkor CT1-gyel kompenzálunk, majd lezárjuk a Saga-t.
CT1: A forrás számlára visszaírjuk a levont összeget.
T1 és T2-őt itt egymás után futtatjuk.

Például mi van akkor, ha a T2 elhasal és a CT1 sem futtatható valami hiba miatt?

"Az nem megoldás egy problémára, hogy nem oldjuk meg, mert a választott technológia képtelen rá."

Megoldjuk, csak másként. Van egy feladat arra keresünk megoldást. Van rá A, B és C megoldás. Mindegyiknek vannak előnyei és hátrányai a másikakkal szemben. Ha úgy fogalmazod meg a feladatot, hogy abba már belefoglalod az előnyöket/hátrányokat, akkor természetesen igazad van.
Eddig viszont úgy véltem a mondanivalód alapján, hogy a horizontális skálázhatóság a fő szempont, ott pedig az elosztott tranzakciós megoldások nem jók.

Scalability Best Practices: Lessons from eBay
"Most real-world use cases simply do not require immediate consistency. Just as availability is not all or nothing, and we regularly trade it off against cost and other forces, similarly our job becomes tailoring the appropriate level of consistency guarantees to the requirements of a particular operation."

"Például mi van akkor, ha a T2 elhasal és a CT1 sem futtatható valami hiba miatt?"

Pl.: a CT1-et ismételgetik, amíg le nem fut, vagy ha egy bizonyos ideig sem fut le, akkor értesítés, hogy kézi beavatkozás szükséges. Itt nem annyira érdekes az idő tényező, akár napokig is mehet a próbálkozás, ha nem sürgős a kompenzáció, mert nincs hatása a többi tevékenységre, azok futhatnak tovább.

Hasonló hiba felléphet az elosztott tranzakciónál, ahol viszont egyéb gondok is adódhatnak, mivel ott nagyon gyorsan kell valamit csinálni (beleértve a kézi helyreállítást is), mert amíg ez nincs megoldva, addig lockolva vannak ezen adatok.

"Megoldjuk, csak másként. Van egy feladat arra keresünk megoldást."

Ahja... megoldjuk okosba.

"Ha úgy fogalmazod meg a feladatot, hogy abba már belefoglalod az előnyöket/hátrányokat, akkor természetesen igazad van."

Úgy fogalmaztam, hogy nem létezik _minden_ _problémára_ stateless és elosztott tranzakció mentes megoldás. Te kivettél egy csomó problémát a halmazból, hogy azzal nem foglalkozunk, mert "csak" és arra a maradék problémára adsz stateless és elosztott tranzakció mentes megoldást, amelyekre lehet... a többit meg oldja meg más, ugye?

"a CT1-et ismételgetik, amíg le nem fut, vagy ha egy bizonyos ideig sem fut le, akkor értesítés, hogy kézi beavatkozás szükséges"

Ettől baromi boldog lesz mindenki... ja, nem, ez sok esetben használhatatlan. Szóval erről beszéltem, hogy a SAGA nem egy elixír az IT minden bajára, lefed egy csomó dolgot, de nem univerzális eszköz.

"Hasonló hiba felléphet az elosztott tranzakciónál, ahol viszont egyéb gondok is adódhatnak, mivel ott nagyon gyorsan kell valamit csinálni (beleértve a kézi helyreállítást is), mert amíg ez nincs megoldva, addig lockolva vannak ezen adatok."

Ennél azért szofisztikáltabb a dolog...

"Ennél azért szofisztikáltabb a dolog..."

Fogj két szervert, amik között megy az elosztott tranzakció, mind a kettőn indíts egy enyhe stressz tesztet, majd a két szerver között szakítsd meg a netet egy időre, majd nézd meg a teszt eredményeket, és a két szerveren a konzisztenciát.
Hasonló tesztet csinálhatsz 3+3-as felosztásban, ott is érdekes eredményeket kapsz.

(1. Leáll a feldolgozás, amíg a kapcsolat újra nem épül. 2. Megy tovább a feldolgozás és a két rész klaszteren inkonzisztensek lesznek az adatok.)

Vesd össze a Saga-val: továbbra is megy a feldolgozás, a net megszakadás idején nincs konzisztencia, ami nem nagy gond, lásd a korábbi két linkem és idézetem, majd ha visszajön a net, akkor konzisztens lesz minden.
Az elosztott tranzakciónál a két rész klaszteren az inkonzisztens adatok nagyon nagy probléma, mert azt még kézzel sem lesz egyszerű helyre rakni.

A többi kérdésre adott írásod nem igazán válaszok.
Azokhoz nem igazán van mit hozzátennem, amit korábban írtam.

SAGA esetén ugyanaz az eredmény van brain split során, mint elosztott tranzakciónál... ezen nem segít a SAGA vagy valami totálisan mást értünk elosztott tranzakción és a brain split fogalmán... vagy egyszerűen a leggyakoribb SAGA tévedésbe estél: a SAGA logot veszed úgy, hogy az mindig és minden körülmények között konzisztens, perzisztens és elérhető, pedig azt is érinti általában a brain split... átrugdostuk a problémát valahova máshova, oszt szopjanak ők vele, hm?

Adódhat azért, hogy a DB roundtripek lassúak, mert valami összetett lekérdezés, tárolt eljárások eredménye az állapot amit lekérdezel. Erőforrás pazarlás, szükségtelen késleltetés mindig a különböző feldolgozó instanceokról, ahová a stateless rendszerben a LB dobja épp a requestet, lekérdezni, és oda átvinni az adatot majd használat után eldobni. Ez még akkor is igaz, ha valami komolyabb infrastruktúra van adatforrás oldalon alatta (RAC + FC SAN). A DB infratruktúra vertikális skálázás önmagában nem megoldás, része persze a megoldásnak. A lényeg, hogy sticky session + valamiféle állapot cachelés általában elkerülhetetlen a middlewareben is. Sőt, az nagy jóság, ha nem kell minden service hívás végén komplex updatet végezni, és lehet cachelni. Hogy aztán http sessionben, sfsb-ben, vagy dedikált cacheben az lehet (hit)vita tárgya, de a lényeg hogy van állapot. Sőt, ha HA, akkor a cluster memberei közt replikálandó állapotod lesz, vagy nem lesz HA. Nagyon fontos feature-je a JEE konténereknek sok más mellett, hogy mindennek a kezelését szolgáltatja, és csak konfigolsz, és azt sem sokat. Nem pedig magadnak kell az üzleti logikák helyett bonyolult infrastruktúra megoldást barkácsolni. Lehet persze in-memory DB vagy IMDG gondolkozni, és stateless service API réteget futtatni, de tapasztalatom szerint ezt az architektúra váltást az üzemeltetők nem nagyon vállalják. Egy alkalmazásfejlesztési projekt apropóján pedig semmiképp. Meg egyébként is, az megint csak egy stateful rendszer, csak más architektúrával, nyilvánvaló előnyökkel de az egy másik történet.

En meg csak karcolgatom a temat, azert vagyok ennyire erdeklodo. Viszont mielott, en magara az alkalmazasra gondolok, mikor statelesst irok, termeszetesen maga a rendszer lehet stateful. Java EE-t nem ismerem en se, en is Spring oldalrol kozelitem meg a dolgot.

Igazabol azt nem ertem, hogy ha a fentiek nem oldhatok meg kenyelmesen infrastrukturabol, akkor hogy-hogy ennyire terjednek a Scalas, illetve FP szemleletu microservice architekturak? A masik topicban javasolt Web Scalability for Startup Engineers c. konyv is arrafele teszi le a voksat, hogy vertikalisan skalazni egy ideig jo, de utana draga lesz, mig horizontalisan forditva. Van egy pont ahol ez megint atfordul? Vagy igazabol csak azon megy a vita, hogy vajon magat az alkalmazas state-jet jo-e replikalni a tobbiek kozt (a'la van stateje az alkalmazasnak, Java EE), vagy pedig az alkalmazas aramvonalas es stateless legyen, viszont be kell hozni plusz infrastrukturalis elemeket? Legacy vagy green field project?

Mert ugye a tobbire biztos van megoldas, DB eseten cache, meg a tobbi ismeretlen roviditesre is :)

"Java EE-t nem ismerem en se, en is Spring oldalrol kozelitem meg a dolgot."

Nem nehéz: @Autowired helyett @EJB kell, illetve @Component helyett @Stateless, aztán ennyi. Na jó, kicsit több, se nem sokkal. :D

"Igazabol azt nem ertem, hogy ha a fentiek nem oldhatok meg kenyelmesen infrastrukturabol, akkor hogy-hogy ennyire terjednek a Scalas, illetve FP szemleletu microservice architekturak?"

Mert abban is addig gondolkodnak, hogy stateless minden és majd valaki valahol megoldja, ha stateful kell... tulajdonképpen áthajítják a problémát egy szinttel feljebb (load balancer, network, middleware) vagy egy szinttel lejjebb (adatbázis, queue, cache), aztán örömmel hátradőlnek, hogy mennyire cool dolgot csináltak, mennyire jó ez a [insert divatos framework here], bezzeg a többi terület állandóan szív mindenféle problémával.

"A masik topicban javasolt Web Scalability for Startup Engineers c. konyv is arrafele teszi le a voksat, hogy vertikalisan skalazni egy ideig jo, de utana draga lesz, mig horizontalisan forditva."

Ez továbbra is igaz... horizontálisan nagyon könnyű skálázni, ha csak azzal kell törődnöd, hogy stateless a szolgáltatásod. Aztán majd a DBA, a hálózatos vagy a Sysadmin vagy mind a három szopjon a skálázhatósággal, mert valahol mégiscsak ott a rendszer szintű state a stateless middleware esetén is.

Így megy ez, fogod a kis Spring, Scala vagy bármi egyéb kedvenc kis keretrendszert, mögé teszel egy MySQL-t, elé egy Nginx-et, aztán írod a kis microservice halmazodat, naponta kétszer leszopod magad, hogy milyen király csávó vagy... csak ugye ha jön a terhelés, akkor kiderül, hogy a ténylegesen állapotot tároló a MySQL és az Nginx bizony nem skálázható úgy, ahogy a stateless middleware... és akkor jön az, hogy redis, meg memcached, meg terracotta, meg szinkronizáció, meg cluster, meg éjszakázás, meg hétvégézés, aztán éjszakázás hétvégén, aztán végül új állás... vagy átmész röhögni a DBA-hoz, ha van, és nézed, ahogy szív a terheléssel, aminek a töredékét kapná az adatbázis, ha egy kicsit is stateful működne a szarod...

"DB eseten cache"

Ja, persze. Ennyi. Cache sor elé egy pipa, Apply, aztán minden rendben van. Ja. Így szokott lenni.

Muszaj szivnia a tobbi teruletnek? Komolyan kerdem. Tehat mar elviekben sem lehet egy jol skalazhato rendszert osszerakni Springgel, vagy csak az elore nem gondolkodas hianya a gond? Tehat nem mindent MySQL-be tenni, hanem rendesen microservice felfogassal a user adatbazist MySQL-el, a termek adatbazist az arra alkalmassal, az eventlogolast meg a harmadikba, ami arra van kihegyezve? Tehat rendesen, elore tervezve az infrastrukturaval is, nem megoldhato?

Vagy az uzemeltetes ennyire bonyolult? Tenyleg meg csak most akarok ismerkedni a terulettel, ezert kerdem. Teoretikusan, lehet olyan infrastruktura konyezetet megbizhatoan, keves szivassal uzemeltetni, amit az elejetol igy terveztek, nem pedig utolag toldozgattak? Vagy a kieso szerverek, replikacio hibak, egyebek tenyleg annyira sulyosak, tenyleg ennyire nehez managelni egy jol felepitett infrastrukturat? Nincsenek ezekre mar ootb megoldasok?

"Muszaj szivnia a tobbi teruletnek? Komolyan kerdem."

Valamelyik rétegnek szívnia kell a stateful működéssel, főleg, ha beüt a főnyeremény és túl nagy lesz a terhelés.

"Tehat mar elviekben sem lehet egy jol skalazhato rendszert osszerakni Springgel, vagy csak az elore nem gondolkodas hianya a gond?"

Lehet, csak stateless kell működjön és más rétegben kell megoldani a stateful viselkedést... ahol vagy megoldják vagy nem. Vagy szívnak vele, vagy nem. De verni a mellünket, hogy de fasza kis rendszer ez, holott csak más rétegbe toltuk a szopást, az nem túl elegáns. Ha pedig visszatolják a szart, hogy nem tudják megoldani, akkor lehet zsákban futni a maratont...

"Tehat nem mindent MySQL-be tenni, hanem rendesen microservice felfogassal a user adatbazist MySQL-el, a termek adatbazist az arra alkalmassal, az eventlogolast meg a harmadikba, ami arra van kihegyezve? Tehat rendesen, elore tervezve az infrastrukturaval is, nem megoldhato?"

Ez mind szépen működik, amíg nem lesz valahol egy hiba... és akkor bizony probléma van... amit vagy lekezelsz, vagy nem. Ha lekezeled a hibákat és visszavonogatod a tranzakciókat az összes érintett rendszerben, az már ismét stateful. Ha leszarod, az nem elegáns, de szokták csinálni. Vagy minden művelet idempotens, ami sok esetben ismét a szar szőnyeg alá söprése és jól megtaposása, mert máshol lesz belőle probléma...

"Nincsenek ezekre mar ootb megoldasok?"

Még nem találták meg a szent grált...

"a user adatbazist MySQL-el, a termek adatbazist az arra alkalmassal" jah csak eleg nehez ezzel a "felfogassal" tranzakcionalni a kereseket. Egy leegyszerusitett pelda (es lehet nem a legjobb de hatha igy erthetobb), A user megveszi B termeket, ez az uzleti logika:

- A usernek a kontojarol le kell vonni a penzt
- B usernek hozza kell adni
- a termeket archivalni kell
- B usernek kell kuldeni egy ertesitest
- Meg kell novelni az oldalon ossz eladasszamot

Itt kell eldonteni, hogy mekkora meretekben milyen hibaturessel akarsz dolgozni. Vannak hibara nem annyira erzekeny rendszerek, es hibara erzekenyebbek. Ha fontos a hibatures, akkor egy tranzakcionak kell lennie az osszes lepesnek. De ha kulon microserviceid vannak, akkor neked kell gondoskodni mindenrol, hogy ha hiba lep fel, akkor a modositast vissza kell vonni ott ahol sikerult, de ha a modositas visszavonasa nem sikerult, akkor vissza kell vonnod a modositas modositasat, es igy tovabb :D Es nem beszeltunk arrol, hogy mi van, ha a modositas sikerult, csak az ertesites veszett el a modositas sikeressegerol, stb. vegtelen a szopasok szama, Szoval microservicekkel a skalazhatosag jol megoldhato, de nehez a konzisztenciat biztositani.

Az erem masik oldalan (tudom ennek az eremnek ezer oldala van :D) ott van az, hogy nem darabolod szet a rendszert, hanem a keres elejen inditasz egy tranzakciot, megcsinalod, amit kell es ha sikeres, akkor ok, ha nem eldobsz mindent. Ez gyonyoruen fog mukodni jo lesz a konzisztencia, egy gepen, viszont ha skalazni kell, akkor jon a szivas.

Itt jon a kepbe, hogy kell-e allapotot tarolnod. Nyilvan uzleti logika kerdese a dolog. Ha nem kell allapotot tarolnod, akkor sokkal konnyebb a dolog, hiszen minden keres maganak eloallit minden adatot, lenyegeben teljesen mindegy, hogy a load balancer melyik kiszolgalohoz iranyitja a kerest, de ha kell allapotot tarolnod, akkor maris meg kell okositani a load balancert, hogy ugyanazon usert mindig ugyanarra a gepre iranyitsa, de mi tortenik, ha kiesik a gep, vagy az epp olyan terhelt, hogy mar nem tud kereseket kiszolgalni, stb. hogyan kerul at az allapot egy masik gepre, melyikre kerult at? ... Na itt az uzemeltetes fog szivni.

A lenyeg, hogy valaki szivni fog :D

A JavaEE platform nagy elonye, hogy oob tud allapot es allapot mentes, tranzakcionalis, es tranzakcio mentes mukodest elosztottan. Hatranya, hat nehez mondani hirtelen de ha majd eszembe jut updatelem a postot ;) De talan az, hogy lassabban reagal a divatra, sok korulotte a burokracia. Ettol fuggetlenul nem jo mindenre, pl shell-t nem lehet benne irni.
A Spring elonye, hogy tobb mindenre lehet hasznalni, pl lehet vele shell-t irni, dinamikusan fejlodik, gyorsabban reagal bizonyos kihivasokra. Hatranya, hogy nem tud oob tranzakcionalis allapottarto mukodest tobb gepen. Ha ilyenre van szikseg, akkor jon a barkacs. Tehat ez sem jo mindenre.

Monolitikus rendszer elonye, hogy konnyu allapotot tarolni es tranzakcionalni, de nehez horizontalisan skalazni. Ez se jo mindenre.
A microservice architekturaval konnyu skalazni, de nehez hibat kezelni, allapotot tarolni, es tranzakcionalni. Es ez sem.

Bocsi ha szajbaragosra sikeredett, csak annyi topicot dobtal itt fel, hogy gondoltam kicsit osszefoglalom mirol is megy a vita :)

Big Data trendek 2016

"Szoval microservicekkel a skalazhatosag jol megoldhato, de nehez a konzisztenciat biztositani."

Cserebe a rendszer minden egyes apro elemet az utolso csavarig ismered (hiszen te tervezted), ha valami nem mukodik, bugos stb, sokkal konnyebb megtalalni es kijavitani a hibat, vagy adott esetben modositani a rendszertervet, mintha egy kesz frameworkot hasznalnal (sok sikert peldaul, ha veletlenul belefutsz egy Java EE bugba, ami a remote tranzakciokat erinti - szerinted mikorra fogja az Oracle azt kijavitani?).

"A microservice architekturaval konnyu skalazni, de nehez hibat kezelni, allapotot tarolni, es tranzakcionalni."

Ez igaz, de eleve maskent tervezel microservice kornyezetben, nehany buzzword a kozelmultbol: event sourcing, cqrs. Ha valaki a frameworkos rendszert akarna egy-az-egyben atultetni microservice-re a tranzakcioival, akkor persze, hogy nagyot koppanna. Ha azt eroltetned, hogy ugy nezzen ki a rendszered, mintha egy atombol allna (mindig minden mindennel konzisztens), akkor szopni fogsz. Ha ertelmesen vegiggondolod, hogy valojaban mik a business kovetelmenyek (lehet, hogy a felhasznalot nem zavarja, ha nem mindig a legfrissebb allapotot latja, amennyiben van egy timestamp is a summaryn?), akkor felfedezheted, hogy eleg nagy mozgastered van ahhoz, hogy a fentiek ne jelentsenek problemat.

En ugy latom, hogy ketfele ember van: a rendszergazda/uzemelteto beallitottsagu (eljen a framework, akkor csak konfiguralgatni kell meg finomhangolni, kodolni szinte nem is), meg a fejleszto beallitottsagu (eljen a no-framework, majd en megcsinalom, es akkor pont olyan lesz, amire szukseg van). En az utobbi taborba tartozom, aki a Java EE-t szereti, az valoszinuleg az elobbi taborba. Mindkettonek meg van a helye az univerzumban, ugyhogy peace! ;)))

"Cserebe a rendszer minden egyes apro elemet az utolso csavarig ismered (hiszen te tervezted)" ez neha elony neha hatrany. Hatrany pl mert az uj munkaero betanulasi gorbeje tul meredek, ha mindent ertenie kell, vagy nem ismeri csak a sajat servicet, de arra meg nem all, amit irsz. A vegen ugyse te irsz mindent nullarol, mert az annyi mernokorat igenyel, es meg csak az sem biztos, hogy jo lesz.

"En ugy latom, hogy ketfele ember van" akkor van harmadik is, aki mar latott akkora rendszert, aminek minden alkotoelemet keptelensegnek tartja lefejleszteni, ezert minden reszegyseghez kivalasztja a emgfelelo megoldast, ami neha sajat tool irasa, neha mar meglevok felhasznalasa. En azert szeretek inkabb az uzleti logikara koncentralni pl saja leader election framework fejlesztese helyett. De distributed resource schedulert sem szivesen irnek amig nem az a feladat, mert tudom mennyi mernokora van egy ilyen fejleszteseben, teszteleseben.

Azert preferalom az opensource megoldasokat, mert felhasznalom a libet/frameworkot/algoritmust, ahelyett, hogy sajatot irnek, es ha valami nem tetszik, vagy bugzik kijavitom, vagy sajat igenyre szabom.

-
Big Data trendek 2016

Hol irtam olyat, hogy mindent ujrairok a nullarol? Szo sem volt ilyesmirol, csak arrol, hogy mekkorak a legok, amivel jatszunk. Ha frameworkod van, akkor le van gyartva elore az urhajos legoemberke, es az urhajo is egy-ket darabbol van, ha nem tetszik, vagy te inkabb kiralylanyosat szeretnel jatszani, akkor jonapot. De van olyan lehetoseg is, hogy az urhajot te rakod ossze, de az nem arrol szol, hogy te ontod a legodarabokat a gyar helyett, remelem igy tiszta, mire gondolok.

"Hol irtam olyat, hogy mindent ujrairok a nullarol?"
"eljen a no-framework, majd en megcsinalom" "En az utobbi taborba tartozom"

bocs ha nem tudok a sorok kozott olvasni ;)

Nem minden framework heavyweight, olyat olyankor valasztunk ha sok szolgaltatasra van szuksegunk. De ha nincs, akkor nem azt valasztjuk, legalabbis felenk. De minek legozzak valamit ossze, amikor az igenyeknek megfelelo is letezik, ha a Spring akkor az, ha EE akkor az (foleg ha elosztott allapottarto tranzakciokat szeretnenk). Igy legalabb 5nel tobb fejleszto sziv hasonlo problemakkal, 5nel tobb szakertot lehet talalni a projektre, stb. Minel szelesebb koru technologiat vetsz be, vagy a csapatot kell tudnod skalazni horizontalisan, hogy egyes teruleteken ne legyen szukseg olyan sok mindenre, vagy vertikalisan kell tudod skalazni a mernokoket, magyarul egyre okosabbakat kell felvenned, hogy ertsek mi a fene tortenik a hatterben es esetleg tudjak javitani (azt meg nem talaltam ki, hogy ez a vegtelenbe tart-e?? :))

-
Big Data trendek 2016

no framework != no 3rd party

"egyre okosabbakat kell felvenned" - ez egy erv, komolyan? Ki akar felvenni hujeket, mar bocsanat? De irtam mar lejjebb, hogy szerintem ez egy FUD, hogy ha nincs a framework eledrakva keszen, akkor csak atomfizikusokkent phd-zett raketamernokok fognak tudni dolgozni a projekteden.

Egy ember nem csak egy babu, akit ide-oda rakosgathatsz, lenyeg, hogy a letszam meglegyen! Foleg nem a mi szakmankban. De a szakmai tudas csak egy resze a szukseges skilleknek. Lehet valaki Nobel dijas tudos, de az adott csoportba vagy a konkret feladatra teljesen alkalmatlan.

"raketamernokok fognak tudni dolgozni a projekteden" nyilvan nem (irtam is, hogy nem tart a vegtelenbe a dolog), de azt azert be kell/lehet latnod, hogy minel tobb a custom fejlesztes, mikozben te azt akarod, hogy "minden egyes apro elemet az utolso csavarig ismered", akkor bizony szembesulni fogsz a problemaval, hogy a budos eletbe nem fogsz olyan embert talani, aki kepzett a rendszeredben, es akkor jonnek a jo hosszu betanulasi idok. Persze ha jo dokumentacio van a cucchoz, meg vannak ilyen "mysystem in action" konyvek, akkor konnyebb a dolog (igen minden custom cucc jol dokumentlt ezt mindd tudjuk), de jo doksi hijjan marad a felfedezes, ami roppant idoigenyes, es a reverse engineering pedig komolyabb szakertelmet kivan. Van az az elmelet, hogy debugolni nehezebb mint kodot irni, tehat ha legjobb tudasod szerint irod a kodot, nem fogod tudni debugolni. Sajnos a szerzore nem emlekszem, de van benne valami. Tehat ha van egy sajat fejlesztesu komplex rendszered, es azt szeretned, hogy az uj ember belathato idon belul magabiztosan mozogjon benne, akkor benne vagy a slamasztikaban. Ezzel szemben, ha a feladatra megfelelo es jo esetben elterjedt sokak altal ismert rendszert valasztasz, akkor sokkal jobbak az eselyeid, hogy talasz olyan embert, akinek mar a 0dik napon van valamilyen tapasztalata, mert (jol) dokumentalt, legalabb meg 1000 ember sziv ugyanazokkal a problemakkal a vilagon. Egyszeruen tapasztalatom szerint letezik a problema, es szamolnod kell vele mikor belevagsz egy ilyen jellegu sajat fejlesztesbe. A projekteken amin dolgozok eppen eleg a szukseges custom fejleszteseket eszben tartani, meg a kapcsolodasi pontokat mas rendszerekhez, nem kell meg szivatnunk magunkat azzal, hogy feltalaljuk a kereket.

a framework temaval meg egyre kevesbe ertelek ;), most akkor "no-framework, majd en megcsinalom", de a "no framework != no 3rd party" szoval eljen a 3rd party, akkor csak konfiguralgatni kell meg finomhangolni? Tehat akkor te is a "rendszergazda/uzemelteto beallitottsagu" vagy csak kifejezetten a frameworkoket utalod valami okbol?

-
Big Data trendek 2016

Mi nem építünk ilyen nagy rendszereket, de egyébként érdekelne, hogy egy ilyen hogy épül fel.

Ha jól értem, ha mondjuk van egy rakás felhasználó, akiknek az online jelenlétét tárolni kell (pl. a bejelentkezett ismerősök listája) akkor ezt egyszerűbb és hasznosabb memóriába tárolni, mintsem az adatbázisban tárolni. Aztán ha történik egy comment, akkor azt nem kell az összes node-ra egyből replikálni, hanem majd valamikor előbb utóbb ráér. De ha mondjuk megváltoztatja a jelszavát, vagy ilyesmi, annak azonnal kell megtörténnie.

És akkor egy átlagos rendszerben (ami nem J2EE, hanem egyszerű python vagy php, vagy akármi) ezt úgy oldják meg, hogy vannak az adatbázisaik, illetve van külön redis/memcached/etc. rendszerük, és a szükséges adatokat a megfelelő rendszerből vadásszák kifelé, és tolják le a kliensnek?

Egy ilyen rendszer architekturája hogy nézne ki "normálisan"?

"És akkor egy átlagos rendszerben ..."

Az a helyzet, hogy az itt megszólalók átlagos rendszere olyan, hogy elfut egymagában egy darab havonta öt dolláros virtuális hardveren és azt se terheli ki különösebben. Aztán ezen felbátorodva elkezdenek nagyobb forgalmú rendszereket fejleszteni, de azok is olyanok, hogy az adatintegritás vagy a rendelkezésre állás nem igazán lényeges tervezési szempont, különben más eszközt használnának. Közülük szinte senki nem jut el olyan szintre, ahol már kihasználták volna a vertikális skálázás minden lehetőségét és horizontálisan kell stateful skálázni, többségüknek egy percnyi tapasztalatuk nincs abban, hogy kell ilyen rendszert felépíteni, fejleszteni és üzemeltetni. Aztán ezek az emberek jönnek ide és osztják az észt, hogy a Spring mennyire jó...

"Érdekelne, hogy mi a gond a Spring-gel, ami miatt nem tud horizontálisan skálázódni... (nem használunk spring-et, volt időben tervezve)."

Egyszerűen nem tud... nincs semmilyen replikációs réteg, amivel különféle szinteken állapotot lehet replikálni, perzisztálni és/vagy tranzakcióban kezelni, a maximum, amit ki tudsz hozni a dologból, az egy sticky session, amitől a legtöbb Spring fejlesztő a seggét a földhöz veri, hogy milyen kurvajó dolgot csinált, de az csak egy apróság a replikálandó dolgok között. Minden más esetben vért kell izzadni és 3rd party cuccokat kell integrálni, amivel mindenféle egyéb problémát magadra húzol...

"Illetve erről mi a véleményed?"

Ez nem Spring, ahogy látom, mi legyen a véleményem? :)

Erről a részről tudnál egy kicsit írni, mert nekem valahogy ez a rész nem teljesen tiszta. Úgy látom, hogy amikor valamit ki akarunk
perzisztálni, azt mindkét rendszerben JPA-val tesszük, és tranzakciós manageren keresztül (amivel mondjuk lehet 2phase commit protocol-t
csinálni, vagy bármi hasonlót). Biztos, hogy van valami plusz trükk, amit a J2EE tud, de nem látom, hogy hol.. ezt esetleg össze tudnád
foglalni?

Plusz még egy kérdés, JPA-hoz kapcsolódóan: mi elég komolyan kihasználjuk az adatbáziskezelőnk összes feature-jét, viszont sokan a JPA
miatt az adatbáziskezelőt egyszerű store-nak használják. Ez nem okozott nálatok még teljesítménygondot? (plusz olyan feature-ök nem
hiányoztak, mint gis támogatás adatbázis szinten, json, különböző indexek, tárolt eljárások, esetleg módosítható view-k, materializált
view-k, stb. )

"Biztos, hogy van valami plusz trükk, amit a J2EE tud, de nem látom, hogy hol.. ezt esetleg össze tudnád
foglalni?"

Röviden azt, hogy két JVM között is tudja hatékonyan az elosztott tranzakciót, nem kell egy JVM-ben lennie az teljes hívási láncnak, könnyebb horizontálisan skálázni szolgáltatás szinten.

"Plusz még egy kérdés, JPA-hoz kapcsolódóan: mi elég komolyan kihasználjuk az adatbáziskezelőnk összes feature-jét, viszont sokan a JPA
miatt az adatbáziskezelőt egyszerű store-nak használják."

Ez alapvetően vagy-vagy eset. Vagy full feature JPA és csak object store az adatbázis VAGY simple ORM a JPA és full feature az adatbázis. A vegyes használat csupa szopás, főleg, ha bejön az, hogy több gépen is van több szintű cache, aztán az adatbázis az alkalmazás háta mögött is ír meg olvas, amiről a JPA nem tud... remek inkonzisztens állapotok szoktak lenni ilyenkor mindenféle misztikus hibákkal tarkítva.

Mondtam párat ilyen hátrányt, ezekre az jött vissza, hogy "nem vagyok szakerto a temaban", "másodikat manapság nem valamiféle memcached jellegű dologgal szokták megoldani?", "kimentek ezek már a divatból" és a többi; vagyis a projekt elején: gány, workaround, kompetencia teljes hiánya; projekt vége felé: leszarom, majd az utódom megoldja.

Amíg a közelében nem vagy egy olyan rendszernek, amelyre totálisan alkalmatlan a Spring, addig könnyű osztani az észt, hogy bezzeg a Spring milyen jó... :/

> Amíg a közelében nem vagy egy olyan rendszernek, amelyre totálisan alkalmatlan a Spring

Ha olyan rendszert fejlesztek amire alkalmas akkor a Spring bizony nagyon jó. A jelek szerint a legtöbb alkalmazás ilyen. Azon kívül hogy minden kommentbe megy a "stateful horizontális cluster" copy-paste nem mondtál semmit, csak fröcsögsz a kollégákra. Mondjuk írhatnál róla egy posztot, mert ez egy szar ELTE előadás színvonal, amiből megtudjuk hogy a Java szar. Bemutathatnád miért jobb üzleti döntés Spring helyett mást használni egy projektben amire az előbbi teljesen alkalmas.

Az nem példa hogy egy problémára nem nyújt megoldást egy keretrendszer.

stateful horizontális cluster még mielőtt lemaradna.

"Mondjuk írhatnál róla egy posztot, mert ez egy szar ELTE előadás színvonal, amiből megtudjuk hogy a Java szar."

Menjünk csak vissza a szál elejére: "Az az igazság hogy a Java EE elvesztette a versenyt az üzleti alkalmazások piacán, elsősorban a Spring kárára. Nem kár érte."

Na, ebből megtudtuk, hogy a Java EE szar, mindenféle indok nélkül... azóta azon rágódunk, hogy talán még se szar, ha többet tud, mint a Spring, mert
- "ha olyan rendszert fejlesztek amire alkalmas akkor a Spring bizony nagyon jó"
- "a másodikat manapság nem valamiféle memcached jellegű dologgal szokták megoldani?"
- "ez nem a springnek, mint keretrendszernek a feladata"
- "kimentek ezek már a divatból... ha voltak egyáltalán..."
- "nem tudok, de nem vagyok szakerto a temaban"

És csak ebből a témából szemezgettem, mert mindig arra sikerül kilyukadni, hogy mennyi mindenre alkalmatlan a Spring, de amire használjátok, arra pont jó. Paradox módon ezzel alátámasztottnak veszitek, hogy a Spring azért jobb, mint a Java EE 7, mert nem tud annyit; a fejlesztés kényelmességéről pedig a 15 éves J2EE 1.3 az utolsó homályos (többnyire kollektív) emléketek.

Ha meg mégis kellene az a néhány plusz dolog, amit a Java EE 7 alapból stabilan ad, akkor az egyszeri Spring kiddie úgy tesz, mint Nigel Farage a sikeres Brexit kampány után: felmond és megy másik céghez, mert csak a pofája nagy, tervei nincsenek arra, hogy oldja meg a hiányosságokat...

Olvasd végig a hozzászólásokat... ha azokból nem érted meg, hogy mi a Spring alapvető problémája, akkor Neked tényleg csak a Spring való... bár én a helyedben elgondolkodnék egy Node.js irányon is, amire a Spring jó, arra a Node.js sokkal alkalmasabb és már jobb teljesítményt is nyújt.

Irhatnal mar tenyleg valami erdemit, mert itt elfogyott a popcorn! :)
"Remote call with distributed transaction? Stateful cluster?"

Nagyon szeretnek egy pelda rendszert, amire szerinted a Java EE a legalkalmasabb eszkoz ma a piacon. Nem kotekszem, komolyan kerdezem.

/ egy erlang fejleszto, akinek hamarosan legacy java szervleteket kell feltamasztania a sirbol... ;(((

ui. szivesen irok en is olyan peldat, amire azt gondolom, korrekt megoldast adtunk Erlang / RabbitMQ alapon microservicek formajaban. Lehet nyugodtan kopkodni, sot, nagyon is szivesen olvasnek erdemi kritikat, amibol tanulni tudok.

Most rákerestem a nickemre és kerestem a lendületet, de nem találtam. :)

szerk.:
"Az az igazság hogy a Java EE elvesztette a versenyt az üzleti alkalmazások piacán, elsősorban a Spring kárára. Nem kár érte."
^ha erre gondolsz akkor beláthatjuk hogy ha a piacot nézzük akkor így van (+ a tényt hogy minden bizonnyal kihúzták a java ee 8 fejlesztésből a pénzt)

--
arch,debian,osmc,android,windows

Ha piacot azzal ítéled meg, amilyen munkákkal találkozol, akkor eléggé félre tud vinni, mert ha csak Spring alapokon dolgozol, akkor más technológiával nem találnak meg... :)

"a tényt hogy minden bizonnyal kihúzták a java ee 8 fejlesztésből a pénzt"

Ehhez azért lesz valamennyi szava az IBM-nek és a Red Hat-nek is, amelyek az utóbbi pár évben tolták a dolgot, mert az Oracle évek óta nem csinál szinte semmit... az összes húzóember elment már, a sok Oracle fejlesztő meg szinte csak azzal foglalkozik, hogy a com.sun. csomagneveket javítja com.oracle. csomagnevekre a JDK-ban. Az innovációkra képes emberek évek óta függetlenek.

Ha minden igaz, egy honap mulva lesz egy kis idom, szeretnek egy rovid erlangos gyorstalpalot osszeutni githubon, abbol kiindulva, hogy en mivel szivtam az elejen (tudom, ott van a LYSE, es tarsai, de en picit masrol/mashogy szeretnek irni), illetve milyen architekura az, amire az erlangos rendszerek kulonosen alkalmasak - szerintem. Amint lesz valami ertekelheto produktum, megadom a linket.

"Nagyon szeretnek egy pelda rendszert, amire szerinted a Java EE a legalkalmasabb eszkoz ma a piacon. Nem kotekszem, komolyan kerdezem."

Ha Java backend kell, amelyiknek kommunikálnia kell mindenféle legacy rendszerekkel, adatbázisokkal mindenféle protokollon, akkor friss Spring vs Java EE platform közül Java EE a kézenfekvő, feltéve, hogy nincs raktáron egy csomó unatkozó fejlesztő, akik csak a Spring keretrendszert ismerik és semmi mással nem hajlandóak dolgozni. Ha csak úgy backend kell és stateless működés, akkor a Java se feltétlen szükséges.

A Spring működésmódja teljesen más, mint a Java EE működésmódja, ez egy külön hosszú előadás témája lenne, hogy milyen alapvető filozófiai különbségek vannak közöttük.

Például Spring esetén szálbiztosan kell megírni a metódusokat, mert általában egy classloader esetén egy példányban jönnek létre a Spring kontrollerek, ennek a referenciája kerül át a hívó oldalra az @Autowired esetén (ezért külön szívás egy két JVM közötti klasszikus RMI és ezért kell minden függőséget belepakolni a Spring csomagokba), Java EE esetén biztos lehetsz benne, hogy egy szál - egy EJB a működésmód, nem kell törődni a szálbiztossággal (sokkal kevesebb a tévedési lehetőség), csak azzal, hogy a @Stateless esetén tényleg stateless legyen a működésmód, és azzal, hogy legyen egy interfészed a meghívandó szolgáltatáshoz, nem kell törődnöd azzal, hogy az éppen hol van és milyen implementáció van mögötte, nem függsz a meghívott szolgáltatásoktól és kevesebb a memory leak esélye, mert minden EJB egyben eldobható és szükség esetén újra létrehozható, ellentétben a singleton-tól.

Innen jön az a fajta mondás, hogy Spring programozó bármilyen platformon képes Spring programot írni, ezért forgatják az EJB-t, mint medve a sünt, de nem értik, hogy miért működik úgy, ahogy. Aztán persze könnyű azt mondani, hogy szar az egész, mert nem jól használják... :)

Nem, nem session jellegű adatokra. Mindenféle adatokra, amely állapotot hordoznak...

Mondok egy példát: fogod a kis alkalmazásodat, megírod stateless és microservice, a kliens küldi mindig a tokent, hogy ő kicsoda, az adatbázis pedig tárol mindent, a kulcs ez a token. A rendszered egésze stateful lesz, a kliensnek tudnia kell, hogy melyik szolgáltatást hol éri el, az adatbázis pedig vállalja a teljes stateful működést.

Ha jön a terhelés és skálázni kell, akkor hiába tudod jól skálázni a middleware rétegedet horizontálisan, ha a kliens nem fogja tudni, hogy melyik az éppen élő és terhelhető node a sok közül ("lécci tegyetek elé egy load balancer-t!"), illetve az adatbázis skálázhatatlan mennyiségű terhelést kap ("miért baj az, hogy mindent mindig lekérdezek?"), mert nem tudod tovább vertikálisan növelni a hardvert, horizontálisan meg a választott technológia nem skálázódik...

...ilyenkor tök jó, amikor a fejlesztő a képedbe röhög, hogy az ő cucca s-t-a-t-e-l-e-s-s, oldja meg a middleware körüli rétegben valaki a problémákat és lemegy kávézni a büfébe, ahol elmeséli, hogy mennyire hülyék az üzemeltetésen, hogy nem tudják kiszolgálni a terhelést.

Oké, próbálok értelmes kérdéseket feltenni :)

Tehát, az első kérdésem a load balancer. A mai modern webes rendszereknél ahol kb. egy REST interface van, ott a kliens mindig egy adott címre küld kérést (myapp.example.com/rest/persons) és valami rendszer ezt továbbdobja a megfelelő szerverhez. Gondolom itt lenne a load balancing. Ez hogy alakul J2EE környezetben?

A másik, amit nem értek, hogy mondjuk egy egységsugarú rendszernél ez úgy néz ki, hogy jön a request, ebből kiszedjük a paramétereket, lekérdezzük az adatbázisból (select * from persons where id = 23) és ezt visszaadjuk mondjuk json formátumban. Ez egy skálázódó rendszerben hogy néz ki?

"Gondolom itt lenne a load balancing. Ez hogy alakul J2EE környezetben?"

Ha nincs lehetőség a REST kikerülésére, akkor általában ugyanúgy. De ez már egy stateful működés, ha van load balancer.

"A másik, amit nem értek, hogy mondjuk egy egységsugarú rendszernél ez úgy néz ki, hogy jön a request, ebből kiszedjük a paramétereket, lekérdezzük az adatbázisból (select * from persons where id = 23) és ezt visszaadjuk mondjuk json formátumban. Ez egy skálázódó rendszerben hogy néz ki?"

Mondjuk úgy, hogy a request egy EJB-be fut be, amiből van n darab inicializálva m darab gépen, ebből az EJB-ből hívsz egy másik EJB-t, ami végrehajtja az SQL hívást, abból is van n darab inicializálva m darab gépen, de ezekről nem kell tudnod, hogy hány gép szolgálja ki és azok közül éppen mennyi mennyire van terhelve és ha hiba van, akkor a teljes hívási láncon le tudod kezelni a hibát különösebb ráfordítás nélkül. De ez mind stateless, ebben semmi különbség nincs a Spring és a Java EE között, a tánc akkor kezdődik, amikor bejön egy stateful igény. :)

Oké, idáig ezt nagyjából értem. Most akkor az a kérdésem, hogy ha mondjuk az adatbázis
a szűk keresztmetszet a nagy terhelés esetén, akkor az ellen hogy véd a J2EE, illetve
tudnál-e példát mondani a stateful igényre, aminél előjönnek az általad említett problémák.

"Oké, idáig ezt nagyjából értem. Most akkor az a kérdésem, hogy ha mondjuk az adatbázis a szűk keresztmetszet a nagy terhelés esetén, akkor az ellen hogy véd a J2EE, illetve tudnál-e példát mondani a stateful igényre, aminél előjönnek az általad említett problémák."

Pölö úgy, hogy nem csak egy adatbázist használsz, hanem többet, az adott részfeladatnak megfelelő céllal, ezeket szét tudod tenni több gépre, közben él a tranzakciód, esetleg felhúzol feladatokat a middleware rétegbe és ott oldod meg a replikációt, ezzel terhet veszel le az adatbázisról... és így tovább... ha tudsz stateful részeket mozgatni a middleware rétegben, azzal mozgásteret nyersz, ha pedig van mozgástered, akkor azzal tudsz finomhangolni szükséges esetben. Feladatfüggő.

"Tehát mondjuk az egyik adatbázisba írom a felhasználó adatainak módosulását, egy másikba pedig loggolok, és mindezt meg tudom csinálni úgy, hogy ezek egy tranzakcióban történjenek."

Pölö igen. Mondjuk naplózni külön tranzakcióban szoktak, hogy hiba esetén megmaradjon a napló, de bármi mást odaértve igen, ilyesmi... :)

"A stateful részek middleware rétegben történő mozgatása mit jelent?"

- másképp finomhangolt JVM -- van pár száz JVM opció és van az a terhelés, amikor érdemes a különböző terhelési profilt okozó szolgáltatásokat másképp optimalizált JVM-re tenni
- más architektúrájú fizikai gép (x86, SPARC, Power, stb) -- van, amikor számít, hogy inkább kevés, de erős mag, vagy inkább sok, de gyengébb mag a hasznos
- másképp virtualizált gép, más storage, más operációs rendszer, satöbbi -- mert nem mindegy, hogy mit és hogyan használunk

Ha nem tudsz horizontálisan stateful szolgáltatást használni, akkor a fentiek nagy része kiesik, mint lehetőség... persze ez messze van a szimpla fejlesztőtől, mert elkészíti a csomagot, odafut az üzemeltetéshez, elejti, majd elfut két hét szabadságra, de ha teljesítményt kell hangolni, akkor ezek elő fognak kerülni és sokat segít, ha van lehetőség ezekre middleware rétegben is, nem csak alatta vagy felette.

"Mit jelent a stateful részek middleware rétegben történő mozgatása? Mi számítana state-nek?"

Pont azt, hogy képes vagy mondjuk egy memória intenzív szolgáltatást, egy hosszabb ideig futó CPU intenzív szolgáltatást és mondjuk egy több száz szálon futó szolgáltatást három különböző JVM-re és/vagy fizikai architektúrára tenni, mégis képesek ugyanazon állapotot látni, képesek egyazon tranzakcióban működni.

Ugye a middleware réteged nem feltétlen egy monolitikus dolog, ha van lehetőséged a szolgáltatást mozgatni tágabb határok között, azzal sokat lehet nyerni kritikus esetben. Ha minden egy gépen fut és nem tudod külön gépekre tenni, különben funkcionalitást vesztes, akkor kritikus esetben nem tudod megoldani a problémát.

Érdeklődéssel olvasom a topicot, mert se EE-t, se Springet nem használok, és nem teljesen értem, hogy az EE miért annyira király. Amennyire én látom, egy (opcionálisan stateful) load balancer elég fontos (és tervezett) eleme tud lenni a skálázódásnak, illetve egy (by definition stateful) adatbázist is lehet végtelenségig horizontálisan skálázni. A latency és eventual consistency oltárán szoktunk áldozni egy keveset, de mivel egy user nem ugrál hirtelen egyik földrészről a másikra, ez nem szokott gond lenni. Nem kételkedek benne, hogy sok a tapasztalatod, csak egy kicsit túlzásnak érzem, hogy az jön le, hogy EE==siker és Spring==fail. Egy tök kicsi rendszerre biztos jó a Spring, egy hatalmas rendszerre meg önmagában az EE (illetve bármi más polcról levehető megoldás) is kevés lesz. Van az a szint, ahol az általad eddig írt EE előnyök (pl. JVM-ek közötti átjárás) kb. lényegtelen mikrooptimalizációnak tűnik. Nem kötekedni akartam, csak árnyalni a képet :).

--

"Érdeklődéssel olvasom a topicot, mert se EE-t, se Springet nem használok"

Ejha, így az igazán könnyű szakértőnek lenni... én használom mind a kettőt (és még pár egyéb keretrendszert is, amikor hatékonyabb) és így van ez a kialakult véleményem, ami persze nem számít, mert azok szerint, akik egyiket se használják vagy világéletükben csak a Spring keretrendszert használtak, azok szerint a Java EE szar... ide kívánkozik egy nagy facepalm... és ezzel a lendülettel ki is szállok a vitából: igen, a fekete billentyűk hangosabbak.

Szerintem ezt kicsit túltoltad, mert egyáltalán nem mondtam, hogy szar, tényleg érdekelt, hogy mitől olyan jó :). Mi saját keretrendszerrel rakunk össze világméretű alkalmazásokat, és nekem tényleg kimaradt a Spring és EE is. És amennyire látom, nálunk máshol van a fókusz, mint amit te itt kiemeltél, de ez többnyire csak megérzés. Ha majd egyszer máshol dolgozok esetleg, ahol nincs meg ez a belső keretrendszer, egy kicsit biztos bajban leszek, mert a tapasztalat egy része nehezen átültethető :).

--

Amikor stateful és stateless szerverről beszélünk, akkor igen, session jellegű adatokról van szó.
Szerver szempontból a következő fajta adatok vannak:

  1. külső adat (adatbázis, service, fájl, ...),
  2. számolt adat,
  3. előző két fajta adat cache-elve,
  4. session adat (kliens program állapotát leíró adat).

Stateful szerver esetén a szerver tárolja a kliens program állapotait, pl. ki van bejelentkezve, melyik menüpont az aktív, ..., a kliens csak egy azonosítót ad át ezen adatok helyett.
Stateless szerver esetén a kliens tárolja az állapotait és a szerverhez forduláskor átadja a futáshoz szükségeseket.

Stateful előnyei:

  • a kliensnek nem kell tárolnia az állapotokat,
  • kevesebb adatmennyiség mozog a kliens felé való kéréskor.

Stateful hátrányai:

  • nagy adatmennyiséget kell tárolnia, ha sok kliens sok adatát kell tárolnia,
  • mivel a szerver példányok között szinkronban kell tartani az adatokat, ezért nem jól skálázódik,

Stateless előnyei és hátrányai pont az ellentéte a Stateful-énak.

Az egyik legegyszerűbb módja a teljesítmény növelésének a cache-elés. Ilyenkor viszont az inkonzisztencia területére tévedünk. Ha pl. egy felhasználó azonosító alapján betöltjük a felhasználó adatait (név, email, cím, jogosultságok, ...), majd cache-eljük 5 mp-re, akkor a felhasználó adatok változása után max. 5 mp-ig inkonzisztens állapotban lesz a rendszer. Ez, ha belegondolunk nem nagy áldozat. Rendszerektől függően 1mp-től akár percekig is elfogadható lehet az inkonzisztencia hossza.

Sokan stateful szerver esetén a cache jellegű adatokat is session adatként tárolják, ami nagy hiba, hiszen így növelik a szinkronban tartandó adatok mennyiségét, ami drasztikusan csökkenti a skálázhatóságot és így a teljesítményt is.

"Amikor stateful és stateless szerverről beszélünk, akkor igen, session jellegű adatokról van szó."

Te ez esetben csak _web_ és _middleware_ szerverről beszélsz, jelentősen egyszerűsítve a problémateret... és persze a middleware úgy stateless, hogy a state tárolását elegáns mozdulattal áttolod egy másik rétegbe, amelyiknek a skálázása nem a Te kompetenciád és felelősséged, mert minden rendszer stateful, csak esetleg vannak stateless rétegei is...

"a state tárolását elegáns mozdulattal áttolod egy másik rétegbe, amelyiknek a skálázása nem a Te kompetenciád és felelősséged"

Ezt már sokadjára mondod, de ez nem feltétlenül baj. Létezik nagyon jól, sőt világ szinten skálázódó adatbázis.

De már ott rossz a gondolat, hogy valaki áttol valamit. Én azt feltételezem, hogy egy nagy rendszert teljes egészében terveznek meg, IOPS-től a QPS-ig. De persze elhiszem, hogy ez sok helyen nem így van :\.

--

"Ezt már sokadjára mondod, de ez nem feltétlenül baj. Létezik nagyon jól, sőt világ szinten skálázódó adatbázis."

Nem feltétlenül baj. Akkor baj, ha megy a melldöngetés, hogy a middleware réteg stateless és korlátlan mértékben skálázható, a többi terület meg szopjon csak a kliens oldaltól egészen a hardveresekig.

"Én azt feltételezem, hogy egy nagy rendszert teljes egészében terveznek meg, IOPS-től a QPS-ig. De persze elhiszem, hogy ez sok helyen nem így van :\."

Ó. Persze. De kevés helyen van így... ahhoz gondolkodni kellene. Sokat.

"Létezik nagyon jól, sőt világ szinten skálázódó adatbázis" biztosan, bar multi datacenter master master relacios adatbazis viszonylag keves van :D, de nem az a problema, hogy nincs ilyen megoldas, hanem az, hogy ha szet szeretned az uzleti logikat tobb vegrehajto egysegre osztani, akkor ket lehetoseged van:
- minden vegrehajto egyseg eloallit maganak minden adatot
- megosztod az allapotot kozottuk

Az elobbi szepen mukodik by default kicsi adatszettek, es keves keres eseten. Ha a keresszam novekszik, elkezded skalazni, egy darabig vertikalisan, aztan horizontalisan. Ha mar az elejen valami skalazodo nosql megoldast valasztottal, akkor konnyebb a dolog, de azok sem jok mindenre, ha relaciokra van szukseged, maris egyre nehezebb a horizontalis skalazas, De mi tortenik, ha az adatszett merete novekszik? mondjuk 5 perc / keresre? Szepen elosztod a feladatokat 6 microservice kozott, es mind a 6 szepen eloallitja maganak ugyanazt az adatot 5 perc alatt. Na itt jon a kpebe, hogy egyszer eloallitod az adatot, es utanna a folyamatok mar az adattal dolgoznak.

-
Big Data trendek 2016

"jelentősen egyszerűsítve a problémateret"

Ez a lényege a jól átlátható, könnyen módosítható és karbantartható programoknak. A fenti esetben még a jól skálázhatóság is mellé jön.
Külön van az üzleti logika a perzisztenciától, ezért külön külön lehet ezeket skálázni.
Ha micro service-ket használsz, akkor ezek még funkciónként is szétválnak, funkciónként üzleti logika és perzisztencia.
Egy másik irányból is szétvághatod, ha CQRS-t használsz, ilyenkor szétválik az írás és olvasás, így ezeket is külön tudod skálázni.

"Ez a lényege a jól átlátható, könnyen módosítható és karbantartható programoknak."

Nem-nem-nem. Attól, hogy Te csak biciklivel vállalsz kis tételben futárszolgálatot egy településen belül, mert csak egy biciklid van, attól nem szűnik meg az üzleti igény se a települések közötti postára, se a légipostára, se a nagy tételes vízi konténeres szállításra. Te egyszerűen figyelmen kívül hagyod azokat az üzleti igényeket, amelyeket nem tudsz megoldani az eszközkészleteddel...

Minden példa rossz, de ez különösen.

Ha már szállításra akarod kihegyezni, akkor kb. így lehetne módosítani (ez a példa is rossz, de nem annyira). Mind a két esetben ugyanazok a szállítási járművek, de stateful esetben belerakják az üléseket, a kapaszkodókat, a kerékpárszállító elemeket, ... Stateless esetben pedig minden jármű egyforma és a kliensek viszik magukkal az üléseiket, kapaszkodókat, ... Így akármelyik jármű el tud szállítani bármit.

"Te egyszerűen figyelmen kívül hagyod azokat az üzleti igényeket, amelyeket nem tudsz megoldani az eszközkészleteddel..."

Mondj már egy olyan üzleti igényt, amit stateless szerverekkel nem lehet megoldani, de statefulakkal meg lehet.

"Stateless esetben pedig minden jármű egyforma és a kliensek viszik magukkal az üléseiket, kapaszkodókat" hogy ez mekkora baromsag, mar bocsi. Ha mar a te hasonlatodnal tartunk, akkor a stateless eseten akarhol leszallhatsz a buszrol, mindig lesz masik busz amivel folytathatod az utadat, de a csomagjaidat neked kell vinni. Statefulnal barmikor megallsz es amikor folytatod az utazast ugyanaz a busz visz tovabb,igy a csomagjaodat bennehagyhatod.

"nem lehet megoldani" olyan nincsen ;) csak kerdes mennyi ido hibaturore lefejleszteni meg tesztelni, es mennyire lesz terhelheto.

-
Big Data trendek 2016

Nem akkora baromság, mint a korábbi volt, itt legalább kísérlet volt a stateful és stateless lényegének megragadására, szemben azzal, hogy a stateless az bicikli, a stateful meg repülő.

Én a Te példádat sem tartom nagyon rossznak, de ez sem tökéletes. Ha két pont között négyszer annyi személyt akarunk szállítani, akkor négyszer annyi buszt állítunk be. Stateless esetben bárki bárhol felszállhat, nincs hatása a többi buszra. Stateful esetben minden egyes felszállásnál, leszállásnál, vagy ha módosul az utazó csomagja (pl. megeszik valamit belőle), akkor futárt kell indítani a többi buszhoz, hogy ott a klón személy csomagjait is annak megfelelően módosítsa, illetve kezdeni kell azzal is valamit, ha egyszerre módosulna két buszon ugyanazon személy csomagja. Szóval, minden példa rossz.

"akkor futárt kell indítani a többi buszhoz" ugyerted ha elosztott a bean.

"annak megfelelően módosítsa, illetve kezdeni kell azzal is valamit, ha egyszerre módosulna két buszon ugyanazon személy csomagja" Figyi, valahol ezeket mindd kezelni kell, ha hidd, hogy stateless eseten ezeket meguszod. A kerdes az, hogy eloallitani az adatot, es szinkronban tartani a stateless muveletek kozott, es hibat kezelni hogyan egyszerubb. Nem vagyunk satefull hivok, ha erted, ahol lehet a stateless megoldast erdemes preferalni, de ahol nem, ott meg nem. Es kellemetlen ha arra lenne szukseg, de a framework nem tamogatja.

-
Big Data trendek 2016

"Minden példa rossz, de ez különösen."

A hozott példád különösen rossz... :)

"Mondj már egy olyan üzleti igényt, amit stateless szerverekkel nem lehet megoldani, de statefulakkal meg lehet."

Például a stateless load balancer és a stateless adatbázis az konkrétan hogy működik az esetedben?

"Nem igazán értem ezek alatt mit értesz."

Másról beszélünk. Te a 3-10 réteg közül egyetlen egy rétegről beszélsz: a middleware réteg egy szeletéről, mint stateless rendszerről. Én meg a teljes vertikumról beszélek. Nem nagy dicsőség egy több rétegű rendszer egy rétegét stateless tartani, de mindegyik réteg nem lehet stateless... ezt jelenti az, hogy a stateful működés skálázását elegánsan átdobod egy másik terület asztalára, szopjanak ők vele...

"Talán ha nagy vonalakban leírod, hogy stateful szerverrel ezeket az üzleti igényeket (?), hogyan lehet megvalósítani."

Például azt, hogy a hívó fél ne tudjon arról, hogy ha a hívási láncban bármelyik node menet közben elhalálozik, egy másik node úgy vegye át a folyamatban lévő hívást, hogy erről az adott tranzakciós burokban se tud senki más. Ezt egy stateless middleware nem képes kivitelezni.

"Másról beszélünk. Te a 3-10 réteg közül egyetlen egy rétegről beszélsz: a middleware réteg egy szeletéről, mint stateless rendszerről. Én meg a teljes vertikumról beszélek."

Valóban, tényleg másról beszélünk. Visszaolvastam a hozzászólásokat és rájöttem, hogy azt hívod stateful szervernek, aminek van állapota, pl. azt gondolod, hogy egy adatbázis az mindenképp stateful. Ha így nézzük, akkor nincs is stateless szerver, mert minden szervernek van állapota, pl. a bejött kérések adatai, az éppen feldolgozás alatt állók, a számolt adatok, vagy miket kell naplózni, hova, hiba esetén hova menjen email, mi az email szerver elérhetősége, ... Ezek mind a szerver állapotai, amik akár dinamikusan is változhatnak.

Én meg (és szerintem ez az általános) azt tekintem stateless szervernek, amelyik nem tárol kliens állapotot, a kérések végrehajtása nem függ a kliens állapottól.

"Például a stateless load balancer és a stateless adatbázis az konkrétan hogy működik az esetedben?"

Nézzünk egy egyszerű példát stateful és stateless adatbázisra. Legyen a feladat egy egyszerű kulcs-érték adatbázis készítése, ahol az érték egy feldolgozáson esik át mielőtt tárolásra kerülne, hogy jobban látszódjanak a stateful előnyei.

Stateful esetben szolgáljon ki három kérést:

  1. érték megadása, itt a megadott értéket feldolgozza és az eredményt hozzárendeli a klienshez,
  2. kulcs-érték tárolása, itt a megadott kulcshoz eltárolja a klienshez korábban hozzárendelt, már feldolgozott értéket,
  3. kulcs elkérése, itt a korábban eltárolt kulcshoz visszaadja az eltárolt értéket.

Stateless esetben szolgáljon ki két kérést:

  1. kulcs-érték tárolása, itt a megadott értéket feldolgozza és a megadott kulcshoz eltárolja,
  2. kulcs elkérése, itt a korábban eltárolt kulcshoz visszaadja az eltárolt értéket.

Stateful esetben, ha egy értéket több kulcshoz is el akar tárolni egy kliens, akkor csak egyszer adja át az értéket, majd különböző kulcsokhoz eltárolja. Ilyenkor kevesebb adatot ad át a szervernek, hiszen nem kell minden kéréskor elküldenie az értéket. Gyorsabb is lesz a kérések végrehajtása, hiszen a megadott értéket csak egyszer kell feldolgoznia. Ezek az előnyei a statefulnak a stateless-szel szemben.

Nézzük a horizontális skálázást!

Tegyük fel, hogy sokkal több adatot szeretnénk tárolni illetve sokkal több kérést feldolgozni, mint amit egy szerverünk tud.
Stateless esetben felállítunk mondjuk száz korábban definiált stateless szervert, eléjük rakunk egy stateless load balancert, ami a beérkező kérésben szereplő kulcsot használva egy hash algoritmus által meghatározott szerverhez delegálja a kérést, ami azt lekezeli és válaszol a kliensnek.
Ennyi. Ahogy vártuk a stateless szerverünktől, egyszerűen és jól skálázható.
Ideális hash algoritmus esetén egy-egy szerverünk század annyi tárolóhelyet használ, mintha egy szerver lenne, illetve egységnyi idő alatt százszor annyi kérést dolgoz fel a rendszerünk.

Stateful esetben már szinkronizációs, zárolási, sorrendiségi és egyéb problémák adódnak. A tisztelt olvasóra bízom a fenti stateful K-V adatbázis horizontális skálázását! :)

Visszaolvastam a hozzászólásokat és rájöttem, hogy azt hívod stateful szervernek, aminek van állapota, pl. azt gondolod, hogy egy adatbázis az mindenképp stateful.

Nem stateful szervernek, stateful rendszernek... a stateful rendszereknek része lehet a stateless middleware szerver... Te pedig végig stateless middleware szerverről beszélsz.

Én meg (és szerintem ez az általános) azt tekintem stateless szervernek, amelyik nem tárol kliens állapotot, a kérések végrehajtása nem függ a kliens állapottól.

A stateful és a stateless rendszer között az a különbség, hogy a stateless esetén mindig minden adatot át kell küldeni és mindig minden adatot vissza fog küldeni az adott rendszer, a stateful pedig megőrzi az állapotának egy részét.

Stateful rendszer esetén a kliens lehet stateless. Stateless rendszer esetén a kliens stateful kell legyen.

Stateful esetben szolgáljon ki három kérést:
1, érték megadása, itt a megadott értéket feldolgozza és az eredményt hozzárendeli a klienshez,
2, kulcs-érték tárolása, itt a megadott kulcshoz eltárolja a klienshez korábban hozzárendelt, már feldolgozott értéket,
3, kulcs elkérése, itt a korábban eltárolt kulcshoz visszaadja az eltárolt értéket.

Stateless esetben szolgáljon ki két kérést:
1, kulcs-érték tárolása, itt a megadott értéket feldolgozza és a megadott kulcshoz eltárolja,
2, kulcs elkérése, itt a korábban eltárolt kulcshoz visszaadja az eltárolt értéket.

Ez elég nagy hülyeség. Nem azért stateful, mert _korábban hozzárendelt_ vagy _korábban feldolgozott_ értéket is tárol, hanem azért, mert már _tárol_ klienshez kötődő értéket, az, hogy a rendszer két kérés között _tárol_, már megvalósítja a _stateful_ viselkedést. Ha az csak egy kulcshoz csak egy érték, akkor az már stateful...

Ha feltöltesz egy képet egy azonosítóval egy szerverre, az már state, amihez stateful rendszer kell, amelyik visszaadja a feltöltött képet, ha megmondod neki az azonosítót. Az, hogy ezt esetleg stateless middleware szolgálja ki, mert a middleware rétegben nem tárolsz állapotot, attól még a rendszer egésze stateful.

Stateless esetben felállítunk mondjuk száz korábban definiált stateless szervert, eléjük rakunk egy stateless load balancert, ami a beérkező kérésben szereplő kulcsot használva egy hash algoritmus által meghatározott szerverhez delegálja a kérést, ami azt lekezeli és válaszol a kliensnek.

Mi a stratégiád arra, ha kiesnek node-ok a szolgáltatásból? Hogy biztosítja ez az architektúra azt, hogy minden körülmények között képes leszel egy kulcshoz egy értéket letárolni és azt visszaolvasni? És hogy kötsz össze egy tranzakcióba két ilyen szolgáltatást?

Ideális hash algoritmus esetén egy-egy szerverünk század annyi tárolóhelyet használ, mintha egy szerver lenne, illetve egységnyi idő alatt százszor annyi kérést dolgoz fel a rendszerünk.

Jahogy ideális esetben.. és való életbeli nem ideális esetben? Replikálni kell az adatokat több szerverre, kezelni kell az adatütközéseket, kezelni kell a kiesett szervereket, kezelni kell a visszatérő szerverek adatszinkronizációját, kezelni kell a hálózati problémákat, és a többi... rögtön nem lesz egyszerű a dolog, de ugye a teljes szopást áttoltad az adatbázis rétegre, oldják meg: "Stateful esetben már szinkronizációs, zárolási, sorrendiségi és egyéb problémák adódnak."

A tisztelt olvasóra bízom a fenti stateful K-V adatbázis horizontális skálázását! :)

Látod, erről ugatok mióta: az a stateless middleware fejlesztők vesszőparipája, hogy szopjon a másik terület, ha mégis kell stateful működés. És persze kell a stateful.

Mégiscsak hét éven át tanítottam, aztán meg ott az utóbbi 8-10 évben is sok volt a balfasz, akinek mindig mindent el kellett magyarázni az alapoktól kezdve. :)

Röviden és nem matematikai nyelven:
- Stateless rendszer: bármelyik időpillanatban nézve a kimenete csak a bemenettől és a rendszer statikus állapotától függ.
- Stateful rendszer: a kimenete függ az aktuális bemenettől, a rendszer statikus-, illetve az aktuális (dinamikus) belső állapotától.

Ha egy kulcshoz letárolsz egy értéket, amit később - egy független külön kérés során bármilyen módon felhasználsz, az már stateful rendszer, mert nem a bemenettől és a statikus állapottól függ a kimenet értéke.

"Stateful esetben, ha egy értéket több kulcshoz is el akar tárolni egy kliens, akkor csak egyszer adja át az értéket, majd különböző kulcsokhoz eltárolja. Ilyenkor kevesebb adatot ad át a szervernek, hiszen nem kell minden kéréskor elküldenie az értéket. Gyorsabb is lesz a kérések végrehajtása, hiszen a megadott értéket csak egyszer kell feldolgoznia. Ezek az előnyei a statefulnak a stateless-szel szemben"

Nem bantani akarlak, de nem erted.

Big Data trendek 2016

"Stateless esetben felállítunk mondjuk száz korábban definiált stateless szervert, eléjük rakunk egy stateless load balancert, ami a beérkező kérésben szereplő kulcsot használva egy hash algoritmus által meghatározott szerverhez delegálja a kérést, ami azt lekezeli és válaszol a kliensnek.
Ennyi."

En: Megkerdezhetem, hogy hova perzisztalod az adatokat, hol lesznek vegul eltarolva?
Te: ...
Mire en: Na az a stateful resze a rendszernek, ott tarolod az allapotot, es oda toltad a problemat. Ameddig az birja, addig skalazodik a rendszered, es nem tovabb. Ha az egy egyszeru text file a storagen, akkor amig a csovon kifer, addig a stateless reteged tudja tolni a kereseket, es amikor elered a veget hiaba inditasz meg 100 stateless szervert. Ekkor jonnek a trukkok, ujabb retegek, amivel bonyolitod az achitekturat. Bevezetsz egy cache reteget, hogy a gyakran kert adatokat ne a diskrol olvassa a storage, hanem benne legyenek memoriaban. Amikor kifogysz a memoriabol, akkor elkezded a stateless retegbe vinni az adatokat, pl bevezetsz egy distributed cachet, es eljutottunk ismet a kalyhahoz, ugyanis maris nem annyira stateless az a stateless. De meg nincs vege. Elkezdesz "csalni", bevezetsz egy stateful loadbalancert, es adott user kereset mindig ugyanarra a szerverre iranyitod, mondjuk szerver terheles szerint. De mi tortenik, ha az egyik szerveren, pont az odairanyitott userek 80% elkezdi hasznalni a legeroforrasigenyesebb vegpontokat? Egy par osszeomlas utan kuka az egesz. Valahogy meg kell oldani, hogy az allapot legyen szinkronba, hogy ne a komplett kereseket lehessen iranyitani, hanem az elvegzendo muveletet lehessen barmely szerverre kuldeni. Kb eddig jok a distributed cachek, mert ha eleg kicsi az egyes nodeok kozott a kesleltetes, akkor barmelyik el tudja latni a feladatot.
Te: Akkor ezzel meg is van oldva?
En: Itt jonnek kepbe a tranzakciok. Ugyanis ha tobb elvegzendo muveletet egyben szeretnel kezelni, amik ugye kulonbozo gepeken vannak, ne adj isten a muveletek kolunbozo adaforrasokat is hasznalnak, akkor Springgel nincs ra megoldas, neked kell hibaturore irni az alkalmazast, ami lehet az, hogy a felhasznalo toleralja a hibat (blog, hirek, forum), es lehet az, hogy az alkalmazas (bank, biztositas, kormanyzat). Ellobbirol annyit, hogy az az egyszerubb ;) utobbirol pedig, irto nagy szopas megcsinalani uzembiztosra. Csomo 3rd party dolognak kell osszhangban mukodnie a sajat kododdal (cachek, adatbazisok, es egyeb nyalanksagok), raadasul a teszteles es total rad harul, mert lehet a vilagon is csak 5 masik ember hasznalja pont azt amit te, pont ugy. Amig ugyanez Java EE hasznalata eseten, leven a JVM-ek egymas kozott oldjak meg a dolgot, sokkal kissebb a szivas, legalabbis nekunk fejlesztoknek ;). Tudja: rollback pont.

-
Big Data trendek 2016

Ha jól értem, az adatbázis a történet végén mindig ott lesz, akár J2EE-t,akár bármi mást használsz, tehát végülis mindig az lesz a szűk keresztmetszet, nem? Mert mondjuk
adatot gyűjtesz, amit ki KELL perzisztálni, mert terabájtnyi adatokat NEM lehet memóriában tartani. Akkor viszont amikor kiolvasod, ugyanúgy ott a probléma, amiket leírtál,
hogy a gyakran használt lekérdezéseket be kell cache-elni, hogy gyorsabb legyen, stb, stb.

"Ha jól értem, az adatbázis a történet végén mindig ott lesz, akár J2EE-t,akár bármi mást használsz, tehát végülis mindig az lesz a szűk keresztmetszet, nem?"

Általában van ott valami, ami tárolja a rendszer aktuális állapotát... mindegy, hogy mi az, lehet adatbázis, lehet egy füzet, akár egyiptomi rabszolgák is véshetik a piramis falára, de ott van az aktuális állapot.

Nem biztos, hogy szűk lesz a keresztmetszet. De lehet, hogy szűk. És ha szűk lesz, akkor egy másik dobozkába kell tenni valamennyi állapotot, ha azt bele tudod tenni a vertikum bármelyik rétegébe, akkor mozgástered van. Ha nem tudod beletenni bármelyik rétegbe, akkor nincs mozgástered: kényszerpályán leszel.

Az is kényszerpálya, ha azt mondod, hogy oldja meg valaki más, mert Te csak a middleware rétegért vagy felelős, ott ugye nem lehet bizonyos technológiák esetén és akkor nem érzékeled igazán a problémát.

Ha az egész rendszerért vagy felelős, akkor viszont valamelyik ujjadba bele kell harapj... és ha tudod, hogy lennének kevésbé fájdalmas megoldások, akkor utólag verheted a falba a fejed.

"Akkor viszont amikor kiolvasod, ugyanúgy ott a probléma, amiket leírtál, hogy a gyakran használt lekérdezéseket be kell cache-elni, hogy gyorsabb legyen, stb, stb."

Igen, de ezek benne vannak a specifikációban és az implementációkban is. Nem kell feltalálni a melegvizet, csak használni kell, ha szükséges.

Például ha vannak egymástól különálló stateless middleware szolgáltatásaid, külön gépeken, külön adatbázissal, akkor ezt tök egyszerű megcsinálni bármilyen technológiával, nem lesz teljesítménybeli különbség, nem lesz fejlesztési időben különbség, nem lesz üzemeltetési költségekben különbség.

Ha közben felmerül egy üzleti igény (ami lehet akár egy tervezési hiányosság!), hogy két ilyen stateless middleware szolgáltatás mégis legyen egy tranzakcióban, mert azzal mondjuk az üzlet megtakarít évente 20 embernapot, akkor Java EE esetén könnyedén be tudod vonni egy tranzakcióba csak ezt a két szolgáltatást, hamar megtérül a módosítás, mindenki boldog.

Más esetben hugyozhatsz vért is, akkor se fog menni ilyen egyszerűen, ezért soha nem fog megtérülni, ezért aztán bele se kezdenek, sokszor el se jut a fejlesztőig, hogy lenne erre igény, az üzlet pedig elfogadja, hogy évente 20 embernappal több munkája lesz. Nem kötik bele a rendszer TCO-ba, hogy van x esetben y embernapnyi plusz munka, ezért az IT oldalról az látszik, hogy csodálatosan olcsó az adott szolgáltatás, az üzlet oldaláról az látszik, hogy kaptak üzleti értéket, tehát jobb mint volt, de elfogadják, hogy nem lehet ennél jobb és soha nem vetik össze, hogy más technológiával mennyi lenne a TCO.

"különálló stateless middleware szolgáltatásaid, külön gépeken, külön adatbázissal,"

A saját definíciód szerint
"Stateless rendszer: bármelyik időpillanatban nézve a kimenete csak a bemenettől és a rendszer statikus állapotától függ."
ezek nem is stateless-ek, hanem stateful-ok, mivel a kimenet külső, dinamikus adatoktól is függ.

"mivel a kimenet külső, dinamikus adatoktól is függ" szerintem meg most hagyd abba, mert ebbol mar nem josz ki jol. A stateless eredmenye csak a kulso dinamikus adattol fugg, a statefulle meg nem, mert belul is van allapot. Nagyon hasonlo pelda. Vannak a thread safe osztalyok, meg a nem thread safe. A thread safe nem tarol allapotot, ezert adott bemenetre adott kimenetet ad mindig, a nem thread safe meg tarol allapotot, es nem megjosolhato milyen bemenetre mikor milyen kimenetet ad. Hasznalsz thread safe meg nem thread safe osztalyokat? ugyanaz, csak egy-ket absztrakcios szinttel feljebb.

-
Big Data trendek 2016

A definíciód szerint nem az. Vagy a stateless rendszer (most akkor van ilyen szerinted?) definíciója más, mint a stateless szolgáltatásé?
Ha igen, akkor légy szíves definiáld a stateless szolgáltatást!

Egyszer definiálod, hogy mi a stateless rendszer, máskor meg azt írod, hogy nincs is ilyen, mert a rendszer egésze mindig stateful. Ezt is végre rendbe rakhatnád, hogy ezt végül is hogyan gondolod!

"A definíciód szerint nem az."

Nem érted... nagyon nem érted. :(

"Vagy a stateless rendszer (most akkor van ilyen szerinted?) definíciója más, mint a stateless szolgáltatásé?"

Igen, más a rendszer és más a szolgáltatás, ami tulajdonképpen egy alrendszer.

Egy stateless rendszerben minden rétegben minden szolgáltatás stateless. Egy stateful rendszerben van legalább egy stateful szolgáltatás. Egy stateful szolgáltatásnak lehet része sok stateless szolgáltatás, de van benne legalább egy stateful szolgáltatás. Egy több rétegű stateful szolgáltatásnak lehet több rétege is stateless, de van legalább egy stateful rétege.

Ha egy stateless rendszerbe teszel egyetlen egy stateful alrendszert, akkor az egész rendszer stateful lesz. Ha egy stateful rendszerbe teszel egyetlen egy darab stateless alrendszert, attól az nem válik stateless rendszerré.

"Ha igen, akkor légy szíves definiáld a stateless szolgáltatást!"

Definiáltam: bármelyik időpillanatban nézve a kimenete csak a bemenettől és a rendszer statikus állapotától függ.

Ha letárolsz egy kulcshoz egy értéket, az már stateful szolgáltatás, de ennek a szolgáltatásnak lehet stateless a middleware rétege, mert adatbázisban tárolod a kulcshoz az értéket és az adatbázis már stateful szolgáltatás.

"Egyszer definiálod, hogy mi a stateless rendszer, máskor meg azt írod, hogy nincs is ilyen, mert a rendszer egésze mindig stateful."

Stateless middleware rétegről beszéltem. A middleware réteg egy réteg a sok közül. Olvass figyelmesen és gondolkodj el egy kicsit, más jelent a rendszer, a szolgáltatás és a réteg.

Vegyünk egy utolsó példát, hogy egyértelmű legyen miről is beszélsz!

Van egy szolgáltatás, aminek az inputja idA és idB, elkéri adatbázistól az A és B értéket az id-k alapján.
1. Ez a szolgáltatás a definíciód szerint stateless vagy stateful?
2. Van-e stateless rétege?
3. Ha van, akkor mi az?

"1, A szolgáltatás stateful."

Így nehéz valamiről beszélni, ha valami Nálad hol stateless, hol stateful. A példámban a stateful réteget, a szóhasználatoddal élve, áttoltam az adatbázis kezelőbe, itt ("Te ez esetben csak _web_ és _middleware_ szerverről beszélsz, jelentősen egyszerűsítve a problémateret... és persze a middleware úgy stateless, hogy a state tárolását elegáns mozdulattal áttolod egy másik rétegbe") és itt ("fogod a kis alkalmazásodat, megírod stateless és microservice, a kliens küldi mindig a tokent, hogy ő kicsoda, az adatbázis pedig tárol mindent, a kulcs ez a token") az ilyen szolgáltatás ("web middleware szerver", "alkalmazás", "microservice") Nálad még stateless volt.
Sikerült eljutnunk odáig, hogy az idézett szolgáltatások most már stateful-ok, és gyakorlatilag csak az stateless, aminek nincs belső állapota, és nem hív stateful szolgáltatásokat, tehát gyakorlatilag csak "statikus transzformációkat végez".

Ha már saját definíciókat alkotsz, akkor próbáld konzekvensen alkalmazni!

Ez így most már teljesen komolytalan!

Sejtem, hogy erre is jön egy "Olvass figyelmesen és gondolkodj el egy kicsit", "Nem érted... nagyon nem érted. :(", vagy valami hasonló, de már nem nagyon érdekel, részemről itt kiszállok.

Így nehéz valamiről beszélni, ha valami Nálad hol stateless, hol stateful.

Én mindig pontosan fogalmaztam, hogy mikor stateless és mikor stateful, egyszerűen Te kevered, hogy mire írtam... :)

A példámban a stateful réteget, a szóhasználatoddal élve, áttoltam az adatbázis kezelőbe.

Attól még a szolgáltatásod egésze - amely több rétegű - stateful marad, mindegy, hogy melyik rétegbe tolod a stateful működést és hol vannak stateless rétegek...

Sikerült eljutnunk odáig, hogy az idézett szolgáltatások most már stateful-ok, és gyakorlatilag csak az stateless, aminek nincs belső állapota, és nem hív stateful szolgáltatásokat, tehát gyakorlatilag csak "statikus transzformációkat végez".

Mindig is ezt mondtam, hogy a szolgáltatás egésze stateful, aminek van egy stateless middleware rétege. Ízlelgesd egy darabig, ki fog tisztulni. :)

"Ez így most már teljesen komolytalan!"

Ha nem érted a rendszer, szolgáltatás és réteg fogalmakat, akkor veheted komolytalannak is, de szerintem hagyd érlelődni egy kicsit, meg fogod érteni.

"Én mindig pontosan fogalmaztam, "

Direkt be is idéztem ezeket a pontos fogalmazásokat: "_web_ és _middleware_ szerverről beszélsz", "kis alkalmazásodat, megírod stateless és microservice".
Stateless szerverről, és stateless microservice alkalmazásról írtál, nem azoknak valamilyen rétegeiről.
Nem réteget írtál, hanem szervert és alkalmazást. Ízlelgesd egy darabig, meg fogod érteni mit írtál. :)

"_web_ és _middleware_ szerverről beszélsz"

Itt egyértelmű, hogy melyik réteg, meg van nevezve mind a kettő (web és middleware).

"kis alkalmazásodat, megírod stateless és microservice"

Itt meg a szövegkörnyezetben egyértelmű volt, hogy a "kis alkalmazásod" alatt a middleware rétegről van szó és nem egy szolgáltatás teljes vertikumáról.

"Stateless szerverről, és stateless microservice alkalmazásról írtál, nem azoknak valamilyen rétegeiről."

Stateless szervert eddig csak Te írtál, mégpedig sokszor, pedig nincs semmi értelme ennek a kifejezésnek... a stateless microservice alkalmazást se írtam, hanem azt, hogy az alkalmazásodat (=middleware) megírod stateless microservie formájában...

"Nem réteget írtál, hanem szervert és alkalmazást."

Ha már szavakon lovaglunk: szerver szót nagyon ritkán szoktam írni és az alkalmazás szót se gyakran ilyen kontextusban, általában csak akkor, ha reagálok valakinek a gondolatmenetére. Rendszert, szolgáltatást és réteget szoktam említeni, magasabb absztakciós szint és közelebb áll a valósághoz. Az az érdekes, hogy mások számára teljesen tisztán érthető... :/

Pedig egyet kell értenem vele, teljesen jól elmondja, hogy ha bárhol van state tárolás, onnantól kezdve az egész rendszer stateful lesz (ettől még lehet, hogy pl. a middleware stateless), és valódi stateless-ről akkor beszélünk, ha mondjuk int add(int x, int y) { return x + y} jellegű kódok vannak, aminek aztán tényleg teljesen mindegy, hogy melyik gépen, és mikor fog lefutni.

Az az egy gond van ezzel, hogy ez az Ő definíciója, mert azt hiszi valamiért, hogy azért ez a neve, mert a "szolgáltatásban", "rendszerben" vagy "rétegben" való állapot tárolásról nevezték el. Valójában ez a kommunikációs protokoll mikéntjéről kapta a nevét.

Lásd a wikipédián, részlet:
"In computing, a stateless protocol is a communications protocol that treats each request as an independent transaction that is unrelated to any previous request so that the communication consists of independent pairs of request and response. A stateless protocol does not require the server to retain session information or status about each communications partner for the duration of multiple requests. In contrast, a protocol which requires keeping of the internal state on the server is known as a stateful protocol."

"Valójában ez a kommunikációs protokoll mikéntjéről kapta a nevét."

Baszki. Nem. Nem-nem-nem. A stateless protocol az stateless alapokon működik, azért hívják stateless protokollnak... nem a protokoll elnevezéséről kapta a nevét a stateless működés és nem a stateful protokollról kapta a nevét a stateful működés.

Nem azért stateless egy szolgáltatás, mert stateless protokollon át éred el... képzeld: el tudsz érni stateless szolgáltatást egy stateful protokollon is (ilyen például websocket protokollon át egy statikus letöltés), és el tudsz érni egy stateful szolgáltatást egy stateless protokollon (ilyen például bármelyik dinamikus webszerver klasszikus HTTP protokollon). Meddig akarod még égetni magad? :(

Igazabol ebbol indult a vita, nem a protokollokbol.

"Stateful Session Beans
The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client/bean session. Because the client interacts (“talks”) with its bean, this state is often called the conversational state."

"Stateless Session Beans
A stateless session bean does not maintain a conversational state with the client. When a client invokes the methods of a stateless bean, the bean’s instance variables may contain a state specific to that client but only for the duration of the invocation. When the method is finished, the client-specific state should not be retained. Clients may, however, change the state of instance variables in pooled stateless beans, and this state is held over to the next invocation of the pooled stateless bean. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client. That is, the state of a stateless session bean should apply across all clients."

es vannak meg a

"Singleton Session Beans
A singleton session bean is instantiated once per application and exists for the lifecycle of the application. Singleton session beans are designed for circumstances in which a single enterprise bean instance is shared across and concurrently accessed by clients."

-
Big Data trendek 2016

Itt is pontosan arról van szó, amiről beszélek, a klienssel való kommunikáció állapotáról és nem a "szolgáltatás", "rendszer" vagy "réteg" állapotáról.

Egy Stateless Session Bean tud fájl létrehozni és azt a fájlt később olvasni, vagy adatbázisba írni, onnan olvasni (tehát állapotot, state, tárolni és olvasni)? Igen tud. Ez Franko definícójában Stateful.

A definicioja szerint a session bean stateless, de a disk ahova irja pedig stateful, mert az allapot (a file) el van tarolva, es a file olvasas visszateresi erteke nem csak a beerkezo adattol fugg, hanme a rendszer belso allapotatol, azaz a fajl tartalmatol is. Valoszinuleg ezt nem erted. Tehat az egesz rendszered az stateful lesz.

-
Big Data trendek 2016

Stateless: "bármelyik időpillanatban nézve a kimenete csak a bemenettől és a rendszer statikus állapotától függ."

Tehát a kimenet nem csak bemenettől fog függeni, hanem a letárolt értéktől is, amit visszaolvasunk és használunk.
Tehát a rendszer dinamikus állapotától is függ (fájl tartalma, vagy adatbázis tartalma), nem "csak a bemenettől és a rendszer statikus állapotától", ezért lesz stateful, ezt nem érted.

A bemenet az, ami a kéréssel együtt jön, ami máshonnan az nem (fájl, adatbázis).
Azért, hogy még világosabb legyen, ne fájlba vagy adatbázisba tárolja, hanem memóriába. Gondolom erre már végképp nem lehet azt mondani, hogy bemenet.
Ha meg rámondjuk, akkor nem lesz Stateful kategória egyáltalán.

"A bemenet az, ami a kéréssel együtt jön, ami máshonnan az nem (fájl, adatbázis)."

A "máshonnan" jövő bemenet milyen önkényes döntés alapján nem bemenet?

"Azért, hogy még világosabb legyen, ne fájlba vagy adatbázisba tárolja, hanem memóriába. Gondolom erre már végképp nem lehet azt mondani, hogy bemenet."

Az meg milyen állapotmentes szolgáltatás, amelyik memóriában tárol állapotot?! Baszki. Baszki. Ne.

"A "máshonnan" jövő bemenet milyen önkényes döntés alapján nem bemenet?"

/Talán azért, mert egy függvénynek sem bemenete a környezeti változó?/

Akkor ezt a gyöngyszemet is elrakom, egy újabb definíció tanulhattunk meg a bemenet és kimenet fogalmáról, ami eltér a mainstream vonaltól.

"Az meg milyen állapotmentes szolgáltatás, amelyik memóriában tárol állapotot?! Baszki. Baszki. Ne."

Baszki. Baszki. De :)

Stateless Bean-ről beszélünk, ami pl. globális memóriában tárol és onnan olvas adatokat (pl. cache).
Ez Nálad Stateful, a világ többi részének meg Stateless.
Sajnos még mindig nem érted, hogy nem az állapot tárolása miatt hívják így, hanem a klienshez kacsolódó állapot tárolása miatt!

"/Talán azért, mert egy függvénynek sem bemenete a környezeti változó?/"

Változik a függvény kimenete, ha változik a környezeti változó? Ha nem, akkor ugye irreleváns a környezeti változó. Ha igen, akkor a környezeti változó vagy bemenet, vagy a függvény stateful, mert a bemenettől független állapota van, ami befolyásolja a kimenetét. Mit nem lehet ezen érteni? Tök egyszerű elvek ezek.

"Stateless Bean-ről beszélünk, ami pl. globális memóriában tárol és onnan olvas adatokat (pl. cache)."

A Stateless EJB egy _implementációja_ a stateless _elvnek_... ha globális memóriából olvas és ír, akkor egy stateful szolgáltatást meghívó stateless szolgáltatásról van szó. A cache vagy a globális memória ugyanis nem része a Stateless EJB implementációnak, az egy külön réteg, amit használhat egy Stateless EJB is...

"Ez Nálad Stateful, a világ többi részének meg Stateless."

A Stateless Bean attól még stateless marad, hogy meghív stateful szolgáltatást... de ettől a pillanattól kezdve a teljes hívási lánc egésze már stateful, mert van benne már egy stateful hívás.

"Sajnos még mindig nem érted, hogy nem az állapot tárolása miatt hívják így, hanem a klienshez kacsolódó állapot tárolása miatt!"

Bármi, ami állapotot tárol, az stateful. Bármi, ami állapotmentes, az stateless. Ennyi az egész. Ne bonyolítsd feleslegesen.

"Akkor ezt a gyöngyszemet is elrakom, egy újabb definíció tanulhattunk meg a bemenet és kimenet fogalmáról, ami eltér a mainstream vonaltól."

Tedd el. Aztán majd egyszer előveszed és a homlokodra fogsz csapni, hogy mekkora balfasz voltál... :)

Újabb gyöngyszemek! :)

"a környezeti változó vagy bemenet"

Hogyan lehet egy változó vagy bemenet vagy nem?

"a függvény stateful"

Bravúros! :)

"ha globális memóriából olvas és ír, akkor egy stateful szolgáltatást meghívó"

Tehát akkor pl. ez egy globális szolgáltatás hívása: 


GlobalClass.envVar = 15;

Mindig tanul az ember!

"Hogyan lehet egy változó vagy bemenet vagy nem?"

Attól függően, hogy használod, mit rajzolsz körbe stateless és mit rajzolsz körbe stateful vonallal...

"Tehát akkor pl. ez egy globális szolgáltatás hívása: GlobalClass.envVar = 15;"

Igen, bármilyen furcsa, ez egy globális szolgáltatás hívása, ha stateless-nek nevezed a hívót; vagy stateful lesz a függvényed, mert állapotot tárolsz benne. Persze egy node esetén ez nem jelentkezik egyértelműen, de kettő vagy több node esetén már komoly problémáid lesznek, amikor szinkronizálnod kell "GlobalClass.envVar" értékét és rögtön rájössz, hogy ez egy stateful szolgáltatás, csak nem vetted észre vagy nem törődtél vele.

Nem lehet állapotot is tárolni és stateless függvénynek is maradni.

"ami a kéréssel együtt jön" azoka a bemeneti _parameterek_. De minden bemenet, ami nincs bent. A lokalis valtozo nem bemenet, hiszen bent jon letre, es csak a adott scopeon erheto el. Az adattag sem bemenet, hiszen a metodus szamara megcimezheto memoriaban van. Az adatbazisbol viszont bemegy az adat, leven, hogy nem letezik bent es nem is erheto el bentrol. un. kulso forras. De mostmar annyira alap dologrol beszelunk, aminek vajmi keves koze van az informatikahoz, te pedig kotozkodsz/ertetlenkedsz, nem tudom melyik a jobb ;)

-
Big Data trendek 2016

" ami máshonnan az nem (fájl, adatbázis)" legyszi aruld el, hogy a bean szemszogebol (ott all szegenyke varja a kereseket) az adatbazisbol erkezo adat az micsoda? Mert ugye benne nincsen, mert akkor nem kene lekerdezni. De ha nincs benne, akkor hol van. Valoszinuleg kivul. Ha pedig kivul van es bekerul, akkor... bemenet. Szoval szerinted micsoda? Legy oly kedves fejtsd ki. Amugy ez egy baromi egyszeru matrix:

eredeti pozicio | mozgas iranya
Kint van | ott marad
Kint van | bemegy
Bent van | ott marad
Bent van | kimegy

Ezek valamelyikenek kell lennie.

-
Big Data trendek 2016

Pedig ennel jobban lecsupaszitani a kerdest nem igen lehet, csak valasztanod kellett volna egyet a 4 opcio kozul, vagy feldobni ujabb lehetosegeket, ha valami kimaradt volna (bar ahogy tudom a bent-kint, mozog-nem mozog opcioknak nincs tobb variansa). Az a baj, hogy ez mar reg nem IT kerdes, hanem egyszeru logika, es kicsit, de csak egy hangyanyit fura, hogy pont akkor szallsz ki a vitabol, amikor mar nem lehet a kerdest tovabb egyszerusiteni. De elhiszem, hogy eddig nem sajnaltad az erot es az idot, hogy kakaskodj a velemenyeddel, de pont most fogyott el a kedved/erod/idod.

-
Big Data trendek 2016

Rendben, akkor még egyszer utoljára (bár tudom, hogy ez is csak időpocsékolás).

Egy szolgáltatásnál a kérést nevezik bemenetnek, a választ kimenetnek. A bemeneten kívül természetesen más forrásokból is szerezhet be információt (ezt nem szokás bemenetnek nevezni), illetve a működése során módosíthat külső dolgokat is (ezt nem szokás kimenetnek nevezni).
Hasonlóan van függvényeknél is, a függvény paramétereit szokás bemenetnek nevezni, a visszatérési értékét kimenetnek. Ha a függvény a futása során külső adatokat szerez be, vagy külső állapotokat módosít, akkor azokat nem szokás bemenetnek és kimenetnek nevezni.

Funkcionális programozásánál egy függvényt pure-nak neveznek, ha adott bemeneti értékekre mindig ugyanazt a kimenetet adja és közben nem okoz felfedezhető mellékhatást.
"A pure function is a function where the return value is only determined by its input values, without observable side effects."

A sin(x) függvénynek egy bemeneti értéke van és egy kimenete, a random() függvénynek nincs bemeneti értéke és egy kimeneti értéke van. Az előbbi pure, a random() nem pure, mivel ugyanarra a bemenetre más és más értéket ad vissza. Ha a random() függvényben zajló információ beszerzést is bemenetnek tekintenénk, akkor a random() is pure lenne, illetve minden függvény az lenne.

Próbáld ki, hogy megkérdezel pár programozót, hogy mi egy konkrét függvény bemenete és kimenete.
Két eset lehetséges:
- Válaszként a paramétereit és a visszatérési értéket mondják.
- Válaszként azt mondják, hogy nem lehet, vagy nagyon nehéz megmondani, mert meg kell nézni a függvény törzsét, végig kell követni az összes hívást és összegyűjtögetni, hogy mik jönnek be és miket módosít.

"mi egy konkrét függvény bemenete és kimenete." de nem a fuggvenyekrol beszelunk, arrol te beszelsz., Hanem arrol a definiciorol, hogy a stateless mukodes csak a bemeneti ertekektol fugg es a belso statikus allapottol, es ezek koze a bemeneti ertekek koze minden odatartozik, ami a stateless funkcinalitast megvalosito reszen kivul van. A metodus es a bemeneti parametere csak egy reszhalmaza a fent emlitett dolognak.

-
Big Data trendek 2016

"Ha a függvény a futása során külső adatokat szerez be, vagy külső állapotokat módosít, akkor azokat nem szokás bemenetnek és kimenetnek nevezni."

Ha szigorúan vesszük, akkor de, mindent kimenetnek és bemenetnek szokás nevezni, ami a dobozba bemegy és kimegy onnan. Javaslom tanulmányozásra például az UML-t, ott ez igen jól definiálva van.

"Az előbbi pure, a random() nem pure, mivel ugyanarra a bemenetre más és más értéket ad vissza."

Igen, a random() a hívó számára nem stateless, mert van egy state benne... fog ez menni, ha rávezeted magad... :)

"Ha a random() függvényben zajló információ beszerzést is bemenetnek tekintenénk, akkor a random() is pure lenne, illetve minden függvény az lenne."

Nem tekintheted annak, mert ha a hívási láncban van akár csak egy stateful komponens, akkor az egész hívási lánc el van "rontva"... hiába pure a sin(x), a sin(random()) nem lesz soha pure. Ezért hiába lehetne pure a random() függvény törzse, az egész random() hívás már nem az, mert valahonnan még szerez be információt, ami egy állapot. Hm?

"Ha jól értem" A vegen ott lesz bizony, de nem mindegy, hogy az alkalmazas leveszi a terhet a vallarol, vagy nem. Egy stateless middreware nem veszi le, egy stateful meg igen, raadasul EE alatt mechanizmus rejtve marad a programozotol meg az uzemeltetotol, mert azt a JVM-ek elintezik egymas kozott.

"terabájtnyi adatokat NEM lehet memóriában tartani" Mindenre nem jo, de ha ilyenre van szukseged, ott tervezesi hibat gyanitok, marmint pl nincs aggregalva az adatbazis tartalom vagy nem szeletelted kelloen kicsire a feldolgozhato egysegeket. Ekkora adatmennyiseget pl map/reduce technokaval szokas feldolgozni, es altalaban valami utemezo nezi, mikor lehet lefuttatni a jobot. De fixme, dolgoz fel valaki tobb terrabajtnyi adatot egytlen elosztott tranzakcioban?

-
Big Data trendek 2016

Szia, nálunk pl. van olyan requirement, hogy GPS koordinátákat kell tárolni sok-sok-sok forrásból, melyek folyamatosan tolják be az adatokat (néhány másodpercenként). Ezt mutatjuk
valós időben (cache) viszont lehetőség van időben visszakérdezni (merre járt adott jármű). Az előny, hogy ez utóbbi esetet nagyon ritkán használják, szóval nincs nagyon időbeli korlát.
Illetve elosztott tranzakció SINCS.

"Illetve elosztott tranzakció SINCS."

Ez teljesen kényelmes kis rendszer innen nézve, bármi megfelelő lehet, mert a stateful (és elosztott) részét az adatbázis csinálja, ha szükséges... csak akkor van probléma, ha előkerül egy olyan üzleti igény, hogy a middleware rétegben is LEGYEN elosztott tranzakció... amíg nincs olyan, hogy "EZT akkor csináld meg, ha AZT sikeresen megcsináltad", illetve "ha EZT nem sikerült megcsinálni, akkor ERRE a pontra állj vissza és próbáld újra", addig nem kell félni.

Ha üzembiztosan akarod megoldani, akkor mindenképpen lesz a rendszerben _valahol_ elosztott tranzakció, vagy sérül valahol az integritás és/vagy a konzisztencia. Ha sérülhet a konzisztencia és/vagy az integritás, akkor nincs semmi gond. Ha nem sérülhet, akkor viszont nincs nagyon más megoldás, vagy ootb elosztott tranzakció kell, vagy le kell fejleszteni az elosztott tranzakciót, ami jelentősen rontja az olvashatóságot, mert üzleti logikát kell keverni technológiai hiányból adódó körbetákolással.

Mondok egy tök egyszerű példát: egy skálázható sorszámosztó rendszert a teljes vertikumában (kopasz vastól a kliensig) hogyan építenél fel, amely szigorúan monoton növekvő sorszámokat kell adjon minden egyes kliensnek érkezési sorrendben?

"Ha csak annyi a lényeg, hogy szigorú monoton legyen, az talán annyira nem gáz."

Érkezési sorrendben? Hibatűrő módon? Akár földrajzilag elosztott környezetben? Hatékonyan? Gondold át. Mondd az ötleteidet. :)

"Ha a folytonosság (1, 2, 3, ...) is elvárt, akkor már inkább."

Ez lenne a következő fokozat, ha az elsőt sikerült megugrani.

"egy skálázható sorszámosztó rendszert a teljes vertikumában (kopasz vastól a kliensig) hogyan építenél fel, amely szigorúan monoton növekvő sorszámokat kell adjon minden egyes kliensnek érkezési sorrendben?"

A konzisztencia is ront a skálázhatóságon és a sorrendiség is. Ennél a példánál egészen annyira, hogy egyáltalán nem is lehet skálázni (horizontálisan).
Ha van skálázható megoldásod, akkor azt kíváncsian várom!

"A konzisztencia is ront a skálázhatóságon és a sorrendiség is."

Igen, tudjuk...

"Ennél a példánál egészen annyira, hogy egyáltalán nem is lehet skálázni (horizontálisan)."

...dehogynem lehet...

"Ha van skálázható megoldásod, akkor azt kíváncsian várom!"

...például elosztott tranzakcióval. Szóval?

Sajnos el kell keserítselek, mert ennél a példánál hiába futtatod 10, 100 vagy 1000 gépen, akkor sem lesz semmivel sem gyorsabb, mint ha 1 gépen futna. Az igaz, hogy üzembiztosabb lesz több géppel.

Ha az 1 géphez adsz még egy-két gépet, amik szintén nyilvántartják a számláló állását, akkor máris meg van az üzembiztonság. Ha az 1 gép kiesik, akkor a tartalék gépek közül egy a helyébe lép. Ennél az architektúránál nem tudsz gyorsabbat csinálni, nem tudod skálázni, mert azt az 1 gépet, ami növeli a számlálót és visszaadja az új értéket nem tudod két gépre vagy többre cserélni. A több géppel egyedül csak az üzembiztonságot tudod növelni.
Azt meg teheted Java EE-vel, Akka Actor (cluster)-okkal, vagy sok egyéb módon.

"Sajnos el kell keserítselek, mert ennél a példánál hiába futtatod 10, 100 vagy 1000 gépen, akkor sem lesz semmivel sem gyorsabb, mint ha 1 gépen futna."

Igen, nem skálázható lineárisan, de ez egy végletekig lecsontozott és triviálisan egyszerű példa a stateful igényre és architektúrára, ennél sokkalta több és összetettebb igény fordul elő, amelyek jobban párhuzamosíthatóak és jobban skálázhatóak ugyanebben a környezetben.

"Az igaz, hogy üzembiztosabb lesz több géppel."

Ez nem csak azért van, mert több géped van.

"Ha az 1 géphez adsz még egy-két gépet, amik szintén nyilvántartják a számláló állását, akkor máris meg van az üzembiztonság. Ha az 1 gép kiesik, akkor a tartalék gépek közül egy a helyébe lép."

Na, és ezt hogy oldod meg? Leírva kurva egyszerű. Írj technológiákat és architektúrát, hogy ezt hogy tudod kivitelezni.

"Akka Actor (cluster)-okkal, vagy sok egyéb módon."

Lássuk a példát, én néztem Akka-t, az Actor cluster közel nem tudja ezt, amire szükség lenne, de itt a lehetőség, hogy bizonyíts, az egyéb módok is érdekelnek.

"Na, és ezt hogy oldod meg? Leírva kurva egyszerű. Írj technológiákat és architektúrát, hogy ezt hogy tudod kivitelezni."

Te még erre se voltál képes csak buzzword-öket soroltál fel!
Leírtam az architektúrát is meg a technológiát is.
Mégis mit nem tud az Akka Actor cluster, amire itt szükség lenne?

"egyéb módok is érdekelnek."

Zookeeper, etcd, consul, RabbitMQ.

The LMAX Architecture

"Te még erre se voltál képes csak buzzword-öket soroltál fel!"

Próbáltad már? Mert egyik sem buzzword, hanem a legalább 15 éve létező Java EE technológiai komponensek megnevezései, egyszerű szimpla tények: "Clustered EJBs behave in their own manner. However, only stateful session beans are clustered."

"Mégis mit nem tud az Akka Actor cluster, amire itt szükség lenne?"

Írj egy példát a teljes failover megoldásra, milyen módon tér vissza normál üzembe véletlenszerűen kieső node-ok visszatérése után... ezek a divatos keretrendszerek mindig ott véreznek el, amikor stateful kell működni és hibát kell tűrni...

"Zookeeper, etcd, consul, RabbitMQ."

Na, ezek a buzzword-ök.

Melyik mit csinál a kérdéses ügyben? Hány nyitott port és process szükséges az üzemszerű működéshez? Milyen monitoring eszközökkel lehet felügyelni ezeket? Milyen eszközökkel lehet menteni az aktuális állapotot? Ismét az a probléma, hogy én teszteltem ezeket, tudom, melyiknek mi a hiányossága és üzemeltetési kockázata... Te melyiket használnád például a saját számlaegyenleged nyilvántartására? Mennyi saját pénzt mernél rábízni bármelyikre?

És melyikkel hogyan tudsz egy tranzakcióba kötni két sorszámosztót? Ja, egyikkel sem? Ó, de kár. :)

"Arra viszont kivancsi lennek, mi tortenik a Java EE clusterrel, ha particionalodik."

Két esetet tudok elképzelni:
- Onnantól rossz sorszámokat fognak visszaadni az egyes cluster partíciók.
- Ha meg van adva egy minimum gép szám a clusterre (nem tudom, hogy JEE-nél lehet-e), akkor a nagyobbik cluster partíció (ami még megfelelő számú gépből áll) üzemel szépen tovább, a többiek nem adnak vissza értéket.

Szerk.:
Utólag néztem meg a linkedet, ahogy látom a Zookeeper nagyjából a második pontom alapján működik, és még az írás olvasást is szépen külön veszi.
Ennél jobban nehéz megoldani a cluster particíókra szakadását!

"Ehhez egy egyszeru Zookeeper konfiguracio is elegendo."

Tudhatja... de ugye ez egy szélsőségesen leegyszerűsített stateful szolgáltatás. Mondhatom azt is, hogy kettő - egymástól független - sorszámot kell visszaadni, és csak akkor, ha mind a kettő sikeres volt, vagyis legyen egy tranzakcióban a két sorszámosztó, ezen az egyszerű bővített igényen már fog hasalni a Zookeeper.

"Arra viszont kivancsi lennek, mi tortenik a Java EE clusterrel, ha particionalodik. Tehat ennek a megfelelojere."

Hibát fog visszaadni, amíg nem áll helyre a megfelelő működés.

Van errol valami doksi? A google-fum cserben hagyott.

Mindenhol csak annyit irnak, hogy ha lehal egy node, akkor a tobbi tovabb mukodik - de ha mondjuk van 5 node: A, B, C, D, E, es C es D particionalodik, akkor honnan tudja C es D, hogy A, B es E nem halt meg, csak pillanatnyilag elerhetetlen (de hibat ad, nem csak feltetelezi, hogy innentol ove a vilag)?

Lehet, hogy nem eleg jo a pelda, de talan ertheto, mire vagyok kivancsi.

"Lehet, hogy nem eleg jo a pelda, de talan ertheto, mire vagyok kivancsi."

Érthető a példa... teljes természetességgel el fog szállni a tranzakció, ha nem érhető el a konfigurációban definiált bármelyik node... ha a node üzemszerűen száll ki a kiszolgálásból, akkor ezt közli mindenkivel és a kontrollerrel is.

"A, B, C, D, E, es C es D particionalodik, akkor honnan tudja C es D, hogy A, B es E nem halt meg, csak pillanatnyilag elerhetetlen"

Ha elérhetetlen, az olyan, mintha meghalt volna. Amíg mind az öt node azt nem mondja egy tranzakcióra, hogy "oké", addig hiba van... ha a kontroller kivesz egyet a normál üzemből, arról tudni fog a maradék négy, ha újra visszateszi normál üzembe, akkor is tudni fog erről mind a négy.

"A kontroller egy single point of failure?"

Lehet több kontroller is, nem csak egy...

"Be lehet azt allitani, hogy az 5 node-bol ha 4 megy, az meg elfogadhato?"

Hogy lenne elfogadható, ha nem tudod, mi van az ötödikkel? Az ötödik mennyi idő után gondolja úgy, hogy nincsenek ott a többiek, ezért valamit másképp kellene csinálnia? Abban az időablakban mit csinál?

"Tudnal irodalmat ajanlani a Java EE ezen reszehez?"

Bármelyik Java EE tutorial jó, de ezek inkább üzemeltetői kompetenciák. Üzemeltetni is fogsz?

De tudom, mi van az otodikkel, a takaritoneni kihuzta a kabelt, hogy porszivozni tudjon. Ettol meg a maradek 4 node el es virul. Ha meg csak siman leszakadt a halorol, akkor (a Zookepernel maradva) eszreveszi, hogy egyedul maradt, nincs tobbseg, nem tud dontest hozni, tehat hibat ad - de ettol meg a tobbi 4 node-on keresztul a szolgaltatas elerheto.

A Java EE tutorialok sajnos siralmasak, semmilyen erdemi kerdesre nem adnak valaszt. De ha tudsz olyat ajanlani, ami a clusteringet erdemben targyalja, akkor azt megneznem.

En ezt talaltam, jonak tunik, de pont nincs fent Safarin: https://www.amazon.com/Real-World-Java-Patterns-Rethinking-Practices-eb…
Erdemes megvenni?

Igen, mondjuk, hogy uzemeltetni is fogok. De legalabbis olyan donteseket kell majd hoznom, amikhez ezeket is tudni kell.

"Ha meg csak siman leszakadt a halorol, akkor (a Zookepernel maradva) eszreveszi, hogy egyedul maradt, nincs tobbseg, nem tud dontest hozni, tehat hibat ad - de ettol meg a tobbi 4 node-on keresztul a szolgaltatas elerheto."

Honnan veszi észre, hogy leszakadt vagy csak felment 20000ms fölé a roundtrip?

"De ha tudsz olyat ajanlani, ami a clusteringet erdemben targyalja, akkor azt megneznem."

A clustering és annak adminisztrációja implementáció függő. A Java EE fejlesztői szemmel - kicsit sarkítva - egyszerű: nem kell foglalkoznod azzal, hogy miképpen fog futni.

"Erdemes megvenni?"

Fogalmam nincs... én általában a "probléma -> keres -> próbál -> megold" ciklusban vagyok és másfél évtized alatt ragadt rám sok minden, az meg nincs könyvben leírva. Mert rendszerek jönnek-mennek, a szopás marad. :)

"Honnan veszi észre, hogy leszakadt vagy csak felment 20000ms fölé a roundtrip?"

Mi a kulonbseg, ha van egy 1000ms timeout-od? A vegeredmeny szempontjabol ugyanaz.

"A Java EE fejlesztői szemmel - kicsit sarkítva - egyszerű: nem kell foglalkoznod azzal, hogy miképpen fog futni."

Dehat ilyen nincs - epp te magad irtad par szaz sorral fejlebb, hogy milyen konnyen vannak a fejlesztok, hogy attolnak mindent az uzemeltetesre, holott a problemak megoldasan nekik (is) kellene dolgozniuk.

Valamint hogyan fejlesztesz valamit, amirol nem tudod (tetszoleges reszletessegig megismerhetoen), hogyan mukodik? Itt azt hiszem, megint eljutottunk a vilagnezeti kulonbsegekhez.

Csak sajat magadat jaratod le az ilyen hozzaszolasokkal, mert senki nem mondta, hogy jol skalazodik (egyszerubb skalazni, mert nem 3rd party megoldas), azt meg vegkepp nem, hogy minden problemara jo (de ezeket mar en leirtam vagy 2x). Van egy olyan terulet, ahol nem igen akad kihivoja, akarmennyit is eroskodtok. Mert olyan megoldast egyikotok sem tudodd mondani, ami oob distributed stateful transactiont tud. Bizonygatjatok, hogy nincs is ilyenre szukseg, meg amire valojaban szukseg van, arra meg letezik X,Y,Z szignifikans megoldas, de az a budos nagy helyzet barmennyire is faj, hogy letezo problemara nyujt megoldast az EE, raadasul baromi kenyelmesen fejlesztoi es uzemeltetoi szempontbol egyarant.

-
Big Data trendek 2016

"senki nem mondta, hogy jol skalazodik (egyszerubb skalazni, mert nem 3rd party megoldas), azt meg vegkepp nem, hogy minden problemara jo"
vs
"Ha ismernéd a Java EE-t, akkor tudnád, hogy üzembiztosan skálázódik, a Stateful EJB kezdetek óra cluster ready és perzisztens... a többi komponens is, ezért Java EE."

Elismerem, hogy egy kicsit sarkított volt, amit írtam, de szerintem ezt jelezte is a smiley a végén.

Elosztott, jól skálázható, hibatűrő, gyors válaszidejű rendszereknél a tervezés az elsődleges. Tudni kell, hogy mik azok a sarokpontok, amik ezeket akadályozzák, pl.: konzisztencia, sorrendiség, elosztott tranzakció, megosztott állapot, szinkron működés. Ezeket amennyire lehet kerülni kell!

"baromi kenyelmesen fejlesztoi es uzemeltetoi szempontbol egyarant"
Ezt nem vitatja senki, de ha (kényelemből) használod a Stateful bean-eket, az elosztott tranzakciót, akkor el kell felejteni az "elosztott, jól skálázható, hibatűrő, gyors válaszidejű rendszert". Mint láttuk, kiesik egy node és akkor az egész rendszer leáll. Ez sem nem hibatűrő, sem nem gyors válasz idejű.

Pl., hogy mennyire fontos a tervezés. A kiinduló példánál ("egy skálázható sorszámosztó rendszer") a klienseknek szigorúan monoton növekvő sorszámokat kell adni. Itt nagyon fontos, hogy miért is akarunk sorszámokat osztani nekik. Ha azonosításhoz fogjuk ezeket használni, akkor felesleges a sorrendiségre vonatkozó kitétel. Ilyenkor sokkal jobb választás UUID generálása és adása. Egy egyszerű tervezői döntéssel skálázható (X gép esetén teljesen mindegy melyik szolgálja ki a klienst), hibatűrő (ha kiesik egy gép, semmi gond, amíg van egy, addig tud újat generálni) és gyors válaszidejű (ha X db kérés érkezik egyszerre, akkor az X kliensnek nem kell egymásra várniuk) rendszerünk lesz.

Egy két érdekes oldal a témában: Reactive Design Patterns, You Cannot Have Exactly-Once Delivery, Microservice Trade-Offs (Distribution)

"Ezeket amennyire lehet kerülni kell!" ez igy van, de nem azt irtad, hogy mindig, hanem amennyire.
"elosztott, jól skálázható, hibatűrő, gyors válaszidejű rendszert" mondta barki, hogy ez egyidoben fog teljesulni?
"Ez sem nem hibatűrő" inkonzisztens lesz a rendszered? egy lepesben visszavonta az egesz muveletet hiba eseten?
"Ilyenkor sokkal jobb választás UUID generálása és adása" persze, mert az ugy megy, hogy a technologia hatarozza meg az uzleti igenyt.
"és gyors válaszidejű" ez a vesszoparipad, de nem mindig ez a legfontosabb szempont.
-
Big Data trendek 2016

"Elosztott, jól skálázható, hibatűrő, gyors válaszidejű rendszereknél a tervezés az elsődleges. Tudni kell, hogy mik azok a sarokpontok, amik ezeket akadályozzák, pl.: konzisztencia, sorrendiség, elosztott tranzakció, megosztott állapot, szinkron működés. Ezeket amennyire lehet kerülni kell!"

Nem mindig tudod elkerülni. Vannak olyan területek, ahol nem tudod megkerülni.

"Mint láttuk, kiesik egy node és akkor az egész rendszer leáll. Ez sem nem hibatűrő, sem nem gyors válasz idejű."

Nem fog menni másképp, ha network split van... ez egy ilyen világ, ha elszeparálódnak egymástól a szigorúan együtt dolgozó komponensek, akkor nem tudod soha semmilyen trükkel az üzembiztonságot megoldani. Vagy van rá megoldásod, hogy hiba nélkül adjon szigorúan monoton növekvő egymás utáni sorszámot két egymástól elszeparált szolgáltatás? Ha megoldod ezt a problémát, akkor kaphatsz pár Nobel-díjat szerintem.

"Itt nagyon fontos, hogy miért is akarunk sorszámokat osztani nekik. Ha azonosításhoz fogjuk ezeket használni, akkor felesleges a sorrendiségre vonatkozó kitétel. Ilyenkor sokkal jobb választás UUID generálása és adása."

Ha a választott techológia határozza meg az üzleti igényt, akkor igen. De jobb helyeken az üzleti igény határozza meg a választott technológiát.

És ha szigorúan monoton növekvő egymás utáni számsorozat kell érkezési sorrendben, akkor nem jó az UUID. Nagyon sok mindenre jó az UUID, de például rendszámnak se jó az UUID, bankszámlaszámnak se jó az UUID, kibocsátott számla sorszámának se jó az UUID, telefonszámnak se jó az UUID és IP címnek se jó az UUID... egyszerűen el kell fogadnod, hogy vannak olyan üzleti igények, amikor nem nagyon tudsz mást tenni, esetleg kicsit csalni a szigorúan monoton növekedéssel és előre kiosztasz tartományokat, de azzal se tudsz trükközni minden esetben... ez van.

Az, hogy ezekkel az igényekkel eddig még nem találkoztál, az csak azért van, mert vagy el se jut hozzád, mert nem bíznak meg ilyen feladattal vagy nem dolgoztál még olyan helyen, ahol ez fontos. Vagy leszartad és megoldottad rosszul.

"Ha a választott techológia határozza meg az üzleti igényt, akkor igen. De jobb helyeken az üzleti igény határozza meg a választott technológiát."

Mindenképp az üzleti igény határozza meg a technológiát, én sem írtam mást. Azonban itt pár dolog megint félre van értelmezve.
Az "Elosztott, jól skálázható, hibatűrő, gyors válaszidejű rendszer" ugyanúgy része szokott lenni az üzleti igénynek, mint a szigorúan monoton sorszámosztás. Az első rész az nem technológia!
Ha mind a két oldal része az üzleti igénynek, akkor az teljesíthetetlen lesz. Ilyenkor kell tisztázni, hogy mi is a fontosabb.
Ha a szigorúan monotonság, akkor az első négyesből több mindent is elfelejthetünk, mert nem lehet megcsinálni. Ha az előbbi négyes a fontos, akkor pedig kell találni valamit, ami helyettesíti a sorszámokat. Azonosításnál sok helyen jó az UUID, ahol nem, mint amilyen példákat írtál is, ott mindenképp egy helyen vagy particionáltan (, mint pl. bankok, telefontársaságok, ...) kell generálni azokat. Ha bankszámlaszám helyett sorszám lenne, akkor minden banknak össze kellene hangolnia a számlaszám adását, hasonló a helyzet a telefonszámokkal, IP címekkel.

"Az, hogy ezekkel az igényekkel eddig még nem találkoztál, az csak azért van, mert vagy el se jut hozzád, mert nem bíznak meg ilyen feladattal vagy nem dolgoztál még olyan helyen, ahol ez fontos. Vagy leszartad és megoldottad rosszul."

Ez meg szokásos stílusod: rád ragasztok valami légből kapott dolgot és jól lefikázlak miatta. Gratulálok!

"Az "Elosztott, jól skálázható, hibatűrő, gyors válaszidejű rendszer" ugyanúgy része szokott lenni az üzleti igénynek, mint a szigorúan monoton sorszámosztás. Az első rész az nem technológia!"

A gyors válaszidőt Te hoztad be, egyébként nem része a skálázásnak az, hogy feltétlen gyors is legyen, nagyon sok üzleti folyamat alapvetően lassú, főleg, ha van a folyamatban humán task is. Általában nem az a cél, hogy kurvagyorsan (ezredmásodpercek) alatt folyósítsd a jelzáloghitelt, hanem az, hogy biztosan folyósítsd és a folyamat során sehol ne vesszen el információ és semmiképpen ne legyen inkonzisztens és semmiképp ne sérüljön az integritás, se egy-egy rendszeren belül, se az együtt dolgozó rendszerek összességében.

"Ha a szigorúan monotonság, akkor az első négyesből több mindent is elfelejthetünk, mert nem lehet megcsinálni."

És? Egyedül Te keresed a szent grált. Emlékeztetnélek arra, hogy honnan indultunk: "Ha Java backend kell, amelyiknek kommunikálnia kell mindenféle legacy rendszerekkel, adatbázisokkal mindenféle protokollon, akkor friss Spring vs Java EE platform közül Java EE a kézenfekvő, feltéve, hogy nincs raktáron egy csomó unatkozó fejlesztő, akik csak a Spring keretrendszert ismerik és semmi mással nem hajlandóak dolgozni. Ha csak úgy backend kell és stateless működés, akkor a Java se feltétlen szükséges."

Most szerintem pont itt tartunk, hogy ez a mondat teljes mértékben igaz.

"Ez meg szokásos stílusod: rád ragasztok valami légből kapott dolgot és jól lefikázlak miatta. Gratulálok!"

Miért, dolgoztál ilyen helyen és ilyen feladattal? Ha igen, akkor hol és milyen projekten?

"Mi a kulonbseg, ha van egy 1000ms timeout-od? A vegeredmeny szempontjabol ugyanaz."

Miért lenne ugyanaz?

"Dehat ilyen nincs - epp te magad irtad par szaz sorral fejlebb, hogy milyen konnyen vannak a fejlesztok, hogy attolnak mindent az uzemeltetesre, holott a problemak megoldasan nekik (is) kellene dolgozniuk."

Igen. De - sarkítva - fejlesztési időben nem kell foglalkoznod azzal, hogy amit megírsz, az egy példányban fog futni vagy száz példányban, megírod és ootb menni fog a skálázódás, mert megoldja a framework. Ha nem oldja meg, akkor más megoldás kell, ilyen is van.

"Valamint hogyan fejlesztesz valamit, amirol nem tudod (tetszoleges reszletessegig megismerhetoen), hogyan mukodik? Itt azt hiszem, megint eljutottunk a vilagnezeti kulonbsegekhez."

Tudod, hogy miképpen működik és nem kell mindig mindent az utolsó szögig ismerned. Vagy követed az összes elektront is, ahogy mozog két atommag között?

"De - sarkítva - fejlesztési időben nem kell foglalkoznod azzal..."

De, kell foglalkoznod. Lehet azt mondani, hogy a framework megoldja, mert A, B es C, de kell ismerned A, B es C-t, vagyis erteni, hogy mukodik.

"Tudod, hogy miképpen működik és nem kell mindig mindent az utolsó szögig ismerned."

De igen, amikor nem mukodik. Egyik elso meghatarozo fejlesztoi elmenyem ahhoz kapcsolodik, amikor egy sajat fejlesztesu C++ alkalmazas kiderithetetlen hibat produkalt - vegigdebuggoltuk sorrol sorra, minden ugy nezett ki, ahogy kellett neki, es megsem mukodott. Most ilyenkor mit csinalsz? Elmondom, mit csinalt a fonokom: eloturta az MSDN cedeket, a stdlib forraskodot, a generalt assembly kodot, es kb. ket napon keresztul addig gyotorte a cuccot, amig ki nem derult, hogy a MS std::vector implementacioja hibas, de legalabbis bizonyos peremfeltetelek eseten nem a vart eredmenyt adja (nem emlekszem a reszletekre, csak a vegkovetkeztetesre). Innentol persze mar korbe lehetett programozni a problemat, de igenis ra kellett akaszkodni, mint bulldog a frizbire, es addig nyomozni, amig ki nem derult a turpissag.

Mert 99.99%-ban a hiba a sajat fejlesztesben van. De a maradek 0.1% az pont eleg ahhoz, hogy tonkretegye az egeszet.

Nagyszerű.

De nem előre volt kötelezően ismert az összes fejlesztő által az összes használt framework, operációs rendszer és firmware minden egyes sora, hanem utólag kellett felderíteni a hibát, nem? Szerintem messze nem ugyanaz, amikor _lehetőséged_ van megismerni az utolsó szögig vagy ismerned _kell_ az utolsó szögig.

Az lemaradt, hogy sokmindenre van recipe a Zookeperhez, lasd peldaul: https://zookeeper.apache.org/doc/r3.3.6/recipes.html - shared lock, vagy akar two-phase commit.

Persze ehhez mar picit tobb kell, mint csak maga a Zookeeper, de nem sokkal - elso nekifutasra azt mondanam, egy stateless service eleg a problemahoz (ha szabad itt a "stateless" szot hasznalni - nem tudom, vegul mire jutottatok a masik thread-ben :))

Persze, sok mindent meg lehet oldani. És még több mindent nem.

De minden egyes "picit több kell, mint csak maga az X technológia" mondás mindig csak egy picit nagyobb spagettihalmazt eredményez, mindig csak egy picit nagyobb üzemeltetési kockázatot, mindig csak egy picivel több tudást a projekt minden tagja számára, mindig csak egy picivel több időt a hibakeresésnél... és a végén ott ülsz majd egy több száz különböző időpontban, különbözően verziózott, különbözően konfigurálható, különbözően üzemeltethető és különbözően működő komponenshalom közepén és nem mersz semmit módosítani, mert fogalmad nincs, hogy ez mit okoz majd két komponenssel arrébb a hó végi zárás futtatásánál.

"több száz különböző időpontban, különbözően verziózott, különbözően konfigurálható, különbözően üzemeltethető és különbözően működő komponenshalom"

Erdekes, en ezt a Java alapu (EE vagy sem) rendszerekre altalanosan igaznak erzem - csak probald meg akarmelyik dependency-d verzioszamat megvaltoztatni a pom-ban, es figyeld a hatast :)

Nincs konnyu megoldas a problemakor lenyegebol adod komplexitasra - ezt megprobalhatod eltakarni barmilyen frameworkkel, nem fog sikerulni. Vagy hogy egy klasszikust idezzek: "there is no silver bullet". De azt hiszem, nem fogjuk egymast meggyozni :)

Kicsit kevered a szezont a fazonnal. Valoban a "Stateful szerver" azt jelenti, hogy a szerver allapotot tarol a felhasznalorol, azaz letrehoz egy sessiont a usernek, innentol okositani kell a a load balancert, hogy mindig ugyanoda terelje a usert es/vagy meg kell oldani a session replikaciojat tobb szerverre. De ez nem is olyan nagy ordongosseg, mert a session egy "snapshot" jellegu adat, amit utanna szet kell terjeszteni a gepek kozott. Amirol itt a vita folyik, az arrol szol, hogy beerkezik a user keres, amit beletolunk egy servicebe (bean), ahol indul egy tranzakcio (persze beallitas fuggo csak az egyszeruseg kedveert), es, hogy ez a bean stateless vagy stateful. Ha stateless, akkor tok mindegy melyik szerveren melyik beanbe fut be a keres, hiszen nem tarol allapotot, megcsinalja amit kell, es vege. De az allapottarto beaneknel ugyanahhoz a beanhez erkezi kmindig a keres, tehat lehetoseg van arra, hogy elozoleg eloallitott adatot taroljunk benne. Na ezt a mukodest tudja elosztottan az EE. Tehat az a magia, hogy a a memoriaban levo bean objektumot a benne tarolt allapottal kepesek JVM-ek egymas kozott szinkronban tartani, ami lassuk be egy hangyanyit bonyolultabb mint egy serializalt session filet szetterjeszteni a halozaton.

-
Big Data trendek 2016

Attól függ, hogy milyen memória adatbázisról beszélsz. Ha a memória centrikus rdbms-ről,az a mondás, hogy az rdbms architektúrájából adódóan nem skálázódik túl jól osztott kontextusban, pont a lényege, a joinok miatt, akkor sem ha ramban van, legfeljebb akkor gyorsan nem skálázódik jól... Ha viszont nosql, akkor a komolyabb osztott rendszerek (imdg) mint redis, hazelcast stb nagyon is alkalmasak a horizontális skálázásra jellegükből adódóan, de az egy más alkalmazásmodell. Kulcs-érték tár, mapreduce, ilyesmi. Annak persze semmi akadálya, hogy loaderekkel/writerekkel (javax.cache.integration.*) az alkalmazásaid és az rdbms közé read-through/write-through adatelérésre illesszél egy ilyen réteget. A servletek, filterek, SLSBk stb csakis ezt a nagyon gyors, osztott kulcs/érték tárat hivják majd a különféle entitásaik elkérésére és tárolására. A perzisztencia, a tárolási formátumok és felhasználási formátumok közti transzformálás a cache és a db ügye lesz. Érdekes, mert ha meggondolod, elvileg a perzisztencia sem feltétlen kell, hiszen az adat tartósságot az imdg cluster is biztositani tudná elvileg (replikálás).

"Tehat az a magia, hogy a a memoriaban levo bean objektumot a benne tarolt allapottal kepesek JVM-ek egymas kozott szinkronban tartani, ami lassuk be egy hangyanyit bonyolultabb mint egy serializalt session filet szetterjeszteni a halozaton."

Így van, bonyolultabb és nem igen skálázható. Arra azért felhívnám a figyelmedet, hogy én itt sehol sem azt mondom, hogy rossz a JEE (az egy másik dolog :), nálam csak az veri ki a biztosítékot, hogy a stateful, elosztott tranzakció jól skálázható. Se a stateful, se az elosztott tranzakció nem jól skálázható, se külön külön, főleg nem együtt!

"stateful, elosztott tranzakció jól skálázható" en ilyet nem olvastam. Nem arrol van szo, hogy "jol skalazhato". Persze hogy rohadt bonyolult a hatterben minden szinkronban tartani a gepek kozott, hibat kezelni, stb. Arrol, van szo, hogy a megtartott allapot bizonyos esetekben kissebb rendszerterhelest okoz, mint minden alkalommal eloallitani az adot minden gepen. De ez egy masfajta skalazodas, itt az alkalmazasodat tudod hozzaigazitani az alatta futo masinakra, tehat osszegeszeben jobb vagyis inkabb kiegyensulyozottabb lesz a teljesitmeny, mikozben egy egesz sor bonyolult dolgot egyetlen mozdulattal tudsz rollbackelni, es nem az alkalmazasban kell buveszkedni, hogy minden visszaalljon az eredetire.

-
Big Data trendek 2016

Koszi, hasznos info volt a singleton vs EJB, ugy latszik, tenyleg regen jartam Java EE kornyeken ;)

"nincs raktaron egy csomo unatkozo feljeszto" - eletem egyik fo celjakent tuztem ki az effajta gondolkodasmod elleni harcot - "van 5 darab egysegsugaru koltseghely, adjunk nekik munkat" vs kabathoz a gombot, nem forditva.

Tapasztalatbol mondom, hogy atlagosan ertelmes emberek szakertoi segitseggel 1-2 honap alatt _barmilyen_ nyelvet vagy eszkozt meg tudnak tanulni hasznalni, es onnantol mar tobbet szamit, hogy a celnak megfelelo eszkozt hasznaljak, nem mint ahogy te is emlitetted, mindenre mondjuk a Springet.

( uid_720 | 2016. 07. 05., k – 10:25 )

Ebből a topikból azt is leszűrtem, hogy a javásoknak nem kell ellenség :-D

Fuszenecker Róbert

Amíg szakmai alapokon van a vita, addig van értelme. Amikor valami régmúlt élmények alapján próbál valaki érvelni, az nem kicsit fura.

Egyébként annyi a különbség, hogy választható technológiák szempontjából a Java ökoszisztéma olyan, mint egy jó design pattern: van egy interfészed és arra vannak különféle implementációk, amelyek kismértékben eltérnek egymástól, de az interfészen át jól használhatóak, ha egy implementáció nem támogatott tovább, akkor minimális erőfeszítéssel át lehet térni egy másik implementációra.

A C# ökoszisztéma pedig olyan, hogy van egy darab implementáció mindenből, ha azt megszüntetik, akkor meg van szüntetve, volt Silverlight, nincs Silverlight: nem lehet áttérni se a Goldenflow, se a Pearlybrigth, se a Whiteglow implementációra, hanem marad a szopás és teljesen különböző technológiai stack felé lehet továbbmenni, az eddigi fejlesztés megy a kukába. Szerintem ennél még mindig jobb, ha szakmai vita van arról, hogy a Silverligth, a Goldenflow, a Pearlybrigth vagy a Whiteglow a jobb megoldás egy feladathoz... :)

Wow, I mean, wow, MVC 1.0 JSR! Wow! Visszafele forog az ido kereke :)

"Oracle is committed to Java and has a very well defined proposal for the next version of the Java EE specification – Java EE 8 – that will support developers as they seek to build new applications that are designed using micro-services on large-scale distributed computing and container-based environments on the Cloud," said Moeller.

Egyreszt ez 180 fokos fordulat az eddigiekhez kepest, masreszt valoszinu, hogy keszen lesznek vele fel ev alatt... ennek se fule, se farka.

( haspokember | 2016. 07. 08., p – 17:09 )

Ezt most talaltam HN-en:
https://techsticles.blogspot.co.uk/2016/07/oracle-and-fall-of-java-ee.h…

Erdekes megfigyeles:

Yes, even the tried and true banking and financial industries are moving away from Java EE. Every company has a different set of specifications for what parts they may use in a Java EE stack, but rest assured, its all going by their choice and being as small of a footprint as possible. When companies buy cloud images and the pricing is based on memory size and numbers of cores, it gets real easy to understand why they don’t want to run these stacks that require lots of resources for only needing to use less than 10% of what a Java EE stack may offer. It because it costs more to run crap that you will never use.