Porady dotyczące wdrażania plików wojennych w porównaniu z wykonywalnym plikiem jar z wbudowanym kontenerem

Wydaje się, że w przestrzeni Java istnieje tendencja do odchodzenia od wdrażania aplikacji internetowych w języku Java do kontenera serwletów Java (lub serwera aplikacji) w postaci pliku wojennego (lub pliku ear), a zamiast tego spakowania aplikacji jako wykonywalnego pliku jar z wbudowany serwlet / serwer HTTP, taki jak jetty. I mam na myśli to bardziej w sposobie, w jaki nowsze frameworki wpływają na to, jak nowe aplikacje są opracowywane i wdrażane, a nie na to, jak aplikacje są dostarczane do użytkowników końcowych (ponieważ na przykład rozumiem, dlaczego Jenkins używa osadzonego kontenera, bardzo łatwego do pobrania i użycia ). Przykłady frameworków przyjmujących opcję wykonywalnego jar: Dropwizard , Spring Boot i Play (cóż, nie działa na kontenerze serwletów, ale serwer HTTP jest osadzony).

Moje pytanie brzmi: pochodząc ze środowiska, w którym wdrażaliśmy nasze (do tego momentu głównie Struts2) aplikacje na jednym serwerze aplikacji Tomcat, jakie zmiany, najlepsze praktyki lub uwagi należy wprowadzić, jeśli planujemy zastosować podejście kontenera osadzonego ? Obecnie mamy około 10 własnych aplikacji działających na jednym serwerze tomcat i dla tych małych aplikacji możliwość współdzielenia zasobów i zarządzania na jednym serwerze jest przyjemna. Nasze aplikacje nie są przeznaczone do rozpowszechniania wśród użytkowników końcowych, aby działały w ich środowisku. Jeśli jednak zdecydujemy się wykorzystać nowszy framework java, czy to podejście powinno się zmienić? Czy przejście na pliki wykonywalne jars jest spowodowane rosnącym wykorzystaniem wdrożeń w chmurze (np. Heroku)?

Jeśli masz doświadczenie w zarządzaniu wieloma aplikacjami w stylu wdrażania Play w porównaniu z tradycyjnym wdrażaniem plików wojennych na jednym serwerze aplikacji, podziel się swoimi spostrzeżeniami.

Ciekawe pytanie. To tylko mój pogląd na ten temat, więc traktuj wszystko z przymrużeniem oka. Od czasu do czasu wdrażałem i zarządzałem aplikacjami, używając zarówno kontenerów serwletów, jak i serwerów wbudowanych. Jestem pewien, że nadal istnieje wiele dobrych powodów, dla których warto używać kontenerów serwletów, ale spróbuję skupić się tylko na tym, dlaczego są one dziś mniej popularne.

Wersja skrócona: Kontenery serwletów świetnie nadają się do zarządzania wieloma aplikacjami na jednym hoście, ale nie wydają się zbyt przydatne do zarządzania tylko jedną aplikacją. W środowiskach chmurowych pojedyncza aplikacja na maszynę wirtualną wydaje się lepsza i bardziej powszechna. Nowoczesne frameworki chcą być kompatybilne z chmurą, dlatego przejście na serwery wbudowane.

Myślę więc, że usługi w chmurze są głównym powodem porzucania kontenerów serwletów. Podobnie jak kontenery serwletów umożliwiają zarządzanie aplikacjami, usługi w chmurze umożliwiają zarządzanie maszynami wirtualnymi, instancjami, przechowywaniem danych i nie tylko. Brzmi to bardziej skomplikowanie, ale w środowiskach chmurowych nastąpiło przejście na maszyny z jedną aplikacją. Oznacza to, że można często traktują całą maszynę jak to aplikacji. Każda aplikacja działa na maszynie o odpowiednim rozmiarze. Instancje w chmurze mogą pojawiać się i znikać w dowolnym momencie, co jest świetne do skalowania. Jeśli aplikacja potrzebuje więcej zasobów, tworzysz więcej instancji.

Z drugiej strony serwery dedykowane są zwykle wydajne, ale mają stały rozmiar, więc można uruchamiać wiele aplikacji na jednym komputerze, aby zmaksymalizować wykorzystanie zasobów. Zarządzanie dziesiątkami aplikacji - każda z własną konfiguracją, serwerami WWW, trasami i połączeniami itp. - nie jest zabawne, więc korzystanie z kontenera serwletów pomaga utrzymać wszystko w zarządzaniu i zachować zdrowy rozsądek. Trudniej jest jednak skalować. Kontenery serwletów w chmurze nie wydają się zbyt przydatne. Musiałyby być skonfigurowane dla każdej małej instancji, bez dostarczania dużej wartości, ponieważ zarządzają tylko jedną aplikacją.

Ponadto chmury są fajne, a rzeczy niezwiązane z chmurami są nudne (jeśli nadal wierzymy w szum). Wiele frameworków domyślnie stara się być skalowalne, aby można je było łatwo wdrożyć w chmurach. Serwery wbudowane są szybkie we wdrażaniu i działaniu, więc wydają się rozsądnym rozwiązaniem. Kontenery serwletów są zwykle nadal obsługiwane, ale wymagają bardziej skomplikowanej konfiguracji.

Kilka innych punktów:

• Serwer wbudowany może być zoptymalizowany pod kątem frameworka lub lepiej zintegrowany z narzędziami frameworka (na przykład konsola odtwarzania).
• Nie wszystkie środowiska chmurowe mają konfigurowalne obrazy maszyn. Zamiast pisać skrypty inicjalizacyjne do pobierania i konfigurowania kontenerów serwletów, korzystanie z dedykowanego oprogramowania do wdrażania aplikacji w chmurze jest znacznie prostsze.
• Nie znalazłem jeszcze konfiguracji Tomcat, która nie wita Cię błędem miejsca perm gen co kilka ponownych wdrożeń Twojej aplikacji. Trochę więcej czasu na (ponowne) uruchomienie serwerów wbudowanych nie stanowi problemu, jeśli można niemal natychmiast przełączać się między instancjami przejściowymi i produkcyjnymi bez żadnych przestojów.
• Jak już wspomniano w pytaniu, dla użytkownika końcowego bardzo wygodne jest samo uruchomienie aplikacji.
• Serwery wbudowane są przenośne i wygodne w programowaniu. Dziś wszystko jest szybkie , prototypy i MVP muszą być tworzone i dostarczane tak szybko, jak to możliwe. Nikt nie chce spędzać zbyt wiele czasu na tworzeniu środowiska dla każdego programisty.