Зачем уходить от традиционной банковской ИТ-архитектуры и куда?

В настоящее время для финансовых учреждений, которые стремятся поддерживать свою конкурентоспособность, все большую важность приобретает способность быстро реагировать на меняющиеся требования рынка и запросы клиентов. Ключевую роль здесь играют информационные технологии: они должны быть очень гибкими и легко адаптируемыми к текущей ситуации. Мы встретились с представителями компаний, которые с 1990-х годов работают на рынке ПО. Одна — Red Hat — ведущий мировой поставщик программных и облачных решений, промежуточного ПО, технологий хранения данных и виртуализации на базе открытого исходного кода. Другая — «Синимекс» — специализируется на проектировании архитектуры интеграционных решений, разработке заказных решений, внедрении собственных разработок и тестировании профильного ПО в банковском секторе. В России компания является партнером ведущих мировых поставщиков универсальных решений — IBM, Oracle, Microsoft, Red Hat. Компании «Синимекс» присвоен статус бизнес­партнера Red Hat — Advanced Business Partner.

Илья Фридман, директор по развитию бизнеса компании «Синимекс», и Тимур Кульчицкий, региональный менеджер Red Hat в России и СНГ, считают, что во времена усиления конкурентной борьбы в финансовом секторе на передний план выходят подходы к разработке и внедрению программного обеспечения, в первую очередь ориентированные на гибкость и скорость внедрения.

Часть первая. Перемены действительно необходимы?

Мы не впервые встречаем критику традиционных банковских ИТ­решений. Что с ними не так? И как это вредит банкам?

Илья Фридман:

— Способность финансовых учреждений быстро реагировать на меняющиеся запросы клиентов становится критически важным фактором. Все большее число небанковских организаций уже предлагают услуги по проведению платежей, кредитованию и инвестиционному консалтингу. Эта тенденция сохранится ввиду активного развития механизмов удаленной идентификации клиентов и такого тренда, как развитие направления предоставления открытых интерфейсов (Open API) на финансовом рынке.

Развитию в данном направлении способствует и регулятор, который по своей инициативе открыл отдельное направление деятельности в ассоциации ФИНТЕХ, объединяющее крупнейшие российские финансовые организации.

Усиливающаяся конкуренция, вероятно, заставит банки трансформироваться и пытаться предоставлять своим клиентам абсолютно новые продукты, услуги и каналы взаимодействия. Однако скорость инноваций в банковском секторе зачастую усложняется наличием монолитных ИТ­систем, развитие которых крайне сложно интенсифицировать.

Тимур Кульчицкий:

— За последние десять лет произошел качественный технологический скачок: большинству автоматизированных банковских систем (АБС) требуются все большие инвестиции только для того, чтобы поддерживать их работоспособность, поскольку рост запросов как со стороны сотрудников, так и со стороны клиентов вызывает геометрический рост объемов обрабатываемой информации.

Какие ключевые особенности классических АБС представляются вам наиболее проблемными?

Т. К.:

— Ключевой момент — оптимизация. Согласитесь, ни один банк не откажется от увеличения числа своих клиентов, будь то компании из списка Fortune 500, локальные предприниматели или физические лица, но скорость, с которой приходится бесконечно наращивать мощности своих серверов, вызывает озабоченность руководства банков.

Огромные и неповоротливые АБС становятся бременем, которое тянет банк на дно, так как разобраться в коде системы, оптимизировать его, интегрировать новые модули или функции становится все сложнее. Банк сам по себе довольно инерционная и консервативная структура, а неповоротливое ПО еще больше усугубляет проблему.

И. Ф.:

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

Какие пути решения данных проблем вы видите?

И. Ф.:

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

Контейнеры, микросервисы и правильно выстроенный процесс DevOps действительно оптимизируют и ускоряют современную разработку. Дело в том, что контейнеризация предлагает удобный способ быстрой разработки и развертывания приложений.

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

Продукты, в том числе и новые, опираются на бизнес­логику компании, на человеческие, вычислительные ресурсы. Почему вы считаете, что именно ПО — то самое узкое место?

Т. К.:

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

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

Т. К.:

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

Первое преимущество микросервисов — жесткие границы модулей. Это выражается в том, что, в отличие от программного монолита, они не представляют собой переплетенный клубок, в котором сложно изменить что­то отдельное.

И. Ф.:

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

Наверное, какие­то приложения можно безболезненно перевести на микросервисы, а другие нужно полностью переписать? Есть примеры успешных проектов в крупных банках? Насколько тяжелым был переход на новую платформу?

И. Ф.:

— В последнее время выходит множество специализированных сборок «традиционных» платформ от крупных вендоров, например серверы приложений, интеграционные платформы, движки бизнес­правил и многие другие, предназначенные непосредственно для исполнения в Docker­контейнерах. Появление таких сборок существенно упрощает процесс переноса уже разработанного ПО. С другой стороны, безусловно, существует ряд систем, которые практически непригодны для исполнения на новой технологической платформе ввиду изначально заложенных и совершенно иных архитектурных принципов. Но все­таки предположение, что контейнеры и микросервисы подходят только для разработки новых приложений, в большинстве случаев ошибочно: как показали банковские проекты компании Red Hat, для переноса подходят до 80% приложений. В частности, процесс миграции очень прост для приложений, написанных на Java.

Т. К.:

— Если говорить о примерах, то можно перечислить коммерческие банки из списка Fortune 500 — все они доверяют Red Hat и используют наши решения. Вот несколько из них.

Barclays, мировой поставщик финансовых услуг, базирующийся в Лондоне, столкнулся с растущим регулятивным давлением. Стремясь повысить свою производительность, Barclays приступил к созданию приложения Platform­as­a Service (aPaaS) в рамках своей облачной программы. Он использовал Red Hat OpenShift Container Platform и другие решения Red Hat для обновления своей ИТ­инфраструктуры и принятия гибкого подхода DevOps к разработке приложений. Сейчас банк остается эффективным и конкурентоспособным благодаря быстрому внедрению инновационных услуг.

Macquarie необходимо было преобразовать опыт цифрового банкинга для своих розничных клиентов. Для достижения этой трансформации компания перешла на облачное решение, используя платформу Red Hat OpenShift Container Platform, поддерживаемую Red Hat Gluster Storage, Red Hat CloudForms и Ansible by Red Hat. Кроме того, Macquarie привлекла Red Hat Consulting и Red Hat Training для успешного развертывания нового решения и получения опыта по соответствующим технологиям. Благодаря новой облачной среде и подходу DevOps, Macquarie может быстро развивать и добавлять новые функции в свое предложение, чтобы улучшить качество обслуживания клиентов в цифровом банкинге.

Часть вторая. Особенности российского рынка

Насколько компании Red Hat интересен российский рынок?

Т. К.:

— Российский рынок очень важен для Red Hat. Более того, мы занимаем на нем лидирующие позиции. Согласно совместному с Gartner внутреннему исследованию, уже в 2015 году на долю Red Hat приходилось около 75% российского рынка платного Linux в денежном исчислении. Мы имеем основания полагать, что к настоящему времени наша доля еще выросла.

И как вы его охарактеризуете? Насколько, на ваш взгляд, российский рынок готов инвестировать в смещение подхода в сторону микросервисов и контейнерных технологий?

Т. К.:

— Первыми в Россию пришли компании с проприетарными решениями, которые далеко не всегда готовы подстраиваться под требования времени, отдельных клиентов, специфику рынка. Российский рынок напоминает кота Шредингера: здесь сосуществуют консервативно настроенные клиенты, которым необходимо доказывать целесообразность нововведений, и растущий интерес к ПО на основе открытого исходного кода и связанным с ним инновациям. В целом российский рынок позволяет нам показывать темпы роста на уровне мировых.

Наша задача — увеличивать присутствие, так как в выигрыше остаются все: Red Hat получает дополнительный импульс для развития, а конечные пользователи уходят от проприетарного ПО, которое не только не всегда готово следовать за пожеланиями заказчика, но часто диктует им свои требования.

Часть третья. Открытый исходный код

Внедряя решения на основе ПО с открытым исходным кодом, компания «Синимекс» получила статус Red Hat Advanced Business Partner. Но, как уже заметил Тимур, первыми в Россию пришли компании с проприетарным ПО. Почему именно открытый исходный код?

И. Ф.:

— Мы, как компания, разрабатывающая программное обеспечение, всегда активно смотрели в сторону продуктов с открытым исходным кодом и использовали их. Особый, уже рыночный интерес к OpenSource­продуктам в РФ появился благодаря многочисленным санкционно­ограничительным историям, шумиха вокруг которых поднялась еще в 2015 году. Хотя она и послужила толчком к росту популярности проектов на базе СПО, на наш взгляд, это уже давно и далеко не основная причина его использования. В наши дни функциональность и надежность OpenSource­продуктов в большинстве случаев не уступает проприетарным аналогам, а зачастую уже и превосходит их. Когда речь идет об СПО, ключевую роль играет размер сообщества, которое работает над конкретным продуктом/технологией. Существенный рост количества сообществ, развитие механизмов распространения и участие таких крупных международных вендоров, как, например, Red Hat, очевидно означают для нас перспективы и уверенность в развитии этого направления.

Т. К.:

— Ключевое преимущество OpenSource, помимо инновационности, заключается в его гибкости. ПО с открытым исходным кодом может подстраиваться под конкретные и не всегда простые задачи: если мы посмотрим на список ТОП 500 суперкомпьютеров, то сколько из них будут работать на основе проприетарных ОС?

В Red Hat рука об руку с открытым исходным кодом идет и сотрудничество. Мы внимательно отслеживаем запросы наших клиентов и партнеров и на основе обратной связи от них формируем наш портфель продуктов и решений.

А почему Red Hat выбрала «Синимекс» в качестве российского партнера?

Т. К.:

— Как представительство Red Hat, мы не имеем права вести коммерческую деятельность на территории России, поэтому изначально выбрали модель, основанную на развитии партнерской сети.

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

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

Часть четвертая. Подведем итоги

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

Т. К.:

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

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

И. Ф.:

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

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

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