Оставьте заявку
Оставьте заявку
Микросервисы в стартапах – зло или разумное решение?

Микросервисы в стартапах — зло или разумное решение?

После заявлений о внедрении продуктов на микросервисной архитектуре в таких крупных технологических компаниях, как Google и Amazon, подобный подход при разработке современных приложений многими стал восприниматься как единственно верный. Но так ли это на самом деле?
Так называемую монолитную архитектуру, в рамках которой все компоненты системы находятся вместе и работают в одном приложении, некоторые поспешили похоронить как нечто устаревшее и отжившее свой век. Однако она продолжает пользоваться популярностью, особенно у опытных специалистов, за плечами которых не один успешный проект.

Monoliths first

Эксперты в области разработки программного обеспечения говорят: «Monoliths first» и не рекомендуют стартапам создавать приложения на основе микросервисной архитектуры (MSA), несмотря на веяния моды и пожелания многих высококвалифицированных разработчиков использовать именно микросервисы.

Такие рекомендации основаны на преимуществах монолитной архитектуры перед MSA, которые критически значимы на начальной стадии разработки любого продукта. Речь идет о скорости и простоте разработки, которые так важны при создании минимально жизнеспособного продукта. Добавим сюда сложности определения границ микросервисов на старте, что гарантированно повлечет за собой переработку и без того дорогого продукта. На выходе получатся сорванные сроки, израсходованный бюджет и нечто, напоминающее технологический экзоскелет, которым непонятно, как пользоваться, и непонятно, для чего его делали, ведь заказчик хотел простую «телегу для перевозки грузов»
Сравнение монолитной и микросервисной архитектуры

Инженеры предпочитают MSA

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

Попытаемся понять, каковы причины такого выбора квалифицированных разработчиков. Чаще всего всё сводится к следующим факторам.
  • Независимое масштабирование и развертывание. Основная концепция MSA заключается в четком определении границ каждого микросервиса и минимизации взаимосвязей этого микросервиса с другими. Каждый микросервис – это отдельный модуль с собственной базой данных, который имеет простой и ограниченный набор функций и способен работать независимо от других модулей. Это очень удобно для параллельной разработки, когда несколько команд занимаются каждая своим микросервисом и не зависят от качества кода смежных команд.
  • Отсутствие эффекта «спагетти-кода», который часто встречается в монолитных решениях. «Спагетти-код» – это когда всё находится везде и код перепутан, как спагетти в тарелке. Разработчику крайне трудно разобраться, как работает система, и для того чтобы безопасно изменить такой код, нужно потратить много времени.
  • Свобода выбора технологий. При разработке нового микросервиса отсутствуют ограничения в технологиях из-за принятых ранее решений. В системе, построенной на микросервисной архитектуре, могут прекрасно уживаться сервисы, созданные по разным технологиям и даже на разных языках программирования. Это, в свою очередь, развязывает руки разработчику в применении различных технологий для выполнения конкретных требований.
  • Возможность применения на практике современных методик, описанных ведущими инженерами мира. Данный пункт вытекает из предыдущего. Большинство высококвалифицированных разработчиков при создании очередного микросервиса обязательно захотят «поиграть с новыми игрушками» и попробовать применить на практике современные методики. В случае с MSA у них в этом плане не будет никаких ограничений.

Плюсы и минусы MSA

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

Не вдаваясь в технические подробности, рассмотрим подробнее основные преимущества и недостатки MSA, чтобы понять, в каких ситуациях преимущества будут преобладать над недостатками, а в каких – наоборот.
  • Устойчивость системы. Каждый компонент системы на основе архитектуры MSA способен работать полностью независимо от других компонентов. И в нештатной ситуации из строя выйдет не вся система, а только тот функциональный блок, за который отвечал данный микросервис. Например, если микросервис, отвечающий за поиск, перестанет функционировать, это повлияет только на работу поиска. Остальные функции, такие как создание и открытие документов, продолжат работать без изменений. А благодаря следующему преимуществу (горизонтальному масштабированию) критически важные элементы могут быть продублированы на разных серверах, и в случае выхода из строя одного сервиса его задачи тут же подхватит копия этого сервиса на другом сервере. Таким образом, при желании можно выстроить систему, которая будет устойчива к любым техническим сбоям, связанным с оборудованием.
  • Горизонтальное масштабирование системы. Каждый модуль системы может быть совершенно независим и находиться на отдельном сервере. Например, вместо одного дорогого сервера с высокой производительностью иногда дешевле приобрести четыре дешевых сервера с низкой производительностью и один средний (или два с низкой) для высоконагруженного модуля. Это позволяет гибко управлять ресурсами и экономить на них при резком росте нагрузки на конкретные модули системы. Также это повышает эффективность оптимизации высоконагруженных систем по сравнению с монолитными системами, которые могут быстро увеличиваться в размере и усложняться за счет нагромождения неструктурированного кода. В результате такие системы крайне трудно масштабировать и поддерживать.
  • Независимость компонентов. Каждый модуль системы может быть разработан и развернут независимо от других модулей. Это позволяет быстро вносить изменения в модуль, не затрагивая другие модули системы. Разные команды могут вести разработку параллельно, независимо друг от друга, что очень актуально для сложных систем с большим количеством разработчиков. Независимость компонентов также позволяет не привязываться к какой-либо одной технологии в рамках всей системы. Компоненты могут быть совместимы, но при этом созданы при помощи разных технологий и языков программирования, что открывает простор для безболезненной модернизации тех или иных компонентов в будущем, если они технологически устарели.
Однако помимо достоинств, у MSA есть и серьезные недостатки, многие из которых являются платой за вышеописанные достоинства. Наиболее часто разработчики решений на микросервисной архитектуре сталкиваются со следующими проблемами.
  • Необходимость корректной декомпозиции. У каждого компонента системы должны быть четко очерченные границы, за которые данный компонент отвечает. На старте разработки, когда требования могут быть размыты, а цели не всегда определены полностью, разрастание требований может привести к глобальным изменениям в логике работы целых сервисов, что может повлечь за собой существенные по времени и ресурсам исправления в системе.
  • Сложность разработки. Система на микросервисной архитектуре значительно сложнее в плане разработки, требует высокой компетентности исполнителей, а также подробной документации и слаженности действия команд. Один из примеров такой сложности – версионирование функций модуля. Оно требуется из-за отсутствия информации в изменяемом компоненте о том, какие сервисы и как именно используют его функционал. По этой причине небольшие изменения в одном модуле могут спровоцировать критические ошибки в других сервисах. Эти ошибки иногда трудно предугадать на этапе разработки из-за отсутствия информации у сервиса о потребителях изменяемого функционала. При разработке также необходимо учитывать сетевое взаимодействие микросервисов и возможные сценарии сетевых ошибок при этом. Каждый компонент системы должен четко знать, как реагировать на те или иные сбои: повторять запрос через определенное время, генерировать ошибку или попытаться отменить транзакцию и т.д.
  • Сложность тестирования системы. Это следствие сложности разработки. Юнит-тестов недостаточно, поскольку ошибки могут возникать на стыке сервисов. Если в монолитной системе путь запроса можно отследить в рамках одной системы, то в MSA запрос может выполняться несколькими разными микросервисами и отслеживать придется не только работу самих микросервисов, но и их сетевое взаимодействие. Из-за этого установить, почему именно произошла ошибка при обработке запроса, становится довольно сложно. По этой же причине работа системы должна быть качественно охвачена тестами. Многие ошибки могут быть выявлены только на тестовом стенде, при полном тестировании системы с задействованием всех используемых микросервисов.
  • Работа с транзакциями и целостность бизнес-операций. Целостность какой-либо бизнес-операции может быть гарантирована только в рамках одного микросервиса. Если при выполнении какой-либо бизнес-операции что-то пошло не так, то в отличие от монолитной архитектуры, отменить все выполненные ранее действия в MSA может быть мучительно трудно. Для того чтобы в подобных случаях предусмотреть и нейтрализовать большую часть потенциальных ошибок, команда разработки должна обладать высокой квалификацией

В каких проектах MSA лучше «монолита»?

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

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

Во всех остальных случаях, если нет острой потребности в преимуществах MSA, желательно ограничиться монолитной архитектурой, которая позволит быстро разработать минимально жизнеспособный продукт и привлечь первых клиентов. Только когда такая потребность появится (если появится), можно задуматься о разделении приложения на микросервисы.

Юрий Степанов, ведущий системный аналитик по разработке платформы LDM, ЛАНИТ