Монолит или микросервисы

Одним из самых ярких вопросов в мире программирования является «Монолит или микросервисы». И иногда заказчик может услышать, что для разработки программы будет использоваться архитектура микросервисов. Как правило, этот факт преподносится как некоторое преимущество. И еще чаще монолитная архитектура считается у разработчиков некоторым недостатком. Должен ли данный вопрос волновать заказчика? Ответ – однозначно да.

Начнем издалека. Изначально все приложения были монолитными, да и сейчас большинство такие. Программа в таком случае, как следует из названия, представляет собой единое целое. С этим можно было бы немного поспорить, но это не так важно в нашем контексте. Затем появился интернет, целевая аудитория которого начала быстро расти. Некоторые интернет-сервисы становились настолько крупными, что даже самые дорогие сервера уже не могли в одиночку справляться с обработкой запросов. Поиск решения данной проблемы, в конечном итоге, привел к созданию микросервисной архитектуры, которая стала очень активно применяться в проектах с высокой нагрузкой, например, в соцсетях. В случае микросервисов вся «программа» делится на большое количество более мелких программ, которые обмениваются между собой данными.

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

Большинство разработчиков по умолчанию считает, что микросервисы лучше. Да, это более современная архитектура, позволяющая создавать сервисы, которые легко масштабируются. Очень классно иметь в резюме строчку с микросервисами. Но, как известно, за все нужно платить. Разработка с использованием микросервисов сложнее во всех аспектах, начиная с технической части, заканчивая организацией процессов внутри команды. А сложность – это деньги. В случае микросервисов деньги могут быть очень большие.

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

Вот с разработчиками происходит то же самое. Я специально снова перечитал тему на хабре про архитектуру информационной системы ДодоПиццы. А главное комментарии к ним. Даже сотрудник Додо пишет про стартап на 3-5 пиццерий. Он либо не знает историю Додо, либо упускает очень важные детали. Не думаю, что предпринимателям стоит объяснять, какой путь нужно пройти от пиццерии в подвале до 3-5 пиццерий. Программы автоматизации развиваются параллельно бизнесу, и это естественно. Нельзя использовать решения, которые неадекватны текущим обстоятельствам. Разработчики, даже очень крутые, далеко не всегда это понимают.

Архитектура микросервисов может использоваться при наличии большого бюджета на разработку и расчета на большое количество пользователей программы. Если крупный банк берется за разработку сервиса для своих клиентов, то почти наверняка будут использоваться микросервисы, потому что в этом есть прямая необходимость. Но даже в случае крупных компаний достаточно часто покупается готовая монолитная программа, а затем ее «разрезают» на микросервисы, потому что это выгоднее, чем писать все с нуля. В большинстве случаев микросервисы вырастают из монолита. Если нет уверенности в необходимости решения на основе микросервисной архитектуры, то используйте монолит без раздумий, как это делаем мы для своих проектов.

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

Наша компания уже встречалась с проектами, где без видимых причин использовалась микросервисная архитектура. В итоге программы переписывались. Учитывая тот факт, что все наши проекты долгосрочные, нет смысла годами поддерживать излишнюю сложность, там, где в этом нет необходимости. Не все бизнесы вырастают подобно ДодоПицце. Большинство их них никогда не дорастут до размеров, когда автоматизация процессов потребует микросервисных решений для софта. Еще раз: никогда.

Совет: Не стоит заниматься перевозкой картошки на мерседесе S-класса.

Вам также может понравиться...

Популярные посты