Дисклеймер: сказанное ниже относится к ситуации, когда в компании нет отдела (или хотя бы архитектора), который занимается созданием и развитием внутренних технологий и продукты компании тоже не являются инфраструктурными технологиями.

Я много лет занимался тех. консалтингом и работал архитектором в компаниях с кучей внутренних команд со своими проектами и один из самых частых вопросов:

«У нас система плохо работает. Что нам делать: развивать и оптимизировать или выпилить и переписать?»

“Плохо” – это медленно, с ошибками, маленьким аптаймом, потреблением кучей ресурсов и так далее.

Со временем я сформулировал для себя набор лакмусовых бумажек и одна из последних:

Если речь идёт о коде бизнес-логики — можно подумать. А вот если это инфраструктурный самопал — лучше выпиливать.

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

Что такое «инфраструктурный самопал»

По памяти самые частые кейсы:

1. Мониторинг, логи и трейсы на PostgreSQL / MongoDB.

2. Самописный оркестратор приложений на bash + systemd, администрируемый через консоль.

3. Bash-скрипты для провижининга и деплоя.

4. Read-роутер над базой, который рассылает запросы и мерджит результат кодом.

5. Роутер для шардирования запросов (без какой-либо логики решарда, менеджмента кластера, HA, проверки консистентности и подобного).

6. Очереди на PostgreSQL.

7. RabbitMQ + PostgreSQL для батчинга и долгосрочного хранения событий.

То есть хранилища, базы данных, системы очередей, тасок, деплои, etc.

Чем они так опасны?

Весь ваш бизнес-код будет положен поверх инфраструктурного

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

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

3. Чаще всего, каждый релиз фиксов будет должен предполагать процесс миграции существующих данных в новую версию, что итак сложно в бизнес-коде, а здесь сразу х5

4. Инфраструктурные решения – это собственный домен, а вам надо еще разбираться и заниматься доменом вашего бизнеса.

Как понять насколько гнилой фундамент?

Хорошее инфраструктурное решение должно обладать как минимум:

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

2. Документацией – документацию пишут, когда создатели заинтересованы в развитии и распространении технологии.

3. Сообществом – вы можете посмотреть на те вопросы, которые задавали пользователи до вас и вам есть к кому пойти и задать вопросы про ваш тонкий кейс.

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

А с самопалом чаще всего:

• Стабильная версия – ее не было и никогда не будет

• Документация – нет и не будет

• Сообщество – только если анонимных алкоголиков

Представим, что что-то из этого даже есть, следующий важный шаг – пойти к команде и спросить про причину появления самопала. Почти всегда ответ: “мы думали, что у нас будет ситуация Х и мы не хотели усложнять, используя Y”

А теперь ключевой вопрос: “А как устроена технология Y? Что именно вам в ней не подошло? Достигли ли вы ситуации X и есть ли цифры, подтверждающие это?”

И вот момент истины:

• Мы или получим реальный логичный ответ, что оправдает существование самопала и дает повод продолжать его развивать.

• Или, чаще всего, станет понятно, что разработчики просто не знали о том, как устроены технологии Y и решили вместо инвестирования времени в их изучение, напилить что-то свое.

Если у нас второй кейс, значит появился первый кандидат на выпиливание.

Чем заменить

Для начала определяем область, к которой относится самопал и потом подбираем решение:

• Расчет статистики, например, кол-во вызовов к той или иной системе, чтобы вывести их в ЛК клиента? Возьмите системы мониторинга Prometheus-like, складывайте циферки туда и запрашивайте агрегаты так, как делали бы это в Grafana (а во многих кейсах мы даже саму Grafana впиливали прямо в ЛК клиента). В крайнем случае, задумайтесь о ClickHouse (или даже ClickStack).

• Хранение фактов о совершенный процессах, которые вам надо выводить куда-то клиенту или только себе? Если нужно хранить большой объем неизменяемых данных, которые нужно только для отображения, то это – логи, и хранить их стоит в timeseries tiered хранилищах, например, Loki.

• Разворачиваем и настраиваем сервера, деплоим приложения? начните с Ansible, потом CI/CD, потом Terraform.

• Оркестрируем приложения? Если у вас кластера до 10 серверов в каждом, то можете начать с Docker Swarm + Portainer, если ситуация сложнее или вы готовы проинвестировать больше времени, то k8s + Rancher + ArgoCD (причем не надо k3s, именно k8s, например, через kubeadm).

• Read-роутеры → не переписывайте движок базы, ищите способы его переиспользовать: сначала поищите Federated Query Engine, если нет, то embedded-версии (pglite, SQLite) в которые мы будете временно загружать данные, агрегировать и отдавать пользователям, либо займитесь репликацией со всех баз в глобальную рид реплику (в ней даже можно убрать реляции, поскольку консистентностью будут заниматься локальные версии).

• Шардирование → сначала проверьте, нужно ли оно вообще. Часто проблема в конкретных запросах (time series, OLAP, graph) — для них можно подключить отдельное хранилище, или же в формате загрузки данных (много маленьких insert), тогда батчинг вам в помощь. Если действительно нужно — смотрите в сторону готовых рутеров (в стиле, SPQR) или базы с встроенным шардированием.

• Очереди и события → если персистенция не нужна, возьмите Nats.io, если нужна, но не так важна скорость, возьмите Kafka, если она не подходит по бизнес условиям, посмотрите на VerneMQ, а если у вас совсем что-то сложное (персистентный pull heap с приоритетами и последовательностью), то смотрите на базы данных, которые толерантны к большому кол-ву маленьких insert / update / select (и это не postgresql).

Итог

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

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

P.S.

Если вам интересны подобные истории, приглашаю вас в свой паблик в телеграмме ? IT-Качалка Давида Шекунца ?