Использование инфраструктуры виртуализации для распространения приложений Java EE - приемлемая альтернатива? - PullRequest
2 голосов
/ 11 апреля 2010

Наша компания разрабатывает индивидуальные веб-решения для Java EE. На данный момент мы используем стандартные механизмы распространения Java EE (архивы ear / war). Серверы приложений, как правило, администрируются ИТ-отделами наших клиентов, и, поскольку мы не имеем полного контроля над средой, в решение может быть включена большая энтропия. Например:

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

Мы изучаем использование инфраструктуры виртуализации для распространения приложений Java EE. Вместо отправки архива ear / war мы отправили изображение с узлом сервера приложений и предустановленным приложением. Некоторые из преимуществ те же, что и при использовании инфраструктуры виртуализации в целом, а именно более эффективное использование аппаратных ресурсов. Для нас это снижает энтропию хостинг-инфраструктуры - хостинг-среда должна меньше влиять на распределение виртуальных машин.

Пока что я вижу обратную сторону в лицензиях на сервер приложений, здесь им придется использовать выделенные серверы для нашего решения, но, как правило, это уже сделано. Кроме того, обслуживание инфраструктуры виртуализации сопряжено с трудностями, но часто ИТ-отделы имеют больше опыта, чем с администрированием и тонкой настройкой решений Java EE.

Кто-нибудь имеет опыт работы с этой моделью? Каковы недостатки? Разве мы не просто заменим один тип сложности другим?

1 Ответ

1 голос
/ 11 апреля 2010

Разве мы не просто заменим один тип сложности другим?

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


Обновление: Ответ на комментарий от ОП

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

То, что вы описываете, часто случается и с моим опытом, и я понимаю, что вы говорите, но, тем не менее, даже если разрешение проблем со средой по умолчанию вам, вы не ответственны для них это огромная разница. Я не продвигаю стратегию CYA здесь, я лежу в основе разницы: если вы начнете предоставлять услуги инфраструктуры, что произойдет, если сервер выйдет из строя и если ваш клиент потеряет деньги? Это будет ваша ошибка. Поэтому, хотя модель виртуализации действительно может обеспечить более четкое разделение проблем, это имеет серьезные нетехнические последствия (юридические, финансовые), которые ваша компания должна учитывать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...