"Команда из 10 человек может прекрасно развивать сложный монолит, тогда как для распределённой системы с той же логикой потребуются сотни людей. Разработка в монолите быстрее: только на согласование контрактов между сервисами уходят недели, плюс отладка взаимодействий. " Здесь есть скрытое условие, на котором держится ваш аргумент: “Монолит + высокая инженерная дисциплина + стабильная команда + понятная доменная модель”. В идеальном мире я бы и сам никогда не выбрал сложные микросерисы.
"Вместо одного лога и стектрейса — вам нужна распределённая трассировка по десяткам сервисов. Поиск причины сбоя превращается в детективное расследование." Отчасти согласен, лучше, когда всё в одном месте и нет общей ответственности, но распределённая трассировка это скорее плата за порядок и я бы отнёс это к минусам МКС, не понятно к чему это вы написали. К тому же обычно все логи всех сервисов собраны в одну кибану и нет проблем взять traceId и пройтись по всем системам также как в монолите по модулям. Да настраивать Kibana достаточно ресурсозатратно, но это необходимо.
"Любой вызов теперь уязвим к таймаутам, сетевому лавинообразованию, проблемам DNS. Вы тратите больше времени на написание устойчивого к сбоям клиента, чем на бизнес-логику." - ну, нет Circuit Breaker размыкает цепочку, да, это плата за микросервисы, опять же не вижу, что вы опровергаете, цитируя меня, я не писал, что с сетью лучше работают микросервисы.
"Независимое развёртывание — миф, если изменение API одного сервиса требует синхронного обновления трёх других. Версионирование API, устаревшие клиенты, graceful degradation — это отдельная инженерная дисциплина." - Не понял посыла, я могу в Kubernetes из 3 под 1 оставить со старой весрией сервиса, 2 с новой. Да и вы сами говорите, что это дисциплина, следовательно её используют и применяют и зависит она от зрелости команды, а не от выбора монолит/мкс.
"Масштабирование более чем возможно. Появились распределённые SQL-базы данных нового поколения, такие как YugabyteDB, CockroachDB, Google Spanner. Они предлагают строгую согласованность, горизонтальное масштабирование на уровне данных и распределённые ACID-транзакции — всё то, ради чего мы дробили монолит и отказывались от транзакционности." - Это слишком широкое обобщение. Мы не дробили монолит “ради масштабирования данных” в большинстве кейсов. Чаще причины: независимые релизы, скорость разработки, границы ответственности, разные нагрузки, отказоустойчивость отдельных модулей, организационные причины. От транзакционности в рамках сервиса тоже никто не отказывался, а между сервисами есть SAGA для консистентности, я бы сказал эти аргументы не к месту или не до конца раскрыты. Если есть кейсы, когда можно заменить SAGA на одну из этих технологий без минусов sharedDB или с минимальным количеством, прошу написать.
"В мире микросервисов разработчику необходимо понимать не меньше, но только он не может быстро посмотреть код, который происходит где-то там за границами сервиса " - Разграниченные права в gitlab, где хранятся все сервисы. Во всяком случае у нас. Может.
Зачем вы хотите узнать? С какой стороны мне уточнить?
"Команда из 10 человек может прекрасно развивать сложный монолит, тогда как для распределённой системы с той же логикой потребуются сотни людей. Разработка в монолите быстрее: только на согласование контрактов между сервисами уходят недели, плюс отладка взаимодействий. " Здесь есть скрытое условие, на котором держится ваш аргумент: “Монолит + высокая инженерная дисциплина + стабильная команда + понятная доменная модель”. В идеальном мире я бы и сам никогда не выбрал сложные микросерисы.
"Вместо одного лога и стектрейса — вам нужна распределённая трассировка по десяткам сервисов. Поиск причины сбоя превращается в детективное расследование." Отчасти согласен, лучше, когда всё в одном месте и нет общей ответственности, но распределённая трассировка это скорее плата за порядок и я бы отнёс это к минусам МКС, не понятно к чему это вы написали. К тому же обычно все логи всех сервисов собраны в одну кибану и нет проблем взять traceId и пройтись по всем системам также как в монолите по модулям. Да настраивать Kibana достаточно ресурсозатратно, но это необходимо.
"Любой вызов теперь уязвим к таймаутам, сетевому лавинообразованию, проблемам DNS. Вы тратите больше времени на написание устойчивого к сбоям клиента, чем на бизнес-логику." - ну, нет Circuit Breaker размыкает цепочку, да, это плата за микросервисы, опять же не вижу, что вы опровергаете, цитируя меня, я не писал, что с сетью лучше работают микросервисы.
"Независимое развёртывание — миф, если изменение API одного сервиса требует синхронного обновления трёх других. Версионирование API, устаревшие клиенты, graceful degradation — это отдельная инженерная дисциплина." - Не понял посыла, я могу в Kubernetes из 3 под 1 оставить со старой весрией сервиса, 2 с новой. Да и вы сами говорите, что это дисциплина, следовательно её используют и применяют и зависит она от зрелости команды, а не от выбора монолит/мкс.
"Масштабирование более чем возможно. Появились распределённые SQL-базы данных нового поколения, такие как YugabyteDB, CockroachDB, Google Spanner. Они предлагают строгую согласованность, горизонтальное масштабирование на уровне данных и распределённые ACID-транзакции — всё то, ради чего мы дробили монолит и отказывались от транзакционности." - Это слишком широкое обобщение. Мы не дробили монолит “ради масштабирования данных” в большинстве кейсов.
Чаще причины: независимые релизы, скорость разработки, границы ответственности, разные нагрузки, отказоустойчивость отдельных модулей, организационные причины. От транзакционности в рамках сервиса тоже никто не отказывался, а между сервисами есть SAGA для консистентности, я бы сказал эти аргументы не к месту или не до конца раскрыты. Если есть кейсы, когда можно заменить SAGA на одну из этих технологий без минусов sharedDB или с минимальным количеством, прошу написать.
"В мире микросервисов разработчику необходимо понимать не меньше, но только он не может быстро посмотреть код, который происходит где-то там за границами сервиса " - Разграниченные права в gitlab, где хранятся все сервисы. Во всяком случае у нас. Может.