Дмитрий Свалов, BSS: Микросервисная ДБО даст банку более высокую скорость time-to-market, гибкость и свободу действий

Дмитрий Свалов: Мы наблюдаем постоянный рост требований банков к полнофункциональному омниканальному взаимодействию с клиентом. Вследствие этого значительно выросла важность систем ДБО для банковского бизнеса. В системах выросло количество сервисов и, как следствие, уменьшилось количество визитов клиентов в отделения банков, снизилось количество отделений. Вместе с тем повысились требования к скорости поставки сервисов на рынок (time-to-market - T2M), качеству работы систем ДБО, к их стабильности, отказоустойчивости и масштабируемости. Особую важность приобретает информационная безопасность систем ДБО. В этой сфере задачи ставятся на высоком, правительственном уровне, при участии ЦБ РФ. Также серьезное влияние на изменение роли систем ДБО оказал стабильный рост доли использования мобильных приложений, удаленная идентификация, в том числе – биометрическая, и Система Быстрых Платежей (СБП).

Мы наблюдаем рост интереса к реализации функционала открытого банковского API (Open Banking API), что также является инициативой ЦБ РФ, и к организации прямых взаимодействий host-to-host (H2H) между крупными корпорациями и банками. Кроме того, банки интересуются интеграцией ДБО с маркетинговыми и рекомендательными продуктовыми системами, CRM и продуктами класса «знай своего клиента» (KYC, Know Your Client). Последнее очень важно в силу того, что при переходе в онлайн теряется индивидуальный подход, который важен клиентам, причем как физическим так и юридическим лицам.

Дмитрий Свалов: В период пандемии система ДБО стала единственно возможным каналом для безопасного предоставления банковских сервисов. Пандемия создала у клиентов ожидания наличия любой услуги в системе ДБО и стала драйвером и стимулом к наращиванию набора услуг, предоставляемых в цифровых каналах. Хотел бы отметить здесь, что микросервисная архитектура позволит банкам быстрее адаптировать системы ДБО к потребностям клиентов, к вызовам рынка и требованиям регулятора.

Дмитрий Свалов: Основных преимуществ несколько. Во-первых, это возможность обеспечить более высокую скорость поставки клиентам новых решений (T2M) и развития существующих. Во-вторых, — возможность частичной замены и модернизации функционала действующей системы ДБО. В-третьих, это большая независимость при совместной с вендором разработке. Таким образом, микросервисная ДБО даст банку более высокую скорость T2M, гибкость и свободу действий.

Дмитрий Свалов: Преимущества микросервисной ДБО наиболее очевидны на стороне банка. Как вендор, в данном случае мы идем навстречу требованиям банка, стараемся соответствовать рынку. Нам, конечно, было бы выгодно полностью привязать к себе клиента, как это и было лет 10 назад. То есть внедрить все, что есть, а потом, в зависимости от вида лицензии, включать тот или иной функционал. При этом заказчик вынужден использовать систему вне зависимости от того как меняется среда бизнеса. Но рынок давно уже изменился, и, по сути, в случае микросервисной платформы ДБО выигрывают обе стороны – и банк, и вендор, т.е. ситуация win-win. Это позитивный процесс, поскольку создается конкурентная среда, в которой мы мотивированы производить более качественные решения.

Дмитрий Свалов: Описанная в вопросе ситуация может произойти при реализации системы в любой архитектуре. Безусловно, сохранять концептуальную целостность системы намного проще в монолитной архитектуре, но платой за это является T2M. Недостатки есть и у монолитной архитектуры, и у любой другой – микросервисной, бессерверной и так далее. Каждая из архитектур предназначена для эффективного решения определенных задач при одной важной оговорке: производство системы в той или иной архитектуре должно быть выстроено с учетом особенностей этой архитектуры.

Дмитрий Свалов: Безусловно, на Западе есть примеры перевода монолитных систем ДБО на микросервисы и создания тиражируемого решения. Однако на российском рынке они не представлены и маловероятно, что будут представлены в обозримом будущем вследствие двух факторов. Первый — это валютные риски, когда затраты на сопровождение и развитие систем западного производства могут моментально существенно вырасти. И второй фактор — курс Правительства РФ на импортозамещение, который включает грантовую поддержку отечественных разработчиков, различные преференции российскому ПО.

Дмитрий Свалов: Банк ожидают изменения в части принципов построения инфраструктуры для развертывания и эксплуатации системы ДБО, управления инфраструктурой и автоматизации работы с ней. Изменится и технология поставки, развертывания решений. Для эффективной эксплуатации системы ДБО в микросервисной архитектуре потребуется развернуть среду управления контейнерами — такую, как Kubernetes или OpenShift. Надо будет выстроить совместно с вендором конвейер для поставки и развертывания компонентов микросервисной платформы в контейнерах Docker, развернуть и настроить системы для сбора логов и для мониторинга — например, на стеке EFK, Prometheus/Grafana или Zabbix. В настоящее время компоненты системы ДБО разворачиваются в полуручном режиме или полностью вручную. При переходе на микросервисную архитектуру вследствие значительно большего количества компонентов потребуется полностью автоматизировать этот процесс.

Дмитрий Свалов: Да, на начальном этапе остается возможность сохранить применение привычной технологии поставки и развертывания. До тех пор, пока количество микросервисов не начнет приводить к существенным затратам на развертывание и обновление системы ДБО. Например, если банк эксплуатирует наше стандартное коробочное решение ДБО и обновляет его вручную, то на начальных этапах новые сервисы, реализованные в микросервисной архитектуре, банк также может разворачивать и обновлять вручную. При условии, что временные затраты на это для него приемлемы. Таким образом, компания BSS оставляет возможность для плавного перехода на микросервисную платформу ДБО, без необходимости замены имеющейся системы и всей имеющейся инфраструктуры (причем система ДБО не обязательно от компании BSS).

Дмитрий Свалов: Изменятся сами принципы внутренних коммуникаций между ИТ и бизнесом. Например, микросервисная платформа устранит необходимость синхронизации сроков и состава релизов системы между бизнес-заказчиками. Релизы смогут выпускаться независимо друг от друга и, как следствие, намного быстрее. Кроме того, ИТ-подразделение получит возможность модернизации и замены части сервисов без необходимости замены всей системы ДБО. Устранятся и противоречия между бизнес-подразделениями в плане финансирования доработок ДБО. При монолитной системе бизнес-заказчики начинают платить за решение задач других подразделений или, по крайней мере, иногда им так кажется. Эта проблема тоже снимается, все будут заниматься ровно тем, чем занимаются напрямую.

Дмитрий Свалов: На начальном этапе возможны сложности с получением дополнительных компетенций по управлению контейнерной средой, с выстраиванием автоматизированного процесса непрерывной интеграции и развертывания (CI/CD) для компонентов ДБО в микросервисной архитектуре в контейнерах Docker, с согласованием этих новых подходов со службой безопасности.

Дмитрий Свалов: Чтобы помочь банкам перейти на качественно новый технологический уровень, компания BSS готова оказывать экспертную консультационную поддержку. И в части построения контейнерной среды и автоматизации управления, и в плане информационной безопасности процессов разработки и эксплуатации. При этом, как я уже говорил выше, внедрение микросервисной платформы BSS позволяет плавно перейти на новую контейнерную среду и на новые сервисы в микросервисной архитектуре, без необходимости полной замены системы ДБО от любого вендора и ИТ-инфраструктуры.

Дмитрий Свалов: Безусловно, изменится. Постепенно.

Дмитрий Свалов: Появление системы ДБО в микросервисной архитектуре позволит улучшить скорость поставки функционала, а также более оперативно поддерживать законодательные инициативы ЦБ, заложить основу микросервисной архитектуры всей цифровой экосистемы банков. Затем, по мере перехода экосистемы банка на микросервисную архитектуру, исчезнет само понятие отдельных систем ДБО и АБС. Бизнес-процессы банка, реализованные в микросервисной архитектуре, заменят существующие АБС и системы ДБО, сформируют цифровой ландшафт банка на новом технологическом уровне. Доступ к функционалу микросервисов цифровой экосистемы банка будет осуществляться через слой открытых API, который отчасти займет место нынешних систем ДБО и будет интегрирован, как во фронтальные приложения сервисов банка, так и в сторонние финтех-приложения.

Дмитрий Свалов: Микросервисная платформа BSS — это сочетание ПО для организации инфраструктуры и управления. Она включает в себя набор системных микросервисов, обеспечивающих работу прикладных продуктовых микросервисов, ПО для мониторинга, библиотек и компонентов для упрощения создания новых сервисов, технологий, подходов и приемов разработки, сопровождения и поставки решений в микросервисной архитектуре.

Дмитрий Свалов: Инфраструктура нашей микросервисной платформы построена на базе Docker и Kubernetes, для мониторинга, аналитики и интерактивной визуализации используются Prometheus и Grafana. Сбор и анализ логов организован на базе стека EFK — это сочетание Elasticsearch, Fluentd и Kibana. В состав микросервисной платформы ДБО BSS входят микросервис аутентификации, поддерживающий протоколы OAuth 2.0/OpenID Connect, API Gateway, микросервисы единой ленты операций и единого фронтального окна, а также сервисы интеграции/нотификации. Мы планируем создать SDK для предоставления нашим клиентам возможности самостоятельной разработки микросервисов на базе нашей платформы. В качестве прикладных решений на базе нашей микросервисной платформы мы реализуем микросервисы кредитов, депозитов и неснижаемых остатков.

Дмитрий Свалов: На системном уровне используется Java и набор сопутствующих фреймворков из стека Spring. В числе поддерживаемых баз данных, также как и в платформе предыдущего поколения BSS Digital2Go, наиболее востребованные нашими клиентами СУБД: Oracle, MS SQL и PostgreSQL. На уровне межсервисного взаимодействия и интеграции используются сервера сообщений Apache ActiveMQ. На прикладном уровне на бэкенде используются языки программирования Java и Groovy, фронтенд – на базе фреймворка ReactJS и ZK.

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

Дмитрий Свалов: Могу подтвердить, что писать микросервисную платформу и все прикладные сервисы с нуля — это экономически невыгодный вариант с точки зрения инвестиций. Сказать, что мы идем революционным путем создания нового продукта, было бы неверно. Во-первых, мы создаем микросервисную платформу при поддержке РФРИТ. Во-вторых, мы используем экспертизу из наших существующих продуктов - платформы Digital2Go, сервера нотификации и типового интеграционного решения. И, в-третьих, немаловажен характер поставки. Это будет, во-первых, поставка коробочного решения, которое будет постепенно уменьшаться в объеме за счет выделения функционала в микросервисы. И, во-вторых, — поставка функционала, реализованного на базе микросервисной платформы, количество которого также будет расти за счет выделения функционала из коробки и реализации его в новой архитектуре.

Дмитрий Свалов: Адаптивный подход основан на применении нашей Low-Code-платформы `Конструктор документов`, предназначенной для реализации прикладного функционала. Она способна разворачивать прикладной функционал как в микросервисах, так и в составе сервера приложений монолитного решения. Это позволит BSS минимизировать затраты на сопровождение одного и того же функционала, содержащегося как в микросервисной платформе, так и в монолите. Эволюционный подход заключается в постепенном выделении функционала из монолитной коробки в микросервисы. Это позволяет постепенно перейти на микросервисную архитектуру, не прекращая предоставление клиентам полного набора имеющегося функционала.

Дмитрий Свалов: Объем самостоятельной разработки на базе SDK устойчиво растет уже на текущей платформе Digital2Go. После выхода микросервисной платформы важность наличия SDK возрастет многократно, так как микросервисная архитектура позволяет вывести как самостоятельную, так и совместную с вендором разработку на качественно новый уровень. Сейчас у банка все-таки остается определенная зависимость от наших циклов разработки, релизов. На новой платформе вендор и банк будут существенно более независимы друг от друга в части вывода новых продуктов на рынок.

Дмитрий Свалов: Интерес к самостоятельной разработке велик и компания BSS отмечает устойчивый рост ее объема. В РФ количество наших клиентов, ведущие свою разработку на базе SDK Digital2Go растет с каждым годом. При этом в республике Узбекистан абсолютно все наши клиенты с самого начала работают с нами по модели совместной разработки. В целом по клиентскому портфелю, около 15% наших заказчиков ведут самостоятельную и совместную разработку на базе SDK Digital2Go. Эффективное распределение задач между банком и вендором позволяет высвободить ценные ресурсы банка на развитие высокоприбыльных направлений, а рутину отдать вендору.

Дмитрий Свалов: С момента старта проекта — 1 февраля 2021 года. Соответственно, с учетом мероприятий по защите проекта перед фондом, в апреле 2022 года мы будем готовы вывести платформу на рынок.

Дмитрий Свалов: На сегодняшний день основная часть работ по реализации завершена, и компания BSS находится в процессе сдачи РФРИТ результатов работы второго этапа проекта. Всего проект состоит из 3-х этапов. Третий завершится, повторюсь, к февралю 2022 года.

Дмитрий Свалов: Да, мы назвали ее Digital2Cloud. Название отражает как текущие возможности, так и планы дальнейшего развития новой платформы. На выбор названия также повлиял возросший интерес банков к развертыванию перспективных решений по модели гибридного облака.

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

Дмитрий Свалов: Безусловно, банки проявляют активный интерес. К тому же, по условиям предоставления гранта, мы обязаны монетизировать продукт в определенном объеме, и это для нас дополнительный серьезный стимул. Поэтому мы подошли к подготовке проекта со всей серьезностью не только в части технической реализации на уровне продукта, но и при заключении предварительных договоренностей о внедрениях.

Дмитрий Свалов : Отмечу, что микросервисная архитектура – текущий мировой тренд в плане создания информационных систем вообще, а не только ДБО. Если попробовать заглянуть в будущее, то на смену микросервисной архитектуре могут прийти решения, спроектированные и реализованные искусственным интеллектом без участия человека.

Дмитрий Свалов: Не совсем — это была шутка:) Если серьезно, то после микросервисов мы будем двигаться в сторону архитектур, стандартизирующих системные функции и все больше берущих эти функции на себя. Тем самым у разработчиков будет высвобождаться все больше времени для решения прикладных задач. Прототипом такой архитектуры может быть Unikernels в качестве замены контейнеров, использующихся в настоящее время. Еще я уверен, что нас ждет дальнейшее развитие бессерверной (serverless) архитектуры. Текущие ограничения этой технологии — привязка к провайдеру, поддержка ограниченного набора языков программирования — постепенно уйдут в прошлое. Новые архитектуры предоставят разработчикам стандартный набор системных функций, тесно интегрированный с инфраструктурой и сервисами динамического выделения ресурсов. Размер сервисов уменьшится до размера функции. Сами сервисы станут намного более переносимыми, чем текущие контейнеры, при этом значительно более легковесными, вырастет количество готовых сервисов, доступных прикладному разработчику.