Микросервисная архитектура становится все более популярной среди крупных организаций и постепенно вытесняет монолитный подход к разработке ПО. Разбираемся, почему это происходит
Благодаря развитию практик DevOps, а также трендам автоматизации и цифровизации бизнес все чаще выбирает микросервисный подход. Согласно опросу Cnews, такую архитектуру уже используют 35% российских компаний, а еще 10% планируют внедрить ее в ближайшее время. Разбираемся вместе с экспертами группы компаний «Ланит», которая занимается разработкой, интеграцией программных продуктов и вопросами консалтинга, в чем преимущества микросервисной архитектуры и как правильно на нее переходить.
Что такое микросервисная архитектура
Микросервисы — это архитектурный подход к разработке программного обеспечения, при котором оно делится на небольшие независимые сервисы, отвечающие за отдельные функции. Эти функции управляются автономными командами, а взаимодействуют между собой через четко определенные API (программные интерфейсы приложения).
Микросервисы постепенно приходят на смену монолитной архитектуре, когда все приложение рассматривается как единое целое. При этом оно может состоять из различных модулей, но их работа настолько тесно связана, что при исключении одного перестанут функционировать и все остальные, а в итоге и сама система.
Директор по развитию платформы Lanit Document Management (LDM) Рамазан Салпагаров отмечает: «Если монолитную архитектуру можно сравнить с башней, которая при неосторожном действии может целиком обрушиться, то микросервисную — с коттеджным поселком, так как она дает возможность легко достраивать и дорабатывать отдельные сервисы, а также быстро расширяться».
Предпосылки возникновения микросервисного подхода
Изначально приложения разрабатывались с простой двух- и трехзвенной архитектурой, а затем она усложнилась и внутри монолита начали возникать сервисы, отвечающие за конкретные бизнес-функции, рассказывает Рамазан Салпагаров. С развитием интернета появилась возможность отказаться от проприетарных протоколов в пользу веб-служб, которые связывали работу разных функций в единое приложение. Это стало основой сервис-ориентированной архитектуры — метода разработки софта, который использует сервисы в качестве программных компонентов для создания бизнес-приложений.
В 2000-х Google, Amazon и Microsoft начали создавать облачную инфраструктуру, чтобы клиенты могли развивать сервисы, не используя собственные мощности. Тогда же IT-гиганты столкнулись с проблемами динамического масштабирования и оптимизации использования вычислительных ресурсов серверов. Они пришли к выводу, что нужно дробить функционал приложений, чтобы улучшать их управляемость при больших нагрузках. Это потребовало разработки специального программного обеспечения для управления инфраструктурой. Именно тогда начали развиваться технологии контейнеризации, в том числе Docker, и платформы оркестрации контейнеров, например Kubernetes. Все это обеспечило необходимую инфраструктуру для развития микросервисной архитектуры.
Окончательно концепция такой архитектуры сформировалась к началу 2010-х, когда ее начали внедрять Netflix, Amazon и другие игроки. Впоследствии к ней обратились многие крупные компании, поскольку тренды цифровизации и автоматизации процессов требовали масштабных обновлений, однако монолитный подход позволял проводить их лишь точечно.
Преимущества и ограничения микросервисного подхода
Микросервисы похожи на конструктор, поэтому их элементы можно легко заменить или обновить. Это позволяет повысить функциональность систем. Кроме того, микросервисный подход дает еще ряд преимуществ.
Плюсы микросервисного подхода
Отказоустойчивость. Поскольку микросервисы работают независимо друг от друга, при выходе из строя одного из них работа системы не нарушится.
Гибкость масштабирования. В случае с микросервисами можно наращивать мощности и управлять нагрузкой отдельных функций. Рамазан Салпагаров отмечает, что при микросервисной архитектуре нагрузка на компоненты растет не одномоментно, а эластично благодаря очередности выполнения запросов. Монолитный подход, по его словам, налагает ограничения на горизонтальное расширение, так как приходится масштабировать все приложение целиком, а не отдельные элементы.
Удобство и скорость обновлений. При монолитном подходе для перехода на новые процессы и технологии потребуется переписать все приложение с нуля. Однако микросервисный подход позволяет в любой момент обновлять и заменять разные функции, не нарушая работу приложения. Директор департамента продуктовой разработки «Норбит» Александр Наймарк отмечает: «Микросервисы — это тренд IT-рынка, который позволяет бизнесу смотреть не на текущие показатели, а на перспективы, чтобы эволюционировать и масштабироваться. В этом случае компании не нужно задумываться о том, что будет с сервисами через пять лет, поскольку платформы микросервисов развиваются одновременно с ее бизнесом. Так, с внедрением ИИ радикально изменились и сами платформы. При этом интеграторам необязательно получать соответствующие запросы от заказчиков. Например, с ужесточением требований к использованию российского софта вендоры уже провели необходимую работу».
Независимое развертывание обновлений. Системный архитектор компании «Ланит — Би Пи Эм» Роберт Севумян поясняет, что при микросервисном подходе каждая команда, которая развивает свою часть системы, может делать это независимо от других, что увеличивает продуктивность и time to market. При этом поставкой обновлений могут одновременно заниматься сразу несколько групп разработчиков, что отвечает требованиям CI/CD — непрерывной интеграции и развертыванию.
Широкий выбор технологий. При микросервисном подходе можно использовать любые библиотеки и фреймворки, необходимые для выполнения задачи. Он требует лишь решений для управления системой и настроек среды выполнения. Так, Docker нужен для контейнеризации данных, а Kubernetes — для управления контейнерами. По словам Роберта Севумяна, это особенно актуально в ситуации, когда вендор покидает рынок или выходят новые требования регуляторов.
Рамазан Салпагаров подчеркивает, что помимо очевидных преимуществ микросервисы дают бизнесу большую гибкость при найме сотрудников, особенно в условиях кадрового дефицита: «Благодаря тому, что разработчику не нужно знать всю кодовую базу, а достаточно овладеть компетенциями своей команды, которая работает над отдельным микросервисом, снижается порог входа». С ним соглашается и Роберт Севумян: «В монолите из-за возрастающей сложности системы важно общее понимание работы всей системы в целом. Уход сотрудника, обладающего подобным знанием, является серьезной проблемой».
Минусы микросервисного подхода
Микросервисный подход имеет и ограничения.
Сложность проектирования. При таком подходе важно правильно разделить систему на функции. Кроме того, из-за распределенности данных по модулям приходится проводить мониторинг больших массивов информации.
Управляемость данных. При микросервисном подходе для одной бизнес-операции требуется обеспечить не одну, а множество микротранзакций внутри отдельных микросервисов. Чтобы избежать возможных отказов системы, нужно учитывать альтернативные сценарии, а это усложняет разработку.
Потребность в DevOps-культуре. При внедрении микросервисов возрастает сложность операций, а командам нужно владеть инструментами мониторинга и оркестрации — Kubernetes, Openshift и другими, что требует квалификации и увеличивает нагрузку на IT-отдел. Роберт Севумян поясняет: «Переход на микросервисы непростой, поэтому осуществить его одной командой проблематично. В компании должна быть развита DevOps-культура и экспертиза, а это требует ресурсов и времени. Решение о переходе на микросервисы должно быть стратегическим, так как нужны ресурсы, «дорожная карта», софт. Для этого необходимо пройти путь взросления, внедрять соответствующие механизмы и конвенции».
Стоимость. Для поддержания микросервисной архитектуры требуются не только квалифицированные разработчики, но и инструменты, а также вычислительные мощности. По словам Роберта Севумяна, это решение больше подходит компаниям, которые арендуют или строят свои data-центры.
Кому нужна микросервисная архитектура
Микросервисы упрощают развитие крупных систем, но для небольших могут стать слишком дорогими или громоздкими. Поэтому такое решение подойдет не для каждого бизнеса.
Александр Наймарк отмечает, что выбор должен определяться решением конкретной бизнес-задачи. «Если преимущества архитектуры дают существенный толчок, то следует выбирать именно ее. Для заказчика это открывает возможности для масштабирования, распределения растущих нагрузок, ускорения развития, time to market и отказоустойчивости, гибкости к изменениям». По мнению эксперта, микросервисный подход с меньшей вероятностью подойдет стартапам, которые сильно ограничены в ресурсах и пока не имеют точного представления о том, как будет развиваться продукт в будущем. Для них важно сначала отработать гипотезу и быстро запустить минимально жизнеспособный продукт.
Рамазан Салпагаров напоминает, что изначально микросервисный подход развивали крупные игроки рынка. Несмотря на то что со временем стоимость вычислений снижается, переход на новую архитектуру должен быть оправдан с точки зрения функционала, отмечает эксперт. «Если на рынке есть готовое решение на микросервисах, то его можно внедрять. Но если в компании есть свой софт и нет планов по быстрому росту, то переходить на новую архитектуру не нужно», — поясняет он.
Роберт Севумян соглашается, что микросервисы больше подходят крупным организациям, у которых есть стратегия будущего развития. «Мы видим, как банки ставят во главу угла микросервисный подход при разработке новых проектов и переводят на него старые системы. Они убедились, что монолитный подход заводит в тупик лет через десять, а микросервисы позволяют развиваться несколько десятков лет», — говорит эксперт.
Как правильно внедрять микросервисы
Обычно разработка микросервисов требуется, когда система нуждается в модернизации, не справляется с нагрузкой или не поддерживает необходимый бизнесу темп развития. Однако компания может построить такую систему и с нуля.
Александр Наймарк говорит, что если решение внедряется с чистого листа, то сначала нужно разделить его на независимые области, под которые будут выстраиваться микросервисы. При реорганизации монолита он разбивается на отдельные микросервисы, с которыми далее работают специалисты, увеличивая скорость поставки изменений там, где это требуется. Старая система при этом продолжает работать, чтобы сохранить общую работоспособность.
«Перед внедрением подхода выстраивается команда, формируется DevOps-практика, создаются среда разработки, тестирования, продуктива, средства регистрации, оркестрации и мониторинга, чтобы клиент мог эффективно управлять решением», — поясняет Наймарк.
Опыт: микросервисы и low-code-платформы
Если компания работала с монолитным решением, а затем захотела перейти на микросервисное, то она может использовать и готовый продукт, но это лишит ее бизнес-преимуществ, так как процессы придется адаптировать для существующих практик рынка.
Low-code-платформы позволяют не привлекать разработчиков, так как на них решения конфигурируются в визуальном дизайнере силами аналитиков и методологов, тех, кто непосредственно работает с бизнесом. Это позволяет минимизировать ошибки в разработке, снизить затраты на ресурсы, а также сосредоточиться на оптимизации и улучшении бизнес-процессов.
Александр Наймарк приводит в пример организацию low-code-платформы NBT собственной разработки «Норбит». Микросервисы в ней обеспечивают отказоустойчивость, распределение нагрузок, информационную безопасность. Средства мониторинга и оркестрации позволяют отслеживать работу сервисов при нагрузках. Визуальный конфигуратор помогает проектировать процессы, опираясь на эталонные практики. На базе NBT можно в короткие сроки собрать CRM, HRM, SRM, запустить портальные решения, крупные блоки по материально-техническому обеспечению, бюджетированию, ТОРО, управлению договорами, IT-активами, обращениями и другие.
Эксперт поясняет: «Чаще всего заказчик приходит с проблемой, связанной с уже выстроенной инфраструктурой — ERP, бухгалтерией и т.д. Обычно трудности вызваны сложностью интеграций. На нашей платформе есть отдельный микросервис для интеграций с визуальным редактором, который позволяет отстраивать эти процессы».
По словам Наймарка, микросервисные low-code-платформы помогают следовать новейшим трендам в IT, например развивать отдельные ML/AI-сервисы или внедрять уже готовые новые решения под конкретные задачи. Так, ИИ может находить ошибочные записи в справочниках и редактировать их, а инструменты предиктивного анализа позволяют запускать скоринг или делать прогнозы. Сам сервис можно отключать, подключать или переобучать на разных датасетах. Наконец, можно внедрять чат-боты для поддержки клиентов и сотрудников.
Опыт: микросервисы в банкинге
Банки с переходом на микросервисы обычно пытаются устранить проблемы автоматизации конкретной бизнес-задачи или отказа от зарубежного решения, когда требуется миграция всех работающих процессов.
Рамазан Салпагаров отмечает, что при выборе платформы компания сама решает, какие рабочие модули ей нужны. Также она может перевести свою работающую платформу на микросервисы, сохранив все интерфейсы. Наконец, благодаря сквозной интеграции и open-source-решениям компания может работать в едином информационном поле. Например, если она использовала систему управления базами данных ушедшего иностранного вендора, то теперь сможет обращаться к этой информации как к архиву.
Рамазан Салпагаров приводит пример: «Банк из топ-5 решил приобрести платформу Lanit Document Management, чтобы перенести решения по автоматизации кредитных процессов с западного аналога. Клиент самостоятельно провел миграцию своих решений на нашу платформу». К моменту миграции, по словам эксперта, на платформе банка находилось уже около 100 млн документов, а новая система должна была выдерживать работу 20 тыс. пользователей, около 30 тыс. запросов в час и добавление порядка 30 млн новых документов в год. В итоге клиенту удалось добиться всех этих показателей.
Роберт Севумян приводит еще один кейс с банком, который работал на монолитной архитектуре, но решил перейти на микросервисы с автоматизацией факторингового бизнеса. По его словам, перед переходом специалисты компании «Ланит — Би Пи Эм» разработали архитектурный план по разбивке функционала на микросервисы, а затем вместе с заказчиком проанализировали, как система будет развиваться дальше. Сейчас она уже вышла в опытно-промышленную эксплуатацию, а через два-три месяца начнет полноценно функционировать, поясняет Роберт Севумян.
В другом случае банк в рамках цифровой трансформации решил перевести на микросервисы систему предодобренных кредитов для юрлиц. Как рассказал Роберт Севумян, в итоге удалось добиться не только одобрения кредитов за несколько минут, но и в течение полутора лет увеличить суммы одобрения с 4–5 млн до 50 млн руб., поскольку теперь система поддерживает опции залогов и поручительства, а также программу госпомощи предпринимателям.
«В случае с предодобренными кредитами особенность в том, что предложения формируются раз в определенный период — месяц или квартал. Когда появляются новые предложения, то приходит сразу много клиентов, которые ими заинтересовались, и система перегружается. Благодаря микросервисам мы выдерживаем эти нагрузки. В случае же со скорингом для одобрения кредитов микросервисы позволяют принять решение в срок от 30 секунд до нескольких минут, то есть клиенты получают займы всего за пару минут», — говорит эксперт.
По словам Роберта Севумяна, переводить на микросервисы можно одновременно несколько банковских процессов, все зависит от ресурсов и бюджета заказчика. «Изменения можно внедрять быстро и в итоге поменять вообще всю банковскую систему», — заключает эксперт.
