po co serwery aplikacyjne (Spring boot)

0

Na przestrzeni ostatnich kilku lat zetknąłem się z kilkoma monolitycznymi aplikacjami opartymi na spring boocie. Deploy każdej z nich polegał na umieszczeniu wara na serwerze aplikacyjnym. Najmniej szkodliwy był mechanizm polegający na tworzeniu obrazu dockerowego na bazie tomcata i przekopiowaniu zbudowanego wara w Dockerfile'u. Ale oprócz tego zdarzały się jakieś ręcznie ogarniane WildFly-ie, Tomcaty, itp.

Pytanie - po co? Dlaczego w nowoczesnych aplikacjach ludzie bawią się w stawianie jakiś AS i kopiowanie warów. Czy nie mogę po prostu zrobić jara z embedded tomcatem i się niczym nie przejmować? To jakiś kult cargo czy ja po prostu o czymś nie wiem i taki ręcznie zarządzany AS ma jakieś plusy?

4

Możesz. I tak robisz w nowoczesnych aplikacjach.

8

Czy nie mogę po prostu zrobić jara z embedded tomcatem i się niczym nie przejmować? To jakiś kult cargo czy ja po prostu o czymś nie wiem i taki ręcznie zarządzany AS ma jakieś plusy?

Chyba przespałeś długi czas bo własnie tak się robi od kilku ładnych lat. Ewentualnie masz stary projekt ;)

3

Taki serwer aplikacyjny enterprise to nie tylko kontener serwletów, tylko sporo dodatków typu konfigurowanie puli wątków (monitoring z paczki), pule połączeń do źródeł danych czy kolejek (oczywiście enterprise) i inne rzeczy, które konfigurowali sobie - nie wiem - admini? Często z własną dystrybucją Javy. Na jednym serwerze można stawiać wiele apek. Kiedyś skalowalo się głównie wertykalnie dodając do maszynki więcej węgla, myślenie o wielu węzłach może i było, ale na pewni nie tak popularne. Tylko, że to było ok. 10-15 lat temu.

0

Taki embaded tomcat jest dobry do profilu lokalnego, nawet jak masz na prodzie Webshepry itd.

Aplikacje klasy Enterprise uzywaja „ciężkich” środowisk by robić bardziej skomplikowane rzeczy w szybszy sposób.
Przychodzi taki admin, kilka zgodnie z jakaś instrukcja tworząc środowisko i fajnie.
Tobie jest potrzebne środowisko by stestowac jeden, ewentualnie kilka modułów, wiec możesz to robić embaded tomcat.

Minus jest taki by uważać, przy robieniu profili excludujac Jarki które będą się gryzły na dwóch profilach.

5

@DKN:

Aplikacje klasy Enterprise uzywaja „ciężkich” środowisk by robić bardziej skomplikowane rzeczy w szybszy sposób.

Czyli jakie?

Generalnie obecnie serwer aplikacyjny Java EE obecnie nic nie daje, a mocno przeszkadza. Serwery aplikacyjne javowe miały jakiś sens - w latach 1999-2003 (czyli na samym początku) - potem ich sens znacznie się zmniejszył. A od czasów dokeryzacji to te serwery nie mają już żadnych zalet i są tylko koszmarną kulą u nogi. I dla prtogramistów i dla opsów. Konfiguracje tych webspherów na produkcji to koszmar - w każdej większej firmie są jakieś dodatkowe rozwiazania skryptowe, żeby sobie z tym radzić, które dodatkowo co jakiś czas się rypią, albo trzeba zmieniać bo wchodzi nowy websphere. JBoss, Wildfly też nie lepszy.

Programowanie z serwerami aplikacyjnymi nigdy nie było szybkie i nigdy te serwery nie grzeszyły wydajnością. Chociaż nie ukrywam, że kiedy nie znałem alternatyw to JBoss wydawał mi się naprawdę fajny i byłem fanatykiem .earstwa.

Przy okazji: wbudowanego tomcata też uważam za pomysł przestarzały - po prostu krok pośredni do normalności - czyli prostej biblioteki do rest. (zobacz np. ktor, javalin, czy choćby spring webflux). Z punktu widzenia wdrożenia to samo - mamy po prostu .jar, ale nie ma całej machinerii tomcatowej związanej z classloaderami, zasobami javaee itp. której i tak w zasadzie się nie używa.

0

@jarekr000000: Nie chciałem się przedstawić jako zwolennik websphera czy innych ciężkich kalibrów serwerowych, jednak dla celu dyskusji, utrzymam to stanowisko.

Najważniejsza rzeczą jest to, ze pewne rzeczy stają się klikologiczne. Jakie?
Kolejki,
Jndi, pula połączeń.
Zasób memory/cpu zajmowany przez kontretne aplikacje.
Pula wątków.
Masz możliwość monitoringu.

Ma to na celu wcześniej wspomniana, klikologiczną konfigurowalność aplikacji.

6

Najważniejsza rzeczą jest to, ze pewne rzeczy stają się klikologiczne. Jakie?
Kolejki,

Nie są klikologiczne, bym powiedział, że zrobienie kolejek jakichkolwiek od rabbitmq czy kafkę jest prostsze bez serwera aplikacji (bo nie trzeba dodaktowo tego definiować w specyficzny dla serwera sposób).

Jndi, -

specyficzna dla Java EE rzecz, pytanie po co Ci JNDI? - to jakby zaletą samochodu było lanie do niego benzyny.

Jak juz do najbliższą alternatywą do JNDI jest zookeeper - ale po prawdze wykorzystuje się go do rzeczy, których JNDI nigdy nie miało (leader election np)

pula połączeń.

Jakich połączeń? Bazodanowych? Nawet nie zauważam, ze mam je skonfigurowane - nie muszę do tego serwera mieć (głupi spring to ma bez serwera).
Bez springa to są 3-4 linijki w kodzie. Od dawna. Tyle co ta konfiguracja w Java EE - tylko masz wybór i łatwiej debugować jak się coś rypie.

Zasób memory/cpu zajmowany przez kontretne aplikacje.

No właśnie - w praktyce 99% aplikacji było odpalanych pojedynczo - jeden serwer - jedna aplikacja - więc zwykłe mierzenie zużycia na poziomie VM okazało się o wiele sensowniejsze.
Odpalanie kilku aplikacji na jednym serwerze to zawsze była droga do frustracji i szukania winnych - karania niewinnych. JVM pozwala dość ładnie izolować logikę aplikacji dzięki classloaderow, ale niestety całość wywala się na rzeczach typu GC. Wyciek pamięci w jednej aplikacji potrafi powodować OutOfmemory w zupełnie innej (co zresztą widziałem kilka razy). Dlatego już od wielu lat się tak nie robiło.

Pula wątków.

Znowu - rzecz dostępna w JDK... od dawna. Co więcej nowoczesne apliakcje robi się bez wątków (non blocking).

Masz możliwość monitoringu.

Jak już wyżej - ten monitoring jest w praktycznie każdej sensownej bibliotece, ma to Spring, a niezależnie zupełnie sensowny zwykle zapewnia Ci infrastruktura (cloud).

Serwery aplikacji powstały z koncepcji uruchamiania kilku aplikacji na jednej JVM - dzięki współdzieleniu zasobów i cześci kodu mozna było oszczędzić RAM.
RAM potaniał, a koncept okazał się męczący.

Tu jeszcze warto wyróżnić koncepcję JavaEE, która choć związana z serwerami aplikacji miała dodatkowe cele. Przez wiele lat mówiło się, że centralnym konceptem JavaEE są rozproszene transakcje - to faktycznie było coś. Coś, co się nie sprawdziło jak aplikacje zaczęły rosnąć i mieć wiecej niż kilkaset użytkowników.

2

Najważniejsza rzeczą jest to, ze pewne rzeczy stają się klikologiczne. Jakie?
Kolejki,
Jndi, pula połączeń.
Zasób memory/cpu zajmowany przez kontretne aplikacje.
Pula wątków.
Masz możliwość monitoringu.

Ma to na celu wcześniej wspomniana, klikologiczną konfigurowalność aplikacji.

Przecież możesz te wszystkie rzeczy wczytywać na starcie z jakiegoś aplication.properties albo ze zmiennych systemowych. W przypadku JBossa miałbyś XML w przypadku application.properties plik... properties ;)
Gdzie tu zaleta serwerów aplikacyjnych?

1 użytkowników online, w tym zalogowanych: 0, gości: 1