Разговор о микросервисах и монолитах. Как определить лучший путь для проекта?
Выбор между микросервисной и монолитной архитектурой не является строгим дихотомичным разделением, а требует глубокого анализа специфики бизнеса, технологических возможностей и ресурсов компании. К таким выводам пришли участники круглого стола, организованного журналом IT Manager и клубом «ИТ Диалог». ИТ-директора и представители ведущих ИТ-компаний обсудили, когда и почему выбирать микросервисы или монолиты для своих проектов. Разговор получился живым и полным разнообразных мнений. Эксперты согласились, что любой подход должен быть оправдан с точки зрения реальных задач и целей.
Между модой и функциональностью
Алексей Михайлов, Delivery Manager компании «Астон», начал с того, что признал преимущества микросервисной архитектуры, но быстро перешел к ее недостаткам. Он подчеркнул, что для многих компаний микросервисы могут оказаться слишком сложными и дорогими в содержании, учитывая необходимость в инвестициях, в команде, инфраструктуре и DevOps. «Монолиты еще долго будут с нами», — сказал он, указывая на простоту и доступность такого подхода для стартапов и компаний с небольшими сервисами. В свою очередь, Антон Кузнецов, ИТ-директор «Динекс Русь», выделил ключевые преимущества микросервисов, такие как способность быстро адаптироваться к изменениям бизнес-требований и масштабируемость. «Высокая отказоустойчивость — одно из главных достоинств», — подчеркнул он, добавив, что в случае сбоев в одном микросервисе остальные продолжают функционировать без проблем.
Авенир Воронов, CTO «Корус Консалтинг», поставил под вопрос противопоставление монолитов и микросервисов как нечто чересчур упрощенное. «Есть много других архитектур», — заметил он, и важно не следовать слепо моде, а выбирать подход, оптимально решающий конкретные задачи бизнеса. Он также упомянул, что некоторые «модные» технологии могут быть привлекательны, но не всегда оправданы с точки зрения бизнес-потребностей.
В ходе обсуждения эксперты согласились, что выбор между монолитной и микросервисной архитектурой не должен основываться на тенденциях или предвзятом мнении. Решение должно опираться на глубокий анализ требований и возможностей бизнеса, с учетом всех преимуществ и недостатков каждого подхода.
А что происходит с реальной практикой внедрения и представления архитектурных решений клиентам? Модератор дискуссии Максим Каранкевич задал провокационный вопрос, сталкивался ли кто-то с ситуацией, когда монолит продавался как набор микросервисов.
Действительно, иногда монолитные решения могут представляться как микросервисы из маркетинговых соображений. «Микросервисы воспринимаются как что-то модное и масштабируемое, но зачастую это просто удобный способ представления», — объяснил Авенир Воронов («Корус Консалтинг»), добавив, что иногда целесообразнее начать проект с монолита, а затем, если это оправдано, перейти к микросервисам.
Но при выборе технологического решения архитектура системы редко бывает ключевым фактором. «В итоге все сводится к тому, насколько хорошо предложенное решение удовлетворяет потребностям бизнеса, в первую очередь, и ИТ. Архитектура — это лишь один из множества факторов», — сказал Тарас Сорока, управляющий директор Уральского банка реконструкции и развития, подтверждая слова других участников о том, что внимание должно быть сосредоточено на решении конкретных бизнес-задач.
Скорость, масштабирование и другие критерии
Выбор архитектуры всегда зависит от динамичности бизнес-требований. «Если бизнесу необходима быстрая адаптация и масштабирование, то выбор падает на микросервисы. Но если требования относительно статичны, то начать можно и с монолита, хотя со временем возможно придется переходить на микросервисы», — объяснил Антон Кузнецов («Динекс Русь»), указывая на общую тенденцию перехода к более гибким решениям.
Алексей Михайлов («Астон») не согласен с утверждением, что микросервисы всегда быстрее и дешевле в разработке. «Не в каждой компании происходит взрывной рост, который оправдывает сложности и издержки микросервисов. Для многих ИТ-решений, особенно в компаниях с небольшими ИТ-отделами, создание монолита остается более доступным и экономически выгодным», — отметил он.
По словам модератора Максима Каранкевича, есть определенная аналогия с автомобилями, где скорость достижения требуемых показателей зависит от множества факторов, включая размер команды и масштаб проекта: «Все спикеры упоминают один важный аспект — скорость адаптации архитектуры под требования бизнеса. Представьте, что нам нужно разогнать автомобиль до 200 км/ч. И при одинаковой мощности двигателя, команды разработчиков могут достичь этой цели с разной скоростью, в зависимости от «веса» системы — монолита или микросервисов. Антон утверждает, что микросервисы позволяют быстрее адаптироваться, а Алексей настаивает на том, что монолит проще и быстрее в разработке на начальных этапах. Обе стороны основывают свои аргументы на личном опыте, и, как видно, размер и структура команды играют решающую роль в эффективности каждого подхода».
По мнению Алексея Михайлова, хотя монолит может проигрывать во времени на тестирование, в итоге это компенсируется меньшей потребностью в координации между командами и пересмотре документации. «Да, монолит тестировать сложнее, зато у вас не будет проблем с несогласованностью между сервисами», — аргументировал он. Алексей также заметил, что начальная скорость разработки монолита может быть выше, но максимальная эффективность микросервисов значительно больше при условии инвестиций в их развитие.
В ответ на это Антон Кузнецов указал на важность хорошо налаженной инфраструктуры для разработки: «У нас настроены системы непрерывной интеграции и доставки, Jenkins и другие инструменты, что позволяет нам быстро адаптироваться и использовать различные технологические стеки в рамках одного проекта. Благодаря этому микросервисы мы можем разрабатывать значительно быстрее».
Гибридный подход
Выбор между монолитами и микросервисами не всегда является простым решением «либо/либо». Вместо этого компании часто используют гибридные подходы, выбирая наилучшее из обоих миров в зависимости от конкретной задачи и сферы деятельности. Это особенно актуально в таких крупных и консервативных отраслях, как банкинг.
«Часто обсуждение сосредоточивается на размере команды или компании, но на самом деле должно опираться на нужды бизнеса. Крупные компании могут рассматривать микросервисы для своих технологически сложных и высоконагруженных функций, тогда как более стандартные корпоративные функции часто выполняются на базе монолитных или готовых решений», — сказал Тарас Сорока (Уральский банк реконструкции и развития). Он также добавил, что наличие стандартных корпоративных решений не всегда оставляет место для микросервисов, за исключением специфических, нестандартных требований.
А еще он поделился опытом работы в банковском секторе, где основные системы, так называемый core banking, в подавляющем большинстве случаев все еще остаются монолитными по множеству причин. При этом у него есть успешный опыт миграции кредитного конвейера на микросервисы, что позволило улучшить производительность и управляемость процессов: «Переход на микросервисы решил многие проблемы, которые мы не могли реализовать в рамках старой монолитной системы», но, как верно отмечали коллеги, требует новых компетенций команды и влечет за собой дополнительные издержки.
Константин Волошин, заместитель генерального директора по цифровой трансформации компании «Корпоративные сервисы», начал свое выступление с критического взгляда на обе архитектуры, поднимая важные вопросы. «Как ИТ-директор, я сталкиваюсь с необходимостью обеспечить стабильную работу системы, которая, будучи монолитом, может вызвать серьезные сложности при каждом обновлении. В то же время микросервисы предлагают использовать разнообразные технологии для каждой задачи, что приводит к необходимости иметь огромную команду специалистов — по одному на каждый сервис», — поделился он своим опытом.
Он также выразил сомнение в целесообразности создания микросервисов для комплексных корпоративных систем типа ERP или CRM с нуля, подчеркивая предпочтительность «коробочных» решений от крупных вендоров. Однако, для специфических задач, таких как навигация или диспетчеризация, он упомянул успешное использование микросервисов, включая партнерство с крупными технологическими компаниями вроде Яндекса.
Трудности перехода
Почему многие компании начинают с монолитной архитектуры и впоследствии пытаются интегрировать микросервисы? «Что в технологии не так, что базовые приложения все еще делают монолитами?» — спросил Максим Каранкевич.
Изменения в монолите часто бывают трудоемкими и сложными, особенно в критических ситуациях, когда требуется быстрая адаптация. «Недавно мы столкнулись с необходимостью быстро развернуть функционал на микросервисах из-за отключения от корневой системы, чтобы обеспечить непрерывность бизнеса», — поделился Антон Кузнецов («Динекс Русь»).
Алексей Михайлов («Астон») удивился решению Антона начать «пилить» систему на микросервисах в ситуации срочной необходимости. Он указал на возможности масштабирования и управления нагрузкой в монолитных системах через множественные инстансы: «Вы можете управлять большим монолитом, используя различные инстансы для распределения нагрузки, что решает многие проблемы с доступностью».
В ответ на этот комментарий Антон затронул вопрос стоимости и владения такими масштабными системами: «Поддержка множества инстансов может стать очень затратной, особенно когда речь идет о крупных объемах и мощностях».
А у Тараса Сороки есть опыт работы в телеком-секторе, где обновление большой монолитной системы происходило всего несколько раз в год из-за сложностей и длительности процесса. «Мы обновляли систему редко, потому что каждое обновление требовало длительной подготовки, тщательного тестирования изменений от разных команд, больше суток на остановку сервиса и еще больше на поднятие, и в случае выявления проблем, чтобы уложиться в технологическое окно, все откладывалось до следующего квартала», — рассказал он. После того как вендор выпустил обновление , позволяющее обновлять систему на лету, ситуация улучшилась.
Он также отметил, что многие системы были разработаны десятилетия назад, когда они соответствовали самым передовым технологиям: «Корпоративные системы, которыми мы продолжаем пользоваться, были созданы 15–20 лет назад. В то время они представляли собой передовые технологии, но теперь устарели, хотя они все еще поддерживаются и используются, а их замена на что-то новое влечет несоизмеримые с предполагаемой выгодой затраты».
Критерии выбора
Кроме практических есть еще и стратегические аспекты выбора архитектуры. В каких случаях руководителю бизнеса следует выбирать микросервисную архитектуру, а когда лучше остановиться на готовом монолите или начать разработку собственного монолита?
«Обычно, если проект предполагает значительную геораспределенность, первым рассматривается вопрос о микросервисах. Например, когда требуется собирать данные со всего мира или нагрузка распределена по различным регионам, микросервисы предоставляют необходимую гибкость и масштабируемость» — такие критерии назвал Авенир Воронов («Корус Консалтинг»)
В ответ Алексей Михайлов («Астон») подчеркнул важность понимания потоков данных для эффективного перехода на микросервисы: «Допустим, у вас уже есть созданная крупная рабочая система. Тогда гораздо проще сделать следующий шаг, например, выделить лямбды в AWS или определить будущие топики в Kafka. Если в системе четко понятен поток данных, а также уже предусмотрены интерфейсы для взаимодействия со смежными сетями и известны общие потребности и предпочтения вашего клиента, переход на микросервисы будет значительно проще».
Иван Козлов, ИТ-директор группы «Латео», объяснил позицию по выбору между монолитами и микросервисами, исходя из своего опыта: «Когда мне нужен новый продукт, мне обычно не нужен маленький кусочек. Если мне нужен маленький кусочек, я делаю заказную разработку, и эта заказная разработка у меня работает отдельным решением. А если мне нужна ERP или CRM или еще какая-то большая система, мне нужен сразу большой функционал, который писать по кусочкам и собирать из микросервисов — долго, дорого и зачем?».
Максим Каранкевич заключил, рассматривая практическую сторону использования микросервисов и монолитов: «И тут мы выясняем, что ложкой — хлебать, вилкой — колоть. Микросервисы хороши там, где надо делать распределенную нагрузку и быстрое масштабирование. И при этом есть возможность привлекать экспертизу высокого уровня. Не только в разработке, но и в DevOps и в администрировании. Во всех других случаях лучше использовать монолит, так как его можно купить готовый, и стоимость владения монолита все-таки меньше, чем микросервисной архитектуры при той же функциональности».
Плюсы и минусы
В ходе дискуссии о преимуществах микросервисной и монолитной архитектур участники круглого стола высказали свои точки зрения.
Безусловно важными являются отказоустойчивость и надежность. Антон Кузнецов («Динекс Русь») отметил, что при падении монолита вся система становится недоступной, в то время как при использовании микросервисов отказ одного сервиса не останавливает работу остальных. К примеру, если в кредитном конвейере при микросервисной архитектуре упадет лишь один этап, это не приведет к полной остановке системы.
Но не менее важны такие критерии для микросервисов. Потому что для обеспечения надежной работы микросервисов требуется значительное усилие по настройке обвязок, созданию механизмов отслеживания и диагностике проблем: «Чтобы у вас микросервисы были надежными и работали хорошо, во-первых, нужно сделать просто колоссальную работу, обвязки этих самых микросервисов, вам нужно поднять ЕЛК, сделать traceability», — отметил Алексей Михайлов («Астон»). Также он выразил опасения относительно прочности цепи микросервисов, добавив, что с увеличением числа звеньев в цепи растет вероятность ее поломки.
Иван Козлов (группа «Латео») привел пример стратегии разделения монолита на отдельные компоненты для упрощения процесса обновления функционала: «Проблема большого монолита в том, что для обновления его нужно остановить, и на какое-то время все предприятие не сможет работать с ним». Он подчеркнул, что разбивая монолит на части, можно обновлять их по отдельности, минимизируя простои и влияние на весь функционал.
По мнению модератора Максима Каранкевича, монолитная архитектура может быть эффективной. Например, она позволяет не останавливать работу компании для апдейтов. К тому же связать несколько монолитов можно с помощью интеграционной шины.
С ним согласен и Алексей Михайлов (Астон): «Вам не обязательно переделывать полностью монолит для того, чтобы обеспечить возможность деплоить его, когда вы захотите».
Пример подхода к обновлению и сопровождению сложных систем, используя концепцию "clean core", которую пропагандирует SAP, привел Петр Сагаловский, ИТ-директор российской компании. Он отметил, что подобный подход напоминает использование микросервисов, где стандартный код остается в системе, а нестандартные программы выносятся в отдельные исполняемые программы через API. Это позволяет упростить обновление и сопровождение системы, минимизируя изменения в стандартном коде и упрощая разработку нестандартных решений.
***
Несмотря на разность взглядов и подходов, все участники дискуссии сошлись в том, что выбор архитектуры — это искусство. Искусство баланса между новаторством и проверенными решениями, между смелыми идеями и ограниченными бюджетами. Важно не то, какие кубики мы выбираем для своего ИТ-конструктора, а какую картину мы хотим в итоге собрать.
