Mała prowokacja
Może nie ban, ale przynajmniej alert, migające pomarańczowe światełko co do wielu modnych technik
(a propos, szyldem Javy / Jakarta EE sie nie przejmujcie, nie mam nic n/t)
2
4
Ja się zgadzam, że jest dużo hype driven development w tej branży. Tylko naprawdę musiałbym się ostro nawalić i jeszcze samodzielnie walnąć gazrurką w głowę, żeby wejść w JEE...
4
Z kompilacją AOT to też problem specyficzny dla Javy. W Java AOT jedyne co daje to przyspieszenie czasu startu, kosztem spowolnienia działania. Natomiast nie oznacza to że te zalety są tak znikome w innych językach z AOT. Po prostu Java jako język nie była projektowana pod kompilacje statyczna i dlatego bardzo trudno się optymalizuje.
Kompilacja i linkowanie statyczne pozwalają uzyskać niesamowicie małe, szybkie i lekkie binarki, idealnie nadające się do uruchamiania w kontenerach w chmurze, ale trzeba użyć innego języka (Rust, Go, Zig, C, C++). Przykładowo obraz jednego z naszych produkcyjnych komponentów zajmuje 30 MB (cały obraz dockera nie sama apka) i to tak dużo tylko dlatego że wkompilowaliśmy debug Info. Bez debug info obraz zajmuje 12 MB, apka 2 MB.
Ktoś zapewne zaraz wyleci tu z tym że obecnie komputery mają dziesiątki GB RAMu i że to premature optimization. A jednak dzięki temu że ten dodatkowy mikroserwis zajmuje tylko kilkadziesiąt MB a nie kilka GB uniknęliśmy rozmów typu "a o ile to podniesie rachunek za chmurę"? Bo gdyby potrzebował gigabajtów to trzeba by zmienić specyfikację zasobów i ostatecznie dać większe instancje. A tak idzie jako sidecar, którego praktycznie nikt nie zauważy.
0
Krolik napisał(a):
Z kompilacją AOT to też problem specyficzny dla Javy.
A C#? Czy uważamy że C# to Java M$ :P
Ktoś zapewne zaraz wyleci tu z tym że obecnie komputery mają dziesiątki GB RAMu i że to premature optimization
Ja to przerabiałem. Java z OSGi w Dockerze wysyłane do AWSa w USA (bo taniej). Dużo kawy można było wypić czekając na deploy. Jak usuneliśmy OSGi to śmigało tak szybkoże aż byliśmy w szoku. I wstawało też tak szybko że byliśmy w szoku. Picie kawy się skończyło
0
Krolik napisał(a):
Z kompilacją AOT to też problem specyficzny dla Javy. W Java AOT jedyne co daje to przyspieszenie czasu startu, kosztem spowolnienia działania. Natomiast nie oznacza to że te zalety są tak znikome w innych językach z AOT. Po prostu Java jako język nie była projektowana pod kompilacje statyczna i dlatego bardzo trudno się optymalizuje.
Kompilacja i linkowanie statyczne pozwalają uzyskać niesamowicie małe, szybkie i lekkie binarki, idealnie nadające się do uruchamiania w kontenerach w chmurze, ale trzeba użyć innego języka (Rust, Go, Zig, C, C++). (...)
golang też się wlicza? golang ma gc z dużym narzutem wydajnościowym. czytałem też, że kompilator golanga stawia na szybkość kompilacji, a nie na szybkość działania programu, więc nie robi zasobożernych optymalizacji (biorąc pod uwagę czas kompilacji).
4
@Krolik: Wydaje mi się, że przeceniasz wpływ AOC/JIT na ostateczną wydajność programu. W Javie te techniki miały zapewnić optymalizację podczas przełożenia bytecode na kod maszynowy i dostosować wynik do konkretnej maszyny. Tym czasem, największym problemem wydajności aplikacji w Java jest nie język, tylko pisany na pałę kod, bez myślenia o zużyciu CPU, zajętości pamięci itd. Jak ktoś pakuje w kontener serwer JEE, albo SpringBoota z Tomcatem i wszystkimi możliwymi zależnościami, to szybko i oszczędnie nie będzie.
0
@PiotrPro: jak dla mnie pakowanie javy enterprise do hello worldów to i tak mały pikuś, bo rynek to zweryfikuje. większym problemem (i jednocześnie równo olewanym przez prawie wszystkich programistów) jest złożoność obliczeniowa. o(n^2) czy o(n lg n) - nie ma różnicy dla typowego klepacza. co najwyżej się zrównolegli program na wiele instancji 
1
@Krolik: to, że java jest straszliwie dynamiczna i przez to trudna do zoptymalizowania pod statyczną kompilację to prawda, ale jeśli chodzi o małe binarki to co w sumie przeszkadza?
Główny problem, który znam to granuralność obecnego AOT na poziomie klas (w sumie to nie wiem jak naprawdę jest, ale tak to wygląda z boku) - czyli nie wywalimy kodu metod, które nie są używane, bo nie wiemy które to, ale czy coś jeszcze?
0
KamilAdam napisał(a):
Krolik napisał(a):
Z kompilacją AOT to też problem specyficzny dla Javy.
A C#? Czy uważamy że C# to Java M$ :P
pewnie nie wspomina, bo nie chce tracić łapek od @somekinda
0
Wibowit napisał(a):
KamilAdam napisał(a):
Krolik napisał(a):
Z kompilacją AOT to też problem specyficzny dla Javy.
A C#? Czy uważamy że C# to Java M$ :P
pewnie nie wspomina, bo nie chce tracić łapek od @somekinda
Nie dałem łapki Królikowi za pisanie o Javie czy jakimkolwiek innym języku, tylko za sensowne moim zdaniem podejście do korzystania z zasobów chmurowych.
1
somekind napisał(a):
Nie dałem łapki Królikowi za pisanie o Javie czy jakimkolwiek innym języku, tylko za sensowne moim zdaniem podejście do korzystania z zasobów chmurowych.
no faktycznie. jak klepać coś na chmurę to tylko w rust/c/c++ i to z intrinsics :/ . chmura sama w sobie jest optymalizacją kosztów. nie widzę powodu, by zmieniać język przechodząc na chmurę.
no i gdybyś sam zaczął stosować to "sensowne twoim zdaniem" podejście to przerzuciłbyś się z c# na rust/c/c++. planujesz?
2
Wibowit napisał(a):
no i gdybyś sam zaczął stosować to "sensowne twoim zdaniem" podejście to przerzuciłbyś się z c# na rust/c/c++. planujesz?
Sam stosuję to podejście, nie potrzebuję do niego żadnego rusta ani C++.
Jak napisałem, nie chodziło o języki, tylko właśnie o podejście polegające na tym, że myśli się o tym, ile zasobów zżera soft, a nie wychodzi z założenia o gigabajtach RAMu.
2
somekind napisał(a):
Wibowit napisał(a):
no i gdybyś sam zaczął stosować to "sensowne twoim zdaniem" podejście to przerzuciłbyś się z c# na rust/c/c++. planujesz?
Sam stosuję to podejście, nie potrzebuję do niego żadnego rusta ani C++.
Jak napisałem, nie chodziło o języki, tylko właśnie o podejście polegające na tym, że myśli się o tym, ile zasobów zżera soft, a nie wychodzi z założenia o gigabajtach RAMu.
eeee, ale przecież te wady co wymienił Królik w mniej więcej takim samym stopniu dotyczą javy co .neta. z tego co zrozumiałem to @Krolik postulował, żeby przerzucić się z tych ciężkich platform (.net czy java) na te lekkie (c/c++/rust/golang/etc).
1
Krolik napisał(a):
Z kompilacją AOT to też problem specyficzny dla Javy. W Java AOT jedyne co daje to przyspieszenie czasu startu, kosztem spowolnienia działania. Natomiast nie oznacza to że te zalety są tak znikome w innych językach z AOT. Po prostu Java jako język nie była projektowana pod kompilacje statyczna i dlatego bardzo trudno się optymalizuje.
a co jeśli to nie natura javy, a żądza pieniądza jest większym problemem? native image w wersji płatnej ma dużo wyższą wydajność niż wersja community i dorównuje wydajnością standardowemu jitowi:
https://blogs.oracle.com/java/post/graalvm-enterprise-213
https://www.infoq.com/articles/native-java-graalvm/
przypomnę też, że w wersji community native-image ma bardzo kiepski garbage collector.
o ile dobrze pamiętam to sami programiści oracla przyznali, że nie ma jakichś konkretnych powodów dla których java aot miałaby być wolniejsza od javy jit, oprócz tego, że jit był dopieszczany przez dekady, a aot to względnie dalej nowinka w świecie javy.
2
Wibowit napisał(a):
eeee, ale przecież te wady co wymienił Królik w mniej więcej takim samym stopniu dotyczą javy co .neta. z tego co zrozumiałem to @Krolik postulował, żeby przerzucić się z tych ciężkich platform (.net czy java) na te lekkie (c/c++/rust/golang/etc).
No dobrze, nie przeczę, że tak napisał. Nie przeczę, że dotnet ma te same problemy co Java. Łapkę dałem wyłącznie za ten fragment, bo jest zgodny z moim sumieniem:
Ktoś zapewne zaraz wyleci tu z tym że obecnie komputery mają dziesiątki GB RAMu i że to premature optimization. A jednak dzięki temu że ten dodatkowy mikroserwis zajmuje tylko kilkadziesiąt MB a nie kilka GB uniknęliśmy rozmów typu "a o ile to podniesie rachunek za chmurę"? Bo gdyby potrzebował gigabajtów to trzeba by zmienić specyfikację zasobów i ostatecznie dać większe instancje. A tak idzie jako sidecar, którego praktycznie nikt nie zauważy.
Tobie też daję łapki, jak napiszesz coś, z czym się zgadzam, więc nie musisz już doszukiwać się wszędzie zdrady. :*
0
somekind napisał(a):
Tobie też daję łapki, jak napiszesz coś, z czym się zgadzam, więc nie musisz już doszukiwać się wszędzie zdrady. :*
mój oryginalny przytyk był pół-żartem, pół-serio (chociaż tego wprost nie zaznaczyłem). nie doszukuję się zdrady, a raczej hipokryzji i bezsensu. robisz te mikroserwisy na kilkadziesiąt megabajtów zużycia zasobów? nie lepiej upchać nową funkcjonalność do któregoś istniejącego mikroserwisu niż zmieniać język, by zrobić osobnego mikrusa?
jak dla mnie to jest nawet lekki hype (w moim zespole) na rozmnażanie mikroserwisów. zamiast zastanowić się gdzie jest wąskie gardło (zwykle baza) i czy faktycznie coś wymaga fikuśnej architektury to od razu jest pęd do robienia nowego mikroserwisu, bo to niby automatycznie oznacza, że "będzie szybciej". jak dla mnie to im więcej mikroserwisów tym więcej kosztu utrzymania i narzutu na komunikację między nimi, więc trzeba to wyważyć w zależności od okoliczności. nie twierdzę, że trzeba robić mało opasłych mikroserwisów, ale robienie np. 100 mikrusów w 5-osobowym zespole to przesada.
1
Wibowit napisał(a):
mój oryginalny przytyk był pół-żartem, pół-serio (chociaż tego wprost nie zaznaczyłem). nie doszukuję się zdrady, a raczej hipokryzji i bezsensu.
Ja nie muszę pisać w tym samym języku, co ktoś inny, żeby go łapkować. Oceniam sens posta, nie technologie, czy autora. Nie widzę tu hipokryzji.
robisz te mikroserwisy na kilkadziesiąt megabajtów zużycia zasobów?
Staram się jak najmniejsze po prostu.
Ale ja mam takie realia biznesowo-technologiczne, ktoś inny ma inne.
nie lepiej upchać nową funkcjonalność do któregoś istniejącego mikroserwisu niż zmieniać język, by zrobić osobnego mikrusa?
Ficzery do mikroserwisów dodaje się ze względów biznesowych, nie technologicznych. Języka bym nie zmieniał, po prostu zrobił oddzielny serwis w tym samym. U nas nie ma aż takiego ciśnienia na zużycie pamięci, ale umiem sobie wyobrazić, że u @Krolik kryteria są inne.
jak dla mnie to jest nawet lekki hype (w moim zespole) na rozmnażanie mikroserwisów. zamiast zastanowić się gdzie jest wąskie gardło (zwykle baza) i czy faktycznie coś wymaga fikuśnej architektury to od razu jest pęd do robienia nowego mikroserwisu, bo to niby automatycznie oznacza, że "będzie szybciej". jak dla mnie to im więcej mikroserwisów tym więcej kosztu utrzymania i narzutu na komunikację między nimi, więc trzeba to wyważyć w zależności od okoliczności. nie twierdzę, że trzeba robić mało opasłych mikroserwisów, ale robienie np. 100 mikrusów w 5-osobowym zespole to przesada.
No nie wyobrażam sobie utrzymywania 100 mikroserwisów przez 5 osób. Nie spotkałem się też nigdy z technicznymi czy wydajnościowymi powodami do wydzielania mikroserwisów. To zawsze jest powód biznesowy, ergo serwis ma po prostu pełnić zbiór powiązanych ze sobą funkcji. A wąskimi gardłami są głównie 3rd party libraries utrzymywane przez jednego Pakistańczyka z Kanady, które ktoś kiedyś wciągnął do projektu. ;)
0
@somekind:
no wiadomo, że w konkretnej aplikacji ma być zbiór powiązanych ze sobą funkcji, a nie przypadkowe rozlosowanie funkcji po mikroserwisach. wiadomo też, że unikanie szalonego zużycia zasobów to coś co powinno być priorytetem. to takie trywializmy, że nie widzę powodu by się o tym rozpisywać i plusować. wracając do wcześniejszej dyskusji: w poście Królika nie chodziło o takie wysokopoziomowe decyzje projektowe, a o czyste technikalia, tzn. o to, że w javie niby nie da się zejść do tych kilkudziesięciu megabajtów zajętości pamięci dla całego mikroserwisu.
znów się dałem wciągnąć w bezsensowną dyskusję, bo @Krolik i @somekind mnie sprowokowali. @Krolik wstydziłbyś się :)
0
somekind napisał(a):
No nie wyobrażam sobie utrzymywania 100 mikroserwisów przez 5 osób. Nie spotkałem się też nigdy z technicznymi czy wydajnościowymi powodami do wydzielania mikroserwisów. To zawsze jest powód biznesowy, ergo serwis ma po prostu pełnić zbiór powiązanych ze sobą funkcji. A wąskimi gardłami są głównie 3rd party libraries utrzymywane przez jednego Pakistańczyka z Kanady, które ktoś kiedyś wciągnął do projektu. ;)
To już będzie off-top do off-topu, ale co jest złego w utrzymywaniu 100 mikroserwisów przez 5 osób? Napisałem kiedyś usługę, która pobierała obrazek.png z jakiegoś storage, robiła z niego obrazek.jpg i obrazek.gif, ładowała na inny storage. Mam wrażenie, że napisałem ją tak, że działa, skalowanie było potrzebne, nie ma żadnego kontaktu ze światem zewnętrznym i nawet podatności nie bardzo są powodem do zmiany tego kawałka, więc nie przewiduję, żeby ktoś musiał zajrzeć do tego kodu przez następne 10 lat, a jak zajrzy, to będzie musiał przeczytać może 100 linii kodu i raczej nie spędzi nad tym więcej niż pół dnia. Powód to utrzymywania tego jako osobnego komponentu też jest, bo raz na 3 godziny wpada pierdylion obrazków i trzeba je przekonwertować na szybkości.
0
Wibowit napisał(a):
somekind napisał(a):
no faktycznie. jak klepać coś na chmurę to tylko w rust/c/c++ i to z intrinsics :/ . chmura sama w sobie jest optymalizacją kosztów. nie widzę powodu, by zmieniać język przechodząc na chmurę.
Chmura nie bardzo jest optymalizacją kosztów. Jeżeli przeniesiesz instalacje on-prem 1:1 do chmury to masz 99/100 szans że zapłacisz więcej. Chmura daje za to pewne możliwości i wygodę której nie masz w przypadku klasycznej serwerowni, a jak umiesz sensownie wykorzystać te możliwości to faktycznie możesz obniżyć koszty.
Olbrzymia zaletą chmury jest możliwość skalowania aplikacji i płacenia tylko za to co faktycznie zużywasz. Ale do tego musisz mieć inną architekturę aplikacji, zwykle oparta na małych i lekkich mikroserwisach, które możesz szybko startować / zatrzymywać w miarę potrzeby. I teraz jak masz dużo takich serwisów to naprawdę ma znaczenie czy serwis potrzebuje 100 MB RAMu czy 8 GB i ile miejsca zajmuje obraz.
A język to oczywiscie drugorzędna sprawa i zgadzam się z @somekind że tu bardzo dużo też zależy od podejścia. Można serwis w Java zbloatować do poziomu gigabajtów, a można się pilnować i tragedii pewnie nie będzie.
Choć i tak moje doświadczenie jest takie, że w językach zaprojektowanych od początku pod AOT dużo łatwiej tę lekkość osiągnąć bez wielkich wyrzeczeń i dodatkowych komplikacji.
3
@Krolik: Zależy jak liczysz. Koszty utrzymania własnej serwerowni, to też gość, który będzie tam chodził i wymieniał dyski w macierzach, możliwe, że potrzeba 24/7, to gości będzie więcej, ochrona, prąd, zapasowy prąd, łącza internetowe itd. Nawet jeżeli ktoś na pałę przeniesie swoje VM'ki z piwnicy w chmurę, to jest spora szansa na jakieś tam oszczędności na samym utrzymaniu infrastruktury. Jeżeli firma prowadzi jeszcze development, to fakt, że np. postawienie serwera baz danych, czy dodanie kilku node'ów trwa moment nie pozostaje bez znaczenia na koszt projektu, bo zespół developerów, czekający na miejsce do postawienia jakiejś tam usługi przez 3 miesiące, aż przyjdzie serwer, później przez kolejne 3 miesiące aż przyjdzie switch, bo gniazdek zabrakło to też kasa, nawet jeżeli policzysz same pensje, bez szacowania finansowych skutków opóźnienia się projektu i nie policzysz kosztów wycofania się z jakiegoś pomysłu.
Oczywiście, jak podejdziesz do tego z odrobiną rozsądku, czyli postawisz na usługi zarządzalne, konteneryzację, mikroserwisy skalowalne horyzontalnie, czyli ogólnie to co kryje się za modnym aktualnie hasłem "cloud native", to można drastycznie te koszty ograniczyć i co równie ważne przyśpieszyć implementację.
Masz też rację z dbaniem o wydajność, bo pewną wadą chmury jest to, że jak masz g... serwis, to bardzo łatwo dojść do konkluzji, że on musi brać tyle zasobów ile bierze, jak mu nie starcza, to trzeba go postawić na wydajniejszej maszynie - suwak w prawo i problem rozwiązany za jedyne $100 miesięcznie.