О плюсах и минусах облачных технологий и решений на собственных серверах (on-premises), а также о подходах к выбору между этими моделями в эфире Бизнес ФМ рассказал руководитель по технологическому развитию Яндекс 360 Сергей Педченко.

Поговорим про сложности выбора между облачными решениями и on-premises-моделью, когда сервисы разворачиваются на серверах клиента. Правильно ли я сформулировал проблему?
Сергей Педченко: Да, в общих чертах это звучит так.
Последние лет десять и вендоры, и провайдеры облачных сервисов, и журналисты, и я в их числе, старательно убеждали индустрию в том, что облако — это перспективно, современно, надежно, безопасно и, что особенно важно, экономически эффективно. Кажется, что облако — это уже устоявшийся мейнстрим. Насколько это правда? Есть ли исключения и где эти исключения лежат?
Сергей Педченко: SaaS и в широком смысле облачные решения остаются основным способом потребления IT для большинства компаний. Но есть подход, когда по требованию регуляторики, по внутренним регламентам, по модели угроз, которым следует компания-заказчик, необходимо использовать не только облачную модель (а иногда бывает, что облачные модели просто запрещены), а разворачивать все в собственной инфраструктуре — on-premises.
И это сейчас является одним из подходов, когда существенная часть рынка, которой нужны гибкость, быстрота масштабирования, идет в облако, а для некоторых задач все-таки приходится осознанно понимать, что нужно предпочесть on-premises.
Давайте обозначим границы, отделяющие бизнес, которому нужно облачное решение, от бизнеса, которому, скорее всего, нужно подумать над решением on-premises.

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

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

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

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

Сергей Педченко: Как раз моя работа часто связана с коммуникацией с заказчиками. И я могу привести много положительных доводов относительно облаков. Тем более что до этого у нас была только модель поставки SaaS. Чаще всего дискуссии у нас с коллегами развиваются на тему информационной безопасности.

Звучат вопросы: «А где ваши сервера? Где ваши дата-центры, которые хранят данные? Есть ли трансграничная передача данных?» Здесь у нас все замечательно, все дата-центры находятся на территории РФ, с персональными данными мы работаем в рамках федерального законодательства. Но далее начинаются вопросы: «А как нам убедиться, что вы точно не потеряете данные при какой-нибудь аварии, при сбое? Как мы можем контролировать персонал, который работает с сервисами по развитию и обновлению? Как мы можем гарантировать, что никто ничего не смотрит, никто ничего не читает?»

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

Если мы говорим про собственников, то для них самое главное — предсказуемая модель оплаты, чтобы можно было вместе с финансистами прогнозировать рост потребления и четко планировать бюджеты. И в SAAS это удобно, и в on-premises мы тоже поставляем лицензии по понятным, прозрачным моделям.

Правильно ли я понимаю, что теперь все сервисы Яндекс 360 доступны и в облаке, и в on-premises?
Сергей Педченко: Да, и уже сейчас по модели on-premises доступны Диск, Документы, Доски и Браузер для организаций. До конца года все наши ключевые сервисы можно будет развернуть на собственных серверах заказчиков: это Почта, Трекер, Телемост, Мессенджер и другие.
Продолжим игру: если мы снова пришли в эту же переговорную беседовать с тем же советом директоров, но в данном случае обсуждается инсталляция on-premises, наверняка есть какие-то специфические требования, опасения, пожелания, которые возникают в этом случае. Чего ждет заказчик от провайдера услуг при принятии решения об on-premises-развертывании?

Сергей Педченко: Заказчик ждет понятный продукт, чья функциональность не зависит от модели поставки. Фактически частое требование — это единая продуктовая логика с облаком.

Еще из обязательного — прозрачные требования к инфраструктуре, масштабирование, инструкции по разворачиванию решений, предсказуемые и ритмичные обновления продуктов, соответствия корпоративным стандартам и лучшим практикам на рынке интеграций. Требуют работу с технологией Single Sign-On (удобным единым входом), чтобы можно было использовать один корпоративный пароль, а не десять разных. Также аудируемость, возможность гибкой настройки в зависимости от роли пользователя по работе с сервисами.

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

Что меняется в тот момент, когда заказчик решает разворачивать сервисы on-premises, для него и для вендора с точки зрения стоимости, сроков и, возможно, обучения?

Сергей Педченко: Меняется почти все, кроме продукта. Его функциональность должна оставаться той же самой. В Яндекс 360 это наше кредо. Во-первых, мы хотим развивать продукт ритмично и в SaaS, и on-premises. Во-вторых, для пользователя это должно быть привычно. Сейчас мы видим, что SaaS и on-premises — это два полюса. Но мы, делая on-premises, не выключаем SaaS, не «закапываем» его. И, напротив, делая SaaS, не ставим по остаточному принципу on-premises. Модели поставки могут быть разные, но продукт должен быть один. И у пользователя не должно возникать когнитивного диссонанса, он должен видеть, что мы делаем одну логику.

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

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

Одно из требований on-premises — встроиться в то, что уже есть. Есть разные требования к этой инфраструктуре, к интеграции, к скорости обновления в каждой из инсталляций. И у заказчика могут быть разные команды с разным уровнем зрелости для поддержания. Кто-то говорит, что он на «кубере» (Kubernetes) собаку съел, а кто-то спрашивает, что такое Docker. И для нивелирования этой сложности мы развиваем наши партнерские каналы, которые должны предоставить конечную экспертизу заказчику, чтобы вне зависимости от зрелости команды и уровня развития все работало.

Мы как вендор предоставляем не только готовый продукт, веб-интерфейс (Почты, Диска), конечные приложения, но и эксплуатационную совместимость, чтобы они обновлялись, поддерживались и надежно работали вне нашей инфраструктуры так же, как и в облаке.

Заказчик в свою очередь получает больше контроля, имея возможность развернуть продукт в своей инфраструктуре. Но вместе с тем он принимает и больше ответственности: начинает отвечать не только за правильное использование сервиса, но и за среду, резервирование, безопасность, доступы. Если у нас что-то упало, мы это быстро чиним, у нас в договоре прописаны критерии доступности сервисов. Если надо обеспечивать доступность сервиса — мячик на стороне команды заказчика. Поэтому в моем понимании on-premises имеет смысл, когда дополнительный слой и возможности контроля действительно нужны бизнесу.

Если я правильно понял саму суть нашей сегодняшней беседы, то Яндекс 360 одинаково готов предлагать свои услуги клиенту и в облаке, и на собственных серверах клиента. Все так?
Сергей Педченко: Да, мы здесь говорим о том, что мы не хотим кого-то принуждать — идти только в облако или только в on-premises. В первую очередь мы хотим, чтобы компании-клиенты пользовались нашим продуктом. А уже как им пользоваться — полностью в облаке или в on-premises, это их выбор на основе конкретных потребностей. Мы хотим сделать и возможность использовать наш продукт в гибридной модели. Кто-то может сказать, что те, кто используют on-premises, ретрограды. Но я не согласен: это не шаг назад, а способ закрыть особые потребности наших крупных заказчиков. И я считаю, что будущее за единым продуктом в разных сценариях развертывания.
При внедрении сервиса у клиента каким образом вы принимаете решение, что ему рекомендовать: облако или on-premises? На что вы смотрите? Каков алгоритм принятия решения?

Сергей Педченко: Вначале спрашиваем: есть ли жесткое требование по работе с данными, которые будут храниться в системе, и каковы контур взаимодействия с этими данными и регуляторика? Если компания занимается медициной, финансами и другими «секретными» областями, то выбор падает на on-premises и в дальнейшем, возможно, на гибрид.

Далее уточняем: насколько критично заказчику управлять полным циклом обновлений и управлением с интеграцией со своей инфраструктурой? Если он хочет, чтобы среда была полностью контролируемая, чтобы она обновлялась при необходимости, то on-premises в этом случае вероятнее.

Следующий вопрос заказчику: есть ли на его стороне инфраструктура, команда, которая знает, как работать с таким классом решений? Если есть компетенции, есть доступ к инфраструктуре, то да, это будет on-premises.

Ну и в конце нужно оценить, действительно ли требования к on-premises, исходя из внутреннего регламента, из общей регуляторики, настолько суровы. Можно ли пойти на некие компромиссы и поработать с внешним сервисом либо необходимо инвестировать в собственный контур.

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