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.