Hosting for Java Web App

[Мальчик-Одуванчик]

А чем это лучше деплоймента говнокода на провайдеровский application/web server?

Каждая какашка в своей баночке.

[Montchik]

Не вижу смысла в накручивании еще одной абстракции между OS/VM и hosted application server. Какашки уже упакованы в web apps.

Google App Engine в итоге разонравился по тем же причинам что и Хероку - proprietary API которая сильно привязывает к хостинг провайдеру.

Google Compute Engine is bare bone, а хочется чтобы web server was provided.

KUBERNETES - это от лукавого. Надо подождать пока пена спадет и будет видно реально ли этот контейнерный подход лучше/удобнее чем PaaS.

Опять начал вкуривать AWS, на этот раз более вдумчиво. Пока нра...

[tessob]

В AWS удобный сервис "деплоить все подряд" - ElasticBeanstalk‎. Можно просто ручками дать ему спрингбутовый джарник и забыть. У меня в продакшене так несколько десятков джарников крутится. Причем, если мало мощщи, то можно в два клика отмасштабировать на n серверов через реверс проксю (Nginx).

Только я так и не понял чем хероку не понравился. У меня там тоже сервисы в продакшене живут. Иногда просто супер-удобно деплоить изменения через интеграцию с гитхабом. Единственное различие с обычным пайплайном - нужно добавить Procfile в корень. Разонравится хероку, можно просто в одну команду собрать джарник на ноуте и затолкать на амазон. Плюс у Хероку HTTPS из коробки и с ним вообще не нужно париться.

[Montchik]

Мне показалось на минуточку что web app должна использовать heroku specific api для того чтобы ее можно было ранить на heroku hosted Tomcat. Может ошибся, не знаю.
Сечас про еще один "косяк" прочитал - heroku ожидает что web server будет embedded in the application. А что если у меня две web apps and I wanna run them on the same tomcat instance и деплоить независимо друг от друга?

[Sergunka]

Мне показалось на минуточку что web app должна использовать heroku specific api для того чтобы ее можно было ранить на heroku hosted Tomcat. Может ошибся, не знаю.
Сечас про еще один "косяк" прочитал - heroku ожидает что web server будет embedded in the application. А что если у меня две web apps and I wanna run them on the same tomcat instance и деплоить независимо друг от друга?

Архитектура в Клоуд Фоундри заточена под маштабирование микросервисов так, что вполне разумное ограничение

[Montchik]

Имхо tomcat все-таки более позиционируется как application server и его embedded версия просто дань моде. А для микросервисев лучше пользовать apache httpcomponents framework, а не tomcat.

[Sergunka]

Имхо tomcat все-таки более позиционируется как application server и его embedded версия просто дань моде. А для микросервисев лучше пользовать apache httpcomponents framework, а не tomcat.

Технически spring boot отличное решение в Cloud Foundry есть некоторые недостатки, но вполне терпимые. Микросервис в концепции Cloud Foundry это несколько другое чем просто компонент - это вполне независимое самостоятельное решение которое легко деплоится, маштабируется, имеет свое секьюрити и тд. Есть довольно много на эту тему рассуждений, что более выгодно монолит или микросервис архитектура... в зависимости от задач понятно и подход. В принципе всех кого пришлось переучивать уже как за три года начинали с монолита и были вполне так счастливы пока не возникли вопросы с маштабируемостью и производительностью...

[Montchik]

Понятно, но думаю что мне все-таки лучше пользовать app server. Наверное. Может быть.

[Vladimir Kr.]

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

[tessob]

Мне показалось на минуточку что web app должна использовать heroku specific api для того чтобы ее можно было ранить на heroku hosted Tomcat. Может ошибся, не знаю.

Зачем ранить на их томкате? Можно в спрингбуте сделать джарник с томкатом внутри и он сам себя ранить будет. Это еще и удобно, т.к. можно тестить на локальной машине. Холодный запуск при разумном подходе от 2 до 4 секунд. С девтулом некоторые вещи можно обновлять на лету.

Сечас про еще один "косяк" прочитал - heroku ожидает что web server будет embedded in the application. А что если у меня две web apps and I wanna run them on the same tomcat instance и деплоить независимо друг от друга?

Это не косяк, это фича! Если вы не любите котов микросервисы, то вы просто не умеете их готовить. ))
Если поведение ваших инстансов должно быть независимо, то возможно вам просто нужно несколько инстансов.

[Montchik]

Мне показалось на минуточку что web app должна использовать heroku specific api для того чтобы ее можно было ранить на heroku hosted Tomcat. Может ошибся, не знаю.

Зачем ранить на их томкате? Можно в спрингбуте сделать джарник с томкатом внутри и он сам себя ранить будет. Это еще и удобно, т.к. можно тестить на локальной машине. Холодный запуск при разумном подходе от 2 до 4 секунд. С девтулом некоторые вещи можно обновлять на лету.

Сечас про еще один "косяк" прочитал - heroku ожидает что web server будет embedded in the application. А что если у меня две web apps and I wanna run them on the same tomcat instance и деплоить независимо друг от друга?

Это не косяк, это фича! Если вы не любите котов микросервисы, то вы просто не умеете их готовить. ))
Если поведение ваших инстансов должно быть независимо, то возможно вам просто нужно несколько инстансов.

А за чем мне springboot если я могу задеплоить мой варик на provided tomcat server напрямую без всяких дополнительных приблуд?

Томкат можно ранить в eclipse и тут же "не отходя от кассы" деплоить и дебагить веб аппку на нем. Вообще никакие девтулы не нужны! Зачем усложнять?

ИМХО ембедить lightweight! web server нужно только если это действительно микросервис или web access есть побочная фича не веб аппликухи. К примеру у меня в realtime message processing application через веб сервис можно посмотреть it's internal state, что удобно. И не нужен для этого никакой томкат или даже джетти - apache httpcomponents framework хватило с лихвой.

Проблема с испольвованием custom api в том что будет трудно перейти на другого провайдера. Ничто не вечно и cloudefoundtry может завтра сделать все! или перестать поддерживать старые версии своих же библиотек на новых серверах. It happens!

[Sergunka]

Томкат можно ранить в eclipse и тут же "не отходя от кассы" деплоить и дебагить веб аппку на нем. Вообще никакие девтулы не нужны! Зачем усложнять?

Тоже самое можно делать и с springboot в том же эклипсе.

[valchkou]

Мне показалось на минуточку что web app должна использовать heroku specific api для того чтобы ее можно было ранить на heroku hosted Tomcat. Может ошибся, не знаю.

Зачем ранить на их томкате? Можно в спрингбуте сделать джарник с томкатом внутри и он сам себя ранить будет. Это еще и удобно, т.к. можно тестить на локальной машине. Холодный запуск при разумном подходе от 2 до 4 секунд. С девтулом некоторые вещи можно обновлять на лету.

Montchik, этот совет вам здравый.
спрингбут все в себя включает из коробочки. даже билдит executable jar(self contained microservice) для вас который стартует где угогдно где есть жава,
работает одинаково и на амазоне и на шушле и ажуре и внутри докера и без него,
томкат там не обязателен, можно использовать жетти, м даже нетти в последних версиях. Причем код не потребуется менять. Достаточно включить/исключить депенденси.
апа сама поймет какая имплементация доступна и поднимет соответствующий контейнер.

Вот вам пример такого приложения с rest api
https://github.com/valchkou-app/fibonacci-microservice

чтобы посмотреть нужно всего лишь:
- git clone
- gradlew bootRun - эта команда запустит сервис на порте 8080
- gradlew build - сдклает для вас жарник который можно запустить как "java -jar jarname"

Так как это хотите сделать вы в наши дни уже никто не делает

[Vladimir Kr.]

Так как это хотите сделать вы в наши дни уже никто не делает

может для себя-то лучше делать, не так как модно, а как лучше и правильнее?
а не с точки зрения достижения job security on microservices spaghetti architecture & make aws more profitable?

[valchkou]

Так как это хотите сделать вы в наши дни уже никто не делает

может для себя-то лучше делать, не так как модно, а как лучше и правильнее?
а не с точки зрения достижения job security on microservices spaghetti architecture & make aws more profitable?

челу вообще нужен 1 апп с рест интерфесом. Boot упрощает очень много в его задаче.
насчет спагетти, так это ваши архитекторы кривые и идея микросервисов не причем.
вы же как то решаете задачу с депенденси библиотеками?
примерно так же решается проблема совместимости сервисов. Система должна иметь consistent state основанный на версионности артифактов.
проблема в том что нельзя просто клепать микросервисы, параллельно нужно иметь экосистему.
если все организовать здраво то job security отдельного программиста как раз уменьшается. Упрощается код, сокращается время разработки и подзадачи запросто распараллеливаются и аутсорсятся.
скорее возрастает важность девопса. Архитектор всегда в цене, независисмо от кривости архитектуры
У меня свой вполне положительный опыт, без спагетти.