Когда стоит выбирать микросервисы
Всем привет! Меня зовут Виктория, в Typeable я занимаюсь вопросами архитектуры приложений и не могла пройти мимо вечного вопроса: быть или не быть? Точнее переводить нам наши решения на микросервисы или нет. И с целью это понять я провела небольшое исследование возможных причин и анти-причин, выводы по которому и привожу здесь.
Микросервисы начали набирать популярность в 2011–2014 годах, органично заменяя тяжеловесные SOA и монолитные решения, там где архитектура блокировала доступ к быстро развивающемуся рыночному сектору облачных приложений.
Сам подход оформился на стыке технологий из конкурентной необходимости мгновенно вывести бизнес на новый уровень, и поэтому решения развивались лавинообразно и быстро обзаводились надстройками, паттернами и CI/CD обвеской. Для бизнеса причины не теряют актуальности и интерес к микросервисам также не угасает последние десять лет. При этом сделать решение на микросервисах для ИТ команды — задача творческая, интеллектуальная, позволяющая опробовать современные подходы и уложить на лопатки драконов консерватизма предыдущих решений. То есть, вполне благородный вызов.
Но вот стоит ли поддаваться этой магии — большой вопрос.
Как и всякое модное решение микросервисы не всегда идут на пользу. И не являются панацеей от всех проблем.
Впрочем, давайте разбираться.
Эволюция решения и микросервисы
Итак, эволюция типичного ИТ решения может развиваться по следующему пути:
Стартап MVP решение, чья цель в основном попробовать рынок и решить, подходит ли вообще этот концепт. Здесь не нужны сложные технологии, продвинутые интерфейсы и высоконагруженные сервисы. На этом этапе ценится прежде всего минимизация затрат и скорость вывода на рынок. Иной раз MVP проваливается уже на стадии опроса целевых групп. Стоит ли в этом случае сразу строить решение на микросервисах? Мой ответ — нет, не стоит даже думать об этом. Пока вы будете продумывать архитектуру и налаживать инфраструктуру уйдёт время. А это для стартапа самый ценный ресурс. Да и ключевой профит-фактор микросервисов — параллельную разработку, с командой стартапа реализовать затруднительно.
Новорождённое монолит решение. Архитектура приложения не выверена до конца, неизвестны все внутренние и внешние сервисы, которые будут задействованы. Непонятны до конца цели и задачи конечных потребителей. Неясна стратегия развития структуры данных и функциональности. Определенно не стоит перескакивать на рельсы микросервисов и здесь, если только ваша команда не состоит из профи, щёлкающих микросервисы как орешки.
Давно существующее на рынке и стабильное монолит-решение, вся функциональность которого выверена от и до, возникающие проблемы решаются грамотным рефакторингом и развитие подразумевается плавное, в едином концепте, без конкуренции между функциональными блоками. Стоит? Возможно, стоит задуматься, если цель — интегрироваться с внешними сервисами, увеличить нагрузку на существующие функциональные блоки, обеспечить их независимое развитие и вывод на рынок, если вы хотите сэкономить на технологическом стеке или улучшить характеристики решения за счёт переиспользования компонентов. Но при этом вы должны быть готовы усилить команду нужными специалистами и потратить время на грамотное разбиение монолита на независимые или очень слабосвязанные функциональные блоки, а затем на вывод этих блоков из монолита в качестве отдельных сервисов. Это определённо будет стоить дополнительных ресурсов, а также времени на обучение команды и поиск подходящих технологий.
Многоуровневый монолит в концепции DDD. Функциональность логически сгруппирована в изолированные или слабосвязанные блоки, которые, однако, все еще находятся внутри монолитной структуры, логика отделена от инфраструктуры. Это хорошая стартовая точка для перехода на микросервисы.
Распределенный монолит. У команды разработки почти получилось раздробить монолит, но что-то явно пошло не так. Сервисы слишком сильно связаны друг с другом, присутствуют явные и неявные зависимости, страдает бизнес, поскольку выдвигает требования к одному модулю, а оказывается что нужно перерабатывать несколько, эффект изменений трудно отследить, тестирование и разворачивание требуют отдельных нетривиальных подходов. Вот здесь задумайтесь. Нужны ли вам микросервисы? Действительно ли есть проблемы, которые нельзя закрыть изначально монолитным решением? Если нужны, то следует собрать эту пирамидку заново, но уже в правильном порядке.
SOA решение. Не стоит воспринимать микросервисы как следующий шаг эволюции SOA. Надо понимать, что основное отличие шины от канала обмена сообщениями между сервисами состоит в том, что именно шина несёт на себе значительную часть логики преобразования данных и их оркестрации. Канал обмена сообщениями между микросервисами, в свою очередь, должен быть максимально надёжным и «тупым». Его цель — передать сообщение. Внедрение микросервисов в такие решения может очень дорого обойтись, поскольку якобы «независимые» модули могут быть сильносвязанными через логику шины, и простой заменой этой логики на агрегирующие паттерны не обойтись. К тому же в существующих SOA решениях в основном используются неоднородные технологии и конструкты, которые тяжело поддаются адаптации. Стоит ли вообще задумываться о таком переходе? Как правило, нет. Скорее всего, выбор SOA был обусловлен сложностью и разнородностью приложений, с которыми необходимо интегрироваться, масштабом приложения, необходимостью обеспечить согласование данных и сложную логику их преобразования. И в этом случае он был сделан правильно. О микросервисах, как об альтернативе, стоит задуматься только, если основная часть решения устарела, отпала необходимость интегрироваться с тяжеловесными приложениями, стоит вопрос об избавлении от легаси-кода и переходу к более простым веб-решениям, нет необходимости поддерживать высокий уровень абстракции и согласования данных и при этом критичны скорость разработки отдельных модулей, либо необходимо обеспечить автономность работы отдельных команд.
Монструозный монолит. Монолит полный легаси-кода и построенный на заплатках. Монолит, который развивался так давно, что превратился в огромную и не поддающуюся изменениям структуру. Монолит целиком состоящий из спагетти-кода. Это, пожалуй, единственный случай когда стоит воспользоваться лозунгом Интернационала и разрушить все до основания, тщательно вымести обломки и на развалинах построить новое решение. Возможно, на микросервисах.
Как правило, команда разработки начинает задумываться о микросервисах на стадии стартапа или монструозного монолита. А возможно, на волне популярности микросервисов, эта мысль просто бродит в умах.
Итак, когда же стоит выбирать микросервисы?
Если:
цель разработки — среднего размера нетривиальное веб-приложение, состоящее из набора слабосвязанных или полностью изолированных модулей;
есть критичные требования по устойчивости приложения к нагрузкам и/или поддержке интеграции с внешними сервисами (платежные системы, банки, внешние хранилища и т.п);
бизнес уже сейчас требует значимого ускорения разработки, планирует выводить на рынок изменения сразу по всем направлениям, и не готов ждать последовательного внедрения ключевых изменений в каждой области;
требуется использование разнородного технологического стека (для целей реновации, адаптации к условиям рынка, ускорения внутренних процессов и т.п);
можно выделить модули, допускающие повторное использование с поддержкой вызова по разнородным каналам (сервисы авторизации и аутентификации, поисковые движки, аудит и т.п);
бизнес выдвигает требования к блокам системы с различной скоростью, важность быстрого вывода в релиз отдельных блоков также неоднородна;
есть экономически обусловленная необходимость дальнейших частых изменений в отдельных блоках (следование тренду, маркетинговой стратегии);
стратегические цели бизнеса требуют, или потребуют в перспективе, точечного горизонтального масштабирования, либо разной скорости изменений в различных точках приложения;
тактические цели бизнеса требуют внесения множества микроизменений в различные модули системы «на лету» без угрозы падения всего приложения (доступ 24/7 и высокая вероятность багов ввиду сложности системы),
то возможно вам стоит задуматься о реализации решения на микросервисах.
Заметьте, что практически везде главной движущей силой принятия решения является не команда разработки, а бизнес, и это важно. Если микросервисы не решают задачи бизнеса, то это бесполезная трата времени и денег. Если команда разработки или сам бизнес не имеет представления о текущей и стратегической парадигме продукта, то это также бесполезная трата времени и денег.
Весьма интересным, к примеру, является исследование, проведённое Camunda в 2018 году среди 354 предприятий, представляющих разные страны и индустрии. И хотя, согласно результатам, 63% предприятий ратуют за внедрение микросервисов или уже внедряют их, только 45% явно документируют бизнес-процессы, и это представляет определённую сложность для оценки влияния микросервисной архитектуры на реализацию этих процессов. При этом основными причинами выбора микросервисной архитектуры компании называют: повышение масштабируемости (64%), ускорение цикла разработки (60%), поддержка трендов цифровой трансформации и интеграция с приложениями следующего поколения (54%), обеспечение автономности команд разработки (54%), повышение устойчивости приложения (50%).
А вот по данным компании O«Reilly, которые провели похожее исследование в 2020 году среди 1052 компаний, микросервисами пользуется 77% опрошенных, при этом практически треть в течение последних трёх лет. Конечно, эти два исследования сравнивать нельзя, но явный рост популярности микросервисов виден. Однако и здесь выявлены проблемы схожего характера: неправильная декомпозиция и сложность как самого решения, так и управления набором микросервисов. Хотя фигурально по результатам опросов на первое место выходит корпоративная культура. Впрочем, и она является тормозящим фактором при внедрении микросервисов.
К сожалению, аналогичных исследований по российскому рынку я не нашла, но можно предположить, что и здесь действуют те же принципы.
К тому же есть ограничивающие факторы, которые стоит принять во внимание:
У вас есть большая команда, которой нечем заняться :) Это шутка, но в ней большая доля правды. Минимальный пул для одного микросервиса это команда от шести и до девяти человек, включая разработчиков, тестировщиков, и желательно аналитика. И эти люди не должны отвлекаться ни на что другое, кроме своего микросервиса, или в крайнем случае двух микросервисов. Можно сказать, что где два, там и три, а где три, там и четыре. Но это плохой путь. Где два, там максимум два и точка.
Ваша devops архитектура настроена на поддержку независимой разработки или вы готовы выделить на это ресурсы и время. Для начала у вас точно есть devops. Убедитесь в этом.
Вы готовы к организации тестовых окружений, подходящих для независимого тестирования микросервисов, а также для тестирования взаимодействия микросервисов, и готовы уйти от концепции чистого end-to-end тестирования к структуре, состоящей из модульных, интеграционных, компонентных и end-to-end тестов с разработкой заглушек и публикацией контрактов.
Вы готовы потратить время на неудачные попытки, либо вы уже наступили на все грабли в проектировании своего монолита и чётко знаете на какие именно изолированные сервисы можете его разбить без ущерба качеству данных, скорости их обработки и надёжности приложения в целом. В крайнем случае, вы чётко представляете себе структуру данных в каждом домене, знаете потребности бизнеса и можете выделить слабосвязанные или полностью независимые домены. Ни в коем случае не привязываете структуру микросервисов к структуре предприятия. Иерархические схемы красиво выглядят на бумаге, но по факту часто скрывают за собой подводные камни плохо организованных бизнес-процессов.
И, наконец, убедитесь, что за разработкой не скрываются легаси приложения, с которыми необходимо поддерживать интеграцию, а также в том, что поддержка транзакционности данных не является критичным фактором в выделенных вами доменах (либо вы знаете и готовы применять паттерн распределенных транзакций SAGA).
Микросервисы всегда несут в себе определённую сложность, и если у бизнеса нет проблем, которые нивелирует внедрение микросервисов, то не стоит их добавлять, бизнес не оценит. Здесь как в анекдоте: если жизнь стала слишком простой и лёгкой — заведи козу.
Я уже выбрал микросервисы, что пошло не так?
Если скорость выхода в релиз не увеличилась, то всё пошло не так, увы.
Скорее всего, вам нужно ещё раз оценить возможные источники проблем:
Слишком много микросервисов. Возможно вместо 7 микросервисов на которых зашивается пять команд, стоит завести только пять? Или вообще два. На самом деле, мнение, что микросервисов должно быть много — ошибочно. В большинстве случаев компания не является ни Amazon, ни Netflix.
Плохо проведён анализ бизнес-доменов. Есть неявные зависимости, требуется обеспечение транзакционности, отсутствует общее решение по архитектуре.
Отсутствуют/нарушены предварительные договорённости по разработке API, тестированию, настройке CI/CD цикла.
Команды не автономны, либо чересчур автономны и отсутствует практика обмена опытом и ретроспективы.
Управление и поддержка жизнедеятельности команд не организована должным образом. Есть споры за ресурсы, отсутствует четкое видение бизнес-целей как всего приложения, так и отдельных сервисов.
Есть, однако, ситуации, когда кажется, будто что-то идёт не так, но ты не можешь быть достаточно уверен в этом.
И чтобы не перегружать вас очередным длинным текстом, я просто помещу тут картинку с рядом примеров.
Выводы
На этом позвольте закончить статью и привести кратко выводы по этой теме:
Не стоит рушить то, что хорошо работает, просто ради модной тенденции.
Если вы решили что-то разрушить, сперва посоветуйтесь с хозяином собственности (бизнесом) и объясните все возможные последствия, прежде всего стоит проанализировать скажется ли это позитивно на бизнес-процессах и существуют ли потребности, которые нельзя закрыть существующим решением. Не стоит просто рисовать красивый макет поверх руин, прежде всего это будет иметь негативные последствия для команд разработки.
Если бизнес пришёл к вам с похвальной инициативой, также объясните им последствия. Бизнес есть бизнес, они не обязаны знать обо всех подводных камнях.
Убедитесь, что у вас есть все ресурсы и чёткое понимание маршрута, прежде чем пускаться в путь.
Не провороньте тревожные маркеры, которые говорят о том, что вы свернули не туда.
И наконец. Большинство команд, которые добились успеха на пути использования микросервисов, перестраивали свою архитектуру не раз и не два, или шли по пути последовательного разбиения монолита. Так что не стоит отчаиваться.
Благодарности и дополнительные материалы
В заключение я также хочу сказать спасибо автору курса Микросервисная архитектура, Кириллу Ветчинкину, благодаря которому первоначальное погружение в эту область для меня вышло захватывающим приключением.
А также порекомендовать прочесть еще несколько интересных статей по теме:
Эти материалы показались мне интересными и заслуживающими внимания.
