Comments 9
Нехватает продолжения в виде "и в итоге очень пожалели"
Не видел ни одного случая, когда в процессе нескольких лет доработки и эксплуатации, после перехода на микросервисы не начиналась бы мигрень у всего коллектива. Хотя, палка о двух концах конечно же.
Через год можно писать «как мы перешли с микросервисов на монолит».
Изменения в одном модуле могли повлиять на другую часть
Так всё-таки — могли или реально влияли?
А почему тогда не рассматривался вариант доработки архитектуры в сторону меньшей связанности модулей? Не факт, что она была изначально плохой — просто иногда такие ситуации становятся поводом для улучшений.
И ещё интересно: в чём именно была сложность полного тестирования системы? Это больше про объём работы, отсутствие автоматизации или про организационные ограничения?
Как это обычно бывает, микросервисная-на-словах архитектура стала просто сервисной (SOA).
Подозреваю, многие процессы, например отладки багов или деплоя апдейтов на прод и в прочие окружения, - также усложнились.
А всё потому, что кто-то где-то услышал, что (микро)сервисная архитектура - это стильно, модно, молодёжно.
Вообще не вижу ничего плохого в том, что распилили на сервисы. Даже поддержал бы в том, что разным стекам место в разных репозиториях. Контракты на gRPC -- окей. Документированное API -- ну а как иначе? Нужен девопс -- куда-ж без него, когда ещё надо и горизонтально масштабироваться?
В принципе всё логично. Но сухо: "было так, решили, переделали, стало сяк. Вот очевидные плюсы и очевидные минусы". А где мясо?
Какие были сложности и внезапные приколдесы при рефакторинге?
Что рассматривали и в итоге взяли для gRPC сервера на пыхе с симфой?
Смотрели ли на Temporal? Почему не взяли?
Смотрели ли на OTEL и трейсинг в целом?
Какие ошибки допустили и какие советы могли бы дать, чтобы это избежали другие?
Вообще не вижу ничего плохого в том, что распилили на сервисы
Пилить на микросервисы только ради того, чтобы были микросервисы, это уже плохо.
Надо начинать с вопросов: действительно ли есть проблемы, которые решают микросервисы? Готовы ли разработчики к многократному усложнению инфраструктуры? Осилит ли команда поддержку такой системы?
Если ответы — нет, возможно, переходить на микросервисы преждевременно.
К тому же известны случаи, когда компании после перехода на микросервисы откатывались обратно на монолит.
Segment — переход назад к монолиту (Goodbye Microservices: From 100s of problem children to 1 superstar)
Hey.com / Basecamp — возврат к монолиту. DHH (David Heinemeier Hansson) про возврат к монолиту («Не буду отрицать, что существуют случаи, когда архитектура, ориентированная на микросервисы, имеет смысл, но, думаю, их мало. Подавляющему большинству систем гораздо выгоднее начинать и поддерживать величественный монолит.») Рассуждения и рекомендации, почему вернулись и не стоит дробить систему.
Monzo — не то, чтобы вернулись, но признали проблемы и развернулись в сторону централизации.
Надо начинать с вопросов: действительно ли есть проблемы, которые решают микросервисы? Готовы ли разработчики к многократному усложнению инфраструктуры? Осилит ли команда поддержку такой системы?
Я рассуждаю так: если уже распилено, значит причины (проблемы) были. Раз решились, значит о рисках знали и их приняли (или не знали, но готовы были встретить). В общем статья то и не о муках принятия решения, а конкретно о переходе.
Я работал с микросервисами и чувствовал себя прекрасно; и как какой-то сервис слишком набухал, его дробили. Да, можно писать весь проект в одной репе и размазывать его полностью или частично по подам, называя это распределённым монолитом. Но будем честны: у монолитов тоже хватает проблем.
Изменения в одном микросервисе тоже легко могут поломать другой. Так что мотивация для распила монолита так себе. А вот существенное усложнение системы налицо. Если оно окупается, то гут.
Рефакторинг системы рекомендаций: как мы перешли с монолита на микросервисы