Комментарии 4
Мне кажется сама статья не следует логике вступления, где тонко намекается на:
Необходимость искать корень проблемы
Искать решение, которое влияет на корень проблемы
Статья бодро бежит в сторону, когда решение уже есть, оно верно, так как это аксиома. И дальше в рамках принятой гипотезы верно мы рассказываем какие мы молодцы.
В реальности есть очень важный аспеки. Это принципиальная возможность декомпозиции логики на слабо связанные куски. И это чисто задача на логическом уровне. Потому что если ее не решить - как можно резать на микро/нано сервисы, чтобы в конце не получить мешанину, где все вызывают всех триллион раз. Т.е. наверное стоит посмотреть на логику, скелет бизнес требований, на четкие нефункциональные требования и потом уже искать решения.
Теперь про отдельные свойства:
Масштабируемость. Есть база. Можно расти вверх, а можно в сторону. И еще важно помнить, что если мы уперлись в 100% утилизации CPU, и нет возможности дать больше - то вашему решению станет очень плохо в любом раскладе. Второй момент - нагрузку дает не код, а пользователи. Т.е. если у вас монолит, то он просто занимает больше памяти как код, но с точки зрения утилизации ресурсов он ничем не отличается от распределенного внедрения. Также надо понимать, что горизонтально растягивается как большое, так и маленькое придожение одного стека. Ну реально разницы нет. Ну разве что время запуска, но ... каммон, не зря в скриптах/настройках ставится метрика реагирования с запасом
Отказоустойчивость. Тоже разницы нет. Ошибка в коде "положит" список бизнес функций, в зависимости от того, что в коде, а не как вы его внедрили. Все остальное зависит от стека, а не от размера
Сопровождаемость - это вообще все равно. Вы сопровождаете код. Сложность зависит от его структурированности и связей мнжду модулями. Да, гавнокод сопровождать сложнее :) Но это никак не связано с ахитектурой на уровне монолит/микросервисы.
Тестируемость. Тут да, банально легче дернуть сервис отдельно и автомвтизироватл рутину
Депдоймент - да по фиг, если код структурирован. На это влияет CI/CD и зрелость команды, а также трезвая оценка своих сил (если мы не можем на текущем этапе выдавать релизы раз в две недели - мы будем выдавать раз в месяц). Если команда пытается быть быстрее, чем может - точно облажается
Понравился момент с тем, что архитектура, а точнее гибкость, позволяет быстрее выйти в прод. Да нет, в прод быстрее позволяет точное формирование скоупа MVP (чем меньше в нем никому не нужного гавна,ьам быстрее) и сосредоточенность на нем. И еще иногда выбор стека под команду в наличии :) И еще иногда выбор low-code платформы
Как по мне, полезно, но нет. Заранее извнстен "правильный" ответ, который на самом деле не гарантирует ничего
Единственное, где монолит точно проигрывает - это когда идет разработка, и на локальном или общем стенде надо чего-то собрать и проверить. И желательно с разныи версиями.
Тут очевидно много компонентов дают плюсы и много. Можно легко проверить как работают мои изменения с изменениями соседа, можно собрать себе конфиг, когда два изменынных модуля работают локально, а остальные с общего стенда и т.д.
Это плюс реально есть, но, если не ошибаюсь, о нем так вот явно и именно в контексте процесса разработки не сказано
Вы перевели эту "книгу"? Больше, пожалуйста, не переводите
Hidden text
Интересная попытка в рассказ, который по итогу имеет отрицательную художественную ценность
Тысячный раз мусолят одну и ту же тему. Ничего нового, ничего конкретного. Даже критики не выдерживает (см. комментарий выше)
Серьёзно, ну зачем?
Все почему-то забывают, что не каждая компания может написать больше 3-5 программистов. А чем больше детализация и чем больше различий в квалификации между программистами, тем больше потребуется времени на сопровождение и доработку. Думаю выбор архитекторы в-первую очередь зависит от размера персонала, который должен её реализовать и поддерживать. Чем сложнее и попсовее архитектура, тем больше нужно людей
Книга «Современный подход к программной архитектуре: сложные компромиссы»