Владимир Мельник

"А дробить на более мелкие части -- совершенно бесполезно..."

• Не совсем понятно, что вообще планируется дробить и зачем, если бесполезно.

"..., так как такие наносервисы -- избыточное потребление ресурсов ..."

• Какое избыточное потребление ресурсов? Если мы одно ограничение (пропускную способность в данном случае) расширяем за счет другого (большего!), например ресурса процессора и RAM, то это единственный способ, как вещи вообще происходят, потому что все требует выполнения какой-то работы и все обладает не 100% КПД. С вашим подходом и автомобиль - плохо, потому что ему нужен бензин, и электролампочка - плохо, потому как она потребляет энергоэнергию, а при этом есть же Солнце. Это путь в никуда.

"... при собственной неполноценности и невозможности по отдельности выполнять заложенный функционал ..."

• Почему не возможно? Почему они не полноценны? "Полноценность" - это от слова "ценность", то есть об ожиданиях, а не о чем-то объективном. Если вы ожидали одного, а получили другое - кто тут виноват?

" Пассаж, про неэффективность советской экономике -- убери, будь ласка. Не пиши того, о чём не имеешь понятия."

• Это мое мнение. Вы с ним можете быть несогласны, как и я с приведенными вами выше доводами.

Хорошая метафора, которая мне не пришла сразу в голову:

Не нужно строить новый завод, если можно поставить на имеющийся несколько новых верстатов.

"Оптимизировали "бутылочное горлышко", сделали реплики. Увеличивается нагрузка - увеличиваем число реплик. И уже бутылочным горлышком становится не та же часть сервиса, для которой мы увеличили реплики, а соседняя - та, из которой в эту приходят данные. "

Сразу после того, как вы расширили одно бутылочное горлышко - оно перестает быть таковым и появляется другое. Нам не нужно ждать больших нагрузок - мы практически всегда будем иметь участки с наименьшей пропускной способностью уже сразу после устранения предыдущих.

С большой нагрузкой действительно может измениться поведение системы и могут появиться действительно новые бутылочные горлышки из-за эмерджентных свойств системы, например, проблемы могут возникнуть из-за большого количества таймеров в системе, необходимости репликации данных, работы GC в условиях слишком высокого распараллеливания и т.д. Как не оптимизируй - всегда будет возможность для еще большей оптимизации. Таких решений, чтобы раз и навсегда не бывает.

"И начинаем вычленять новое бутылочное горлышко, наращивать реплики и т.д. И так по кругу. И вот мы уже выделили десяток таких частей. К чему мы пришли?"

Мы можем прийти в таком случае к микро-сервису только если все узкие места связаны одним bounded context и имеют более-менее одинаковую пропускную способность. Если же пропускная способность этих, связанных одним контекстом, фрагментов отличается существенно, то нам, опять таки не обязательно разбивать микросервис (который уже обслуживает конкретный домен!) на несколько других (каковыми будут их домены?) только для повышения пропускной способности. В этих целях, описанный выше подход можно использовать и в микро-сервисах, стоит только заменить слова "система" и "под-система" в тексте статьи на "микросервис".

"И уже бутылочным горлышком становится не та же часть сервиса, для которой мы увеличили реплики, а соседняя - та, из которой в эту приходят данные."

Совсем нет. Следующим бутылочным горлышком может оказаться любой другой фрагмент кода в графе вычислений.

"И вот мы уже выделили десяток таких частей. К чему мы пришли? Да к той же микросервисной архитектуре, ..."

Совсем нет. Микросервис подразумевает некий bounded context - предметную область, в которой он работает. В случае с вынесением бутылочных горлышек - это может быть просто функция, которую мы запускаем в несколько потоков. В случае, например с Golang, где есть многопоточность, медленную функцию можно никуда не выносить, а просто запускать N-горутин для распараллеливания на одной машине, если ресурса одной машины в принципе хватает. Если функция слишком тяжелая и ресурса одной машины не хватает - можно использовать хранимые процедуры aka AWS lambda или что-то типа того.

" ... от которой автор предлагал уйти..."

Автор не предлагал ни от чего уходить. Автор предложил не тратить время на сложные инженерные решения вроде SOA или микро-сервисной архитектуры, при возникновении проблем с масштабируемостью, но найти "рычаг" и воспользоваться им в решении таких проблем.

Микро-сервисный зоопарк для многих неподьемная ноша. Если вы не Netflix, а молодой стартап - не стоит плодить сложность, а микро-сервисную архитектуру можно будет оставить на потом, сделать ее следующим витком развития проекта.

"Давайте не писать микросервисы, а напишем микросервисы?"

Нет, давайте выполнять минимально необходимое количество работы для решения конкретной проблемы.