Вполне себе предложение, как я писал выше, монолит(так сказать все пошло от SOA) не обязан быть одним, просто чем больше сервис(система), тем больше он подходит под термин монолита, никто не мешает выделить на огромный кровавый энтерпрайс 5-6 монолитов, заставить их сообщаться и добавить пару "микро" сервиса, которые будут написаны native и иметь высокую скорость обработки запросов, по факту просто решать необходимые вопрос о производительности. Вот эти приколы про декомпозицию монолита и те очень часто заводят в никуда. Однако, не могу не отметить, если у проекта монолит из 2000х и он на java, то да такое лучше было бы переписать на что то более современно, хотя бы исходя из того, что куча депрекейт кода связанного с безопасность. Вот если у вас стек монолита на интерпретируемом языке, обычно кодовая база в десятки раз меньше, чем на той же Java или .Net, потому всякие Github, Gitlab, Shopify не удалили и не переписали ядро монолита на такие классные микросервисы. Хотя, можно и пойти по пути Озона - у них сотни микросервисов, но по рассказам все равно есть "фавортные" микросервисы которые можно с натяжкой назвать микро, ведь там куда больше бизнес логики, чем в других. Так что статья, наверное, в первую очередь говорит о том, что дело не в том какой тулчейн у вас в проекте, а насколько правильно этим tool-ами пользуется команда и как хорошо ПОД них написали архитектуру.
Если говорить о технических проблемах, то есть множество контр-примеров того, что микросервисы как решение "технических проблем", является путем куда более длинным и тяжелым, нежели SOA-подобный монолит, и тому есть куча примеров, множество докладов с highload-а идут с топиками подобными "как мы решили проблему нагрузки" и очень часто дело не в монолитах, достаточно вытащить из монолита узкое горлышко (bottle throat) и вы получите куда более потрясающие результаты не сильно уступающие монолитам. В пример, можно взять Gitlab - там решили проблему с файловой IO нагрузкой по средствам выделения слейвов которые являются git-холдерами (RPC микро сервис которому дают git комманды), я когда то изучал архитектуру гитлаба и там полноценный монолит, все не координально важные но нагруженные фичи просто перенесены в сервисы. Другой важный пример - Shopify. Тут решение еще более простое - они создали монолит по тенантам, каждый тенант отдельно имеет свой pod или несколько тенантов имеет свой под, из за чего лоад-балансеры распределяют с легкостью клиентов по не нагруженным тенант-podам. B свою очередь сверх-перегруженный маркет превращается в простой монолит, у которого не так уж и много нагрузки. Не правда ли, это прекрасное архитектурное решение? Казалось бы тир1 система для покупок, хайлоад, однако, все технические решения решаются на уровне архитектуры и деплоя, а не на уровне "хайпа".
Как мне кажется монолит - очень громоздкий способ решения простых проблем. Лишь действительно большие проблемы могут быть решены данным способом, а все остальные проблемы намного проще решаются при помощи монолитов или архитектурных SOA. Если у вас шташ в 100+ человек только разработчиков и у вас килотонны метрик, то очевидно, что монолит - единственно правильное решение, а иначе я бы 10 раз задумался, хочу ли я для каждой из команд тратить половину времени на то, чтобы документировать API, утверждать API между командами и тратить кучу времени на то, чтобы модифицировать API между командами(одна просит другую ради какой то фичи) и те. Да, связность падает, однако, на практике, очень редко, когда архитектура и АПИ утверждаются и не вносятся изменения в АПИ, а в этом главная проблема микросервисов - человеческая бюрократия в межсервисном взаимодействием. Если вы попробуете меня переубедить с аргументом, что деплой проще, то можете посмотреть топик Self Contained Systems, расширенный термин SOA или в простонародии сообщающиеся монолиты, они решают многие проблемы команд, независимости систем, отказоустойчивости и деплоя.
Вывод из данного треда можно сделать один - самое главное - это архитектурная проработка, "человеческая архитектура", а то, какой фреймворк или какую "физическую архитектуру" вы выбрали - не так уж важно, ведь даже микросервисы могут быть медленные, если вы не умеете ими пользоваться, а лишь пытаетесь залезть на хайп-трейн!
Критикуем обзорную статью на мало кому известный архитектурный подход (декомпозиция систем != SCS)
Вполне себе предложение, как я писал выше, монолит(так сказать все пошло от SOA) не обязан быть одним, просто чем больше сервис(система), тем больше он подходит под термин монолита, никто не мешает выделить на огромный кровавый энтерпрайс 5-6 монолитов, заставить их сообщаться и добавить пару "микро" сервиса, которые будут написаны native и иметь высокую скорость обработки запросов, по факту просто решать необходимые вопрос о производительности.
Вот эти приколы про декомпозицию монолита и те очень часто заводят в никуда. Однако, не могу не отметить, если у проекта монолит из 2000х и он на java, то да такое лучше было бы переписать на что то более современно, хотя бы исходя из того, что куча депрекейт кода связанного с безопасность. Вот если у вас стек монолита на интерпретируемом языке, обычно кодовая база в десятки раз меньше, чем на той же Java или .Net, потому всякие Github, Gitlab, Shopify не удалили и не переписали ядро монолита на такие классные микросервисы.
Хотя, можно и пойти по пути Озона - у них сотни микросервисов, но по рассказам все равно есть "фавортные" микросервисы которые можно с натяжкой назвать микро, ведь там куда больше бизнес логики, чем в других.
Так что статья, наверное, в первую очередь говорит о том, что дело не в том какой тулчейн у вас в проекте, а насколько правильно этим tool-ами пользуется команда и как хорошо ПОД них написали архитектуру.
Если говорить о технических проблемах, то есть множество контр-примеров того, что микросервисы как решение "технических проблем", является путем куда более длинным и тяжелым, нежели SOA-подобный монолит, и тому есть куча примеров, множество докладов с highload-а идут с топиками подобными "как мы решили проблему нагрузки" и очень часто дело не в монолитах, достаточно вытащить из монолита узкое горлышко (bottle throat) и вы получите куда более потрясающие результаты не сильно уступающие монолитам.
В пример, можно взять Gitlab - там решили проблему с файловой IO нагрузкой по средствам выделения слейвов которые являются git-холдерами (RPC микро сервис которому дают git комманды), я когда то изучал архитектуру гитлаба и там полноценный монолит, все не координально важные но нагруженные фичи просто перенесены в сервисы.
Другой важный пример - Shopify. Тут решение еще более простое - они создали монолит по тенантам, каждый тенант отдельно имеет свой pod или несколько тенантов имеет свой под, из за чего лоад-балансеры распределяют с легкостью клиентов по не нагруженным тенант-podам. B свою очередь сверх-перегруженный маркет превращается в простой монолит, у которого не так уж и много нагрузки. Не правда ли, это прекрасное архитектурное решение? Казалось бы тир1 система для покупок, хайлоад, однако, все технические решения решаются на уровне архитектуры и деплоя, а не на уровне "хайпа".
Как мне кажется монолит - очень громоздкий способ решения простых проблем. Лишь действительно большие проблемы могут быть решены данным способом, а все остальные проблемы намного проще решаются при помощи монолитов или архитектурных SOA. Если у вас шташ в 100+ человек только разработчиков и у вас килотонны метрик, то очевидно, что монолит - единственно правильное решение, а иначе я бы 10 раз задумался, хочу ли я для каждой из команд тратить половину времени на то, чтобы документировать API, утверждать API между командами и тратить кучу времени на то, чтобы модифицировать API между командами(одна просит другую ради какой то фичи) и те. Да, связность падает, однако, на практике, очень редко, когда архитектура и АПИ утверждаются и не вносятся изменения в АПИ, а в этом главная проблема микросервисов - человеческая бюрократия в межсервисном взаимодействием. Если вы попробуете меня переубедить с аргументом, что деплой проще, то можете посмотреть топик Self Contained Systems, расширенный термин SOA или в простонародии сообщающиеся монолиты, они решают многие проблемы команд, независимости систем, отказоустойчивости и деплоя.
Вывод из данного треда можно сделать один - самое главное - это архитектурная проработка, "человеческая архитектура", а то, какой фреймворк или какую "физическую архитектуру" вы выбрали - не так уж важно, ведь даже микросервисы могут быть медленные, если вы не умеете ими пользоваться, а лишь пытаетесь залезть на хайп-трейн!