Вчера снова поймал себя на мысли — архитектурные задачи очень сложны с точки зрения управления. И начал рассуждать — почему так? Кажется, всё из-за пересечения треугольников.
И нет, я не про ✡️ 😄
Речь о двух треугольниках: управление проектом (время-стоимость-объём работ) и CAP-теорема (доступность-консистентность-устойчивость к разделению).
💭 Представьте ситуацию:
У вас огромный скоуп бизнес задач, которые нужно автоматизировать, и архитектуры ещё нет.
🎨 Ты с энтузиазмом садишься рисовать решение.
😐 Потом — чуть менее радостно — начинаешь согласовывать.
И тут начинается:
— “Есть нюанс...”
— “Тут зависит от контекста.”
— “А как долго мы будем с этим жить?”
— “А если тут вот так?..”
— “Кто ещё будет это использовать?”...
👌 Окей, уложили концепт, согласовали.
А теперь вспоминаем — всё это нужно сделать за квартал! А по факту — работ на год одной команды.
🤔 “Хм... Тогда давайте пересмотрим приоритеты. Это не столь важно, тут можно упростить, а здесь — временный костыль.”
⏳ Отлично, теперь вроде полгода. Ну что ж, пошли к заказчику со всей фактурой что набрали.
💸 Ура, заказчик говорит: “Нужно в два раза быстрее. Добавим людей!”
И вот ты снова объясняешь: — “Нет, чтобы ускориться в 2 раза, нужно не 2, а 3 команды, и то — начнём с начала, потому что надо архитектурно распараллелить работу.”
⚙️ “Давайте всё попилим на более гранулярные микросервисы!”
🔥 Отлично! Только теперь...
— Потеряли консистентность
— Началась гонка версий контрактов
— Логи разъехались по 10 местам
— И CI/CD теперь живёт своей жизнью
А где-то ещё параллельно звучит:
— “А почему latency выросло в 3 раза?”
— “А почему у нас теперь три контура мониторинга?”
— “А почему мы выкинули гарантированную доставку из скоупа?!”
И вот ты сидишь, смотришь на эти два треугольника —🔺🔻 и понимаешь, что они пересекаются не в точке... а в болоте компромиссов.
А что ещё тут стоит учитывать? Или, может, уже хватит? 😅
