Иногда самые интересные вызовы находятся там, где ты их совсем не ждешь. Эта история - о том, как случайное собеседование обернулось детективом, технотриллером и в итоге одним из самых интересных проектов в моей карьере.
Пролог: Собеседование ради любопытства
Два года разработки. Команда программистов, дорогие серверы, собственный дата-центр. Всё это было инвестировано в создание маркетплейса для одной амбициозной компании. Но на момент моего собеседования работающего прототипа так и не существовало. Руководство теряло доверие и терпение, а технический директор был на грани увольнения.
Я пришел туда без особых надежд и даже не искал новую работу. Скорее, это был профессиональное любопытство, чтобы узнать о болях компании в тот период времени. И вот, в разговоре, менеджер обмолвился именем того самого техдира. Имя было редкое, и я его сразу узнал.
Мы пересекались с этим человеком в прошлом. Тогда его подход к работе - хаотичный, недисциплинированный и больше похожий на “цирк”, чем на разработку, - заставил меня высказать всё, что я думаю, после чего наши пути разошлись. И вот он, дежа вю: тот же человек, тот же подход, тот же результат - горы “красивого” (в его понимании), но абсолютно неработающего кода.
Мой скептицизм мгновенно испарился. Мне страстно захотелось заглянуть под капот этого провала и, возможно, помочь его исправить. Я согласился присоединиться.
Диагноз: Архитектурный апокалипсис
То, что я увидел, превзошло мои самые пессимистичные ожидания. Бэкенд проекта представлял собой россыпь из 20 (двадцати!) микросервисов. Каждый - отдельное Laravel-приложение.
Это была классическая ошибка «хайп-драйвена» развития. Где-то в 2018-2020 годах микросервисы считались серебряной пулей, которая решает все архитектурные проблемы. Их внедряли везде, не глядя на размер команды, сложность продукта и операционные издержки. Я уже наступал на эти грабли в прошлом и знал, что микросервисы - это не про масштаб системы, а про масштаб команды.
А какая была команда? После двух лет бесплодных усилий от первоначального состава бэкендеров остался один-единственный изможденный разработчик. Представьте: два человека и двадцать микросервисов. Это не архитектура. Это садомазохизм.
Сложность деплоя, отладки, обеспечения консистентности данных, мониторинга была запредельной. Микросервисы не разбивали монолит - они дробили контекст и убивали продуктивность.
Лечение: Жестокая, но необходимая хирургия
Мне было сложно убеждать менеджмент в необходимости тотального пересмотра архитектуры. Не у всех было время и желание вникать в технические детали. Поэтому я действовал по наитию, с единственной целью — спасти проект.
Решение было радикальным: убить все микросервисы и собрать модульный монолит.
За несколько дней я переписал бэкенд, объединив всё в одно цельное, но хорошо структурированное Laravel-приложение. Модульный монолит дал нам:
Единую кодобазу для всех разработчиков.
Простоту деплоя - теперь нужно было запустить один проект, а не двадцать.
Скорость разработки - исчезла необходимость настраивать сложные взаимодействия между сервисами.
Сохранение контекста - разработчик мог работать с функцией от и до, не прыгая между репозиториями.
Параллельно нужно было решить проблему интеграции с 1С, что было больной темой для предыдущего техдира. Мой принцип прост: чтобы выполнить задачу, я готов работать с кем угодно. Мы нашли общий язык с ребятами из 1С (отдельный респект Дмитрию), и в кратчайшие сроки настроили стабильную синхронизацию.
Следующий шаг - инфраструктура. Сложный и тяжелый в поддержке Kubernetes для нашего нового монолита был избыточен. Я мигрировал всё на Docker Swarm - простой и отказоустойчивый инструмент, которого более чем хватало для связки Laravel + MySQL + Nuxt.js на фронте.
Результат: Презентация вопреки всему
У нас не было времени. На носу была внутренняя презентация для владельцев компании, которая должна была решить судьбу проекта после двух лет разработки и значительных финансовых вливаний.
Без ChatGPT, без большой команды, почти в одиночку, мы сделали невозможное:
Переписали и объединили бэкенд.
Подправили фронтенд.
Выстроили CI/CD для нового монолита.
Выкатили работающий прототип.
Менеджеры смогли показать владельцам не просто отчеты о затратах, а живой, дышащий продукт. Помню, как главный менеджер сказал мне: «Ты нас спас». Это было искренне и это многое значило.
Позже проект стал локомотивом компании. На его основе мы запустили еще несколько направлений. Для меня же это был очередной урок, подтверждающий простую истину: не существует идеальной архитектуры на все случаи жизни. Есть архитектура, адекватная вашей команде и продукту на данном этапе его жизни.
Иногда самое элегантное и эффективное решение - это не добавить еще одну сложную технологию, а набраться смелости и убрать лишнее. Даже если это 20 модных микросервисов.
P.S. Иногда до сих пор приходят уведомления от системы мониторинга. Если вижу, что ребята не реагируют, пишу знакомым менеджерам - подсказать, где искать причину. Связь времен не прервалась.
Оставить комментарий
Комментарий