ВР
Бедолага из кузовного цеха.
Size: a a a
2020 January 29
2020 January 30
ЕТ
Тагир Валеев и Егор Бугаенко так хорошо известны джавистам, что зачастую их называют просто «Тагир» и «Егор». На прошлом JPoint они пересеклись, когда Егор взял интервью у Тагира, а теперь мы сделали текстовую версию этого интервью: https://habr.com/ru/company/jugru/blog/485134/
J🎩
Тагир Валеев и Егор Бугаенко так хорошо известны джавистам, что зачастую их называют просто «Тагир» и «Егор». На прошлом JPoint они пересеклись, когда Егор взял интервью у Тагира, а теперь мы сделали текстовую версию этого интервью: https://habr.com/ru/company/jugru/blog/485134/
там один комментарий, и он не бровь, а в глаз.
2020 February 03
AV
Разработчики: давайте делать микросервисы!
Корпоративные архитекторы: да! Но чтобы не писать дважды, мы создадим util-common-infrastructure модуль, запихнём туда все потенциально возможные библиотеки, и у вас будет в проекте только одна зависимость от него.
Корпоративные архитекторы: да! Но чтобы не писать дважды, мы создадим util-common-infrastructure модуль, запихнём туда все потенциально возможные библиотеки, и у вас будет в проекте только одна зависимость от него.
AG
Разработчики: давайте делать микросервисы!
Корпоративные архитекторы: да! Но чтобы не писать дважды, мы создадим util-common-infrastructure модуль, запихнём туда все потенциально возможные библиотеки, и у вас будет в проекте только одна зависимость от него.
Корпоративные архитекторы: да! Но чтобы не писать дважды, мы создадим util-common-infrastructure модуль, запихнём туда все потенциально возможные библиотеки, и у вас будет в проекте только одна зависимость от него.
Одна зависимость - типа maven BOM файла?
AV
Одна зависимость - типа maven BOM файла?
Зачем файла. Просто infrastructure-common-everything.jar.
И чтобы два раза не вставать версии +.+.
И чтобы два раза не вставать версии +.+.
AV
Хотя не, может и bom. У меня еще не догрузились - прав не хватает)
AV
Наверное всё же, не будем сгущать
AG
Зачем файла. Просто infrastructure-common-everything.jar.
И чтобы два раза не вставать версии +.+.
И чтобы два раза не вставать версии +.+.
Fat jar получается. У этого подхода боюсь есть недостаток. Когда надо будет добавлять какие-то зависимости надо будет пересобирать этот infrastructure-common.jar
AV
я считал, что смысл микросервиса, как раз в том, чтобы использовать только то что нужно, и не боятся дупликации - но не зависеть от огромного монолитного сборища всего.
Но возможно, мои взгляды слишком узки и консервативны.
Но возможно, мои взгляды слишком узки и консервативны.
ПП
А как же обработка ошибок, настройки вещей которые должны быть одинаковые везде? Постоянно дублировать код?
ПП
Каждый сервис начнется с копипаста
MT
я считал, что смысл микросервиса, как раз в том, чтобы использовать только то что нужно, и не боятся дупликации - но не зависеть от огромного монолитного сборища всего.
Но возможно, мои взгляды слишком узки и консервативны.
Но возможно, мои взгляды слишком узки и консервативны.
А если допустим в такую инфраструктуру вынести только нефункциональные вещи: метрики, трассировку, может что-то ещё. И подключать это одним щелчком. Ведь это надо для всех микрачей
ПП
А если допустим в такую инфраструктуру вынести только нефункциональные вещи: метрики, трассировку, может что-то ещё. И подключать это одним щелчком. Ведь это надо для всех микрачей
И все это через стартеры
PD
Через сайдкары
ПП
А кто как у себя избавляется от дублирования кода в микросервисах?
ПП
Речь про общие вещи для сервисов и групп проектов
PD
Библиотеки и сайдкары, так и избавляемся. И тех.радар
T
Разработчики: давайте делать микросервисы!
Корпоративные архитекторы: да! Но чтобы не писать дважды, мы создадим util-common-infrastructure модуль, запихнём туда все потенциально возможные библиотеки, и у вас будет в проекте только одна зависимость от него.
Корпоративные архитекторы: да! Но чтобы не писать дважды, мы создадим util-common-infrastructure модуль, запихнём туда все потенциально возможные библиотеки, и у вас будет в проекте только одна зависимость от него.
Лесом микросервисы! Пустой хайп это. Хорошо модуляризированное монолитное приложение проще поддерживать, развивать, тестировать и развертывать. Да и тупых задержек из-за сериализации всего в JSON нет