Bspleskmad_nazgul,

В наших банках аналогично: "Микросервисы/Битье монолитов" это, конечно, маркетинговая херня, но вот тренд всё в облако идёт сильный/лоббируемый.
Java - кстати в текущих реализациях с docker конвейеризацией не очень дружит и если её jvm не подтюнили, сожрёт по default вообще всю память при определённых кейсах и не важно сколько там 64mb или 64gb. Кстати до бизнеса стало доходить "насколько" в деньгах стало больше в сравнении когда жил кластер app-серверов и теперь ..... чешут репу.
Но зато попёр python/go/php...etc, хотя многие ужаснулись и переписывают обратно на java если сервис оказался полезным.

Ну в докер не обязательно заворачивать.
Можно через Spring-Cloud рулить.

А так микросервисная архитектура, по мне удобнее в разработке, чем монолитная. Особенно, когда это пилит команда более чем из одного человека.

Bspleskmad_nazgul,

В разработке ? ну как сказать, как было настроено (Hot-Deploy). Если раньше "кнопочка" в ide (Пример: установка плагина в confluence), то теперь .... ухх.
Кратко - java мире и так всё было зашибись, хочешь war/ хочешь jar с embedded вариантом и контейнеры и кластера и NEXUS.
Связанность, аналогично, вопрос архитектуры, всё равно будут общие библиотеки/правила. Если сервис A использует сервис B, а сервис B сервисы Z X C, только версиями рулить (major/minor). По факту просто заменяем app-сервер на условный OpenShift, что даёт возможность абстрагироваться от java стека. Т.к. в реальность что-то действительно быстрей/проще написать на python/php/node .. etc.
Только вот поддерживать потом весь этот зоопарк ......

Блин "насношался" я с этими кнопочками в IDE.
Когда проект 200x лохматого года.
Спасибо не надо.

Насчет python/php/node и т.д. Кроме того, что там есть вопросы по производительности, на них гораздо проще писать говнокод.
В этом плане Java более привередлива.

Kachalovmad_nazgulОсобенно, когда это пилит команда более чем из одного человека.
- ?? ee-приложение изначально ориентированно на модульную архитектуру, законтрактованную через интерфейсы. Описали интерфейсы и пилите модули по разным углам комнаты. Готовый модуль можно линковать в разные приложения (сам так делал с JCA-адаптером к HDFS)

Э-э-э чтобы "распилить на модули" нужно в начале понять где проходят границы модулей.
В монолите есть соблазн "забить" на границы и делать как получиться, главное быстро.
А потом смотришь на код.... Начали вроде бы за здравие, но потом пришла другая команда и продолжила, как получиться, потом еще и еще. Пока этот код попадает к тебе. И понимаешь либо пол года нужно будет пилить код на модули, либо как-то изворачиваться.
Т.к. "времени нет", то "как-то изворачиваешься" :-)

PetroNotC Sharpразговор о том что не надо вставлять слово микросервисы. Это штатная работа еще с 90х годов наверное.

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

Kachalovmad_nazgulЭ-э-э чтобы "распилить на модули" нужно в начале понять где проходят границы модулей.
В монолите есть соблазн "забить" на границы и делать как получиться, главное быстро.
- это справедливо и для микросервисов. Быдлокодер может испортить любую идею и довести ее до абсурда.

Скажем так. Быдлокодить монолит гораздо легче чем микросервисы.

Kachalovmad_nazgulСкажем так. Быдлокодить монолит гораздо легче чем микросервисы.
- вынужден не согласиться (c)

Монолит "унутре" может быть как угодно плохо спроектирован архитектурно. Но все равно работать.
Просто изменения будут все дороже и дороже.
А вот с микросервисной архитектурой не совсем так.
Там начнутся проблемы гораздо раньше, как минимум из-за сетевого взаимодествия и смены API REST-сервисов.