Дмитрий Гарбар, «Новая Афина»: Банки должны переходить на односкоростную архитектуру
31.01.2020
CNews: Дмитрий, в конце 2019 года «Новая Афина» презентовала новую микросервисную платформу. Как вы к ней пришли?
Компания «Новая Афина» исторически ассоциируется с полнофункциональным и производительным Core banking — мы не создаем чистые фронты и не пишем ДБО. Наше решение «ИСУБД Новая Афина», успешно функционирующее в крупнейших российских и западных банках, уже может быть отнесено к Legacy. Да, оно спроектировано так, что может активно дорабатываться (что банки и делают сами или с нашей помощью) и держит нагрузки в миллионы документов в день. Но новые вызовы, стоящие перед финансовыми организациями, требуют принципиально других решений.
Поэтому несколько лет назад мы собрали молодую команду и теперь можем с гордостью представить результаты ее труда: платформу в микросервисном стеке, которая призвана стать действительно ядром цифрового банка будущего. Вместе с платформой мы предлагаем так же набор SDK и организацию DevOps-процесса, если бизнес захочет вести самостоятельную или совместную с нами разработку на этой платформе. Сразу хочу оговориться, что это бескомпромиссное решение.
Микросервисы — это хайп. Поэтому любой производитель ПО, желающий остаться в рынке, чувствует, что должен что-то заявить по теме микросервисов. И многие поспешили это сделать. В результате на рынке присутствуют «микросервисные решения», которые являются не чем иным, как на скорую руку упакованными в контейнеры целыми продуктовыми системами. Все это запускается в Kubernetes, и — пожалуйста, «у нас есть микросервисное решение!»
Другой вариант: в банке устанавливается небольшой модуль в микросервисном стеке, решающий узкую бизнес-задачу. И этот модуль выдается за цифровую платформу. Иногда банки не до конца понимают, что им предлагается, а иногда «обманываться рады», так как это позволяет заявить на весь рынок, что они в тренде.
Но мы нацелены на тех заказчиков, которые научились различать, где есть только обертка, а где — качественный микросервисный продукт с оптимально спроектированными микросервисами, которые хотят заложить действительно качественную основу своего эффективного долгосрочного развития, а возможно и просто существования в грядущем мире больших скоростей.
Дмитрий Гарбар:
Выпуску нашего решения предшествовала серьезная архитектурная проработка, в которой, кстати, принимали участие архитекторы одного из крупнейших российских банков. Первый микросервис появился только после того, как были утверждены общая архитектурная концепция и правила разработки. Например, в зависимости от бизнес-задачи микросервисы могут использовать разные СУБД (для ведения баланса и лимитов по счетам мы используем in-memory database), есть элементы low code, которые мы планируем активно развивать. У нас много интересных решений.
Мы прошли по краю, выбирая, с одной стороны, самые современные, а с другой — доказавшие свою работоспособность продукты, которые мы тщательно протестировали, прежде чем включать их в наш технологический стек.
Давайте вспомним, какие неоспоримые преимущества свойственны микросервисной архитектуре. Это стабильность решения при большом количестве изменений и практически безграничное масштабирование при разумной цене на железо — разве это не то, что нужно в Core Banking?
А что касается идеи двухскоростной архитектуры, которая была сформулирована экспертами Gartner еще в 2014 году, то до поры до времени она была вполне разумным для банков подходом. Что-то вроде «есть слона по частям». Если упрощенно, то подход сводился к тому, что должен быть технологичный, быстрый, устойчивый к изменениям фронт и хоть какой-то, какой уж есть, бэк, потому что «не до него сейчас». И применение микросервисных решений, в первую очередь для фронт-офисов, было вполне оправдано. Но пришло время есть «вторую часть слона» — две скорости в архитектуре должны уступить место одной — максимальной.
Растут как объемы информации в системах, так и количество запросов к ним. На первое место выходит скорость формирования предложения клиенту, а значит должен храниться и мгновенно обрабатываться огромный пул информации. В такой ситуации Core Banking уже не получится вынести за скобки.
Соревнование банков на предмет того, «у кого ДБО красивее», завершилось — почти у всех одинаково красиво. Наступает время решения более сложных задач и формирования более своевременных продуктов. Это требует других скоростей на всех уровнях архитектуры, во всех процессах. А поэтому необходимо, чтобы в основе лежала единая современная платформа или платформы, но никак не устаревший монолит или даже «зоопарк» из слепленных Agile-командами «под задачу» функциональностей. Такой подход видится нам наиболее конкурентным в перспективе.
Я еще как-то могу понять те банки, которые отложили вопрос модернизации Core Banking и не трогают его до поры до времени. Но я не понимаю тех, кто уже (или все еще?) пытается его как-то «пилить на части» и делать это не в современном стеке. А значит, опять шина, опять нет реальных 24/7, нет линейной масштабируемости. Потратить кучу ресурсов и снова оказаться позади? Неразумно.
Тут я бы сделал сноску и сказал, что, по моему мнению, изменения в мире финансового ИТ происходят куда медленнее, чем нам кажется. И технологические истории, которые уже много лет звучат на форумах и конференциях, и по ощущениям должны были бы уже давно приземлиться, для подавляющего большинства организаций — вода, в которой они даже не замочили ноги. И если сначала нам казалось как-то неловко приезжать к заказчику и рассказывать его ИТ-специалистам про микросервисный стек как таковой, и про то, что дает его применение (я лично вырезал этот блок из презентаций), то потом мы поняли, что в большинстве случаев разговор приходится начинать именно с этого. Часто заказчик сразу не скрывает, что имеет целью «прокачаться» при общении с нами на тему платформенного подхода и микросервисов и только потом выходить на какие-то осмысленные решения. Для нас такое общение, конечно же, инвестиция. А у банка в результате рождается доверие к нашей компетентности и, что не менее важно, вера в себя — в то, что он хорошо понимает, зачем, что и как он будет устанавливать, как с этим жить и какие преимущества получит.
У всего нового всегда есть сторонники и противники, это нормально. Главное — не пропустить точку невозврата, когда твой здоровый скепсис перестает быть стабилизирующим и не позволяющим рефлексировать на все хайповое, а мешает своевременно вложиться в тренд и отжать от него по максимуму.
Дмитрий Гарбар:
Мы штатно передаем заказчикам коды разработанного для него бизнес-функционала и, да, можем передать код платформы.
Сейчас модно говорить о самостоятельной разработке в банках — это еще один тренд. Не все до конца понимают, зачем им нужен наш код, но все его хотят. А мы не возражаем, так как уверены, что работы на всех хватит. Маятник самостоятельной разработки снова качнулся в сторону «все сделаем сами», но вернется и обратно, и банки неминуемо вспомнят, что является их core-бизнесом. Быть высокетехнологичной финансовой организацией не равно все делать самим. А те яркие примеры с самостоятельной разработкой, которые мы сейчас видим, да еще и зачастую на платформах, которым 20 лет от роду — это… удивительно. И точно не про эффективность.
У нас — все замечательно. Мы — полностью российская компания, и мы старались использовать в нашей платформе или российский, или открытый софт.
Например, для in-memory-расчетов мы можем использовать открытую СУБД Tarantool от компании Mail.ru — этот продукт позволил нам существенно ускорить обработку остатков по счетам в режиме реального времени. Кстати, импортозамещать мы будем не только в России, в планах — продвигать нашу платформу за рубежом, «замещая» устаревшие иностранные решения и на их территории.
Источник фото: ru.depositphotos.com