Переписываем 10-летний легаси, разработчик топит за микросервисы — стоит ли городить это для небольшого продукта?

Serkan Ç***8 месяцев назад·47 сообщений·6,7 тыс. просмотра#архитектура софта #микросервис #устаревшая система #обновление софта

Serkan Ç***ВетеранУчастник сообщества

Дата регистрации: май 2023 г.
Сообщение: 294

8 месяцев назад#1

Мы пишем B2B-софт для логистических агентств в США. У нас есть монолитное ядро, написанное еще в 2014 году и годами обраставшее костылями. В системе ежедневно работают и вбивают данные около 1200 активных корпоративных пользователей. Поддерживать это добро стало адом: меняешь строчку в логике счетов — отваливается вообще в другом месте. В итоге выделили бюджет в 70.000 долларов, чтобы переписать систему с нуля на современном стеке.

Сеньор, который недавно к нам пришел руками и ногами за микросервисы. Говорит, надо обязательно бить систему на сервисы: авторизация, биллинг, операции, отчеты — все отдельно. Но у нас в команде всего 3 разработчика, и отдельного девопса или спеца по облакам нет.

Для системы таких масштабов и команды из 3 человек микросервисы — это адекватный путь или мы просто утонем в поддержке инфраструктуры? Как вообще правильно подойти к модернизации старого софта: микросервисы или аккуратный модульный монолит?

Nuri G***УчастникУчастник сообщества

Дата регистрации: июнь 2025 г.
Сообщение: 158

8 месяцев назадСамый полезный#2

Короткий ответ: для команды из трех разработчиков и 1200 активных пользователей микросервисы — это чистый выстрел себе в ногу. При ваших текущих объемах распределенная система не нужна. Вам нужен хорошо спроектированный, модульный монолит, покрытый автотестами.

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

В вашей ситуации правильный план такой: 1) Четко очертить границы доменов и разделить кодовую базу на независимые модули внутри монолита. 2) Нормализовать базу данных и подтянуть покрытие автотестами. 3) Если какому-то процессу действительно понадобится отдельное масштабирование или он жрет слишком много ресурсов (например, массовая генерация PDF-счетов или тяжелые отчеты), только его и выносите в отдельный фоновый воркер через очереди. Потратьте свои 70.000 долларов на качество и логику продукта, а не на возню с оркестрацией и микросервисной инфраструктурой.

Koray C***УчастникУчастник сообщества

Дата регистрации: окт. 2022 г.
Сообщение: 180

8 месяцев назад#3

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

Tülay A***Участник

Должность: Продавец-консультант
Отрасль: Упаковка
Тип организации: команда из 8 человек
Дата регистрации: дек. 2023 г.
Сообщение: 64

8 месяцев назад#4

Мы в прошлом году наступили на те же грабли командой из 4 человек. Распилили систему на 5 сервисов и первые полгода тупо чинили межсервисное взаимодействие. Счета за облака подскочили с 400 долларов до 2300 долларов в месяц. В итоге плюнули, собрали все обратно в модульный монолит, и скорость разработки выросла втрое.

SelinУчастник

Должность: Фронтенд-разработчик
Тип организации: компания из 20 человек
Дата регистрации: февр. 2024 г.
Сообщение: 164

8 месяцев назад#5

Переход на микросервисы — это не просто другой код. Вам придется настраивать service discovery, очереди сообщений, распределенное логирование и распределенные транзакции. Базу данных вы тоже распилите, так что элементарный SQL-джойн превратится в цепочку API-запросов между сервисами. Без фуллтайм-девопса в штате система станет не быстрее, а тупо медленнее.

Ferhat K***Участник

Должность: Тимлид разработки
Отрасль: Машиностроение
Тип организации: компания в составе холдинга
Дата регистрации: янв. 2023 г.
Сообщение: 377

8 месяцев назад#6

Делайте рефакторинг по шагам: 1) Причешите схему базы и завяжите ее напрямую на бизнес-логику, 2) Структурируйте код с микросервисной строгостью по папкам, но держите все в одном репозитории (модульный монолит), 3) Напишите нормальные юнит- и интеграционные тесты, чтобы релиз не превратился в рулетку.

Ufuk S***Ветеран

Должность: Сетевой администратор
Отрасль: Производство мебели
Тип организации: производство
Дата регистрации: окт. 2024 г.
Сообщение: 187

8 месяцев назад#7

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

Vildan U***УчастникУчастник сообщества

Дата регистрации: дек. 2025 г.
Сообщение: 32

8 месяцев назад#8

А если мы останемся на монолите и через пару лет база вырастет до 10 или 50 тысяч пользователей, нам что, опять придется все выбрасывать и переписывать? Мы так сами себе рост не перекроем?

Pınar K***Новый участникУчастник сообщества

Дата регистрации: авг. 2026 г.
Сообщение: 410

8 месяцев назад#9

Да 50 тысяч пользователей спокойно крутятся на одной грамотно настроенной тачке. Огромные мировые SaaS-сервисы с миллионами транзакций до сих пор прекрасно живут на модульных монолитах. Если потом что-то упрется в потолок, вынесете этот конкретный модуль в отдельный сервис, а городить распределенку заранее нет вообще никакого смысла.

Ömer E***УчастникУчастник сообщества

Дата регистрации: авг. 2023 г.
Сообщение: 71

8 месяцев назад#10

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