Совет по развертыванию файлов войны против исполняемого jar-файла со встроенным контейнером

Похоже, что в Java-пространстве существует текущая тенденция к отказу от развертывания веб-приложений Java в контейнере сервлетов Java (или сервере приложений) в форме файла войны (или файла уха) и вместо этого упакуйте приложение в виде исполняемого файла jar с встроенный сервлет / HTTP-сервер, например причал. И я имею в виду, что это больше связано с тем, как новые фреймворки влияют на разработку и развертывание новых приложений, а не на то, как приложения доставляются конечным пользователям (потому что, например, я понимаю, почему Jenkins использует встроенный контейнер, который очень легко взять и уйти. ). Примеры фреймворков, использующих вариант исполняемого файла jar: Dropwizard , Spring Boot и Play (ну, он не работает в контейнере сервлетов, но встроен HTTP-сервер).

У меня вопрос, исходя из среды, в которой мы развернули наши (до этого момента в основном Struts2) приложения на одном сервере приложений tomcat, какие изменения, передовые практики или соображения необходимо внести, если мы планируем использовать подход со встроенным контейнером. ? В настоящее время у нас есть около 10 собственных приложений, работающих на одном сервере tomcat, и для этих небольших приложений удобна возможность совместного использования ресурсов и управления на одном сервере. Наши приложения не предназначены для распространения среди конечных пользователей для работы в их среде. Однако, если мы решим использовать новую платформу Java, должен ли этот подход измениться? Стимулируется ли переход на исполняемые файлы jar к расширению использования облачных развертываний (например, Heroku)?

Если у вас есть опыт управления несколькими приложениями в стиле развертывания Play по сравнению с традиционным развертыванием военных файлов на одном сервере приложений, поделитесь своим мнением.

Интересный вопрос. Это всего лишь мой взгляд на тему, так что относитесь ко всему с недоверием. Время от времени я развертывал и управлял приложениями, используя как контейнеры сервлетов, так и встроенные серверы. Я уверен, что есть еще много веских причин для использования контейнеров сервлетов, но я постараюсь просто сосредоточиться на том, почему они менее популярны сегодня.

Краткая версия: контейнеры сервлетов отлично подходят для управления несколькими приложениями на одном хосте, но не кажутся очень полезными для управления только одним приложением. В облачных средах одно приложение на виртуальную машину кажется предпочтительным и более распространенным. Современные платформы хотят быть совместимыми с облаком, поэтому переход на встроенные серверы.

Поэтому я думаю, что облачные сервисы являются основной причиной отказа от контейнеров сервлетов. Точно так же, как контейнеры сервлетов позволяют управлять приложениями, облачные службы позволяют управлять виртуальными машинами, экземплярами, хранилищем данных и многим другим. Это звучит более сложно, но с облачными средами произошел переход к машинам с одним приложением. Это означает, что вы можете относиться ко всей машине как к приложению. Каждое приложение запускается на машине соответствующего размера. Экземпляры облака могут появляться и исчезать в любой момент, что отлично подходит для масштабирования. Если приложению требуется больше ресурсов, вы создаете больше экземпляров.

С другой стороны, выделенные серверы обычно мощные, но имеют фиксированный размер, поэтому вы запускаете несколько приложений на одной машине, чтобы максимально использовать ресурсы. Управление десятками приложений - каждое со своими конфигурациями, веб-серверами, маршрутами, подключениями и т. Д. - неинтересно, поэтому использование контейнера сервлетов поможет вам сохранить все управляемым и разумным. Однако масштабировать его сложнее. Контейнеры сервлетов в облаке не кажутся очень полезными. Их нужно будет настраивать для каждого крошечного экземпляра, что не принесет особой ценности, поскольку они управляют только одним приложением.

Кроме того, облака - это круто, а не облачные вещи - это скучно (если мы все еще верим в шумиху). Многие платформы по умолчанию стараются быть масштабируемыми, чтобы их можно было легко развернуть в облаках. Встроенные серверы быстро развертываются и запускаются, поэтому они кажутся разумным решением. Контейнеры сервлетов обычно все еще поддерживаются, но требуют более сложной настройки.

Некоторые другие моменты:

• Встроенный сервер может быть оптимизирован для платформы или лучше интегрирован с инструментами платформы (например, с игровой консолью).
• Не все облачные среды поставляются с настраиваемыми образами машин. Вместо написания сценариев инициализации для загрузки и настройки контейнеров сервлетов гораздо проще использовать специальное программное обеспечение для развертывания облачных приложений.
• Мне еще предстоит найти установку Tomcat, которая не встречала бы вас ошибкой perm gen space каждые несколько повторных развертываний вашего приложения. Немного больше времени на (повторный) запуск встроенных серверов не проблема, если вы можете почти мгновенно переключаться между промежуточными и производственными экземплярами без простоев.
• Как уже упоминалось в вопросе, конечному пользователю очень удобно просто запустить приложение.
• Встроенные серверы портативны и удобны для разработки. Сегодня все происходит быстро , прототипы и MVP нужно создавать и доставлять как можно быстрее. Никто не хочет тратить слишком много времени на настройку среды для каждого разработчика.