Сообщение Re[2]: О микросервисах от 22.11.2021 8:49
Изменено 22.11.2021 8:50 gyraboo
Re[2]: О микросервисах
Здравствуйте, rosencrantz, Вы писали:
BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
R>Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.
Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования. Если про это забыть, то даже у маленьких команд в 5 человек, пилящих монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.
BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
R>Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.
Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования. Если про это забыть, то даже у маленьких команд в 5 человек, пилящих монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.
Re[2]: О микросервисах
Здравствуйте, rosencrantz, Вы писали:
BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
R>Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.
Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования. Если про это забыть, то даже у маленьких команд в 5 человек, реализующих по-старинке монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.
BE>>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
R>Оверхед на микросервисность (и ценность микросервисности) зависит от размера организации — чем больше организация, тем меньше оверхед, и тем больше ценность. Микросервисность — это в первую очередь про изоляцию команд друг от друга. Если речь идёт про 100 команд по 10 человек, вопрос изоляции/автономности есть и он важен. Когда одна команда из 5 человек начинает себе микросервисы делать, это конечно глупость.
Кроме изоляции команд, вторым мотивом является возможность дешевого горизонтального масштабирования. Если про это забыть, то даже у маленьких команд в 5 человек, реализующих по-старинке монолит, может настать момент когда они попадут со своим монолитом в ловушку масштабирования. У нас так один раз случилось, делали небольшой командой монолит, начали выводить на рынок, рынок захотел сразу много всяких фич, начали эти фичи прикручивать, уперлись в том, что монолит просто физически не справляется с задачами, диктуемыми рынком. Начали как говориться "распиливать монолит", потому что иначе невозможно распределить нагрузку. А если бы в начале подумали о масштабировании и изначально бы делали микросервисы, то проблемы бы не было.