Все банки хотят в «облака» и ведут активную работу по внедрению облачных технологий в устоявшуюся IT-парадигму. Сейчас, на мой взгляд, все представители банковской сферы развиваются в одном темпе: никто не хочет собрать все «грабли». Кроме того, действующее законодательство РФ пока окончательно не готово дать зелёный свет облакам, из-за чего возникают сложности с выбором технологического стека и железа.
В этом году банк «Санкт-Петербург» провел пилот (писали о нем здесь) по миграции группы сервисов интернет-банка в облако на базе Yandex.Cloud. Проект хорошо себя показал, а также дал нам возможность получить опыт, когда всю информацию нельзя целиком отправить в облака с точки зрения безопасности — и мы сделали гибрид, где наши сервера и облако взаимодействуют между собой по каналу безопасного соединения.
Пустить весь программируемый контент в публичные облака мы не можем, потому что пока нет четкой формулировка закона и ответственности для банков по этому вопросу. Регулятор работает над этим вопросом, но, на мой взгляд, нормативы, позволяющие банкам в большей степени выйти за периметр, будут готовить не менее двух лет. И на сегодняшний день мы теряем часть облачного профита.
«Публичные облака»
Цель облачности — не облако само по себе, а борьба за эффективность. Когда мы используем облако партнёра, мы как с водопроводом в квартире – не обязаны использовать его круглосуточно. В любой момент мы можем включить или выключить поток, сохраняя ресурсы, и не платить за перерасход. В облаке партнёра мы всегда можем настроить тариф с точки зрения динамики нагрузок: в пиковое время подключать больше серверов, в момент простоя — отключить ненужные машины и приложения, условно, вместо 100 ядер использовать всего 20.
Компании, занимающиеся Public cloud, как раз и зарабатывают на возможности предоставить севера разным компаниям в нужное для них время. Пока ваша машина бездействует, кто-то другой разворачивает там свою запрограммированную инфраструктуру. За собственное железо вы заплатите не намного больше, чем за аккумуляцию публичного облака, но в экономике года эффективность будет очевидна. Если вы не знаете, чем нагрузить мощности купленной машины (а брать придётся мощное оборудование, способное выдержать пики активности), то и профит будет невелик. Не стоит забывать и о зарплатах специалистов, которые будут обслуживать ваше техническое решение. У операторов же — все включено.
«Публичные облака» — отличное решение, но, увы, не для тех компаний, чьи данные не могут быть вынесены за пределы периметра.
«Частное облако»
Если же мы используем свое железо, необходимо обеспечить его загрузку и не допускать простоя, т.к. это нерентабельно. Поэтому основную ставку мы делаем на Private Cloud и гибридную архитектуру. Это открывает возможность использовать оборудование с полной отдачей.
В этом нам помогут парадигмы IaC и IaaS («Зачем администратору становиться программистом?»). Например, пока тестировщики разрабатывают какой-то релиз и не занимают мощности, мы сможем развернуть новый CRM (благодаря программируемой инфраструктуре это не отнимает много времени). Программы будут выполняться по четкому синхронизированному графику, например, утром мы запускаем тестовую зону для одного приложения на 4 часа, затем это приложение сворачивается и на этих же мощностях разворачивается полигон для тестирования следующего микросервиса. Без автоматизации такой гибкости достичь невозможно, без облачности нам придется аппелировать избыточными ресурсами, а мы этого не хотим.
Сейчас Банк «Санкт-Петербург» находится в фазе поиска наилучшего решения для частного облака. Мы понимаем, что нам нужны готовые стойки, чтобы не развивать экспертизу по созданию облака, а использовать опыт и технологии вендора. В нашем шорт-листе — IBM, Oracle. Они готовы привезти уже настроенные ящики для частного облака с полной разметкой и инструментарием управления. Также мы присматриваемся к отечественному Mail и КРОК. Они могут развернуть свое облако на нашем железе и взять на поддержку, что тоже весьма интересно.
Особой функциональной разницы между предложениями вендоров нет, все они похожи и заточены под программируемую инфраструктуру. Для нас очень важно, чтобы вычислительный комплекс подчинялся командам Terraform и не требовал от нас поиска «подкапотных» специалистов в большом количестве. Например, в ходе нашего тестового запуска в облаке Yandex экономика сложилась, когда мы отказались от нескольких инженеров для кластера Kubernetes, используя готовый яндексовский проект.
Наш уровень зрелости
Облачные технологии уже стандартизировались. Даже сейчас мы можем делать разработки такими, чтобы они легко переносились не только в частное облако, но и публичное, когда эта технология станет нам законодательно доступна.
Поэтому пока мы находимся в фазе решения технических вопросов для организации частного облака — мы выбираем cloud ready программное обеспечение. Еще не весь технологический стек готов улететь в облака. Тем не менее, часть платформ уже готова к этой парадигме. Хотелось бы побыстрее разместить в облаке CRM, который архитектурно готов к трансформации. У нас есть предназначенная для автоматизации банковских процессов Anyflow, готовая использовать облачные технологии ещё эффективнее. Проект «Юпитер», который уже заметно повысил транзакционную активность клиентов по конверсионным операциям, хочется перенести в единый кластер.
Мы готовим общую методологию: единые репозиторий и правила для разработчиков и администраторов. Разрабатываем общие подходы к развертыванию приложений, чтобы в нужный момент на контур могли заходить тестировщики, а затем нововведения безболезненно переносились на прод.
Чем быстрее наш Банк сможет включить в свою жизнь Private Cloud, тем будет лучше для Time To Market и бесперебойности (мы писали здесь ранее о том, как Банк «Санкт-Петербург» переносится в облака и ускоряет ТТМ). Потому что парадигмы IaC и IaaS влияют на непрерывность: если мы запрограммировали инфраструктуру на тестовом полигоне, то потом ошибиться в её внедрение на продуктивной среде сильно тяжелее.