Разговор о микросервисах и монолитах. Как определить лучший путь для проекта?

Выбор между микросервисной и монолитной архитектурой не является строгим дихотомичным разделением, а требует глубокого анализа специфики бизнеса, технологических возможностей и ресурсов компании. К таким выводам пришли участники круглого стола, организованного журналом IT Manager и клубом «ИТ Диалог». ИТ-директора и представители ведущих ИТ-компаний обсудили, когда и почему выбирать микросервисы или монолиты для своих проектов. Разговор получился живым и полным разнообразных мнений. Эксперты согласились, что любой подход должен быть оправдан с точки зрения реальных задач и целей.

Между модой и функциональностью

Алексей Михайлов, Delivery Manager компании «Астон», начал с того, что признал преимущества микросервисной архитектуры, но быстро перешел к ее недостаткам. Он подчеркнул, что для многих компаний микросервисы могут оказаться слишком сложными и дорогими в содержании, учитывая необходимость в инвестициях, в команде, инфраструктуре и DevOps. «Монолиты еще долго будут с нами», — сказал он, указывая на простоту и доступность такого подхода для стартапов и компаний с небольшими сервисами. В свою очередь, Антон Кузнецов, ИТ-директор «Динекс Русь», выделил ключевые преимущества микросервисов, такие как способность быстро адаптироваться к изменениям бизнес-требований и масштабируемость. «Высокая отказоустойчивость — одно из главных достоинств», — подчеркнул он, добавив, что в случае сбоев в одном микросервисе остальные продолжают функционировать без проблем.

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

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

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

Действительно, иногда монолитные решения могут представляться как микросервисы из маркетинговых соображений. «Микросервисы воспринимаются как что-то модное и масштабируемое, но зачастую это просто удобный способ представления», — объяснил Авенир Воронов («Корус Консалтинг»), добавив, что иногда целесообразнее начать проект с монолита, а затем, если это оправдано, перейти к микросервисам.

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

Скорость, масштабирование и другие критерии

Выбор архитектуры всегда зависит от динамичности бизнес-требований. «Если бизнесу необходима быстрая адаптация и масштабирование, то выбор падает на микросервисы. Но если требования относительно статичны, то начать можно и с монолита, хотя со временем возможно придется переходить на микросервисы», — объяснил Антон Кузнецов («Динекс Русь»), указывая на общую тенденцию перехода к более гибким решениям.

Алексей Михайлов («Астон») не согласен с утверждением, что микросервисы всегда быстрее и дешевле в разработке. «Не в каждой компании происходит взрывной рост, который оправдывает сложности и издержки микросервисов. Для многих ИТ-решений, особенно в компаниях с небольшими ИТ-отделами, создание монолита остается более доступным и экономически выгодным», — отметил он.

По словам модератора Максима Каранкевича, есть определенная аналогия с автомобилями, где скорость достижения требуемых показателей зависит от множества факторов, включая размер команды и масштаб проекта: «Все спикеры упоминают один важный аспект — скорость адаптации архитектуры под требования бизнеса. Представьте, что нам нужно разогнать автомобиль до 200 км/ч. И при одинаковой мощности двигателя, команды разработчиков могут достичь этой цели с разной скоростью, в зависимости от «веса» системы — монолита или микросервисов.  Антон утверждает, что микросервисы позволяют быстрее адаптироваться, а Алексей настаивает на том, что монолит проще и быстрее в разработке на начальных этапах. Обе стороны основывают свои аргументы на личном опыте, и, как видно, размер и структура команды играют решающую роль в эффективности каждого подхода».

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

В ответ на это Антон Кузнецов указал на важность хорошо налаженной инфраструктуры для разработки: «У нас настроены системы непрерывной интеграции и доставки, Jenkins и другие инструменты, что позволяет нам быстро адаптироваться и использовать различные технологические стеки в рамках одного проекта. Благодаря этому микросервисы мы можем разрабатывать значительно быстрее».

Гибридный подход

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

«Часто обсуждение сосредоточивается на размере команды или компании, но на самом деле должно опираться на нужды бизнеса. Крупные компании могут рассматривать микросервисы для своих технологически сложных и высоконагруженных функций, тогда как более стандартные корпоративные функции часто выполняются на базе монолитных или готовых решений», — сказал Тарас Сорока (Уральский банк реконструкции и развития). Он также добавил, что наличие стандартных корпоративных решений не всегда оставляет место для микросервисов, за исключением специфических, нестандартных требований.

А еще он поделился опытом работы в банковском секторе, где основные системы, так называемый core banking, в подавляющем большинстве случаев все еще остаются монолитными по множеству причин. При этом у него есть успешный опыт миграции кредитного конвейера на микросервисы, что позволило улучшить производительность и управляемость процессов: «Переход на микросервисы решил многие проблемы, которые мы не могли реализовать в рамках старой монолитной системы», но, как верно отмечали коллеги, требует новых компетенций команды и влечет за собой дополнительные издержки.

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

Он также выразил сомнение в целесообразности создания микросервисов для комплексных корпоративных систем типа ERP или CRM с нуля, подчеркивая предпочтительность «коробочных» решений от крупных вендоров. Однако, для специфических задач, таких как навигация или диспетчеризация, он упомянул успешное использование микросервисов, включая партнерство с крупными технологическими компаниями вроде Яндекса.

Трудности перехода

Почему многие компании начинают с монолитной архитектуры и впоследствии пытаются интегрировать микросервисы? «Что в технологии не так, что базовые приложения все еще делают монолитами?» — спросил Максим Каранкевич.

Изменения в монолите часто бывают трудоемкими и сложными, особенно в критических ситуациях, когда требуется быстрая адаптация. «Недавно мы столкнулись с необходимостью быстро развернуть функционал на микросервисах из-за отключения от корневой системы, чтобы обеспечить непрерывность бизнеса», — поделился Антон Кузнецов («Динекс Русь»).

Алексей Михайлов («Астон») удивился решению Антона начать «пилить» систему на микросервисах в ситуации срочной необходимости. Он указал на возможности масштабирования и управления нагрузкой в монолитных системах через множественные инстансы: «Вы можете управлять большим монолитом, используя различные инстансы для распределения нагрузки, что решает многие проблемы с доступностью».

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

А у Тараса Сороки есть опыт работы в телеком-секторе, где обновление большой монолитной системы происходило всего несколько раз в год из-за сложностей и длительности процесса. «Мы обновляли систему редко, потому что каждое обновление требовало длительной подготовки, тщательного тестирования изменений от разных команд, больше суток на остановку сервиса и еще больше на поднятие, и в случае выявления проблем, чтобы уложиться в технологическое окно, все откладывалось до следующего квартала», — рассказал он. После того как вендор выпустил обновление, позволяющее обновлять систему на лету, ситуация улучшилась.

Он также отметил, что многие системы были разработаны десятилетия назад, когда они соответствовали самым передовым технологиям: «Корпоративные системы, которыми мы продолжаем пользоваться, были созданы 15–20 лет назад. В то время они представляли собой передовые технологии, но теперь устарели, хотя они все еще поддерживаются и используются, а их замена на что-то новое влечет несоизмеримые с предполагаемой выгодой затраты».

Критерии выбора

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

«Обычно, если проект предполагает значительную геораспределенность, первым рассматривается вопрос о микросервисах. Например, когда требуется собирать данные со всего мира или нагрузка распределена по различным регионам, микросервисы предоставляют необходимую гибкость и масштабируемость» — такие критерии назвал Авенир Воронов («Корус Консалтинг»)

В ответ Алексей Михайлов («Астон») подчеркнул важность понимания потоков данных для эффективного перехода на микросервисы: «Допустим, у вас уже есть созданная крупная рабочая система. Тогда гораздо проще сделать следующий шаг, например, выделить лямбды в AWS или определить будущие топики в Kafka. Если в системе четко понятен поток данных, а также уже предусмотрены интерфейсы для взаимодействия со смежными сетями и известны общие потребности и предпочтения вашего клиента, переход на микросервисы будет значительно проще».

Иван Козлов, ИТ-директор группы «Латео», объяснил позицию по выбору между монолитами и микросервисами, исходя из своего опыта: «Когда мне нужен новый продукт, мне обычно не нужен маленький кусочек. Если мне нужен маленький кусочек, я делаю заказную разработку, и эта заказная разработка у меня работает отдельным решением. А если мне нужна ERP или CRM или еще какая-то большая система, мне нужен сразу большой функционал, который писать по кусочкам и собирать из микросервисов — долго, дорого и зачем?».

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

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

В ходе дискуссии о преимуществах микросервисной и монолитной архитектур участники круглого стола высказали свои точки зрения.

Безусловно важными являются отказоустойчивость и надежность. Антон Кузнецов («Динекс Русь») отметил, что при падении монолита вся система становится недоступной, в то время как при использовании микросервисов отказ одного сервиса не останавливает работу остальных. К примеру, если в кредитном конвейере при микросервисной архитектуре упадет лишь один этап, это не приведет к полной остановке системы.

Но не менее важны такие критерии для микросервисов. Потому что для обеспечения надежной работы микросервисов требуется значительное усилие по настройке обвязок, созданию механизмов отслеживания и диагностике проблем: «Чтобы у вас микросервисы были надежными и работали хорошо, во-первых, нужно сделать просто колоссальную работу, обвязки этих самых микросервисов, вам нужно поднять ЕЛК, сделать traceability», — отметил Алексей Михайлов («Астон»). Также он выразил опасения относительно прочности цепи микросервисов, добавив, что с увеличением числа звеньев в цепи растет вероятность ее поломки.

Иван Козлов (группа «Латео») привел пример стратегии разделения монолита на отдельные компоненты для упрощения процесса обновления функционала: «Проблема большого монолита в том, что для обновления его нужно остановить, и на какое-то время все предприятие не сможет работать с ним». Он подчеркнул, что разбивая монолит на части, можно обновлять их по отдельности, минимизируя простои и влияние на весь функционал.

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

С ним согласен и Алексей Михайлов (Астон): «Вам не обязательно переделывать полностью монолит для того, чтобы обеспечить возможность деплоить его, когда вы захотите».

Пример подхода к обновлению и сопровождению сложных систем, используя концепцию "clean core", которую пропагандирует SAP, привел Петр Сагаловский, ИТ-директор российской компании. Он отметил, что подобный подход напоминает использование микросервисов, где стандартный код остается в системе, а нестандартные программы выносятся в отдельные исполняемые программы через API. Это позволяет упростить обновление и сопровождение системы, минимизируя изменения в стандартном коде и упрощая разработку нестандартных решений.

***

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