Почему простая архитектура часто сильнее модной
О том, как стремление к «правильному стеку» и красивым диаграммам ломает проекты, которые могли бы спокойно работать годами.
Когда команда впервые видит белый лист и большой бюджет, на него хочется нарисовать что-то впечатляющее. Шину данных, оркестратор, очереди, события, кластер, отдельный сервис на каждую сущность.
Это понятный человеческий импульс. И это почти всегда плохой старт.
Почему "правильный стек" не равно "правильное решение"
Технологический выбор не существует в вакууме. Он живёт внутри:
- размера и зрелости команды;
- бюджета и сроков;
- объёма реальных данных, а не воображаемых;
- темпа изменений в бизнесе;
- готовности компании поддерживать сложность.
Микросервисы, kafka, отдельные хранилища под каждый домен - это всё работает. Но работает только при определённых условиях. Когда условия не совпадают, "современный" стек становится тяжелым налогом, который собирают каждый день.
Что обычно случается с переусложнёнными системами
Через 6-12 месяцев после запуска появляются одинаковые симптомы:
- никто, кроме автора, уже не понимает, как всё связано;
- любая новая фича требует трогать несколько сервисов;
- время на простые изменения растёт нелинейно;
- падения становятся плохо локализуемыми;
- внедрение нового сотрудника превращается в отдельный проект.
При этом бизнес-задачи, под которые всё это делалось, можно было бы закрыть на гораздо более скромной архитектуре.
Что значит "простая архитектура" на практике
Это не значит "монолит и точка". Это значит:
- начинать с минимального набора компонентов;
- добавлять сложность только по факту, под измеримое ограничение;
- предпочитать понятные технологии модным;
- держать данные и логику ближе друг к другу, пока нет реальной причины разносить их;
- задавать себе вопрос "что упадёт, если выкинуть этот слой?" - и если ничего, выкидывать.
Простая архитектура часто выглядит на схеме скучно. Зато она объясняется новому инженеру за полчаса и переживает три смены команды.
Когда сложность оправдана
Сложность стоит вводить, когда:
- появилась нагрузка, с которой простой вариант реально не справляется;
- разные части системы развиваются с разной скоростью и мешают друг другу;
- разные команды должны работать независимо и сейчас наступают друг другу на ноги;
- появились конкретные требования по надёжности или изоляции, которых нельзя обойти.
Во всех этих случаях усложнение - это ответ на проблему, которую можно показать пальцем. Не "потому что так модно".
Простой инженерный фильтр
Перед тем как добавить новый слой, сервис, очередь или фреймворк, я обычно задаю себе три вопроса:
- Какую конкретную проблему это решает прямо сейчас?
- Сколько мы будем платить за это в эксплуатации?
- Что мы потеряем, если этого не сделаем?
Если на первый вопрос нет ясного ответа - значит, это украшение, а не инженерия. И в проекте, который должен жить дольше, чем длится энтузиазм команды, украшения почти всегда обходятся дороже, чем выглядят.