Андрей ПанфиловА при использовании докера каким образом редеплой происходит? контейнер удаляется и создается новый, разве не так? это типа не считается за "перезагрузку"?


Правильно!
Вот только перегрузка/редеплой контейнера в котором крутиться один сервис это гораздо проще.
Чем сервер приложений, на котором крутиться куча приложений, сервисов и пр.

Андрей Панфиловкостыль из-за которого проблемы в приложении менее заметны, но это все равно проблемы приложения.


Угу нет приложений, нет проблем!
Если это проблемы всех приложений, а не некоторых. Может все таки в инфраструктуре есть проблемы?! :-)

Андрей Панфиловага, а для докера не нужна армия девопсов со смузи на гироскутерах...

Для докера - отчасти. И то, чтобы осуществлять горизонтальное масштабирование.
А так все настройки приложения ложатся на плечи программистов.

ImperousПочитал и понял что таки надо было уточнить вопрос (посчитал что это само собой разумеется), интересовал момент - как "делается" энтерпрайз, берут spring-core и добавляют только то что нужно, производя тонкую настройку, или уже ушло то время когда заботились о чистоте и памяти, ведь намного проще взять все и сразу, при этом не используя 60% функционала?
Мне думается так, что на пьянку нужен алкоголь, соленья и мясо, и совсем никчему зефир и аквариум с рыбками и плоскогубцы.
Опыта нет, вот и спрашиваю.

Ну как бы да.
Но есть "нюансы".
Т.к. есть jar-hell, то модули Spring тянут за собой, по транзитивным зависимостям, все библиотеки, с которыми он совместим.
Не все они нужны в вашем приложении.
Чтобы не тянуть лишнего, можно, например через maven, указать, что вам точно не нужно.
Но для этого надо анализировать дерево зависимостей и знать, за что та или иная библиотека отвечает.
Обычно никто этим не заморачивается, ибо "фигак-фигак и в продакшен".
Но тонкий тюнинг возможен. И никто вам не запрещает этим заморочиться.

Андрей ПанфиловЯ чет принципиальной разницы здесь не вижу:
- во-первых versioning deployment придуман ну очень давно
- во-вторых, ну не нравится на одной ноде размещать приложения, размещайте на разных, никто не не запрещает
- в-третьих, не нравится долгий старт - ну делайте стейтлесс с балансировкой, сейчас же так принято, не?


Ага разницы нет. Толи навернется все ИС развернутые на сервере приложении, то ли навернется один контейнер, который тут же будет убит и поднят новый.
И вот не надо про ноды. Приколы, когда сессия гуляет между нодами достаточно "нахлебался".
К этому еще рассинхронизация нод. Когда "неожиданно" на одном кластере разные версии приложения.
И синхронизация происходит через танцы с бубном.
Ну а если делать стетйлесс, то нафига мне сервер приложений?! Когда то же spring boot приложение проще и дешевле разрабатывать и развертывать, чем заниматься церебральным сексом с сервером приложений?

Андрей ПанфиловНет, проблема конкретно с вашим приложением, квантор всеобщности здесь недопустим.



А вот и нет.
Проблема в любом приложении.
Не важно кем и когда написано.
Если его постоянно редеплоить будет утечка памяти в загрузчике классов.
Особенности архитектуры сереров приложений.

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

Вам нет. Бизнесу да.
Они нам деньги платят.
И бизнес во время звонка деньги теряет.
Поэтому и разработаны и разрабатываются методики разработки приложений, при которой необоходимость в поддержке была минимальна.
Как говориться бизнес и ничего личного :-)

andreykaTа насчет мониторинга - так але )) монолит чтоле мониторить не нада?

А смысл?!
Если монолит упадет, то все равно пока не найдешь в каком месте "падает" ничего работать не будет.
С МС сложнее. Там если что для конкретного сервиса-"бутылочное горлышко", можно инстансов подкинуть.
Так что мониторинг начинает иметь смысл.

<:o)

Petro123mad_nazgulЕсли монолит упадетмониторят до падения. Юз кейс не тот.

И-и-и.
Например увидят вдруг офигенное потребление памяти...
Что делать?

Андрей ПанфиловandreykaTименно пусть развораяиванием всего этого зоопарка занимаются мальчики со смузи и на самокатах. а я такой царь буду им только джарники подкидывать нет, мальчики со смузи для начала должны настроить CI/CD, а потом выковыривать оттуда артефакты сборки, я хочу только mvn release:prepare и git push запускать.

Да. Причем если взять, например, gitlab, настройка CI/CD это "next->next->ok"
А потом можно только git push делать :-)

Андрей Панфиловmad_nazgulДа. Причем если взять, например, gitlab, настройка CI/CD это "next->next->ok"
А потом можно только git push делать :-)Чет теперь не удивлен почему у вас с деплойментом в вебсферу проблемы и класслоадеры текут: вы долбаный ретроград, мода на рельсы уже давно прошла, нужно срочно брать что-то на элексире - там будет и в вебсферу нормально деплоится и класслоадеры течь не будут.

Зачем тогда здесь ВебСфера?!
Точно так же будет работать на томкате или джетти :-)