Объявим участников. В правом углу — бывший чемпион в супертяжелом весе — Мистер Монолит. В левом углу — молодая и накачанная банда микросервисов в полулегком весе.

Я видел несколько серьезных монолитов в своей жизни. У одного из них было около 5+ часов времени сборки, и компании пришлось построить свой собственный CI, чтобы продолжать двигаться вперед.

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

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

Определения

Монолитная архитектура ПО — это подход к построению приложений, где весь функционал концентрируется в одном приложении или модуле. Все компоненты, такие как пользовательский интерфейс, бизнес-логика и база данных, находятся внутри одной кодовой базы. В екоме его представляют Битрикс и интерпрайз-решения вроде Magento. 

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

Мертвая лошадь?

Позвольте мне пропустить разговор о проблемах монолита, нет смысла пинать мертвую лошадь. И позвольте мне сосредоточиться немного на проблемах с микросервисами.

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

Кто должен просыпаться в 2 часа ночи, если ваш сервис начал хромать? Специальная команда Ops для монолита обычно обладает достаточными знаниями, чтобы решить проблемы первого уровня и позволяет вам справиться с остальными в 8 утра. Как только у вас появляются сотни микросервисов, вы довольно часто оказываетесь с парой человек или даже с одним, которые знают, как поддерживать работу этого конкретного сервиса. Не очень-то весело просыпаться в 2 часа ночи только потому, что какой-то мониторинг дал ложный положительный результат. Кроме того, это невероятно увеличивает операционные риски что произойдет, если этот человек, который знает какой-то конкретный микросервис, уедет в отпуск в место без интернета?

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

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

Монолит использует тот же язык, фреймворк и т. д. В результате перемещение людей между частями монолита становится простым. Перемещение людей между различными микросервисами (которые могут иметь совершенно разные технологические стеки) — это сложно.

Отладка чего-либо в наборе микросервисов — это, мягко говоря, болезненно. Любой, кому приходилось гоняться за ошибкой в ​​4—5 микросервисах туда-сюда в течение нескольких дней, чтобы обнаружить, что один из них не выполнил какую-либо проверку, поймет.

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

Я почти уверен, что есть много других минусов. Однако даже этот список заставляет меня усомниться в том, что микросервисы — это панацея .

Ок. Монолит плох. Микросервисы плохи... Ааааа... Всё плохо. Бежать некуда. Что делать?

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

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

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

Вопрос масштаба

Забавный факт состоит в том что если достаточно покрутить микроскоп через который мы смотрим на проект в монолите можно микро сервисный подход. Любой проект использует сторонние библиотеки, API и т. д., вполне себе микросервисы. 

А еще забавнее что тот же фокус можно проделать и с микросервисами. И запросто может оказаться что компания которая кичиться что у нее внутри микросервисы, модный смузи и они за френдли атоствфету — окажеться что у них N монолитов как то между собой связаны. 

В данной части я конечно утрирую, но все же от проекта к проекту понитие “микро” может быть разным. Где то это сервис вроде PIM, поиска или шины данных, а у кого то это сервис состоящий из 1 — 2 классов и например конвертирует данные из одного формата в другой. 

Все упирается в вопросы масштаба с которым вы смотрите.

Что выбрать? 

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

По мере того, как они начинают расти, ищите естественные трещины (куски кода с очень разными атрибутами). Это те части, которые можно постепенно разделить на отдельные сервисы. 

Главное не пропустить момент, когда монолит выходит из-под контроля. Лучше начать разделять вещи немного преждевременно, чем сделать это слишком поздно. Мое внутреннее чувство подсказывает, что как только вы начинаете тратить около 5% своего времени на борьбу с проблемами монолита, пора что-то с этим делать.

Приведу пример на родном, прости господи, Битрикс. С ростом проекта, вероятно, первым делом у вас возникнул проблемы со стандартным обмен с 1С, если оно есть. Это решается как раз выделение модуля обмена в отдельный сервис плюс шина данных Ребит или Кафка. 

Контекст имеет решающее значение

В жизни в чистом виде, почти наверняка, нет ни микросервисов ни монолитов. Кругом гибриды и компромиссные решения из набора монолитов и микросервисов. При выборе стоит учитывать эволюционный путь трансформации ПО, сколько это будет стоит и как больной это будет делать.