Современные альтернативы упаковке и развертыванию корпоративных приложений?

Каковы современные альтернативы пакетному и развертыванию серверного java-программного обеспечения ¹⁾ в гетерогенных средах ²⁾?

Я не мог найти много согласованной или актуальной информации по этой теме, но у меня есть несколько идей. Я начну

Традиционный подход к серверу приложений (Jetty, Tomcat и т.д.).
- Соберите программное обеспечение в файлы war и создайте собственные средства обеспечения и развертывания script, например, используя izpack, ant скрипты, cargo или что-то подобное.
Полагайтесь на платформы интеграции, например fabric8, servicemix, fuse и т.д.
- Похоже на хороший упрямый подход. Если вы еще не используете один из них, помимо блокировки, повторное развертывание приложения в этом формате требует некоторой работы. Разве тренд не отходит от больших рамок?
Пакет приложений war в файлы ear (Enterprise archives)
- Требуется полноценный java-сервер EE, например wildfly, glassfish и т.д. Если возможности такого сервера не нужны, он добавляет много накладных расходов на то, что может сделать zip-архив уже.
Виртуальные машины: Vagrant, Docker и т.д.
- Docker хорош, но на хосте Windows все равно нужно запускать виртуальную машину. Виртуальные машины (бродячие или нет) несут накладные расходы на производительность и склонны полагаться на сложные средства обеспечения ресурсов, такие как puppet или salt.
Runnable jars, например Capsule, плагин maven shade, One-JAR.
- Capsule кажется замечательным, это как исполняемый, самораспаковывающийся zip файл, который также запускает приложение. С встроенным приложением несколько традиционных war файлов могут быть поданы из одного исполняемого файла.

Первым вариантом является мой ссылочный подход на долгое время, но для него требуется много средств для создания, установки сценариев, которые варьируются в разных средах (например, Linux, Windows).

Какие современные альтернативы облегчают упаковку и развертывание?

^{1) Создайте изображение, подобное SOA, с помощью микросервисов, связи RESTful и т.д.}
^{2) Имея это в виду, пусть исключают PaaS поставщиков, таких как облачные облака, облачные и т.д. Они заслуживают отдельной темы.}

Ответ 1

Я рекомендую прочитать документ The Twelve-Factor App, вдохновленный шаблонами архитектуры корпоративных приложений и рефакторинга Мартина Фаулера. Он предлагает следующее:

Для каждого приложения должно быть codebase (система управления версиями), а также множество развертываний приложения в разных средах (разработка, постановка, производство).
Dependencies должны быть явно объявлены и изолированы (никогда не полагаясь на неявное существование общесистемных пакетов или системных инструментов).
Config (все, что может варьироваться в зависимости от развертывания) должны храниться в среде, никогда в коде.
Резервные службы (включая другие приложения) должны рассматриваться как подключенные ресурсы, доступ к которым осуществляется через локаторы/учетные данные, хранящиеся в Config.
Сборка, выпуск и запуск должны быть строго отделены друг от друга.
Приложение должно выполняться как один или несколько безстоящих и share-nothing processes (состояние никогда не должно храниться в "липких сеансах", но в хранилище данных который предлагает время истечения срока действия.)
Приложение должно быть полностью автономным (обычно добавляя в приложение библиотеку веб-сервера), экспортируя HTTP в качестве службы привязки к порту.
Из-за разветвленной природы приложения с двенадцатью коэффициентом processes, добавив больше concurrency должны быть просто и надежно достигнуты с помощью модели процесса.
Приложение должно обрабатывать disposability, обеспечивая быстрый запуск и грациозное завершение работы.
Разработки, настройки и производственные среды должны быть как можно более похожими (Dev/prod parity).
Приложение должно обрабатывать logs как потоки событий, никогда не относящиеся к его маршрутизации или хранению.
Процессы администратора должны выполняться как одноразовые процессы.

Там также статья о Microservices Джеймса Льюиса и Мартина Фаулера, в которой перечислены некоторые из перечисленных выше идей.

Что касается упаковки и развертывания, то следующие рекомендации:

Компонент через службы

Приложения (и их микросервисы) должны быть реализованы как компоненты вне процесса (а не внутрипроцессные библиотеки), которые могут быть независимо заменены, обновлены и развернуты. Компоненты обеспечивают более явный интерфейс компонента, используя явные механизмы удаленного вызова.
Организован вокруг возможностей бизнеса

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

Приложения, созданные из микросервисов, должны быть поставлены с использованием простых протоколов RESTish. Двумя наиболее часто используемыми протоколами являются HTTP-запрос-ответ с API-интерфейсом ресурсов и легкая передача сообщений по немой шине (например, RabbitMQ или ZeroMQ).
Автоматизация инфраструктуры

Операционная сложность построения, развертывания и эксплуатации микросервисов может быть уменьшена путем автоматизации с помощью Непрерывной доставки или ее предшественника Непрерывный Интеграция.

Ответ 1

Ответ 2