— ха, это кто трансформирует! Spring != SpringBoot. Фактически сервлеты + SpringCore + Hibernate это альтернативная имплеменатция JavaEE обретшая популярность в силу того что «юношам» сложно настраивать, развертывать (находить хостинг с поддержкой) и понимать, зачем нужен, сервер приложений. После того как первые шаги сделаны, отступать уже поздно — приходиться дальше жить с этим франкенштейном.
скорость/стоимость разработки, стоимость поддержки, а оперативной памяти можно и докинуть
— тут Java EE рулит. Вы еще забыли добавить такие слова как стабильность. Могу это все аргументировать, но если честно, то лень — легко скатиться в холивар.
если вам так важен размер файла дистрибуции
— я имел в виду иное: то что делают разработчики с помощью экосистемы Spring — это сборка функциональности JavaEE из отдельных фреймвоков. Это то чем занимались разработчики TomEE — берем Tomcat, добавляем к нему фреймворк CDI, фреймворк ORM и т д и получаем функционал JavaEE WebProfile.
— а 2.0.3? 1.5.14? Извините за стеб, но уверен Вы понимаете, что суть нашей дискуссии это выбор между: «спецификация + независимые реализации» и «решение единственного вендора с непредсказуемым циклом развития».
— отнюдь, Вы говорите что «нужна изоляция сетевого стека». Откуда взялось такое требование? Из архитектурной идеи дробления монолита. Для реализации этой идеи Вам и понадобился весь этот DevOps. Если я захочу запустить несколько сервисов развернутых на SpringBoot/Tomcat/GlassFish и т п, так чтобы «изолировать сетевой стек», мне просто придется использовать контейнеры/виртуальные машины/физические машины.
Наверное приятно сказать «смотрите какой простой сервис» и промолчать о том что для приложения построенного на его основе придется нанимать штат специалистов по DevOps. Но, если быть честным, весь этот DevOps — это следствие заложенной в приложение архитектуры, следствие дробления на изолированные сервисы.
«зачем ещё и консоли EE сервера» — она уже есть, но если не нужна, можно не использовать. В конце концов, есть минималистичные сервера приложений.
Перечитайте сказку «каша из топора» — эта та история когда берут SpringCore, цепляют к нему Hibernate, навешивают SpringMVC, SpringSecurity и т д, получают WAR размером 50+ Мб и чувствуют что еще не хватает шедулера, MailAPI и JMS)
SpringBoot — основа для сервиса, а AS — основа для крпоративной системы. Разница в необходимом функционале.
— как раз угадал (клиентов миллионы, петабайтные объемы «сырых» даных), именно замах на «мировое господство». Таких бизнесов тысячи, а вот бизнесов где масштаб гораздо меньше и где уместней JavaEE/SpringCore+Hibernate — больше на четыре порядка.
— не хватает чего то в microprofile, никто не мешает использовать более широкую спецификацию — webprofile или, наконец, full JavaEE. Главное, что это всего лишь архитектура и нет никакого конфликта со спецификацией JavaEE.
я уверен
— думаю, Вы сами понимаете, что это слабый аргумент. Чтобы выявить его слабость достаточно задать уточняющий вопрос — в какой конкретно версии SpringBoot Вы уверены?)
изоляции сетевого стека это несколько иное
— кто мешает помещать сервер приложений в Docker/OpenVZ/KVM/Xen и т д?
Вероятно Вы работаете в СберТехе или типа того, с замахом на мировое господство) Для приложений масштаба «компания 100 — 1000» сотрудников либо JavaEE, либо JavaEE-франкенштейн, собранный из Spring библиотек.
Единственное преимущество Spring — его более динамичное развитие, за счет того что это экосистема из разных фреймворков, которые развиваются независимо, в отличие от Java EE, где выход очередной спецификации — это событие.
Микросервисы — это прежде всего архитектура. В EE есть microprofile (если хочется запускать приложение как в SpringBoot). Кластеризация «из коробки» уже давно существует, также как и сетевое взаимодействие между разными инстансами сервера приложений. Что на них разворачивать — дело ваше. Делать монолит или кучу сервисов — решаете сами, к спецификации EE — это все перпендикулярно.
«Много маленьких сервисов» — много гемороя по отслеживанию их работы и настройкам. Даже новая профессия появилась — DevOps. Сложность с настройкой сервера приложений исчезла, появилась новая сложность, связанная с поддержкой инфраструктуры — т е ничего не изменилось в лучшую сторону, скорее даже стало хуже.
«Много маленьких сервисов» — куча ненужного сетевого взаимодействия, да еще и зачастую поверх HTTP, вместо передачи ссылки на объект в рамках JVM. Половина мощности процессора уходит на то чтобы обслуживать интеркоммуникации между микросервисами.
«Без завязок на стандарты» — поделия на Spring — это «каша из топора», когда надо взять десяток фреймворков, слинковать их с учетом версий (тут легко облажаться) и получить подобие функциональнсти сервера приложений, только «без гарантий».
И, да, для каждой задачи свое решение — микросервисы не нужны когда речь идет о корпоративной системе в компании с 1000 сотрудников, работающей с реляционной БД. Тезис, что «бизнесу это больше не нужно» ложный.
Статья дискуссионная) Я вот вижу, что большинство серверов приложений не успевают развитием спецификации (JavaEE 8 на 100% поддерживает только GlassFish 5, да и он не запускается на Java 9), последний TomEE датируется сентябрем 2017 и т п. А без сервера приложений JavaEE это сферический конь в вакууме.
Я удаленщик, работаю дома, в офис не хожу и использую те преимущества которые мне дает работа из дома — в жару одеваюсь легко) В скайпе этого не видно, но я и не стремлюсь — я же не извращенец! А язык тела меня не парит — я предпочитаю задания в письменном виде читать. И в офисе такой подход практиковал — совещания это хорошо, но по итогам должны быть задачи в джире с оценкой и исполнителем.
— ха, это кто трансформирует! Spring != SpringBoot. Фактически сервлеты + SpringCore + Hibernate это альтернативная имплеменатция JavaEE обретшая популярность в силу того что «юношам» сложно настраивать, развертывать (находить хостинг с поддержкой) и понимать, зачем нужен, сервер приложений. После того как первые шаги сделаны, отступать уже поздно — приходиться дальше жить с этим франкенштейном.
— тут Java EE рулит. Вы еще забыли добавить такие слова как стабильность. Могу это все аргументировать, но если честно, то лень — легко скатиться в холивар.
— я имел в виду иное: то что делают разработчики с помощью экосистемы Spring — это сборка функциональности JavaEE из отдельных фреймвоков. Это то чем занимались разработчики TomEE — берем Tomcat, добавляем к нему фреймворк CDI, фреймворк ORM и т д и получаем функционал JavaEE WebProfile.
— отнюдь, Вы говорите что «нужна изоляция сетевого стека». Откуда взялось такое требование? Из архитектурной идеи дробления монолита. Для реализации этой идеи Вам и понадобился весь этот DevOps. Если я захочу запустить несколько сервисов развернутых на SpringBoot/Tomcat/GlassFish и т п, так чтобы «изолировать сетевой стек», мне просто придется использовать контейнеры/виртуальные машины/физические машины.
Наверное приятно сказать «смотрите какой простой сервис» и промолчать о том что для приложения построенного на его основе придется нанимать штат специалистов по DevOps. Но, если быть честным, весь этот DevOps — это следствие заложенной в приложение архитектуры, следствие дробления на изолированные сервисы.
«зачем ещё и консоли EE сервера» — она уже есть, но если не нужна, можно не использовать. В конце концов, есть минималистичные сервера приложений.
SpringBoot — основа для сервиса, а AS — основа для крпоративной системы. Разница в необходимом функционале.
— думаю, Вы сами понимаете, что это слабый аргумент. Чтобы выявить его слабость достаточно задать уточняющий вопрос — в какой конкретно версии SpringBoot Вы уверены?)
— кто мешает помещать сервер приложений в Docker/OpenVZ/KVM/Xen и т д?
«Много маленьких сервисов» — куча ненужного сетевого взаимодействия, да еще и зачастую поверх HTTP, вместо передачи ссылки на объект в рамках JVM. Половина мощности процессора уходит на то чтобы обслуживать интеркоммуникации между микросервисами.
«Без завязок на стандарты» — поделия на Spring — это «каша из топора», когда надо взять десяток фреймворков, слинковать их с учетом версий (тут легко облажаться) и получить подобие функциональнсти сервера приложений, только «без гарантий».
И, да, для каждой задачи свое решение — микросервисы не нужны когда речь идет о корпоративной системе в компании с 1000 сотрудников, работающей с реляционной БД. Тезис, что «бизнесу это больше не нужно» ложный.