CNews: Дмитрий, в конце 2019 года «Новая Афина» презентовала новую микросервисную платформу. Как вы к ней пришли?
Дмитрий Гарбар:
Дмитрий Гарбар
Несколько лет назад мы собрали молодую команду и теперь можем с гордостью представить результаты ее труда: платформу в микросервисном стеке, которая призвана стать действительно ядром цифрового банка будущего.

Компания «Новая Афина» исторически ассоциируется с полнофункциональным и производительным Core banking — мы не создаем чистые фронты и не пишем ДБО. Наше решение «ИСУБД Новая Афина», успешно функционирующее в крупнейших российских и западных банках, уже может быть отнесено к Legacy. Да, оно спроектировано так, что может активно дорабатываться (что банки и делают сами или с нашей помощью) и держит нагрузки в миллионы документов в день. Но новые вызовы, стоящие перед финансовыми организациями, требуют принципиально других решений.

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

CNews: Что вы имеете в виду?
Дмитрий Гарбар:

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

Другой вариант: в банке устанавливается небольшой модуль в микросервисном стеке, решающий узкую бизнес-задачу. И этот модуль выдается за цифровую платформу. Иногда банки не до конца понимают, что им предлагается, а иногда «обманываться рады», так как это позволяет заявить на весь рынок, что они в тренде.

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

Дмитрий Гарбар:

Микросервисы — это хайп. Поэтому любой производитель ПО, желающий остаться в рынке, чувствует, что должен что-то заявить по теме микросервисов.
CNews: И чем же ваша платформа лучше?
Дмитрий Гарбар:

Выпуску нашего решения предшествовала серьезная архитектурная проработка, в которой, кстати, принимали участие архитекторы одного из крупнейших российских банков. Первый микросервис появился только после того, как были утверждены общая архитектурная концепция и правила разработки. Например, в зависимости от бизнес-задачи микросервисы могут использовать разные СУБД (для ведения баланса и лимитов по счетам мы используем in-memory database), есть элементы low code, которые мы планируем активно развивать. У нас много интересных решений.

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

CNews: Есть расхожее мнение, что микросервисы нужны только для фронтальных решений. Вы с этим согласны?
Дмитрий Гарбар:
Дмитрий Гарбар
На первое место выходит скорость формирования предложения клиенту, а значит должен храниться и мгновенно обрабатываться огромный пул информации.

Давайте вспомним, какие неоспоримые преимущества свойственны микросервисной архитектуре. Это стабильность решения при большом количестве изменений и практически безграничное масштабирование при разумной цене на железо — разве это не то, что нужно в Core Banking?

А что касается идеи двухскоростной архитектуры, которая была сформулирована экспертами Gartner еще в 2014 году, то до поры до времени она была вполне разумным для банков подходом. Что-то вроде «есть слона по частям». Если упрощенно, то подход сводился к тому, что должен быть технологичный, быстрый, устойчивый к изменениям фронт и хоть какой-то, какой уж есть, бэк, потому что «не до него сейчас». И применение микросервисных решений, в первую очередь для фронт-офисов, было вполне оправдано. Но пришло время есть «вторую часть слона» — две скорости в архитектуре должны уступить место одной — максимальной.

Растут как объемы информации в системах, так и количество запросов к ним. На первое место выходит скорость формирования предложения клиенту, а значит должен храниться и мгновенно обрабатываться огромный пул информации. В такой ситуации Core Banking уже не получится вынести за скобки.

Соревнование банков на предмет того, «у кого ДБО красивее», завершилось — почти у всех одинаково красиво. Наступает время решения более сложных задач и формирования более своевременных продуктов. Это требует других скоростей на всех уровнях архитектуры, во всех процессах. А поэтому необходимо, чтобы в основе лежала единая современная платформа или платформы, но никак не устаревший монолит или даже «зоопарк» из слепленных Agile-командами «под задачу» функциональностей. Такой подход видится нам наиболее конкурентным в перспективе.

Я еще как-то могу понять те банки, которые отложили вопрос модернизации Core Banking и не трогают его до поры до времени. Но я не понимаю тех, кто уже (или все еще?) пытается его как-то «пилить на части» и делать это не в современном стеке. А значит, опять шина, опять нет реальных 24/7, нет линейной масштабируемости. Потратить кучу ресурсов и снова оказаться позади? Неразумно.

Тут я бы сделал сноску и сказал, что, по моему мнению, изменения в мире финансового ИТ происходят куда медленнее, чем нам кажется. И технологические истории, которые уже много лет звучат на форумах и конференциях, и по ощущениям должны были бы уже давно приземлиться, для подавляющего большинства организаций — вода, в которой они даже не замочили ноги. И если сначала нам казалось как-то неловко приезжать к заказчику и рассказывать его ИТ-специалистам про микросервисный стек как таковой, и про то, что дает его применение (я лично вырезал этот блок из презентаций), то потом мы поняли, что в большинстве случаев разговор приходится начинать именно с этого. Часто заказчик сразу не скрывает, что имеет целью «прокачаться» при общении с нами на тему платформенного подхода и микросервисов и только потом выходить на какие-то осмысленные решения. Для нас такое общение, конечно же, инвестиция. А у банка в результате рождается доверие к нашей компетентности и, что не менее важно, вера в себя — в то, что он хорошо понимает, зачем, что и как он будет устанавливать, как с этим жить и какие преимущества получит.

CNews: Кстати, у многих, до сих пор, вызывают аллергию такие термины как «Agile» или «микросервисы».
Дмитрий Гарбар:

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

Дмитрий Гарбар:

Соревнование банков на предмет того, «у кого ДБО красивее», завершилось — почти у всех одинаково красиво. Наступает время решения более сложных задач и формирования более своевременных продуктов. Это требует других скоростей на всех уровнях архитектуры.
CNews: Вы передаете своим заказчикам коды платформы?
Дмитрий Гарбар:

Мы штатно передаем заказчикам коды разработанного для него бизнес-функционала и, да, можем передать код платформы.

Сейчас модно говорить о самостоятельной разработке в банках — это еще один тренд. Не все до конца понимают, зачем им нужен наш код, но все его хотят. А мы не возражаем, так как уверены, что работы на всех хватит. Маятник самостоятельной разработки снова качнулся в сторону «все сделаем сами», но вернется и обратно, и банки неминуемо вспомнят, что является их core-бизнесом. Быть высокетехнологичной финансовой организацией не равно все делать самим. А те яркие примеры с самостоятельной разработкой, которые мы сейчас видим, да еще и зачастую на платформах, которым 20 лет от роду — это… удивительно. И точно не про эффективность.

CNews: А что у вас с импортозамещением?
Дмитрий Гарбар:

У нас — все замечательно. Мы — полностью российская компания, и мы старались использовать в нашей платформе или российский, или открытый софт.

Например, для in-memory-расчетов мы можем использовать открытую СУБД Tarantool от компании Mail.ru — этот продукт позволил нам существенно ускорить обработку остатков по счетам в режиме реального времени. Кстати, импортозамещать мы будем не только в России, в планах — продвигать нашу платформу за рубежом, «замещая» устаревшие иностранные решения и на их территории.

Источник фото: ru.depositphotos.com