Felszabadítja a Java EE-t az Oracle

 ( Jason | 2017. augusztus 21., hétfő - 13:45 )

Mivel a Java EE kommuna működését nem találták elég rugalmasnak, átláthatónak és nyíltnak, az Oracle azt tervezi, hogy egy nyílt forrást kezelő alapítványnak átadja az írányítást.

További részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Az OpenOffice.orgnál is milyen jól bevált!

:D

:DDDD

OpenSSO -> ForgeAM
Hudson -> Jenkins
OpenSolaris -> Indiana
OpenOffice -> LibreOffice
... -> ...

Az utóbbi években is szinte csak a Red Hat vitte a Java EE ügyét előre a Wildfly kapcsán, a többiek mögötte kullogtak vagy csak a pénzt szedték be. Szóval kíváncsi vagyok, hogy az Oracle árnyéka nélkül merre megy tovább a Java EE.

+1

Az Apache licence-szel rendelkező szoftvert lehet-e forkolni és milyen licenc alatt lehet a forkot kiadni?
Mert a LibreOffice-ra forkolás még az Apache licence alá helyezés előtt történt.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

De a JEE egy specifikáció készletet, minek forkolnák, vagy hogy? Az OO egy konkrét szoftver volt.

Hogy haladjanak vele... :)

:D
Ott amúgy történik még valami?
--
"Sose a gép a hülye."

Szerintem jó ötlet.

nekem amit mostanában szemet ütött, hogy Mark Reinhold egész gyakran emlegeti, hogy éves/fél-éves Java SE kiadási ciklusokra állnának át.
érdekes dolgok jönnek mostanában, kíváncsi leszek az őszi JavaOne-ra...

(rejtett sub)
--
blogom

Amit én láttam eddig, ott csak a Java EE-ről volt szó. Furcsáltam is, hogy mi alapján fogják ezt szeletelni... JVM, Java SE... Tényleg mindent kiadnak a kezükből ilyen könnyen?! Bár tényleg jó lenne már valami előrelépés.

ennek nem sok köze van ez EE-hez, meg olyan utalás nem volt, hogy kiadnák a kezükből as SE-t, de pl.: http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-18

The first item has been mentioned by a few people from Oracle at a couple of JCP EC meetings, and discussed informally at recent developer conferences. The general idea is that the ecosystem would be better served by a more-rapid release cadence for Java SE and the JDK. Since the inception of Java, big features or a handful of big features have driven major releases every two to three years. This was reasonable in the 1990’s and 2000’s. Going forward, Java needs to move at a faster pace in order to remain competitive. People are therefore exploring the possibility of shifting to a yearly or even a six-month cycle. If a big feature is ready, it goes in; otherwise, it waits for the next release. There is no formal proposal at this time; however, discussion is expected in the JCP and OpenJDK communities in the next few months. It is relevant to these EG meetings because “LATER” may be sooner than expected. It could be twelve months after Java SE 9 GA, or even six months. This doesn’t mean that everything will occur in the next year, just that there are likely to be more opportunities for changes to be made.

csak érdekes látni, hogy az elmúlt néhány évnyi szenvedés után most valami mintha...
--
blogom

pláne, hogy ez a jigsaw eléggé elbaszott módon lett megcsinálva. remélem nem kerül be, mert szinte mindent elbaszna.

én még nem játszottam vele (lassan ideje lenne), szóval érdekelne a véleményed: miért?
--
blogom

Olyan modulrendszert vezet be, hogy mindent, de ténylegesen, MINDENT újra kéne fordítani és csomagolni úgy, hogy a module descriptorok belekerülnek + artifactorykat is matatni kell.
Ha ezt nem lépi meg mindenki (itt az összes létező Java developerre ÉS használóra gondolok), akkor párhuzamosan fenn kell tartani egy legacy és egy jigsaw repót MINDENHEZ, mert a legacy cuccokhoz csak legacy artifactokat, jigsaw-osokhoz meg csak jigsaw-osokat használhatsz majd. Ezt mindenre. Gondolj bele, Java fejlesztő vagy, DE kell egy máshogy konfigolt JRE is a gépedre, hogypl. abevjava-t is tudjál futtatni...
Ja, és a modulrendszer mindenben bénább, mint a meglevőek (pl. OSGi), DE nem kompatibilis velük.

* https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f
* https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns
* https://blog.codefx.org/java/dev/how-java-9-and-project-jigsaw-may-break-your-code/

(Pár hónapja találtam egy még olvasmányosabb és megindokoltabb fikázást is, de nem találom a historymban...)

Úgyhogy ezerrel irkálják át a jigsaw-t, gyak. havonta változik.

Hm... ha arra gondolok, hány helyen láttam már VCS-be becsekkolva függőségeket, pedig az osgi (vagy build időben függőség kezelést megoldó maven???) egy ideje a mindennapi technológiák közé tartozik.

Viszont a jlinkkel a nav programozói majd fordíthatnak olyan abevjava natív imageket, amilyen os-t támogatni akarnak, letöltöm, futtatom és kész. Nem kell javat telepítgetnem (csak ha már az abevjavat felhoztad, az előnyöket is próbáljam keresni).

Vagy ez nem arról szól...?
https://docs.oracle.com/javase/9/tools/jlink.htm#JSWOR-GUID-CECAC52B-CFEE-46CB-8166-F17A8E9280E9

> Vagy ez nem arról szól...?
de. nem hinném, hogy ez az elsődleges célja, de erre is tökjó lesz.
--
blogom

előszó: nem próbáltam még, tényleg. te?

Azért ez egy kicsit erős túlzás, amit mondasz, szerintem. A fenti három írásból kettőt olvastam már (meg a rájuk adott Oracle-s választ is). A codefx.org-osat nem, de az így kezd:

Since I wrote this post Project Jigsaw resulted in the Java Platform Module System and a lot of details changed. I explain all of them in my Java 9 migration guide, so you should read that one.

- A RedHat-et kicsit megértem - van egy megoldásuk, ami nem azonos a jövőben a Java által szállítottal, s nem is tudják azonossá tenni. A versenyelőnyük jelentős része megszűnik, fáj, ejnye.

- Az OSGi-s összehasonlítást nem teljesen értem. Kimondottan nem ugyanaz a célja jelenleg a Jigsawnak. Nem zárják ki, lehet egyszer az lesz, de...
A Jigsaw elsődleges célja (szerintem), hogy egy hatalmas technical debtet vegyen le a JRE fejlesztők válláról - s ne kelljen a jövőben különböző `sun.misc` csomagok API kompatibilitásán aggódniuk.

- Kétfelé elágazás:
1. Ami ment Java8-on (s nem használt olyat, amit kifejezetten nem kellene), az menjen Java9-en is
unnamed modul, automatic modules, etc. Csak a jpms-spec-experts listát böngésztem az elmúlt hónapokban, de nem nagyon vannak konkrét projektek bevágva oda, amik problémásak.
Cserébe Reinhold nem egy előadást tartott - igaz, kis projektekkel, meg felkészülve - ahol egészen egyszerűen ment az átállás.

2. Ami megy Java9-en, mennie kellene Java8-on is (ha a release stimmel)
A `module-info.class`t a pre-JVM9-es verziók leszarják, s minden a classpathen van.

- Az abevjava-ra pont ad egy megoldást a jlink, lásd fent. Nem mintha eddig nem lehetett volna statikusan hozzácsapni a JRE-t, amivel megy.
--
blogom

Én inkább félek tőle :) jobban mint az előző, security manifest-es elbaszástól.

Sajnos nem írta oda, mikor írta azt a megjegyzést...

"Kimondottan nem ugyanaz a célja jelenleg a Jigsawnak." De, pont azt akarják, miközben "nem". Nem vallják be? Vagy nem tudják, pontosan mit is akarnak? Ez baj.

Nyakunkon a Java9 release (2017. szeptember 17.!! nincs egy hónap se már), és még mindig nem tudni, mi a fasz lesz pontosan. Évek óta kész kéne lennie a specifikációnak, ehhez képest 2014 óta semmi érdemi fejlődés nem történt, csak újrafeltalálás meg elbaszás-bonyolítás. egyszerűbb lett volna annyit modnani, hogy: "Faszom, legyen az OSGi". (vagy bármelyik másik, rég KÉSZ megoldás, csak ennek rövid a neve xd)

Az elágazás 1) azt jelenti, nincs jigsaw. Akkor minek?
Az elágazás 2) meg azt jelenti, hogy az újabb Java8 jvm release-ek ismerni fogják a java9-es cuccokat, csak leszarják a module-infot? Akkor ez megint egy java9 csak jigsaw nélkül.

Szted a navos programozók _képesek_ lesznek egy ilyenre? Ami bénázást levágtak az elmúlt évtizedben, kétlem.

> De, pont azt akarják, miközben "nem". Nem vallják be? Vagy nem tudják, pontosan mit is akarnak?
Szerintem nem, de nem találom, hol írtak ilyet. A Jigsaw a platformot modularizálja. Ebből a library fejlesztők nyernek még. Én, mint alkalmazás fejlesztő, nem sokat, sőt. Nehezebben fogok belenyúlni a használt libek (belső) dolgaiba. Az OSGi ezzel szemben - legjobb tudomásom szerint, de itt már eléggé el vagyok veszve - az alkalmazás fejlesztőknek ad jónéhány eszközt.

> Az elágazás 1) azt jelenti, nincs jigsaw. Akkor minek?
> Az elágazás 2) meg azt jelenti, hogy az újabb Java8 jvm release-ek ismerni fogják a java9-es cuccokat, csak leszarják a module-infot? Akkor ez megint egy java9 csak jigsaw nélkül.

Nem.

Az 1) azt jelenti, hogy a régi dolgok működnek, probléma nélkül. Továbbra is mondhassa azt a Java, hogyha van egy ~25 éve lefordított magic.jar-od, az megy - s ha nincs meg a forrása, nem tudod újrafordítani, etc., az se legyen gond. DE: Mostantól tudnak a JRE-be olyan dolgokat fejleszteni, amire __biztosan__ nem épít senki, s nem jut az Unsafe sorsára...

A 2) meg, szerintem ez most is megvan. A `module-info` egy nem valid identifier, s így valszeg soha, semmi nem akarja betölteni a pre-java9-es JVM-en.
A JVM9 meg tudja, hogy létezhet egy ilyen speciális fájl (sőt, a modulepathen szerintem léteznie kell, a classpathen pedig továbbra is nem valid identifier), így figyelembe veszi.

tldr: eléggé elvittük offba ezt az egészet (sry). Amennyire én látom, egyre többen kezdik támogatni. De egyelőre minden restriction teljesen ki lesz kapcsolva, szóval hogyha tényleg nagyon problémás lesz ez az egész, még az is lehet, hogy dobja az Oracle később.
--
blogom

Meglátjuk, ahogy a vak is mondta :)

Inkább temessék el, jobban jár mindenki.

--
arch,debian,retropie,osmc,android,windows

Mert?

Vannak sikeres részei (pl. JPA) de nagyobbrészt haszontalan és bonyolult (főleg az appszerverek, az EJB és CDI, meg a társai).

--
arch,debian,retropie,osmc,android,windows

Ez gondolom még akkori emlék, amikor J2EE volt a neve, nem?

Éppen weblogicos, EJB-s, CDI-os projektet reszelek egy nagy bankban, és nem, the pain is real. Az előző ~2 éves szintén banki projektünk során ~10 darab spring-bootos háttérrendszert szállítottunk le dockerrel, "kicsit" jobb volt.

szerk.: java8 és javaee7.

--
arch,debian,retropie,osmc,android,windows

Szóval nagyjából stimmel. Próbálj ugyanígy 10-15 éves Spring-et használni, rájössz, mi az a pain-in-the-ass... :)

Engem nem érdekel milyen volt 15 éve a spring, ha most jó, akkor jó.

--
arch,debian,retropie,osmc,android,windows

Mondjuk úgy, bizonyos feladatra jó. Bizonyos feladatra meg van jobb.

Így van... van, amire JavaEE projekttel indulok neki és van, amire nem... ilyen az, amikor a feladat határozza meg az eszközt és nem az eszközhöz igazítjuk a feladatot. :)

Ha viszont Java8 és EE7, akkor valamit rosszul csinálsz... tippre azt, hogy Spring-ben gondolkodsz és JavaEE környezetben dolgozol.

Maga a kód annyira nem rossz, a problémáim ~90%a a runtime-al kapcsolatos vagy abban áll. (weblogic).

--
arch,debian,retropie,osmc,android,windows

Akkor most mi is a baj? A rosszul megválasztott konténert varrjuk a JavaEE nyakába? :)

A weblogic helyén tetszőleges konténer lehet. Felesleges plusz.

--
arch,debian,retropie,osmc,android,windows

Miért is felesleges plusz? Sok eset van, amikor hasznos a konténer. Sok eset van, amikor hasznos, hogy külön van az alkalmazás önmagában. A baj akkor van, amikor van egy kalapácsod és mindent szögnek nézel...

A szögnek nézős hasonlatot bármelyik oldal magára veheti :) De amúgy szívesen tanulok újat, légyszi mondj egy esetet amikor muszáj konténert használni (weblogic, jboss (egyik jobb mint a másik....), tomee, nekem nyolc) és a spring-boot féle single jar megoldás nem jó.

--
arch,debian,retropie,osmc,android,windows

Például több erőforrást érintő XA tranzakcióval horizontálisan kell skálázódnod...

Ezt egy picit konkretizálod, kifejted, ha megkérlek?

Több erőforrás = több DB (pl) ?
xa tranzakció = distributed transaction = two phase commit?

a horizontálist értjük = több node (számítógép :)

ha igen, akkor ez miért nem működik spring-boottal és miért feltétlenül kell ehhez konténer és amúgy nem valami kerülendő antipattern az egész amiről beszélünk?

--
arch,debian,retropie,osmc,android,windows

Erőforrás: DB, Queue, másik alkalmazás, bármi

"ha igen, akkor ez miért nem működik spring-boottal és miért feltétlenül kell ehhez konténer és amúgy nem valami kerülendő antipattern az egész amiről beszélünk?"

Mutathatnál egy példát, ahol XA tranzakcióban meghívsz egy másik Spring-boot alkalmazást...

Amíg nem fejted ki jobban hogy miről van szó, nem tudok válaszolni. Amint látod, nem csináltam még ilyet.

Most azon gondolkozom, hogy hiányos-e az eddigi életutam és az én hiányosságom, vagy azért nem találkoztam ilyennel mert amúgy jobb így nekem, mert valami antipattern amit az EE-sek csinálnak. Légyszi tegyél rendet :)

--
arch,debian,retropie,osmc,android,windows

Anno volt egy nagyon-nagyon hosszú java fikázós thread, ahol valaki nagyon szépen és hosszan leírta azt, hogy mivel több/másabb a JEE mint a Spring.

[megtaláltam]

https://hup.hu/node/148260

"Amíg nem fejted ki jobban hogy miről van szó, nem tudok válaszolni. Amint látod, nem csináltam még ilyet."

"A" alkalmazás módosít egy adatbázis mezőt és áthív "B" alkalmazásba; "B" alkalmazás beletesz egy queue-ba egy üzenetet és áthív egy "C" alkalmazásba; "C" alkalmazás csinál valahol valamit. Ha bármelyik hívás sikertelen, akkor vissza kell vonnod mindent, amit eddig csináltál és az "A" alkalmazás hívója értesül, hogy a tranzakció sikertelen.

"Most azon gondolkozom, hogy hiányos-e az eddigi életutam és az én hiányosságom, vagy azért nem találkoztam ilyennel mert amúgy jobb így nekem, mert valami antipattern amit az EE-sek csinálnak. Légyszi tegyél rendet :)"

Általában azt látom, hogy ez egy hatalmas fehér folt sok fejlesztőnél. És mivel nem tudnak róla, ezért nem is hiányzik nekik, ha pedig mégis kellene ilyen, akkor körbetákolják valami saját implementációval, amiből már láttam igen hajmeresztőeket is.

Én még nem találkoztam ilyesmivel. Általában egy alkalmazás csinál 1..n dolgot és ha valamelyik sikerül, akkor az addigiakat rollbackeli, a hívónak meg mond egy errort. De köszi, meg a linket is a kollegának, el fogom olvasni.

--
arch,debian,retropie,osmc,android,windows

Így már nem is csodálom, hogy nem érted meg a JavaEE szisztémát... :/

pedig architekturálisan átláthatatlan elb@szott giga-rendszereknél az ilyesmi -szinte- mindennapos :D.
*sóhaj*

Szóval az architekturálisan elbaszott rendszerekre alkalmas a Java EE. :)

--
arch,debian,retropie,osmc,android,windows

Nem, a következőt nevezzük architekturálisan elbaszott rendszernek: "Általában egy alkalmazás csinál 1..n dolgot és ha valamelyik sikerül, akkor az addigiakat rollbackeli, a hívónak meg mond egy errort."

A tranzakciók nem lehetnek antipatternek. Ahol csak lehet, kerülni kell az elosztott tranzakciókat, de nem feltétlenül lehet ezt megoldani. Ha egyszerűbb az use case, akkor oké.

(Ahogy az ACID is lehet fölösleges komplikáció, de csomoszor meg hasznos...)

----------------------
while (!sleep) sheep++;

Architekturális antipatternek is léteznek ám :)

--
arch,debian,retropie,osmc,android,windows

Leteznek, de az elosztott tranzakcio nem tartozik kozejuk, es azt meg, hogy milyen tipusu eroforrast hasznal a tranzakcio egyik eleme, azt hagy valasszak meg a feladathoz.

-
Go konkurencia kezelés gyorstalpaló

Egyszerű algoritmusod van, hallod-e:
1, Google
2, Félig elolvasott szakállas blogbejegyzés of random dude

Ha egy szalon futtatsz valamit, akkor a rendszered valaszideje a feladatok resz idejenk osszegevel egyezik meg, ha pedig parhuzamositod, akkor a leghosszabb futasidovel (leegyszerusitve). Van sok eset, amikor 1) szamit a valaszido 2) vagy mindennek meg kell tortenni vagy semminek. Persze az alkalmazas logikadat is bonyolithatod, hogy hiba turo legyen. Hamar a ket generalis problemajaba utkozol, es implementalhatsz magadnak egy hibaturo protokollt, ami valamifele konszenzussal garantalja azt, hogy a rollback mindenhol meghivodik. Mi tortenik akkor, amikor nem vlaszol a service, ami a rollbacket csinalta? Ahhoz, hogy masik node is atvehesse a kerest idempotensnek kell lennie a muveletnek, nem lehet, hogy elszall az egesz, mert mar nincs meg az adat, amit torolni szeretne. Es addig az alkalmazas all, amig nem lesz elerheto a service es ujra probalja? Vagy timeoutol? De akkor vegkepp nem tudjuk majd, hogy sikerult-e a rollback vagy sem. Akkor kell valami queue, es majd valaki feldolgozza, de varj a queuebol is elosztott meg perzisztens kell. Ok, de hogyan garantaljuk az "exactly once executiont"? Mi tortenik abban az idoben, amig nem sikerul a rollback, hogyan lesz az alkalmazas konzisztens? Csupa csupa olyan kerdes, amire nincs egyszeru valasz. Jah de, beleteszem egy tranzakcioba oket, es amig nincs konszenzus a kommitrol, addig rollback az alapertelmezett muvelet.

-
Go konkurencia kezelés gyorstalpaló

A törlés mondjuk pont idempotens művelet.

Es az update? En torlest irtam, de az akar update is lehet.

-
Go konkurencia kezelés gyorstalpaló

Az elosztott tranzakció esetén sem varázslattal áramlik az információ a node-ok között.
A végrehajtandó tranzakció utasítások is hálózaton mennek, a sikerességükről az információk visszafelé is, majd a rollback, commit információk szintén.
Pontosan ugyanezek a problémák, amiket felsoroltál ott is megvannak.
A fő különbség az, hogy a tranzakció esetén az adatbázisnak az érintett része fagyasztva van addig, amíg commit vagy rollback nem történik, hogy vissza lehessen állítani a kiinduló állapotot.
Míg pl. Saga esetén nincs fagyasztva, mert ott nem az eredetit állítják vissza, hanem az aktuálisat kompenzálják.

Csak két példa a különbségre:
1. Egy adat egy helyen 10, tranzakcióval átállítjuk 12-re, majd rollback esetén vissza 10-re. A tranzakció végéig a 10 nem változhat. Saga esetén nem 12-re írjuk, hanem hozzáadunk 2-őt, utána az érték változhat, ha közben 8 lett, akkor "rollback" esetén a kompenzáció kivon 2-őt és 6 lesz az érték.

2. Tranzakcióban emailt kellene küldeni. Itt azért nem egyszerű megoldani, hogy ténylegesen ne legyen elküldve, de az esetleges hibák (pl. címzett ismeretlen) már a tranzakció alatt kiderüljön, ha emiatt kellene visszavonni az egészet. Saga esetén kiküldik az emailt, majd "rollback" esetén pl. küldenek egy helyesbítő emailt.

Igen, ez nagyon szépen hangzik, csak nem mindent tudsz kompenzálni nyom nélkül, sőt, tulajdonképpen elég kevés dolgot tudsz kompenzálni ilyen egyszerűen, mert a világ ennél bonyolultabb.

Vicces, hogy szerintem nincs fel eve, hogy ugyanezeken atragtuk magunkat, meg az is lehet, hogy a resztvevok is pont ugyanazok, mint anno :D

-
Go konkurencia kezelés gyorstalpaló

unalmas is ez megint

pedig szerintem nagyon sokat lehet a topicból tanulni

...csak aztán könnyű elfelejteni... :D

Műkedvelőként hasznos lehet egy ilyen vitát olvasni, de aki belefut ilyen problémákba a való életben - remélem hogy nem innen tájékozódik és hoz döntést első sorban. :)

"varázslattal áramlik az információ a node-ok között"
persze, csak nekem kell implementalni, meg kitalalni, nem az alkalmazas logikat terhelem

"A fő különbség az, hogy a tranzakció esetén az adatbázisnak az érintett része fagyasztva van addig, amíg commit vagy rollback nem történik, hogy vissza lehessen állítani a kiinduló állapotot."
hat ez azert oriasi kulombseg

"hanem az aktuálisat kompenzálják"
pontosan, es azt eredmenyezi, hogy letezik olyan idopillanat, amikor az adathalmaz inkonzisztens allapotban van. A ugyfel utal B-nek, megjelenik a penz a szamlajan, B elkolti azon nyomban, azt aztan rollbackelheted, ha A-nak megsem volt annyi penze (szar pelda).

Amikor elkuldod a requestet, hogy +2, de nem erkezik valasz. Akkor mit teszel? kuldesz meg egy plusz 2-t? Vagy kuldesz egy -2-t? Ha plusz kettot kuldesz, es egy masik node-ra esik, akkor o is hozzaadhatja, ha minusz kettot kuldesz, meg lehet, hogy hozza sem lett adva. Valahogy alkalmazas logikaval garantalod az exactly-once-t, beleteszel valami azonositot. De ennek az azonositonak service wide elerhetonek kell lennie. Ott vagy ahol a part szakad, vagy tranzakcioba szurod be az event azonositot, es hajtod vegre a muveletet (ami szinten lehet egy remote service call), vagy valami trukkel (alkalmazas logikaval) garantalod, hogy pontosan tudd melyik eventek mentek vegig, es melyikek nem. Mindez csak fokozodik, ha nem 2 service beszelget, hanem mondjuk 3-4 servicera is rahivsz, ami tovabb hiv mas servicekbe. Ha ket lepesben tortenik az update meg a rollback (helyesbites what ever), mindig fennall a lehetosege, hogy valami elromlik. Mert ami elromolhat az el is romlik :)

A tranzakcio egy atomi muvelet in high level, ezt nem tudod semmi massal kivaltani. Akkor megy tovabb az alkalmazas, ha mindenki nyugtazott mindent. A kerdes mindig az adatbazisban lehetseges hiba mennyisege, es a teljesitmeny.

-
Go konkurencia kezelés gyorstalpaló

+1

ilyenkor a horizontális skálázódás hogy néz ki? a request beesik valamelyik node-ra, ott elkezd egy tranzakciót, aztán én számolok sokat.
a számolás egy része „áteshet” ilyenkor másik node-ra? tranzakcióstul, mindenestül?
mennyire hatékony egy ilyen skálázódás? 2/3/4 node-nál mekkora jelentőségű a node-ok közötti szinkronizáció?

lehet hülye kérdések, sry, sosem volt még ilyenhez szerencsém.
ha szeretnék ilyennel játszani, hogy érdemes nekikezdeni?
--
blogom

Igen, így. Nem túl hatékony, de vannak esetek, amikor nem tudod kikerülni. Ha játszani akarsz, akkor Wildfly 11Beta1 és játszol remote EJB hívásokkal több node-os környezetben.

ty!

miért nem tudsz ilyenkor egy loadbalancert rakni az egész elé, s az egész request feldolgozást egy node-on belül tartani?
egy requestre (erre mi a jó szó? ez?) adott válasz már akkora, hogy nem tudja egy node kiszolgálni?
--
blogom

Mert attól nem lesz tranzakcióban, ha load-balancer van előtte, másrészt például más jellegű terhelést más JVM paraméterekkel más node-számmal akarsz skálázni, harmadrészt nem akarod keverni a szolgáltatásokat, mert mondjuk másik terület dolga a cégnél és nem akarod egybecsomagolni a fél univerzumot, csak azért, hogy működjön.

Akárhogy is próbálom rágni a dolgokat, amikor az appom áthív egy másik appba, és az sikertelen, nekem pofonegyszerű nem végrehajtani vagy visszavonni a saját műveletemet, és hibát adni az engem hívót, hogy ugyanezt megtegye. De lehet hogy túlegyszerűsítem a dolgot.

--
arch,debian,retropie,osmc,android,windows

És ha két alkalmazást hívsz, abból az egyik megförmed, akkor hogy értesíted a harmadik alkalmazást és hogy éred el, hogy ő is vonjon vissza mindent?

ami triviális probléma, hogyha nem kapsz választ. akkor a túloldal sikeres volt, vagy sem? Ott volt commit?
vagy van egy

 A |
   |-B
   |-C

felállásod, ahol A hívja B-t, majd C-t, külön nodeon. Itt ugye egészen addig nem szabadna commitot mondanod B-re, se C-re, amíg mindenki commitot nem akar mondani.

nyilván, megoldható (a 2PC is megcsinálta), csak kézzel én biztos nem állnék neki ilyet írni.

hogy mikor kell ilyen, arra a nem akarod keverni a szolgáltatásokat számomra már elfogadható, el tudok képzelni rosszabb felállást is...
--
blogom

Csak éppen mondjuk megoldhatod azt, hogy elindítasz egy Narayana-t, és azzal menedzseled a tranzakciót.
A Narayana-t használja a Wildfly is.
Szép is lenne, hogy amit meg lehet oldani Java EE-ben, azt ne lehessen megoldani nélküle, a Java EE komponenseiből.
Mint ahogy message queue-t is telepíthetsz külön, ha kell neked az a funkcionalitás.

Az egész Java EE vs. Spring és társai történet inkább arról szól, hogy ha éppen mondjuk a JavaEE alkalmazásszervered egyik komponense bugos, akkor nem tudod csak azt lecserélni.
Szar a servlet container, szar a JTA implementáció, szar a JMS implementáció valami miatt - és kötve vagy hozzá, mert az alkalmazásszerver csak azt az implementációt használja.
Viszont ha szépen decoupled rendszert használsz, amiben te mondod meg, hogy melyik szolgáltatás mivel van implementálva, és ha kell, ki tudod cserélni az egyiket a másikra, akkor sokkal jobban kontroll alatt vagy.
Míg a másik esetben nincs más lehetőséged, mint a komplett alkalmazásszervert lecserélni.

Erről szól ez az egész. Monolitikus felépítésű szolgáltatások vs. moduláris.

"Csak éppen mondjuk megoldhatod azt, hogy elindítasz egy Narayana-t, és azzal menedzseled a tranzakciót. A Narayana-t használja a Wildfly is. Szép is lenne, hogy amit meg lehet oldani Java EE-ben, azt ne lehessen megoldani nélküle, a Java EE komponenseiből."

Aztán pont ott vagy, mint a JavaEE esetén, csak évekig tart összereszelni az egészet, illetve fél-egy évig tart betanítani valakit arra, hogy mi merre hány méter... és hogy kell használni a sok custom tákolást és az egymással interferáló 3rd party halmot. És máris ott tartunk, hogy etetjük a saját keretrendszert senior emberhónapokkal, hogy egyáltalán alkalmas legyen a feladatára.

"Az egész Java EE vs. Spring és társai történet inkább arról szól, hogy ha éppen mondjuk a JavaEE alkalmazásszervered egyik komponense bugos, akkor nem tudod csak azt lecserélni."

Ha bugos, ki kell javítani vagy javíttatni... nem olyan nehéz dolog.

"Szar a servlet container, szar a JTA implementáció, szar a JMS implementáció valami miatt - és kötve vagy hozzá, mert az alkalmazásszerver csak azt az implementációt használja."

Elméletben. Gyakorlatilag senki nem fogja lecserélni egy értett és szagos Spring spagetti alatt lévő egyik ilyen komponenst sem, mert egyrészt senkinek halvány fogalma nincs arról, hogy bárki használt-e az adott implementációból valami vendor függő dolgot, másrészt nincs akkora nagy választék. :)

"Míg a másik esetben nincs más lehetőséged, mint a komplett alkalmazásszervert lecserélni.
Erről szól ez az egész. Monolitikus felépítésű szolgáltatások vs. moduláris.
"

Nekem erről nem szólt senki és cseréltem, sőt, patcheltem javaee-ben implementációkat (eclipselink-et, ironjacamart, undertow-t, jboss loggingot... kit tudja még mit) :D

Es el is érkeztünk oda, hogy valaki azt gondolja, hogy majd ő megírja az elosztott tranzakciókezelest. Bamm, be is dőlt a projekt.

Persze ahogy lentebb is írják, lehet használni a komponenseket külön is (pl. a Narayana-t). Kérdés, hogy az egyszerűbb-e.

----------------------
while (!sleep) sheep++;

"De lehet hogy túlegyszerűsítem a dolgot" pl nem veszed szamitasba, hogy a hivasi lanc nem csak linealis lehet, es lehet, hogy X megdoglik, mikozben Y meg vigan csinalja a dolgat. Ezuton, akkor Y-t is ertesiteni kell, hogy fejezze abba.

-
Go konkurencia kezelés gyorstalpaló

köszönöm, emésztem.
--
blogom

gondolj arra az egyszerű példára, hogy megrendel egy terméket (raktár) amiről számla készül (számlázás). Ennek a kettőnek együtt kell megtörténni,
mert különben nem "érvényes" a vásárlás. Mindkettő külön rendszerben van, a felhasználó szempontjából mégis "egyben" kell kezelni.

Ez egyébként pont rossz példa. Egy teljesítéshez több számla is lehet. Ezek különböző időpontokban jöhetnek létre. (Sztornó, helyesbítő stb.) Van előre- és utólag számlázás, és van előleg- és végszámlázás. Ezeknek általában pont nem kell együtt történni, és a vevő pont a számla kiállítás után fogja észrevenni hogy el van írva a neve vagy a címe.

ez a része megvolt, köszönöm :-)
a külön JVM paraméteres dolgot akartam helyre rakni magamban, de azóta azt is sikerült.
--
blogom

Az mondjuk annyit jelent, hogy külön JVM-be teszed a memória intenzív és a CPU intenzív szolgáltatásokat, így külön tudod paraméterezni a két JVM-et, hogy az egyik agresszíven optimalizáljon CPU-ra, a másik meg agresszíven optimalizáljon memóriára és GC-re... viszont a JavaEE megoldja, hogy ez a kettő így is tud egy tranzakcióban futni, nem kell törődnöd ezekkel a dolgokkal.

igen, idővel összeraktam, hogy a két szolgáltatást valszeg nem csak csapat/felelős mentén tudod felbontani, ha esetleg másképp akarod...
(vilmos kicsit lassú volt, sry)

szerk.: mármint nyilván ezt mondtátok az elején is, csak magamtól nem jutott volna eszembe.
meg a mondat elolvasása után se egyből..
--
blogom

Nem értem sokaknak mi a bajuk az alkalmazás szerverekkel és a containerrel. Olyan dolgokat old meg a szabványos fix API-val, amikkel te biztosan nem akarsz vagy tudsz foglalkozni, de általában találkozol vele később. Gyárilag meg van oldva a modularizáció (jar, war, ear), az auto discovery akár clusteres környezetben, dinamikus deploy futó szerverbe, distributed tranzakciók, singleton-ok, distributed cache, messaging stb., és +1x mindez alapjaiban fix szabványos API-val, ami alatt cserélhető az implementáció, bár nyilván mindegyik kicsit eltér.

Nekem éppen a spring boot-tól, meg a dockertől áll fel a szőr a hátamon (értem, hogy mostanában divat). Volt olyan nagy nemzetközi projekt ahol a német architekt bele volt szerelmesedve a spring boot-ba meg a microservice-ekbe, minden egyszerű alap REST-es service-t külön spring boot-os containerbe pakolt. Aztán az egészet ki kellett egészíteni olyan szolgáltatásokkal, librarykkel (auto discovery, routing, load balancing, monitoring) amik egyenként megfeleltethetők voltak a JavaEE stack belső szolgáltatásainak, amiket az alkalmazás szerver biztosít. Mindez http(s) fölött, baromi körülményesen és lassan. Ahhoz, hogy az alkalmazás elinduljon mondjuk egy fejlesztői gépen (8-12 spring boot service), kevés volt a 16GB Ram a gépekbe.

Kérdések:
Miért is kell minden spring boot service-nek önálló környezetet, saját web servert, jpa-t stb. indítani, mikor az érdemi alkalmazás egyébként pár kilobyte bytekód? Szerintem ez pazarlás, ráadásul ezek között a modulok között a kommunikáció (rest, http, https) sokkal lassabb mint egy bináris (akár udp) belső szinkronizációs protokoll.

Miért kell minden szerver komponenst beágyazni a saját alkalmazásba ráadásul saját spring boot-os configgal elfedni az adott modul configját? Elvileg ettől csereszabatos lesz pl. a web szerver, de próbálj meg egy exotikus szerver paramétert megfelelően beállítani.

A docker meg szintén megér egy misét, érdemes végigolvasni: https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/

Ennek ellenére nem mondom, hogy JavaEE az üdvözítő út, de a spring boot biztosan nem az.

Azért a szabványos API köhög néha, emlékszem, még egy primitív tesztkód (EJB, JSF, meg némi JPA és message) migrálása Glassfishről JBossra (még úgy hívták) se volt zökkenőmentes (tipikusan az alkalmazás nem hordta magával a konfigot, az nem volt szabvány), meg emlékeim szerint a JAAS sem a legkulturáltabb történet.

De ez rég volt már, az is igaz (JEE 7 akkortájt jelent meg).

Persze, plusz ha az API ugyanaz is, az implementációs eltérések (pl.: hibernate vs. eclipselink) is be tudnak kavarni. De legalább van miből választani.

Éppen egy nagy bankban verjük be a huszon sokadik alkalmazásmodult, weblogicba, java8, legutolsó weblogic, legutolsó EE specifikáció, és hogy-hogynem, természetesen totál vendor lockos az egész.
Esélytelen weblogic nélkül futtatni. Ezért (is) mondom, hogy az egész inkább kontraproduktív..

--
arch,debian,retropie,osmc,android,windows

Mutathatnál néhány ilyen vendor lock-in példát, megmondom, miért faszság. Oké? :)

Az egész alkalmazásszerver-specifikus leírók azok.

Pl. EJB clustering:
a deployment descriptorba alkalmazásszerver-specifikusan írható csak le, hogy mely beanek azok, amelyeket HA EJB-ként akarod deplyolni.

Vagy persze Wildfly esetén használhatod a @Clustered Wildfly-specifikus annotációd a kódban.
Ez utóbbi eléggé rossz, nem pakolhatod csak úgy át egy-az-egyben a kódodat más alkalmazásszerverre az utóbbi esetben.

Az előbbi esetben meg szépen alkalmazásszerver specifikus leírókat kell csinálnod a projektedhez, azaz tudnod kell fejlesztéskor, hogy deploymentkor mire fogsz deployolni.
Ez probléma.

Az EJB az mindig HA EJB, nem kell semmi hozzá. A @Singleton meg mindig node singleton. Ha cluster singleton kell, ott valami el van toszva a tervezésnél vagy az implementációnál, antipattern és a feladat függvényében sok egyéb megoldás van a problémára.

tranzakció timeout-ot tudok állítani szabványos módon?
--
blogom

A konténer által menedzselt tranzakciók esetén a konténer határozza meg, a konténerben pedig az üzemeltetés. Van olyan konténer, ahol ezt nagyon aprólékosan tudod állítani és van olyan, amelyiknél erre nincs igazán lehetőséged. A véleményem az, hogy ha a normál pár másodpercbe nem fér bele a tranzakció, akkor ott aszinkronná kell tenni a folyamatot, mert a timeout növelése a végtelenségig csak workaround a problémára és nem megoldás.

Ha a konténer által biztosított lehetőségek nem megfelelőek, akkor jöhet az user managed transaction, de ezzel is csínján kell bánni, mert ha az embert elkapja a gépszíj, akkor teletűzdeli finomhangolt timeout definíciókkal a forrását, amivel aztán valamikor később szívni fog.

Szóval röviden: a timeout állítgatása rossz dolog, nem megoldás, hanem szőnyeg alá söprés.

> A konténer által menedzselt tranzakciók esetén a konténer határozza meg, a konténerben pedig az üzemeltetés.
ez valaha elsült jól? fiatal csipszar vagyok, elismerem, de ez erősen átdobom a kerítésen, azt oldjátok meg szagú.

> A véleményem az, hogy ha a normál pár másodpercbe nem fér bele a tranzakció, akkor ott aszinkronná kell tenni a folyamatot, mert a timeout növelése a végtelenségig csak workaround a problémára és nem megoldás.
eddig tipikusan olyankor akartam timeoutot növelni, amikor DB-re vártam, s nálam okosabb emberek sem nagyon tudták gyorsabbá tenni. és többnyire ez üzleti szempontból elfogadható volt. nem akarok kézzel tranzakciót managelni, arra van a JTA.

még csak fix időt sem akarok mondani, nekem elég, ha azt mondom, hogy az `A.a` 3 krumpli-ig, míg a `B.b` 7 krumpliig futhat - oszt' az üzemeltetés majd bejátssza, hogy 1 krumpli milyen értéket vegyen fel, hogy ne is legyen túl sok, se túl kevés.
--
blogom

"ez valaha elsült jól? fiatal csipszar vagyok, elismerem, de ez erősen átdobom a kerítésen, azt oldjátok meg szagú."

Mitől lenne a fejlesztésnek köze ahhoz, hogy az üzemeltetés mennyi erőforrást ad egy-egy rendszer alá? Ez alapvetően üzleti és üzemeltetői kompetencia, a fejlesztésnek az a dolga, hogy bizonyos keretek között optimális algoritmust alkosson a probléma megoldására.

"eddig tipikusan olyankor akartam timeoutot növelni, amikor DB-re vártam, s nálam okosabb emberek sem nagyon tudták gyorsabbá tenni."

Nem feltétlen kell gyorsabbá tenni... át kell gondolni az algoritmust, a folyamatot, az adatszerkezetet, a tranzakció demarkációs vonalait, izolációs szinteket, a szinkron és aszinkron lehetőségeket és az adott dolog üzleti szükségességét. Nagyon sok lehetőség van, a timeout növelése viszont csak tüneti kezelés a problémára, sajnos utána mindenki hátradől a következő alkalomig, amikor ismét lehet emelni a timeout értékét, amíg az ember el nem jut a falig.

"és többnyire ez üzleti szempontból elfogadható volt. nem akarok kézzel tranzakciót managelni, arra van a JTA."

Nem kell kézzel menedzselni a tranzakciót...

"még csak fix időt sem akarok mondani, nekem elég, ha azt mondom, hogy az `A.a` 3 krumpli-ig, míg a `B.b` 7 krumpliig futhat"

És mi van akkor, ha a B rendszer alatt az adatbázis memory based lesz SSD-n és hirtelen 1 krumpli elég a futtatásához? Fordítod újra az alkalmazást, csak mert változott egy rendszer egyik alrendszerének egy komponense? Mi van akkor, ha az A rendszer válasza előre tervezett batch miatt időnként 20 krumpli ideig fog tartani?

Sokan nem értik a microservice-ek lényegét, nem ismerik az előnyeiket (a hátrányaikat általában ismerik :).

Akik nem ismerik a microservice-ek előnyeit, azoknak tudom ajánlani ezt a cikket és ezt a diasorozatot.

A monolitikus felépítésnek és a microservice-es felépítésnek is megvannak a maga előnyei, hátrányai. Ezek figyelembevételével kell egy-egy rendszert megtervezni. Egyik sem jobb a másiknál minden körülmények között!

Aztán az egészet ki kellett egészíteni olyan szolgáltatásokkal, librarykkel (auto discovery, routing, load balancing, monitoring) amik egyenként megfeleltethetők voltak a JavaEE stack belső szolgáltatásainak

Így van, ez pl. az egyik hátránya a microservice-es rendszereknek, hogy ezekre nagy szükség van, és ezek biztosítása, automatikus működése nagy feladatot jelent mindjárt induláskor. Azonban ezek az eszközök is egyre inkább kezdenek kiforrni és egyre több kész eszközt lehet ezekre használni, pl. Kubernetes, Docker.

Ahhoz, hogy az alkalmazás elinduljon mondjuk egy fejlesztői gépen (8-12 spring boot service), kevés volt a 16GB Ram a gépekbe.

Itt valami el lehetett esetleg rontva, mert a microservice-eknek pont az az egyik lényege, hogy nagyon kicsik és egy fejlesztői gépen is azért pár tucatot el lehet indítani belőlük.
Több lehetséges felépítése lehet a microservice-eknek, pl. van ahol egymást hívják, ezeknél fontos a függőségkezelés is; van ahol MessageQueue-kon (MQ) kommunikálnak egymással. Ez utóbbi azért is jobb sok esetben, mert önállóan fejlesztheted, tesztelheted, használhatod a microservice-eket.
Épp ez az egyik előnye a microservice-es rendszernek, hogy nem kell egy hatalmas alkalmazásnak elférnie a fejlesztői gépen, elegendő csak a fejlesztés alatt álló microservice-nek (esetleg egy pár függőségének).

Miért is kell minden spring boot service-nek önálló környezetet, saját web servert, jpa-t stb. indítani, mikor az érdemi alkalmazás egyébként pár kilobyte bytekód? Szerintem ez pazarlás, ráadásul ezek között a modulok között a kommunikáció (rest, http, https) sokkal lassabb mint egy bináris (akár udp) belső szinkronizációs protokoll.

Így van, ez pazarlás, de egyrészt ettől lesz a rendszer horizontálisan, funkciónként (microservice) skálázható, hibatűrő.
Másrészt egy jól elkészített microservice-es rendszernél a kommunikációs közeget könnyen cserélhetőre szokás elkészíteni, amivel a http-s kommunikáció helyett akár egyszerű függvény hívás is szerepelhet, sőt akár több microservice futhat egy monolitikus alkalmazásként is. Ez nagyon jól jön tesztelésnél és fejlesztésnél.

"Sokan nem értik a microservice-ek lényegét, nem ismerik az előnyeiket (a hátrányaikat általában ismerik :)."

Meglepne, ha azt mondanám, hogy lehet JavaEE alapokon microservice architektúrát létrehozni? A JavaEE minden, csak nem monolitikus... :)

Csomagoljunk be ~10 darab weblogicot, darabonként 1-1 EE-s alkalmazással, dockerbe. :))

--
arch,debian,retropie,osmc,android,windows

Segítek: nem kell becsomagolni 10 darab JavaEE alkalmazásszervert egy-egy JavaEE alkalmazással Docker-be (amit amúgy már nem így hívnak), mert maga a JavaEE alkalmazás egy önálló konténer, amit az alkalmazásszerver futtat és menedzsel. Ha ezt bele akarod tenni egy konténerbe, akkor egy konténerbe tett konténerbe teszel egy újabb konténert. Ha pedig valami fura oknál fogva Docker mániád van (idővel el fog múlni), akkor ott a Wildfly Swarm.

Azért ne tegyünk egyenlőségjelet egy Linux konténer (tehát OS virtualizáció Linux alatt = Solaris Zone megfelelője - volt Solaris felhasználók kérem kezdjenek nyugodtabban lélegezni :) ) és a JVM között.

A JVM (lényegtelen, hogy az Oracle (és korábban a Sun) marketing mit állít) nem arra lett tervezve, hogy potenciálisan rosszindulatú kódot izoláljon a rendszer többi részétől. Csak egy példa: Hiába szeparálod szét ClassLoaderekkel és Security Managerekkel a JVM-be töltött kódot, hogy egy JVM-ben az alkalmazásszerver több app-ot futtasson párhuzamosan, ha az egész egy processz, egy heap, tehát ha bármilyen módon az egyik appból natív kódfuttatást tud elérni egy támadó, akkor az összes apphoz hozzáfér az alkalmazásszerveren belül.

És támadási vektorból van elég, hiszen a HotSpot JIT is teljesítményre van optimalizálva, és nem biztonságra (pl. nagyon hiányzik, hogy a generált kódot tartalmazó memóriát W^X módon kezelje, akár úgy, hogy külön sandboxolt processzben történik a fordítás). Vagy csak gondoljunk egy JNI hívásra, ahol a natív kód is ugyanabban a processzben fut hozzáféréssel a teljes JVM memóriához (kód és heap is!).

A fentiek miatt biztonságosabbnak látom azt az irányt, ha az egyes Java appok külön OS szintű konténerbe vannak izolálva. Sőt, az ideális az lenne, ha korlátozni lehetne a JIT-elést, runtime kódgenerálást - beleértve a különböző runtime kódinstrumentálási technikákat is (javassist, cglib és társai). Java9-cel elindult talán az Oracle a jó irányba a jlinkkel és a részleges AOT supporttal, de ez még csak az út eleje.

A Wildfly Swarm, Spring Boot, Java mikroframeworkök mint a Spark (nem az Apache) ... stb. mind ebbe az irányba mutatnak és az ipar nagy része is az OS konténerek felé mozog, nem azért, mert Docker hívők, hanem mert az OS konténereknek van értelmük.

Egyáltalán nem lepne meg, bármilyen eszközzel lehet microservice-es architektúrát létrehozni és monolitikusat is.

A gejzír által felhozott (:-) problémákra reflektáltam, amik JEE-s microservice-es rendszernél is ugyanúgy meglennének, illetve bizonyos problémákból kevesebb lenne, bizonyosakból meg több, attól függően, hogy miként használjuk.

"Egyáltalán nem lepne meg, bármilyen eszközzel lehet microservice-es architektúrát létrehozni és monolitikusat is."

A monolitikus microservice architektúráról mesélhetnél, hogy szerinted milyen.

"A gejzír által felhozott (:-) problémákra reflektáltam, amik JEE-s microservice-es rendszernél is ugyanúgy meglennének, illetve bizonyos problémákból kevesebb lenne, bizonyosakból meg több, attól függően, hogy miként használjuk."

Nem. Nem lennének meg ezek a problémák, mert ezeknek a nagy részét megoldja az alkalmazásszerver.

A monolitikus microservice architektúráról mesélhetnél, hogy szerinted milyen.

Ez miből jött ki? :-D

Nem. Nem lennének meg ezek a problémák, mert ezeknek a nagy részét megoldja az alkalmazásszerver.

Csak pár példa:
Probléma1: Erőforrás (pl. memória, CPU) mennyiségének korlátozása microservice-enként.
Probléma2: Monitorozni az egyes microservice-eket és annak függvényében újak indítása, meglevők leállítása.
Probléma3: Ha heterogén rendszerre (tetszőleges nyelvű microserevice-ek) van szükség (ami egy nagy előnye a microservice-eknek), akkor a kommunikáció, load balancing, auto discovery, routing, ... ugyanolyan problémás.
Probléma4: Amit meg is oldana az alkalmazás szerver azoknak a nagy része is elég korlátozott és nem finomhangolható (load balancing, auto discovery, routing, monitoring).

Én nem látom, hogy sokkal több megoldást nyújtana, mint pl. a Kubernetes.

"Probléma1: Erőforrás (pl. memória, CPU) mennyiségének korlátozása microservice-enként."

Egyrészt mit érsz el azzal, hogy egy hibásan megírt szolgáltatást OOM-re vagy éhezésre késztetsz? Nem a problémát oldod meg, csak a tünetet kezeled. Másrészt tudsz indítani menedzselt külön JVM instance-t azoknak az alkalmazásoknak, amelyeket kordában akarsz tartani. Közel nulla adminisztrációs teherrel.

"Probléma2: Monitorozni az egyes microservice-eket és annak függvényében újak indítása, meglevők leállítása."

Ezt meg tudod tenni gond nélkül JavaEE konténerrel is.

"Probléma3: Ha heterogén rendszerre (tetszőleges nyelvű microserevice-ek) van szükség (ami egy nagy előnye a microservice-eknek), akkor a kommunikáció, load balancing, auto discovery, routing, ... ugyanolyan problémás."

Igen, legrosszabb esetben ugyanolyan problémás.

"Probléma4: Amit meg is oldana az alkalmazás szerver azoknak a nagy része is elég korlátozott és nem finomhangolható (load balancing, auto discovery, routing, monitoring)."

Ez nem tűnt fel... ha már jelentős problémát okoz az, hogy finomhangolni kell ezeket, ott valami más el van rontva és ismét tünetet akarunk kezelni... az egész Java microservice arról szól, hogy valamit elrontottunk (például az, hogy Java-t választottunk a microservice fejlesztéséhez) és a probléma megoldása helyett próbálunk tüneteket kezelni amíg az egész spagetti annyira a körmünkre ég, hogy inkább újraírja az ember az éppen ebben a hónapban divatos új microservice keretrendszerrel, amíg az is szűk nem lesz.

Tudnál mondani egy olyan komolyabb microservice keretrendszert, ami létezett öt éve, most is pont úgy működik és szívesen dolgozol benne?

Ezt meg tudod tenni gond nélkül JavaEE konténerrel is.

Ezt nem ismerem. Tudsz linket adni?

Tudnál mondani egy olyan komolyabb microservice keretrendszert, ami létezett öt éve, most is pont úgy működik és szívesen dolgozol benne?

Nem szeretem a keretrendszereket, nem szívesen dolgozom bennük (velük), ha csak tehetem komponens alapú rendszereket használok.

Pölö WAS esetén teszteltem is régebben: https://advantage.ibm.com/2015/07/07/websphere-liberty-auto-scaling/

De van minden ilyesmi a többihez is.

"Nem szeretem a keretrendszereket, nem szívesen dolgozom bennük (velük), ha csak tehetem komponens alapú rendszereket használok."

A komponens alapú rendszer az nem keretrendszer? :)

Előre bocsátom, hogy nem értek se a microservice-ekhez, sem programozó nem vagyok.

Csak egy kérdésem van:

Azt hallottam az egyik kollégától, hogy a microservice-ek stateless funkciókat tudnak megvalósítani, ha olyasmi kell, pl. webshopban bevásárlói kosár, vagy több lépésből álló tranzakció, ilyesmi, akkor arra csak nagyon körülményesen lehet használni. (Azért jött ez fel, mert ő dolgozott egy projekten, ahol az architect microservice architektúrát javasolt, a fejlesztők meg később vért pisiltek).

Szóval arra lennék kíváncsi, hogy ezeket a feladatokat valóban csak nagyon körülményesen lehet megoldani ilyen architektúrával, vagy esetleg az ő projektjén a fejlesztők (és esetleg az architect) nem értett hozzá, és feleslegesen szívtak, mert van X vagy Y megoldás, amivel viszonylag egyszerűen megoldhatták volna.

"Azt hallottam az egyik kollégától, hogy a microservice-ek stateless funkciókat tudnak megvalósítan"

Negatív. A microservice annyit jelent hogy a minimálisra vagy nullára csökkentjük az adott alkalmazás külső függőségeit, és a jól meghatározott kevés számú feladatát a körülményektől függetlenül el tudja látni. Ettől még nem kell statelessnek lennie. Amúgy az igazi stateless alkalmazás elég ritka.

--
arch,debian,retropie,osmc,android,windows

"Sokan nem értik a microservice-ek lényegét, nem ismerik az előnyeiket (a hátrányaikat általában ismerik :)."

Én szeretek a microservice paradigmára sokkal inkább tervezési patternként gondolni. Ez magyarra lefordítva értelmes és átgondolt service és API szeparációt jelent, ilyen tekintetben tök hasonló a SOA-hoz (csak az SOAP). A gond legtöbb esetben a megvalósítással és a microservice= "új processz" (új spring boot/docker) erőltetéssel van. Jól írta _Franko_, hogy microservice logikai architektúrát ugyanúgy meg tudsz valósítani JavaEE alapokon is, sőt szerintem sokkal inkább úgy van értelme.

"Ahhoz, hogy az alkalmazás elinduljon mondjuk egy fejlesztői gépen (8-12 spring boot service), kevés volt a 16GB Ram a gépekbe."

Itt valami el lehetett esetleg rontva, mert a microservice-eknek pont az az egyik lényege, hogy nagyon kicsik és egy fejlesztői gépen is azért pár tucatot el lehet indítani belőlük.
Több lehetséges felépítése lehet a microservice-eknek, pl. van ahol egymást hívják, ezeknél fontos a függőségkezelés is; van ahol MessageQueue-kon (MQ) kommunikálnak egymással. Ez utóbbi azért is jobb sok esetben, mert önállóan fejlesztheted, tesztelheted, használhatod a microservice-eket.
Épp ez az egyik előnye a microservice-es rendszernek, hogy nem kell egy hatalmas alkalmazásnak elférnie a fejlesztői gépen, elegendő csak a fejlesztés alatt álló microservice-nek (esetleg egy pár függőségének)."

Igen szerintem is el volt. Minden kis piszlicsáré szerviz szét volt szedve nagyon tudományosan, az egész leöntve Spring boot+Netflix framweorkkel (Eureka, Hystrix, stb.). A projekt elején az összerakott példa hello world (szervizenként 2 sor érdemi kód) falta fel a gépet szőröstül bőröstül.

"Így van, ez pazarlás, de egyrészt ettől lesz a rendszer horizontálisan, funkciónként (microservice) skálázható, hibatűrő.
Másrészt egy jól elkészített microservice-es rendszernél a kommunikációs közeget könnyen cserélhetőre szokás elkészíteni, amivel a http-s kommunikáció helyett akár egyszerű függvény hívás is szerepelhet, sőt akár több microservice futhat egy monolitikus alkalmazásként is. Ez nagyon jól jön tesztelésnél és fejlesztésnél."

Ez viszont tévedés. Nem ettől (nem attól, hogy minden külön processz) lesz a dolog skálázható és hibatűrő.

Ha pl. szélsőséges módon úgy definiálod logikailag a microservice-t, hogy microservice=remote EJB, akkor már kész is a jól skálázható, moduláris, elosztott, monitorozható alkalmazásod. A szervizeket teheted egy alkalmazás szerverbe (monolit) vagy akár egyesével külön vagy csoportokban keverve. Akár egy gépen külön processzbe, akár 3 külön gépre. ABC szerviz és pl. 3 gép között akár dinamikusan, terhelés függvényében át tudod dobálni a szervizeket pl: 1[AB] 2[BC] 3[CA], 1[ABC] 2[BC] 3[CA].

Mindezt kód módosítás nélkül, futási időben, elosztott cache-el, ha kell distributed session-el, messaging-el, registry-vel, singletonnal. Cserélhető konténer implementációval.

" Ahhoz, hogy az alkalmazás elinduljon mondjuk egy fejlesztői gépen (8-12 spring boot service), kevés volt a 16GB Ram a gépekbe."

Lássuk be 8-12 darab spring-bootos apphoz ha kevés a 16gb ram, akkor apponként 1-2GB-ot foglalsz be rögtön. Ez innentől kezdve nem spring-bootos probléma és nem úgy kell megoldani hogy ugyanezeket az appokat egy weblogicba teszed be.

Nem a 8 darab embedded tomcat vagy a 8 darab spring context emészti fel a ramot, hanem valami erős elcseszés az alkalmazás kódjában.

--
arch,debian,retropie,osmc,android,windows

Ahogy fentebb már írtam, ez a projekt elején összerakott "példa" hello world (szervizenként 2 sor érdemi kód) volt.
Ez falta fel a gépet szőröstül bőröstül.

Az x-edik projekten rakom össze az y-adik spring-boot alapú appot. Nem foglal ennyit. Elszúrtátok. (ezek között nem csak klasszikus soap/rest szervizek voltak, hanem camel is)

--
arch,debian,retropie,osmc,android,windows

Ő is ezt írta, hogy el volt szúrva: Igen szerintem is el volt. Minden kis piszlicsáré szerviz szét volt szedve nagyon tudományosan, az egész leöntve Spring boot+Netflix framweorkkel (Eureka, Hystrix, stb.).

Az addig teljesen jó egy microservice-es rendszernél, hogy Minden kis piszlicsáré szerviz szét volt szedve nagyon tudományosan, ott rontották el, hogy ~"leöntötték egy framework-kel". A framework-ök nem microservice-ekhez valók!
(Szerintem egyébként leginkább semmihez, sokkal jobb, ha cserélhető komponensekből áll össze a rendszerünk. Ide kapcsolódik A Keretrendszer Legendája)

Szerinted milyen olyan komponenseket lehetne mondjuk java-ban használni, ami kapásból cserélhető másik termékre?

- Spring vs Guice vs Dagger vs PicoContainer vs ..
- SQL vs JOOQ vs JPA vs MyBatis vs QueryDSL vs ...
- Restlet vs Resteasy vs Jax-RS vs ..

Szerintem még ezek nagy része is kb. ágyúval verébre.
A microservice-ek általában nagyon kicsik (1000 sor alattiak), így nagyon kevés támogatás kell hozzájuk, feleslegesek a DI containerek, feleslegesek a nagy JPA-k (kisebb adatbázis támogatások szóba jöhetnek), de még a REST-es támogatások is, bár ezen Java lib-eket nem ismerem, nem tudom mekkorák.
Ebből a szempontból én inkább csak a Scala-s lib-eket ismerem.
Alapvetően a microservice-es rendszerekből nekem a MessageQueue-sok tetszenek, abból is leginkább a Kafka-ra épülők, mivel azoknak a legegyszerűbb és szerintem a leghatékonyabb az architektúrájuk. Ott egy-egy microservice (Scala-s) tapasztalatom szerint kijön 50-200 soros nagyságrendben.

Na, szerintem most kezdődik az érdekes beszélgetés.

Van egy olyan elképzelés, hogy a java-s alkalmazásokat elkezdik egy container-be csomagolni, mert ... (és itt egy csomó indokot lehet felsorolni). Erre volt az ellenérv,
hogy valójában a JEE container már egy container, nem kell itt semmit sem csomagolgatni. És ez valójában így is van.

Te most nagyon ügyesen behoztad azt, hogy egy microservice alapvetően kicsi, egy dolgot csinál. Na, és szerintem itt lehet a kutya elásva: spring-gel általában
egy darab nagy monolitikus alkalmazást fejlesztenek az emberek. Ezzel az égadta világon semmi baj nincs, egy rakás esetben egyszerűen nem feltétel az, hogy több
millió customer-re skálázódjon a rendszer. Ha viszont skálázódni kell, akkor jönnek a problémák. Ha jól értem, ilyenkor az egyik megoldás az, hogy a nagy alkalmazást
szépen szétszedjük kisebb részekre, és ezek egymással történő kommunikációját valahogy megoldjuk (és akkor bejön a tranzakciókezelés, meg service discovery, meg minden más)
vagy pedig átnyergelünk JEE-re, ahol az egyes service bean-eket tekinthetjük úgy, hogy ezek bizony microservice-ek, és a fent említett problémákat a container reményeink
szerint kezelni fogja.

És ugye itt jön be a kolléga jogos reklamálása, mert ha fogunk egy JVM-et, hozzárakunk egy spring+tomcat-et, és ezt összerakjuk egy "microservice"-be, akkor simán el tudom
képzelni, hogy annak több száz mega memória kell, és ha van 10 ilyenünk, akkor máris elfogyott a gépben a memória.

Jól látom a kérdést?

A JEE-s alkalmazást, ha több "microservice" is található benne, akkor szerintem nem lehet microservice-es alkalmazásnak tekinteni.
Nem tudod microservice-enként korlátozni az erőforrás használatot. Ez azért fontos, hogy egy-egy microservice ne fogyassza el mások elöl az erőforrásokat.
Tekinthetjük úgy, hogy jó, tudjuk így is futtatni, mint a monolitikusokat, de szükség esetén szétdobhatjuk több gépre.
Itt meg az lesz a gond, hogy a JEE container-ek erőforrás többlete jóval nagyobb, mint a spring-eseké (kivéve a kolléga esetét, ahol még megvolt fejelve egy jó kis framework-kel).
A fenti adatok alapján egy spring-boot-os microservice-t meg kellene úsznunk 30-100MB-ból. A normálisabb JEE container-ek meg alapból 500-800MB-ot fogyasztanak.

Én még azt is problémásnak találom, hogy JEE-s alkalmazásnál sokkal kevésbé vagy ráutalva, hogy alaposan átgondold, hogyan osztod fel a programot részekre.

(Még vannak más okok is, de már késő van és ez szerintem elég off már amúgy is, meg valóban volt itt már a hup-on hasonló téma végigbeszélve.)

Tehát szerintem a JEE-vel nagyon jó, modulokból felépülő alkalmazásokat készíthetünk, amelyek még valamelyest skálázhatók is, de microservice rendszerre nem igazán alkalmas.

"Nem tudod microservice-enként korlátozni az erőforrás használatot."

+1, jó látni, hogy pontosan melyik microservice vadult meg.

Log? Heap analyze? Bármi egyéb diagnosztika? Vagy a naplózást, a diagnosztikát és a hibakeresést váltjuk ki microservice architektúrával?

Töltögessen be 64+ GB-s heapdumpot akinek két anyja van.

Csak elválasztjuk egymástól a hideg és a meleg vizet, ne egy csőben jöjjön már.

Mitől is 64+ GB a heapdump? Másrészt egy jó logból nagyon sok minden megmondható. Debug nem lesz éles rendszeren, csak log. :)

igazán szopatós hibák csak élesben jönnek ki :)
Én főleg jirával kapcsolatban találkoztam olyannal, hogy teszt környezetben a legnagyobb terhelést is elbírta (gépi + emberi használat), élesben meg csak pislogtunk.

"igazán szopatós hibák csak élesben jönnek ki :)"

Az elég baj...

"Én főleg jirával kapcsolatban találkoztam olyannal, hogy teszt környezetben a legnagyobb terhelést is elbírta (gépi + emberi használat), élesben meg csak pislogtunk."

A Jira az tipikus példája annak, hogy mennyire szar, inkoherens és ezer sebből vérző kódot lehet írni, ha workaround driven development a fejlesztési modell és az alapul szolgáló OSGi és Spring spagettihalmaz pedig ezt teljes vállszélességgel támogatja.

Ennyi...
De ettől ez még létező probléma, sajnos.

Nagyszerű, de ezt a problémát nem oldja meg az, hogy ha még jobban külön futtatod a dolgaidat... minden metódust nem tudsz külön virtuális gépben futó virtuális környezetben futó virtuális gépben futtatni, mert elvesztesz minden performancia előnyt azért cserébe, hogy egy beteg metódust elkülöníts, ahelyett, hogy megjavítsd... ennél már az is jobb, ha az új dolgokat karanténba teszed és ha jól viselkedik, akkor mehet a többi jól viselkedő szolgáltatás mellé, JavaEE esetén teljesen transzparens, hogy éppen ugyanabban vagy egy másik JVM-ben futó metódust kell meghívni és ez üzemeltetési és nem fejlesztési feladat.

vagy nem használok jirát, tudom :)

Ha használsz, akkor van rá support, ha hiba van, akkor szopjon a support a pénzéért, nem?

Nem teljesen értem, hogy jutottunk el onnan, hogy tudni akarod, hogy "pontosan melyik microservice vadult meg", odáig, hogy a nem akarsz 64+ GB heapdump-ot nézni a Jira miatt...

Te üzemeltettél már olyan jirát, amire plugint is telepítettél?
Csak szólok, hogy olyankor nem jár a support.

Nem tudom, szerintem most mindenki kisírja a Java EE kínjait.

"Te üzemeltettél már olyan jirát, amire plugint is telepítettél?"

Aha.

"Csak szólok, hogy olyankor nem jár a support."

Járt rá... :/

Szerencsés vagy, mert hivatalosan nem jár.
Gondolom ausztrál mérnököt fogtatok ki, nem indiait, mert az előbbi szarik az SLA-ra (jó és rossz értelemben is).

Oszt az Atlassian Support Offerings melyik pontjára hivatkoztak ez ügyben, hogy egy telepített plugin miatt az egész instance unsupported lett? Mert itt valami kommunikációs hézagot sejtek.

Leirom, mert latom te szerencsere nem szoptal ezzel.

Amint elkuldod a logokat, latjak benne, hogy milyen pluginokat hasznalsz.
Kozlik, hogy nem gyari pluginok is vannak jelen, plz disable all plugins (ez benne volt a feltetelekben, de mar nem dolgozom ott, nem tudom idemasolni neked), ha ugy is fennall a hiba, kuldjunk megint logokat.
Mivel ugy NYILVAN nem jelentkezik a hiba, case closed.
Az mas kerdes, hogy neha pont az egyik _Atlassian altal_ keszitett plugin okozta a hibat.

Mashogy leirva: alaprendszerbeli regressziot nem tudunk ellenorizni, ha a letiltott pluginok miatt nem tudjuk mukodtetni a folyamatainkat.

Na, ez azért nem ugyanaz a helyzet... :D

Websphere Liberty? Vagy mivel az kevesebbet igényel nem normálisabb JEE container?

Az is normálisabb, de alapból nincsenek benne azok a dolgok, amiktől olyan nagyon jónak tartják gejzírék a JEE konténereket (distributed transaction, distributed cache, JPA, messaging, monitoring, ...). Ha ezeket is beleteszed, akkor ez sem lesz kicsi.

A Wildfly 10.1 például -Xmx48M elindul Web profile-al, amiben benne vannak az említett dolgok... ha kivesszük belőle, akkor ennél kevesebbel is elindul. Ha csak Undertow kell, az jóval kevesebbel is beéri, mint egy Tomcat... az előnye viszont az, hogy ha felmerül fél évvel a fejlesztés elkezdése után, hogy mégis kell esetleg valamelyik komponens, akkor egy CLI paranccsal visszakapcsolható.

"Tehát szerintem a JEE-vel nagyon jó, modulokból felépülő alkalmazásokat készíthetünk, amelyek még valamelyest skálázhatók is, de microservice rendszerre nem igazán alkalmas."

Aha... na, csináltam teszteket (spring-boot-memory-performance és azonos greeting REST stateless EJB).

Minimum az elinduláshoz és a stabil 16 szálas terheléshez szükséges memória (4 MB lépésekben):

Spring-boot: 24 MB
Wildfly Swarm 2017.8.1: 40 MB
Wildfly 10.1 Standalone default configuration: 56 MB

Terheléses tesztek az elinduláshoz szükséges minimum memória mellett, warm up után.

Spring-boot, -Xmx24M:

Requests per second: 435.86 [#/sec] (mean)
Time per request: 36.709 [ms] (mean)
Time per request: 2.294 [ms] (mean, across all concurrent requests)

Wildfly Swarm 2017.8.1, -Xmx40M:

Requests per second: 2262.06 [#/sec] (mean)
Time per request: 7.073 [ms] (mean)
Time per request: 0.442 [ms] (mean, across all concurrent requests)

Wildfly 10.1 Standalone default configuration, -Xmx56M

Requests per second: 1106.37 [#/sec] (mean)
Time per request: 14.462 [ms] (mean)
Time per request: 0.904 [ms] (mean, across all concurrent requests)

Terheléses tesztek az elinduláshoz szükséges minimum memória +16 MB mellett (ezzel ajánlották futtatni a Spring-boot demót), warm up után.

Spring-boot, -Xmx32M:

Requests per second: 14436.82 [#/sec] (mean)
Time per request: 1.108 [ms] (mean)
Time per request: 0.069 [ms] (mean, across all concurrent requests)

Wildfly Swarm 2017.8.1, -Xmx56M:

Requests per second: 22141.01 [#/sec] (mean)
Time per request: 0.723 [ms] (mean)
Time per request: 0.045 [ms] (mean, across all concurrent requests)
T

Wildfly 10.1 Standalone default configuration, -Xmx72M

Requests per second: 17819.74 [#/sec] (mean)
Time per request: 0.898 [ms] (mean)
Time per request: 0.056 [ms] (mean, across all concurrent requests)

Terheléses tesztek az elinduláshoz szükséges minimum memória +16 MB mellett két külön alkalmazással, külön-külön futtatva, warm up után.

2x(Spring-boot, -Xmx32M), összesen 64MB memória:

Requests per second: 14786.16 [#/sec] (mean)
Time per request: 1.082 [ms] (mean)
Time per request: 0.068 [ms] (mean, across all concurrent requests)

Requests per second: 14498.15 [#/sec] (mean)
Time per request: 1.104 [ms] (mean)
Time per request: 0.069 [ms] (mean, across all concurrent requests)

2x(Wildfly Swarm 2017.8.1, -Xmx56M), összesen 112MB memória:

Requests per second: 22311.87 [#/sec] (mean)
Time per request: 0.717 [ms] (mean)
Time per request: 0.045 [ms] (mean, across all concurrent requests)

Requests per second: 22222.77 [#/sec] (mean)
Time per request: 0.720 [ms] (mean)
Time per request: 0.045 [ms] (mean, across all concurrent requests)

1x(Wildfly 10.1 Standalone default configuration, -Xmx72M), két külön war alkalmazás, összesen 72MB memória.

Requests per second: 17151.07 [#/sec] (mean)
Time per request: 0.933 [ms] (mean)
Time per request: 0.058 [ms] (mean, across all concurrent requests)

Requests per second: 17877.72 [#/sec] (mean)
Time per request: 0.895 [ms] (mean)
Time per request: 0.056 [ms] (mean, across all concurrent requests)

Mindenki gondolkodjon el rajta, mind a terheléses teszten, mind azon, hogy biztos külön-külön szerver kell-e a két külön microservice futtatásához... és persze azon is, hogy a valóságban egy komplexebb metódus esetén elég-e +16 MB memória vagy mondjuk +512 MB kell, amikor szinte nullára olvad a Spring-boot előnye még egy alkalmazással is. És persze azon is érdemes elgondolkodni, hogy ha kell egyszer egy JTA ernyő vagy egy JTS, esetleg local queue, akkor azt mekkora fejlesztési és üzemeltetési overhead belehegeszteni a Spring-boot alkalmazásokba...

Szép, köszönjük :)

Kétszer mérj, egyszer vágj, ahogy a mondás tartja. Én mindent ki szoktam mérni magam is, nem nyelek be csont nélkül semmit, amit egy eléggé elhivatott szerző ír...

"A fenti adatok alapján egy spring-boot-os microservice-t meg kellene úsznunk 30-100MB-ból. A normálisabb JEE container-ek meg alapból 500-800MB-ot fogyasztanak."

Alapvetően ezt kellene átgondolni... félelmetes, hogy mennyire torz képe van sok fejlesztőnek arról, hogy milyen erőforrás-szükséglete és teljesítménye van az egyes technológiáknak... :/

Érdekes ez a mérés, gondolom nektek nem ugyanazt mondja, mint amit nekem.

Eleve azt nem értem, hogy miért nem ugyanakkora memóriával vannak összehasonlítva az egyes rendszerek. Ugyanannyi erőforrást kellene kapjanak, hogy összehasonlíthatók legyenek.
/Ha az egyik egy maggal is elindul, a többinek meg minimum 8 kellene, akkor az sem lenne fair, hogy annyival hasonlítsuk össze őket./

Még kevesebb memória esetén is a spring-boot a jóval gyorsabb, mint a másik kettő több memóriával:

SB: 32M => 14436.82 [#/sec]
WS: 40M =>  2262.06 [#/sec]
Wf: 56M =>  1106.37 [#/sec]

Ráadásul a +16M összevetésből a spring-boot csak +8M-at kapott meg (24M+16M => 32M, oops).

Ezen kívül az Xmx és a tényleges memóriafogyasztás az nem ugyanaz. Így egy reális mérésnél az összes memóriafoglalásoknak kellene inkább egyezniük.

Egyébként köszi a mérést, tényleg hasznos!

Eleve azt nem értem, hogy miért nem ugyanakkora memóriával vannak összehasonlítva az egyes rendszerek.

Mert van egy minimum memória igényük és az ezen felül használható memóriával vannak összehasonlítva. Ha írnék egy puszta HTTP szervert csak erre az egy demo REST kérésre, akkor annak még kevesebb elég lenne, csak semmit nem bizonyít... :)

Ezen kívül az Xmx és a tényleges memóriafogyasztás az nem ugyanaz. Így egy reális mérésnél az összes memóriafoglalásoknak kellene inkább egyezniük.

Maga a process mindegyik esetben az operációs rendszer szintjén már 260-320 MB körül fogyasztott (VmHWM), tulajdonképpen teljesen eltűnt -Xmx érték, a +16MB is csak öt-nyolc százalékkal több memóriát igényelt, ami elenyésző.

Mekkora -Xmx beállításokkal futnak átlagosan a Spring-boot alkalmazásaid? :)

Ráadásul a +16M összevetésből a spring-boot csak +8M-at kapott meg (24M+16M => 32M, oops).

Oh, az egy szimpla elírás, megkapta a szükséges plusz memóriát, ahol 32M volt írva, oda 40M értendő.


SB: 32M => 14436.82 [#/sec]
WS: 40M => 2262.06 [#/sec]
Wf: 56M => 1106.37 [#/sec]

Te most századra pontosan azt kaptad, amit én mértem, vagy csak bemásoltad vegyesen azt, amit én mértem, úgy, ahogy szerinted valamit jobban alátámaszt? :D

jajj, weblogikussal ne akarj Spring ökoszisztémát használni...

A CDI meg az EJB-k egyszeruek, mint a faek (WF10/JEE7 kornyezetre gondolok). A Dockernek ehhez zero koze van.

Nem is ertem, hogy akinek megy a Spring, az mit talal nehezkesnek vagy bonyolultnak a JEE7-ben (vagy akar a WF Swarm-ban). De most tenyleg.

----------------------
while (!sleep) sheep++;

https://hup.hu/node/154960#comment-2132361

szerk.: a dockernek valoban nincs kozvetlen koze a dologhoz, ne is koncentraljunk ra.

--
arch,debian,retropie,osmc,android,windows

Na, akkor egy kérdést be is dobnék a közösbe:

ha van egy nagyobb projektetek, amit külön tesztelők tesztelnek, akkor a build rendszert, ami legenerál "valamit" amivel a tesztelők tudnak
dolgozni, azt hogy raknátok össze?

A teljes rendszerteszthez kb. adatbázis, jee container, applikáció, stb. kelleni fog, tehát én arra gondoltam, hogy a build system vagy valamiféle
letölthető vagranttal buildelt virtuális gépeket generálna, vagy docker image-eket.

A kérdés, hogy jó lesz-e ez nekem így :D

Használj Devops-ot, és minden jó lesz. :)

Viccen kívül: A Devops lényege technológiai szinten szerintem az, hogy egy olyan fejlesztés - tesztelés - ops folyamatot hozol létre, ahol mindhárom fázis ugyanazokkal az artifactokkal dolgozik.

Tehát a fejlesztő által kirakott csomag (hogy a csomagban mi van az lényegtelen) módosítás nélkül mehet a system testnek és az opsnak is. Megvan, hogy ennek a csomagnak milyen paramétereit lehet tekergetni akár tesztelésnél akár élesben (pl. hogyan skálázod fel az application layert), de azon kívül nem az ops-tól várja el a rendszer, hogy a fejlesztő által kilapátolt f*sból építsen valamit (Hofi után szabadon: "és ha majd összeállt mi lesz belőle?" :) )

Ha standardizálódik a folyamat egy csomagformátum (és futtatókörnyezet) körül, ami automatizáltan telepíthető / működtethető, akkor a hibák kezelése is tisztább lesz - nem egymásra fog mutogatni a dev és az ops, hogy ki miatt történt a hiba.

Visszatérve a kérdésedre: szerintem olyan formátumot válassz, ami egységesen a dev kimenete a system test és az ops felé. Ez lehet docker, ha az ops docker alapú. Vagy Kubernetes. Vagy egy zip fájl, mellette Ansible playbook.

Ezt a részt értem, csak konkrét megoldásokra gondoltam, hogy ki hogy szokta. A dockerrel kapcsolatban elég vegyes érzéseim vannak,
de egyébként a vagrant-tal kapcsolatban is úgy vagyok, hogy a jó kis update scriptjeim egy sima update után volt, hogy egyáltalán
nem mentek (repok szűntek meg, meg ilyesmi).

A lent berakott link alapján még gondolkodom azon, hogy tényleg docker kell-e nekünk...

https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/

Mivel már többen linkelték, mint a Docker haszontalanságának bizonyitékát, elolvastam a cikket.

Olvassunk egy kicsit a sorok között:
- Adott egy cég, ami sok pénzt mozgat, feltételezem, hogy nekik is van rendesen budgetjük
- Elkezdik bevezetni a Dockert, de nem vesznek supportot (legalábbis mélyen hallgatnak róla)
- Meglepődnek, hogy az open-source verzió nem örökké + 1 napig supportált, hanem kb. a bleeding edge van kirakva
- Debian Jessie-n akarnak Dockert futtatni, amit nem erre terveztek
- Később rájönnek, hogy a Docker az csak egy konténer runtime + API, semmi más funkcionalitást nem nyújt (ki igért ilyet?)
- Miután leoltották (gondolom, nem volt időm/kedvem végigolvasni) a kommentekben, updateli a cikket, hogy ja, van itt egy CoreOS nevű dolog, amit direkt arra terveztek, amit mi akarunk csinálni, de nem próbáltuk
- Ugyanezt Kubernetes-szel
- És végül, hogy teljes legyen a kép, leírja azt is, hogy van ez a Google Container Engine, ami Kubernetes és Docker felett fut, és azt tudja stabilan, amit ő nem tudott összerakni

Akkor ezért most a Docker a hibás?

Ez nekem ahhoz hasonlít, mint amikor tavaly az Uber körbehaknizta a sajtót, hogy ők most visszaváltanak Mysql-re Postgres-ről, mert ilyen-olyan gondjaik vannak Postgres-szel. Aztán a sorok között olvasva (illetve meghallgatva a kampány "arcát" a SW Engineering Daily podcaston), azért árnyalódott a kép:
- nem kellőképpen tesztelt séma updatek miatt "némi" problémába ütköztek a szoftver updateknél
- valakinek eszébe jutott, hogy a Postgresnél a séma update is rollbackelhető, ha gond van (egyébként ez király feature, én is nagyon szeretem)
- nosza váltsunk Postgres-re
- USA két partja között csináltak eddig automata replikálást Mysql-lel (ahol ez logikai = SQL statement szintű), de sebaj összelőjjük Postgres default verziót (WAL replikálás)
- Csodálkoznak, hogy a két megoldásnak mások a trade-offjai, pl. teljesítmény-karakterisztikában
- Nem hívnak egy hozzáértőt (esetleg vezetnek be logikai replikálást Postgres felett), hanem inkább vissza Mysql-re (meg építenek saját "schemaless" megoldást Mysql fölé, juhé!)

Akkor ezért most a Postgres (vagy korábban a Mysql) volt a hibás?

És halkan megkérdezném, hogy hol van mindkét történetben a CTO, aki ezeket a döntéseket jóváhagyta?

A Docker-t nem csodaszer, egy alacsony szintű API a (mostmár elvileg cserélhető) OS konténer runtime-ok felett.
Sőt a Docker Inc. féle implementációval erős fenntartásaim vannak, de maga az irány (lightweight, egyfeladatos OS konténerek) szerintem jó.

Production konténer alapú rendszert én Kubernetesre (ill valamelyik kereskedelmileg támogatott disztribúciójára pl. Google Cloud Engine, RH OpenShift) építenék. És Kubernetesen belül is nagyon meg kell válogatni, hogy melyik feature-t használod, és miért.

Érdemes meghallgatni Bryan Cantrill előadását, hogy ők a Joyent-nél SmartOS / Triton felett, hogyan építettek automatikusan skálázódó Docker runtime-ot (nem a Docker Inc. implementációval), milyen architektúrát használnak és miért (és emiatt miért nem támogatnak bizonyos Docker funkciókat): https://www.joyent.com/blog/docker-and-the-future-of-containers-in-production
Gyakorlatilag a teljes Triton cluster egy db óriási Docker hostnak tűnik, a konténerek menedzsmentjét / ütemezését megoldja a Triton.

Mi a cégen belül év végéig át akarunk állni egy Kubernetes alapú infrastruktúrára a mostani Proxmox alapúról.

ennyi

- Azért, mert sok pénzt mozgatnak, nem biztos, hogy nagy a budgetjük.
- Volt egyfajta stabilitási elvárásuk, ami lássuk be, valamennyire azért jogos, de ezt Dockertől nem kapták meg
"There are all kind of subtle regressions between Docker versions. It’s constantly breaking unpredictable stuff in unexpected ways."
- Nem ment együtt stabilan egy Debian Jessie-vel, mint hosttal. Ez szerintem azért gáz.
- Storage driverek nem voltak stabilak
- Rájöttek arra, hogy egy külsős global registry-től függenek, amelyik ha nem megy, akkor nekik sem megy semmi (java világban maven-nél hasonló már előfordult, de js-nél is volt ilyenre példa)
- Kubernetes a bevezetéskor szerintem még nem volt

Én azt látom, hogy van egy agyon hype-olt technológia, amire mindenki rávetette magát, anélkül, hogy pontosan értené, hogy ennek hol a helye, és mik
a limitációi (úgy a technológiának, mint a megvalósításnak).

"Én azt látom, hogy van egy agyon hype-olt technológia, amire mindenki rávetette magát, anélkül, hogy pontosan értené, hogy ennek hol a helye, és mik
a limitációi (úgy a technológiának, mint a megvalósításnak)."

Ettől még értő kezekben van értelme. De ha telesírja a sajtót egy hozzá nem értő, az gáz.

--
arch,debian,retropie,osmc,android,windows

A Dockernek az a legnagyobb baja, mint a Linuxnak. Olyan, mintha a Leatherman és a Victorinox _összes_ multi-toolját egy eszközbe berakták volna, majd a kezedbe adják, hogy "nesze, ez mindent tud". Ezért tetszett pl. a fent linkelt Joyent féle megoldás: saját Docker API implementáció, Triton API-kra építve, kihagyva azokat a feature-öket, amiket az ő rendszerük nem tud / akar támogatni.

Az, hogy az upstream Docker verziók nem stabilak, meg regressziók vannak persze szomorú, én is azt szeretem, amikor ingyen kapok top quality megoldást és pöccre induló verziót. :) .De a Linus által kiadott vanilla Linux kernel sem enterprise ready. Arra még mérnökórák ezrei rámennek mire RHEL (vagy akár Ubuntu / Debian) kernel lesz belőlük.

Nagyon kevés olyan upstream open-source projekt van, amire igaz az, hogy production ready amikor letöltöd az oldalukról. Az Ubuntu, Debian és társai disztribúciók: pont hogy mások kódját csomagolják könnyen emészthető formába. De akár egy Samba-t az ember nem a samba.org-ról szokott szedni, hanem a disztróból. Nyilván vannak ellenpéldák (pl. LibreOffice), de egy szerver szoftvernél az a gyakoribb, hogy az upstream release-t még jelentősen reszelni kell, mire az adott környezethez illeszkedik.

Ezt a reszelést kell megfizetni a tökös helyi mérnök fizetésekent, support contractként (vagy kivárni, amig lelkes őrültek belerakják a Debianba rendesen, és apt install :) )

A global registryre mint single point of failure-re rácsodálkozni 2016 / 17-ben minimum furcsa. Hiszen már (mint írod) a JS fejlesztők is rájöttek erre, ők meg toolingban 10 - 15 évvel vannak lemaradva mondjuk a JEE világ mögött... :)

Update: nem azt akarom mondani, hogy nem hasznos ismerni a potenciális problémákat, és ha a blogpost egy "10 dolog amire figyelj, ha Dockert használsz" jellegű problémacsokor lett volna, akkor az teljesen helyénvaló. A problémám egyrészt a tálalással (drámai szünetek, ... stb.), és a hatalmas meglepetésként tálalt, egyébként egyáltalán nem meglepő gondokkal van. Pl. ha CoreOS-en vagy Atomic-on összeomlik a hivatalosan támogatott Docker, az lehet hír. Ha Debian stable-re (*) rá apt installozod, és belefutsz egy (sok) bugba, az bugreportot érhet a megfelelő helyre, de ilyen hatásvadás "why docker fails" jellegű posztot nem.

*: Egy kedves barátom szerint két Debian verzió létezik: unstable és obsolete :)

"unstable és obsolete"
:DD
De az a baj, hogy igaz. Választhatsz hogy új kell ami instabil, vagy a régi, ami stabil. De régi. Ami néha probléma. Kb. ugyanez a Fedora-CentOS páros.
--
"Sose a gép a hülye."

Az uberes tortenethez hozzatartozik egy ilyen dontes nem biztos ,hogy eljutt mert a csapatok onalloan donthetnek. Az mas kerdes ,hogy jo-e vagy rossz-e. De tobb ponton elcsuszott a dolog a nagyobb problema ,hogy korbe hakniztak a sajtot vele.

A Dockernek sok baja mint mindennek viszont egy nagyon nagy rugalmassagot add egy rendszer szamara. Nekunk van egy viszonylag "nagy" rendszerunk 40-70 instance 2-4k container (terheles fuggo) meg 70+ fajta servicunk. AWS + Kubernetesen futtatva spotinsteken. Viszont nem java ezert annyira nem relevans a topickhoz :)

De amugy egy csomo jo meetupan van itthon erre amire erdemes elmenni es beszelgetni ezekrol mert itt azert eleg sokan csak talalgatnak es olvasgatnak ,hogy epul fel egy ilyen rendszer.

https://www.meetup.com/Cloud-Budapest/
https://www.meetup.com/Microservices-Budapest-Meetup/

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Nalunk ugye mindenki otthonrol dolgozik, tehat kicsit hasonlo a problema. Ugy oldjuk meg, hogy
- van egy Vagrantfile (nem egy teljes image, azt maceras lenne letoltogetni), ha arra nyomsz egy 'vagrant up'-ot, akkor fello egy Linux VM-et, felinstallal mindent, ami szukseges (Docker, hozzaferes repokhoz, etc.)
- a build rendszer (es a CI) Docker image-eket general
- ha manualisan tesztelni akarod a rendszert, akkor kb. azt csinalod, hogy 'docker-compose -f test.yml', ami fello egy teljes kornyezetet egy rakas kontenerrel, fake teszt adatokkal az adatbazisban

----------------------
while (!sleep) sheep++;

Tehát ha jól értem van egy előre összerakott alaprendszeretek, ami mindenkinél ott van, ami egyébként a build rendszerből
letölti a docker image-eket (pl. svn build number szerint) és aztán elindítja azokat?

Plusz egy kérdés: a customernél deployolt rendszer az hogy működik? ott is egy virtuális gépen futó linux (pl. debian server)
van, ami mellett ugye kell futnia adatbázisnak, meg valami webes cuccnak, stb. Ezek docker container-ben futnak, vagy
máshogy kerülnek telepítésre?

Tesztelők gépén akarod futtatni a tesztelendő dolgot vagy van egy felhő valahol, ahol lehet ilyesmit futtatni? Mert ha az utóbbi, akkor el kell készíteni valamilyen kedvelt eszközzel azt a környezetet, ahogy az éles üzemben is fut vagy fog futni és a build végén oda megy a deploy, úgy, ahogy az éles környezetbe menne és azt tesztelik, úgy, ahogy az éles rendszert használnák.

Nem hiszek abban a filozófiában, hogy minden egyes tesztelőnek oda kell adni egy steril tesztelendő környezetet steril adatokkal, mert nem így fogják használni a felhasználók sem. Ha a tesztelőket zavarja a rendszeres deploy, akkor a felhasználókat is zavarja. Ha az üzemeltetőket zavarja a sok probléma, ami ezzel kapcsolatos, akkor az éles üzemben is zavarni fogja őket. Ha egy build eltosz valamit egy másik alkalmazásban, akkor steril környezetben nem fog kiderülni, éles üzemben fogják észrevenni, hogy eltoszott valamit. Arról nem is beszélve, hogy ha hagyod elburjánzani a tesztrendszereket, akkor csak káosz lesz a vége, senki nem tudja, hogy melyiken éppen milyen build van, melyikre milyen adatok vannak visszatöltve és honnan, melyiken mit tesztelnek és a többi.

Köszi, ez nagyon jó ötlet volt.

+1

Itt a nagy kérdés, hogy mi a célunk a system teszttel. Amit leírsz, az akkor jó, ha a main success scenario-kat (pl. lehet-e rendelést feladni a webshopban) és néhány egyértelmű, izolált hibaesetet akarunk system teszttel ellenőrizni (pl. regisztráció invalid adatokkal).

Ha ennél többet akarunk, ott már előjön, hogy a system tesztelőnek be kell tudnia állítani a rendszer állapotát egy olyan pontra, ahonnan a kérdéses teszteset(ek)et hatékonyan tudja futtatni. Az a rendszertől függ, hogy az ilyen teszteseteket el tudod-e intézni automatizáltan (ez lenne a legjobb), vagy kell hozzá manuális teszt is.

sub


Sic Transit Gloria Mundi