IK
разработчиков - 40, соответственно, один разраб несколько систем, у каждого разраба - дублер (иногда несколько). в случае больших систем может доходить до 3-х человек.
Size: a a a
2017 May 25
AS
Я не такой тру-архитектор как некоторые собравшиеся - но не пойму, почему в обсуждении неявно подразумевается "или"? Ведь это всё инструменты - и энтерпрайз часто состоит из нескольких интегрированных приложений. И у сапожника, и у хирурга много разных инструментов - большие молотки и тонкие скальпели. Почему нельзя объединять и микро-, макро-, и вообще безсервисные архитектуры по мере необходимости?
IK
все микросервисы внутренние, а точнее интерфейс взаимодействия с клиентом - через почту и файлы )
RK
микросервисов (у нас это называется расчетная система) порядка 60.
класс
RK
разработчиков - 40, соответственно, один разраб несколько систем, у каждого разраба - дублер (иногда несколько). в случае больших систем может доходить до 3-х человек.
тоже класс!
RK
база общая?
MS
Мне вот этот подход, например, понравился https://www.oreilly.com/ideas/modules-vs-microservices?utm_medium=social&utm_source=facebook.com&utm_campaign=lgen&utm_content=modules_vs_microservices
IK
база общая?
Нет, конечно, это ж микросервисы. У каждого своя. Вот только взаимодействие не на основе HTTP, а на основе JDBC.
AV
нет, у нас же кровавый ынтерпрайз. К нам кстати @mxsmirnov собирался прийти по приглашению руководства, но пока видимо до конкретики не дошло. Было бы интересно его заключение ).
"Кровавый Ынтерпрайз" — отличное название для группы
IK
что дает сильную связность в итоге.
RK
Я не такой тру-архитектор как некоторые собравшиеся - но не пойму, почему в обсуждении неявно подразумевается "или"? Ведь это всё инструменты - и энтерпрайз часто состоит из нескольких интегрированных приложений. И у сапожника, и у хирурга много разных инструментов - большие молотки и тонкие скальпели. Почему нельзя объединять и микро-, макро-, и вообще безсервисные архитектуры по мере необходимости?
Прямо сейчас вроде не спорим об "или". Как раз интересно, в какой ситуации нужно использовать одно, в какой другое и в какой — третье.
IK
но там логика запаяна внутрь баз на процедурном sql. поэтому по сути приложения внутри базы, соответственно они и общаются
RK
Нет, конечно, это ж микросервисы. У каждого своя. Вот только взаимодействие не на основе HTTP, а на основе JDBC.
очень интересно. а если бы было java-апликуха, то трудоемкость развития и поддержки была бы выше?
IK
очень интересно. а если бы было java-апликуха, то трудоемкость развития и поддержки была бы выше?
"если бы" у нас не очень практикуется. микросервисы не всегда соседствуют с "экспериментаторской культурой".
RK
но там логика запаяна внутрь баз на процедурном sql. поэтому по сути приложения внутри базы, соответственно они и общаются
то есть микросервисы — это хранимки в разных базах?
IK
то есть микросервисы — это хранимки в разных базах?
по факту да.
RK
"если бы" у нас не очень практикуется. микросервисы не всегда соседствуют с "экспериментаторской культурой".
понятно, что это очень дорогой вопрос :) но если представить? хранимки не в разных базах, а в одной? одна база бы по перфомансу потянула бы?
IK
то есть микросервисы — это хранимки в разных базах?
но это как бы итог, снаружи выглядит немного по другому, плюс логика размазана слегка.
KB
понятно, что это очень дорогой вопрос :) но если представить? хранимки не в разных базах, а в одной? одна база бы по перфомансу потянула бы?
и где тут слабосвязанность? одна точка отказа. отказала и всё - туши свет. каламбурчик :)