Поэтому я про структуру каталогов даже не писал ничего в статье :) Если модуль можно безболезненно подменить другой реализацией, то границы выставлены приемлемо. И это несложно проверяется при попытке написать авто-тесты.
И другой побочный эффект - снижается количество создаваемых инстансов.
Все так, но в реальной жизни бизнес-логика типичного метода сервиса - это не два числа сложить, а гораздо сложнее. Это один или несколько непростых запросов к БД, результат которых может занимать десятки-сотни килобайт, потом маппинг этого всего к нужному виду и на фоне всех этих операций сериализация/десериализация результата - это самое большее +1% работы, а к серверной БД обращаются также по сети, поэтому передача пакетов все равно будет. В общем нагрузка от удаленного вызова по сравнению с вызовом внутренней функции - это не на порядок тяжелее, а всего лишь на несколько процентов.
Скорее всего есть осознание, что поддерживать текущее стало трудно, рефакторить все - тоже очень трудно, поэтому нужно переписать и с учетом имеющихся данных о нагрузке принимается решение в пользу сервисной архитектуры. А дальше уже насколько грамотно спроектируют.
Вот не понимаю откуда берется такой рост серверов? Сервисы запускают в контейнерах - это по сути просто отдельные процессы и все. Вместо 1 сервера будет 2, от силы 3 - если прямо сильно все обложить мониторингом. Понятно, что расходы вырастают, но не на порядок.
Интересно тогда откуда берутся запросы у нанимающих менеджеров? Примерно на каждом втором собесе можно услышать - мы делаем систему уже 3+ года и она разрослась, теперь хотим распилить это все на микросервисы и ищем разработчиков с подобным опытом.
Это довольно типичная ошибка - излишне подробное дробление задачи на сервисы. Апогеем этого безумия является упомянутое в статье - Function as a Service, этот подход продвигают компании, которые продают условный "хостинг" - чем больше народ на это подсядет, тем больше они заработают.
Интересно было бы увидеть расчеты. С учетом того, что сервисы запускаются в контейнерах и малонагруженные сервисы могут жить на одном сервере в большом количестве, вплоть до десятков штук, пропорция 1:8 вызывает сомнения.
Если монолит изначально был спроектирован плохо - без четкого разделения на модули, то дробить его на части - это серьезная работа, может быть даже настолько серьезная, что проще рядом новую систему разработать.
Начинают проект с микросервисов обычно тогда, когда система разрабатывается для продажи (это продукт), а не под единственного заказчика. А также когда четко видна модульность и понятно, что разным покупателям будут поставляться разные конфигурации модулей.
Также добавлю, что современные фреймворки помогают разрабатывать микросервисные решения с возможностью развертывания сервисов как в отдельных процессах, так и группировать несколько плотно взаимодействующих сервисов в одном процессе (тогда упрощается коммуникация - происходит просто вызов функции в одном адресном пространстве и сериализация/десериализация не выполняются).
В случае интерпретируемых ЯП, например, JS/TS для изменения конфигурации запуска можно даже не пересобирать приложения и контейнеры. Файлы конфигурации запуска сервисов могут использовать переменные среды и в итоге это все может конфигурироваться на уровне параметров запуска контейнеров. То есть систему, спроектированную в микросервисной архитектуре можно запускать как монолитом - одним процессом, так и кластерами сервисов, вплоть до кластеров, состоящих из одного сервиса. И все это без изменения бизнес-логики. Просто исходя из необходимости - нагрузок, доступной инфраструктуры.
В описанной вами ситуации я не вижу разницы с монолитом - там будут примерно те же трудности.
За исключением того, что в случае микросервисов, если сбоит не сильно критичный сервис, то можно его отключить и иметь больше времени на фикс, тест фикса и запуск обновления. Кроме того, перед запуском релиза обычно все таки делается достаточно масштабное тестирование, да и резервная система с предыдущим стабильным релизом тоже не помешает.
Также я сомневаюсь в реальности серьезных трудностей от сценария, который вы описали - при любой реализации системы.
Поэтому я про структуру каталогов даже не писал ничего в статье :)
Если модуль можно безболезненно подменить другой реализацией, то границы выставлены приемлемо. И это несложно проверяется при попытке написать авто-тесты.
И другой побочный эффект - снижается количество создаваемых инстансов.
Все так, но в реальной жизни бизнес-логика типичного метода сервиса - это не два числа сложить, а гораздо сложнее. Это один или несколько непростых запросов к БД, результат которых может занимать десятки-сотни килобайт, потом маппинг этого всего к нужному виду и на фоне всех этих операций сериализация/десериализация результата - это самое большее +1% работы, а к серверной БД обращаются также по сети, поэтому передача пакетов все равно будет. В общем нагрузка от удаленного вызова по сравнению с вызовом внутренней функции - это не на порядок тяжелее, а всего лишь на несколько процентов.
Скорее всего есть осознание, что поддерживать текущее стало трудно, рефакторить все - тоже очень трудно, поэтому нужно переписать и с учетом имеющихся данных о нагрузке принимается решение в пользу сервисной архитектуры. А дальше уже насколько грамотно спроектируют.
Вот не понимаю откуда берется такой рост серверов? Сервисы запускают в контейнерах - это по сути просто отдельные процессы и все. Вместо 1 сервера будет 2, от силы 3 - если прямо сильно все обложить мониторингом. Понятно, что расходы вырастают, но не на порядок.
Интересно тогда откуда берутся запросы у нанимающих менеджеров? Примерно на каждом втором собесе можно услышать - мы делаем систему уже 3+ года и она разрослась, теперь хотим распилить это все на микросервисы и ищем разработчиков с подобным опытом.
Если в одной системе сервисов около 100, то явно нужно разбираться, что же пошло не так
Это довольно типичная ошибка - излишне подробное дробление задачи на сервисы. Апогеем этого безумия является упомянутое в статье - Function as a Service, этот подход продвигают компании, которые продают условный "хостинг" - чем больше народ на это подсядет, тем больше они заработают.
Нормальное решение, если у вас в системе преобладает чтение данных, а если 50 на 50 с записью, или запись преобладает, то выгода будет поменьше?
Интересно было бы увидеть расчеты. С учетом того, что сервисы запускаются в контейнерах и малонагруженные сервисы могут жить на одном сервере в большом количестве, вплоть до десятков штук, пропорция 1:8 вызывает сомнения.
Если монолит изначально был спроектирован плохо - без четкого разделения на модули, то дробить его на части - это серьезная работа, может быть даже настолько серьезная, что проще рядом новую систему разработать.
Начинают проект с микросервисов обычно тогда, когда система разрабатывается для продажи (это продукт), а не под единственного заказчика. А также когда четко видна модульность и понятно, что разным покупателям будут поставляться разные конфигурации модулей.
Также добавлю, что современные фреймворки помогают разрабатывать микросервисные решения с возможностью развертывания сервисов как в отдельных процессах, так и группировать несколько плотно взаимодействующих сервисов в одном процессе (тогда упрощается коммуникация - происходит просто вызов функции в одном адресном пространстве и сериализация/десериализация не выполняются).
В случае интерпретируемых ЯП, например, JS/TS для изменения конфигурации запуска можно даже не пересобирать приложения и контейнеры. Файлы конфигурации запуска сервисов могут использовать переменные среды и в итоге это все может конфигурироваться на уровне параметров запуска контейнеров.
То есть систему, спроектированную в микросервисной архитектуре можно запускать как монолитом - одним процессом, так и кластерами сервисов, вплоть до кластеров, состоящих из одного сервиса. И все это без изменения бизнес-логики. Просто исходя из необходимости - нагрузок, доступной инфраструктуры.
В описанной вами ситуации я не вижу разницы с монолитом - там будут примерно те же трудности.
За исключением того, что в случае микросервисов, если сбоит не сильно критичный сервис, то можно его отключить и иметь больше времени на фикс, тест фикса и запуск обновления.
Кроме того, перед запуском релиза обычно все таки делается достаточно масштабное тестирование, да и резервная система с предыдущим стабильным релизом тоже не помешает.
Также я сомневаюсь в реальности серьезных трудностей от сценария, который вы описали - при любой реализации системы.
Пожалуйста, поясните, как отсутствие интернета мешает работать микросервисам?