Post #244
687
Forwarded from VM
Монолит vs Микросервисы
Я тут пока рассказывал ребятам про pet-проекты крутые, то столкнулся с популярным вопросом на тему того, как мне лучше сделать: все фичи в одном проекте или разбивать на микросервисы? Дескать микросервисы – это хайповая тема, которую хотят в вашем CV все рекрутеры и прочее
В общем когда вы делаете именно pet-проект, то все зависит от вас в общем-то: что вы там хотите изучить, что хотите показать другим людям. Но я бы сказал, что если вы стартанете свой стартап или в принципе какой-то проект с нуля, который будете делать “для себя”, то начинайте лучше с монолита.
Почему? Потому что это гораздо проще разрабатывать. Вы по сути просто пишите код и реализуете фичи, а значит быстрее получаете результат. Как только вы начинаете городить микросервисы просто потому, что они модные, то у вас сразу появляются проблемы:
- Как грамотно разбить вашу логику на отдельные компоненты?
- Какой способ коммуникации между ними использовать?
- Нужно реализовывать механизм retry между сервисами при прерывании коммуникации
- Где хранить данные? У каждого отдельная БД? А куда тогда выносить общие сущности, типа дто, чтобы не дублировать код? Делать библиотеку на artifactory своем? Ух…
Ну и это я так, набросил просто парочку. В общем все сразу усложняется, и вы начинаете заниматься не фичами, а именно микросервисами сначала.
Я бы сказал, что к микросервисам стоит переходить как-то эволюционно. В какой-то момент монолит начинает показывать себя плохо, и тогда нужно садиться и думать, как переехать на микросервисный подход. И это прям задача, требующая размышлений и черновой работы.
Вы удивитесь, возможно, но в BigTech монолит – это крайне часто используемый формат. Т.е. микросервисы не везде. И вообще есть эпизоды эволюции вашей системы, когда микросервисы начинают работать плохо, и вам нужно искать другие решения.
Например, вы, вероятно, слышали про Amazon Prime Video. Ну там сериальчики можно посмотреть, все дела. Так вот они недавно имели архитектуру, которая работала на AWS Lambda и была разбита на атомарные компоненты. В какой-то момент они подумали и решили: “А давай-ка на монолит все перетащим”.
Результат: они урезали стоимость работы сервиса на 90% благодаря этому. Просто представьте, что вы каждый месяц тратите миллионы долларов на это. А тут бац – и в 10 раз меньше!
Посмотреть поподробнее про это можно здесь, например. Очень хороший канал, кстати, рекомендую. Таких мало. Его сделали авторы книжки “System Design Interview”, по которой можно готовиться к собесам, разумеется.
Короче, не торопитесь рисовать микросервисы. Лучше стартаните с одного проекта и заставьте его работать. А потом, если захотите потренироваться, упражняйтесь в разбиении на микросервисы.
Я тут пока рассказывал ребятам про pet-проекты крутые, то столкнулся с популярным вопросом на тему того, как мне лучше сделать: все фичи в одном проекте или разбивать на микросервисы? Дескать микросервисы – это хайповая тема, которую хотят в вашем CV все рекрутеры и прочее
В общем когда вы делаете именно pet-проект, то все зависит от вас в общем-то: что вы там хотите изучить, что хотите показать другим людям. Но я бы сказал, что если вы стартанете свой стартап или в принципе какой-то проект с нуля, который будете делать “для себя”, то начинайте лучше с монолита.
Почему? Потому что это гораздо проще разрабатывать. Вы по сути просто пишите код и реализуете фичи, а значит быстрее получаете результат. Как только вы начинаете городить микросервисы просто потому, что они модные, то у вас сразу появляются проблемы:
- Как грамотно разбить вашу логику на отдельные компоненты?
- Какой способ коммуникации между ними использовать?
- Нужно реализовывать механизм retry между сервисами при прерывании коммуникации
- Где хранить данные? У каждого отдельная БД? А куда тогда выносить общие сущности, типа дто, чтобы не дублировать код? Делать библиотеку на artifactory своем? Ух…
Ну и это я так, набросил просто парочку. В общем все сразу усложняется, и вы начинаете заниматься не фичами, а именно микросервисами сначала.
Я бы сказал, что к микросервисам стоит переходить как-то эволюционно. В какой-то момент монолит начинает показывать себя плохо, и тогда нужно садиться и думать, как переехать на микросервисный подход. И это прям задача, требующая размышлений и черновой работы.
Вы удивитесь, возможно, но в BigTech монолит – это крайне часто используемый формат. Т.е. микросервисы не везде. И вообще есть эпизоды эволюции вашей системы, когда микросервисы начинают работать плохо, и вам нужно искать другие решения.
Например, вы, вероятно, слышали про Amazon Prime Video. Ну там сериальчики можно посмотреть, все дела. Так вот они недавно имели архитектуру, которая работала на AWS Lambda и была разбита на атомарные компоненты. В какой-то момент они подумали и решили: “А давай-ка на монолит все перетащим”.
Результат: они урезали стоимость работы сервиса на 90% благодаря этому. Просто представьте, что вы каждый месяц тратите миллионы долларов на это. А тут бац – и в 10 раз меньше!
Посмотреть поподробнее про это можно здесь, например. Очень хороший канал, кстати, рекомендую. Таких мало. Его сделали авторы книжки “System Design Interview”, по которой можно готовиться к собесам, разумеется.
Короче, не торопитесь рисовать микросервисы. Лучше стартаните с одного проекта и заставьте его работать. А потом, если захотите потренироваться, упражняйтесь в разбиении на микросервисы.
- 👍 7
