Что 2014 год потребует от архитектуры: меньше монолитов, больше дисциплины

Разговоры об архитектуре часто начинаются с терминологии. SOA, микросервисы, API-first - каждый год появляется набор слов, вокруг которых строятся презентации и конференции. Это создаёт иллюзию, что архитектурный выбор - это выбор между модными концепциями.

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

Ближайшие год-два усилят это давление. И стоит понять, к чему именно готовиться.

Проблема монолита - не в размере

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

Это означает, что независимые команды блокируют друг друга. Это означает, что небольшое изменение несёт в себе риск большого инцидента. Это означает, что выпуск превращается в событие, а не в рутину.

По мере того как бизнес требует более быстрой реакции, эта механика становится узким местом. Не потому что монолит плохой, а потому что связность всего со всем делает скорость опасной.

Что нужно разделить в первую очередь

Не нужно переписывать всё. Разумная стратегия - определить, где сцепленность уже стоит денег.

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

Другой кандидат - всё, что имеет внешние интеграции. API для партнёров или мобильного клиента - это естественная граница. Когда он выделен, его контракт стабилизируется, а внутренняя логика может меняться независимо.

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

Дисциплина окружений - недооценённая часть

Одна из самых частых проблем, которую я вижу в командах с быстро растущим числом сервисов, - это не архитектура сервисов, а хаос в окружениях. Идея контейнеризации как способа обеспечить воспроизводимость окружений уже становилась практичной в 2013-м.

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

Дисциплина окружений - это не модная тема. Это операционная гигиена, которая определяет, насколько предсказуем деплой.

Контракты между сервисами важнее реализации

Когда система разбита на части, главным артефактом становится не код каждой части, а контракт между ними. Что именно принимает этот API? Что он гарантирует вернуть? При каких условиях вернёт ошибку?

Эти контракты должны быть явными. Не в головах разработчиков и не в Confluence, который никто не читает. В виде задокументированных, желательно тестируемых спецификаций.

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

Что проверить прямо сейчас

Несколько вопросов, которые помогут оценить готовность архитектуры к ускорению:

1. Сколько времени занимает деплой изменения от коммита до продакшна сегодня?
2. Сколько команд нужно согласовать, чтобы выпустить изменение в одном компоненте?
3. Насколько похожи окружения - что происходит в продакшне, чего не было в тестах?
4. Задокументированы ли контракты между основными компонентами системы?
5. Если один компонент упал - что именно происходит с остальными?

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