Сколько стоит бесплатный open source

Почему банки обратили внимание на open source

«На мой взгляд, активное применение open source-решений в России начало развиваться три-четыре года назад, когда появились отечественные сборки, сопоставимые по качеству с проприетарным софтом и подходящие для enterprise-решений. Например, уже достойно зарекомендовала себя коммерческая сборка Greenplum, которую предоставляют несколько вендоров. Именно поэтому, когда мы решили внедрять вендорский продукт, разработанный на основе open source, знали, что нас ждет успех», — поделился опытом Николай Шевцов, директор по управлению данными ОТП Банка.

Изначально open source-продукты использовались банками для решения незначительных задач, но впоследствии на них стали переносить и части более важной или даже критичной инфраструктуры. Так, в Росбанке на решениях с открытым исходным кодом работают система мониторинга, интеграционные решения.

«Использование решений с открытым кодом дает больше гибкости в доработке, модификации и репликации», — прокомментировала Анна Еганова, директор департамента развития и операционной эффективности IT Росбанка.

Финансовая группа БКС развивает хранилище данных с применением open source-технологий, начиная от решений для хранения холодных данных до задач класса NRT (near real time), которые требуют обширного применения самых современных инструментов. По словам Алексея Карпунина, вице-президента по операционной деятельности и информационным технологиям ФГ БКС, переходя на инфраструктурный уровень, интеграция open source-технологий в IT-ландшафт становится еще более плотной. В БКС практически вся экосистема платформы микросервисов построена на open source-стеке или на продуктах, основанных на базе технологий с открытым исходным кодом. Решения о переходе на открытый исходный код принимаются, когда финансовой группе важны большая гибкость и вариативность использования.

«Предпочтение исходному коду отдается из-за отсутствия отчислений за лицензии на ПО, что позволяет уменьшить общий IT-бюджет на лицензии с помощью постепенной замены наименее критичных сервисов компании. Open source-решения не требуют перестройки бизнес-процессов, а наоборот, позволяют доработать софт под работающие процессы», — считает технический директор IT-кластера МТС Банка Сергей Харитонов.

Приводя пример активно используемой open source-технологии, Александр Сабуров, директор департамента больших данных РСХБ, назвал Hadoop, который часто применяют в качестве коммерческих сборок. «Эта технология требует высокого уровня экспертизы, чтобы ее эффективно использовать “в бою”. Поэтому бывает проще купить решение, чем пытаться с нуля наращивать свою экспертизу внутри. Это позволяет получить пользу быстрее, не отменяя возможность развить свою экспертизу позже», — считает он.

«Ваниль» в банках: когда внедряют и с какими сложностями сталкиваются

Ряд финансовых организаций принимает решение формировать собственную разработку, самостоятельно внедряя, развивая и поддерживая open source-продукты. Такую сборку в IT-кругах называют ванильной. Чаще всего решение о ее внедрении принимается в том случае, когда организация не хочет стать заложником вендорского решения. Однако идут на такой шаг только лидеры финсектора, и это обоснованно.

«Обычно мы заинтересованы в долгосрочном сотрудничестве с вендором, однако в то же время не хотим оказаться в ситуации vendor-lock. Отчасти поэтому в некоторых ситуациях мы решаем все-таки прибегнуть к самостоятельной адаптации “ванильных” сборок. Но скорее, если видим в этом свое ноу-хау, понимаем, зачем оно нам нужно и хотим сформировать внутреннюю экспертизу по этому направлению», — прояснил Алексей Карпунин. Однако, по его словам, «ванильные» сборки, как правило, сфокусированы на развитии основной функциональности решения, а второстепенные функции реализованы в минимальном объеме. Поэтому самостоятельная доработка потребует экспертизы и времени. Также для нее характерны отсутствие стратегии развития, неспособность быстро откликаться на регуляторные требования, низкое качество проработки нефункциональных требований.

При этом для создания, внедрения и поддержания «ванильной» сборки потребуется собственная команда, уже обладающая экспертизой в используемой технологии и способная поддерживать ядро проекта. Это превращается в огромную проблему, так как на российском рынке наблюдается острый кадровый дефицит IТ-специалистов. И, даже набрав команду, компания становится ее заложником, сталкиваясь с непрогнозируемыми рисками по ее удержанию.

«Для российского enterprise, отрезанного от западных технологий, open source — это во многом последняя надежда, что, в свою очередь, разгоняет стоимость опытных специалистов на рынке труда. Найти сильных ребят и два-три года назад было непросто, а сейчас еще многие уехали за рубеж. Собранную команду надо удержать внутри компании. Периодически чувствую себя burn-out-менеджером, пытаясь перекидывать ребят с одной задачи, которая им опостылела, на другую, которая сейчас интересна. В отдельных случаях новую и интересную надо придумать», — поделился опытом Александр Сабуров.

Остаются также проблемы интеграции «ванильной» сборки в IТ-инфраструктуру компании. Как отметила Анна Еганова, не все внутренние системы и компоненты можно перестроить на работу с open source и не всегда использование «ванильной» сборки экономически оправдано ввиду высокого уровня кастомизации, сложности и длительности перехода, потерей производительности.

Стабильность и поддержка

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

«Нам нужно быть уверенными в том, что при апгрейде на новые версии различных компонентов само решение в целом будет работать стабильно и корректно. Это первое. Второе, не секрет, что даже в open source появляются баги, которые правятся. Для этого нужны дополнительные ресурсы. Третий момент — поддержка нас как клиента этого решения. Если просуммировать все три пункта, то их можно было бы сделать самостоятельно на нашей стороне, но тогда мы бы выполняли параллельно работу по разработке ПО, а это не является для банка основным видом деятельности», — считает Николай Шевцов.

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

«Вендорское решение open source-продукта должно быть лучше, чем то, что предлагает комьюнити по значимым для нас параметрам. Например, для нас крайне важны способность держать большую нагрузку, уровень архитектурного качества (у нас очень высокие стандарты), и мы с большим вниманием относимся к процедурам контроля качества на стороне вендора, выпускающего коммерческую сборку. Очень важна способность вендора в кратчайшие сроки реализовывать требования», — уверен Алексей Карпунин.