SaaS-модель снимает с компании значительную часть инфраструктурной рутины: не нужно самостоятельно закупать и обслуживать оборудование, а часть задач по эксплуатации переходит провайдеру. Но одновременно бизнес передаёт ему и контроль над инфраструктурой, обновлениями и доступностью сервисов.
Поэтому для некоторых корпоративных систем компании рассматривают модель On-premises (также встречаются варианты on-premise и on-prem). В такой модели ПО разворачивается в инфраструктуре самой организации и находится под её управлением. Это не делает систему полностью безопасной, однако компания действительно получает больше контроля над архитектурой и рисками.
Altcraft работает с On-Premises-проектами с момента создания в 2015 году: возможность локального размещения закладывается во все наши продукты. В статье разберём, в каких случаях стоит рассматривать On-premises, что понадобится для развёртывания, как перейти из облака, из чего складывается стоимость и как обеспечить нужный уровень отказоустойчивости.
Что такое On-premises и какие ещё есть альтернативы облаку
On-premises предполагает, что компания размещает ПО в собственной инфраструктуре и сама контролирует среду, в которой оно работает. Подробнее о формате и его отличиях от облачных решений читайте в нашем разборе.
При этом отказ от публичного облака не всегда означает переход именно на On-premises. Если компании нужен отдельный инфраструктурный контур, но она не готова брать на себя эксплуатацию собственного оборудования, можно рассмотреть вариант размещения Private Cloud. Если нужны собственные физические серверы, но компания не хочет содержать свой дата-центр, можно рассмотреть colocation (размещение оборудования в стороннем ЦОДе). Возможны и гибридные схемы.
В этой теме легко смешать понятия из разных классификаций. SaaS и IaaS описывают модели предоставления IT-ресурсов, Public и Private Cloud — модели облачного развёртывания, а colocation и dedicated server — способы размещения оборудования. Памятка ниже пригодится, чтобы быстрее сориентироваться в вариантах и подготовиться к обсуждению с IT-командой и поставщиком.
| Понятие | Что это значит для бизнеса |
|---|---|
| SaaS | Компания пользуется готовым ПО, а большую часть инфраструктуры эксплуатирует поставщик |
| IaaS | Провайдер предоставляет вычислительную инфраструктуру, а ОС и прикладные системы остаются в зоне ответственности клиента |
| Public Cloud | Облачная инфраструктура рассчитана на множество клиентов |
| Private Cloud | Облачная среда выделена одной организации |
| On-premises | ПО размещается в инфраструктуре компании и находится под её управлением |
| Colocation | Собственное оборудование компании размещается в стороннем ЦОДе |
| Dedicated server | Физический сервер принадлежит провайдеру, но выделен одному клиенту |
Когда стоит рассматривать On-premises
Для маркетинговой платформы модель On-premises особенно уместна там, где клиентские данные, внутренние системы и коммуникации критичны для бизнеса.
Нужно сохранить контроль над клиентскими данными
Банки, страховые компании, телеком-компании, крупный ритейл и другие организации могут ограничивать место хранения и обработки данных из-за требований ИБ, внутренних регламентов или отраслевых правил.
Например, БНБ-Банк выбрал Altcraft во многом из-за возможности свести к минимуму передачу клиентской информации сторонним ресурсам. Такое же требование было у «АльфаСтрахования»: платформа должна была работать с персональными и поведенческими данными внутри корпоративного контура, в том числе в связке с CDI-системой.
Платформа тесно связана с внутренними системами
Крупные сервисы редко существуют сами по себе. Скажем, CDP получает данные из CRM, DWH, сайта, приложения, программы лояльности и многих других источников.
Если часть этих систем доступна только внутри корпоративной сети, локальное размещение упрощает архитектуру: компания сама определяет сетевые доступы и правила обмена данными.
Нужен контроль над отказоустойчивостью
Архитектуру облачной инфраструктуры во многом определяет провайдер. При On-premises компания сама выбирает, где размещать компоненты системы, как их резервировать и какие площадки использовать.
В частности, такой формат позволяет хранить резервные копии на отдельной физической площадке, а компоненты системы распределить между несколькими дата-центрами. Если одна площадка окажется недоступной, система сможет продолжить работу за счёт ресурсов других ЦОДов.
При этом маркетологу не нужно разбираться в устройстве кластеров и репликации. Вместе с IT достаточно заранее ответить на два вопроса:
- Какой объём данных компания готова потерять в случае серьёзного сбоя?
- Как быстро маркетинговая система должна вернуться к работе?
Ответы определят требования к резервированию и восстановлению системы.
В архитектуре Altcraft On-Premises отказоустойчивое размещение предусмотрено изначально — для него есть отдельная схема развёртывания.
Резервирование на нескольких площадках снижает риск полной остановки системы при сбое одного из ЦОДов
Компания хочет сама выбирать момент обновления
В SaaS серверную часть продукта обновляет поставщик. При On-premises компания сама планирует, когда и как переходить на новую версию: можно сначала проверить сборку в тестовой среде, а затем обновить рабочую систему в удобное время.
Altcraft регулярно выпускает новые версии. В On-Premises клиент сам планирует установку новой сборки в своём контуре, а наша служба сопровождения при необходимости проводит обновление.
Нагрузку можно оценить заранее
On-premises подходит для систем с прогнозируемой нагрузкой: это даёт возможность заранее подобрать ресурсы с необходимым запасом. У маркетинговых платформ основные вводные обычно известны: размер клиентской базы, объём коммуникаций, количество событий и ожидаемый рост. По этим данным можно рассчитать конфигурацию под конкретный проект.
Если же нагрузка резко меняется, проект только запускается либо необходимые ресурсы трудно оценить заранее, облачная модель даёт больше гибкости в масштабировании.
У Altcraft есть несколько вариантов облачного размещения — изучить и сравнить их можно здесь.
Что понадобится, чтобы развернуть On-premises
On-premises иногда связывают с множеством требований к оборудованию, сети и системному ПО. Но это не означает, что для нового продукта компании придётся самостоятельно строить IT-инфраструктуру с нуля.
Если у компании уже есть корпоративная инфраструктура и IT-команда, многое уже готово: сеть, мониторинг, резервное копирование, управление доступами. Для нового продукта нужно прежде всего понять, какие ресурсы он потребует и как встроится в действующую среду.
Для типового проекта не обязательно использовать весь набор технологий, который может применяться в On-premises-инфраструктуре. Конкретная схема зависит от размера базы, интеграций, нагрузки и требований к отказоустойчивости.
Маркетологу не нужно самостоятельно рассчитывать процессорные ядра или разбираться в настройке баз данных. Его задача — вместе с IT и вендором собрать исходные данные проекта.
| Что нужно знать до старта | Зачем это нужно |
|---|---|
| Размер клиентской базы и прогноз роста | Рассчитать необходимый объём ресурсов |
| Объём коммуникаций и ожидаемые пики | Подобрать производительность с запасом |
| Источники клиентских данных | Спланировать интеграции |
| Каналы коммуникации | Понять, какие шлюзы и внешние сервисы понадобятся |
| Требования ИБ | Определить правила доступа и требования к размещению |
| Требования к доступности | Выбрать схему резервирования |
| Наличие тестовой среды | Спланировать проверку обновлений и интеграций |
Altcraft Platform можно развернуть в формате On-Premises на выделенном оборудовании, в виртуальной среде или контейнерах. Мы готовим техническую спецификацию, составляем архитектурную схему и рассчитываем мощности под конкретный проект. Обсудите требования к оборудованию и сайзинг с нашими экспертами.
Как проходит внедрение On-premises
Само развёртывание платформы — только часть проекта. Для бизнеса общий процесс можно свести к нескольким понятным шагам.
Определить требования. Маркетинг описывает бизнес-задачи, источники данных, каналы и необходимые интеграции. IT и ИБ задают требования к инфраструктуре и безопасности.
Подобрать конфигурацию и подготовить среду. По размеру клиентской базы, объёму коммуникаций и требованиям к доступности рассчитываются необходимые ресурсы. После этого IT-команда готовит серверы или виртуальную среду и необходимые сетевые доступы.
Развернуть платформу и интеграции. Устанавливается само ПО, подключаются CRM, DWH, сайт, приложение и другие системы и источники данных, переносятся клиентские данные.
Проверить работу. До полноценного запуска проверяют корректность данных и интеграций, работу каналов коммуникации, систему под нагрузкой и восстановление после сбоев.
Перейти к эксплуатации. После приёмки маркетинг начинает работать в платформе, а IT и вендор сопровождают систему в своих зонах ответственности.
На срок внедрения ощутимо влияют не только желания и потребности, но также объём интеграций и квалификация сотрудников. По опыту Altcraft, крупная компания с большим количеством интеграций и компетентными специалистами может уложиться в 2 месяца или быстрее.
Наши менеджеры и технические специалисты прорабатывают вопросы внедрения вместе с командой заказчика — подробнее об этом процессе читайте в гайде по внедрению Altcraft On-Premises.
Кто за что отвечает
В SaaS значительную часть технической эксплуатации берёт на себя поставщик. При On-premises больше задач переходит к команде заказчика, но поддержка вендора на этом не заканчивается.
| Зона | SaaS | On-premises |
|---|---|---|
| Инфраструктура | Поставщик | Заказчик или его инфраструктурный партнёр |
| ОС и системные компоненты | Поставщик | Заказчик |
| Обновления продукта | Поставщик | Вендор поставляет обновление, заказчик выбирает время установки |
| Мониторинг инфраструктуры | Поставщик | Заказчик |
| Интеграции | Заказчик + консультации вендора | Заказчик + консультации вендора |
| Бизнес-настройки | Заказчик | Заказчик |
| Исправления и обновления | Вендор | Вендор |
Как перейти с облака на On-premises
Если компания уже использует облачное решение, переход лучше планировать как отдельный проект. Важно перенести клиентскую базу и учесть всё окружение, от которого зависят маркетинговые процессы.
Общий порядок смены маркетинговой платформы мы разобрали в отдельном пошаговом руководстве. Ниже — несколько полезных советов.
Сначала составьте карту текущей системы
Для начала зафиксируйте, с какими системами связана платформа: CRM, хранилище данных, сайт, мобильное приложение, BI, коммуникационные шлюзы и другие сервисы. Отдельно перечислите способы обмена данными между ними: API, вебхуки, очереди сообщений, файлы и другие механизмы интеграции.
Проверочный вопрос: какие процессы остановятся, если завтра отключить облако?
Ответ и будет основой плана миграции.
Заранее выясните, что можно перенести
Одни системы позволяют выгрузить не только клиентскую базу, но и историю коммуникаций, шаблоны и сценарии. В других часть настроек придётся воспроизводить заново.
Это влияет и на сроки, и на стоимость переезда. Поэтому до начала проекта нужно понять, какие данные можно забрать, в каком формате они доступны и какие механики придётся воссоздать.
Если перенести можно не всё, миграцию стоит разбить по приоритетам: сначала клиентские данные и критичные коммуникации, затем менее важные сценарии и история.
Подготовьте новую систему до отключения старой
Сначала стоит развернуть новый контур и проверить критичные интеграции, затем — перенести основную массу данных. Изменения, которые появятся до окончательного переключения, синхронизируются отдельно.
Так маркетинговая команда не окажется в ситуации, когда старый сервис уже выключен, а новый ещё не готов к работе.
Заранее предусмотрите план переключения и отката
До перехода согласуйте с IT-командой и новым вендором дату переключения, допустимое время перерыва, порядок финальной синхронизации и критерии успешного запуска.
После запуска новую систему сначала проверяют под реальной нагрузкой и только затем окончательно выводят старую из эксплуатации.
Поэтапная миграция снижает риск простоя: перед окончательным переходом новую систему проверяют, а на случай проблем предусматривают откат
Сколько стоит On-premises
Сравнивать стоимость одного сервера с ежемесячной подпиской на облачную платформу бессмысленно. Для бизнеса важнее совокупная стоимость владения — TCO (Total Cost of Ownership).
Универсальной цифры «через два года On-premises становится дешевле» не существует. Экономика зависит от масштаба бизнеса, нагрузки, уже имеющейся инфраструктуры и модели лицензирования.
В расчёт стоит включить четыре группы расходов:
| Группа | Что учитывать |
|---|---|
| Старт проекта | Лицензия, оборудование или виртуальные ресурсы, внедрение, миграция |
| Эксплуатация | IT-команда, поддержка, сеть, мониторинг |
| Надёжность | Резервирование, резервные копии, запас мощностей |
| Развитие | Рост нагрузки, обновление оборудования и расширение инфраструктуры |
Для облачной модели тоже нужно учитывать не только базовый тариф: итоговая цена может зависеть от объёма данных, трафика, отправок, дополнительных ресурсов и сервисов.
В On-Premises-версии Altcraft стоимость не привязана к количеству отправленных сообщений, а цена фиксируется на согласованный период. Это делает расходы на платформу прогнозируемыми.
Срок окупаемости платформы чаще всего зависит от того, насколько активно бизнес её использует. Например, «Открытие Брокер» окупило годовую подписку на CDP Altcraft за 3 месяца. «АльфаСтрахование» с помощью платформы увеличило прибыль от CRM-маркетинга на 714% за четыре года, а «Выберу.ру» поднял ROI направления до 250%.
Что проверить перед переходом
Чтобы оценить объём проекта и выбрать подходящую модель размещения, задайте своей IT-команде и вендору несколько вопросов:
- Где будут храниться клиентские данные и кто получит к ним доступ?
- Какие внутренние системы нужно подключить?
- Какую инфраструктуру требуется подготовить и что уже есть у компании?
- Как будет выглядеть миграция и что можно перенести из текущего решения?
- Кто отвечает за обновления, мониторинг и восстановление?
- Какие внешние сервисы останутся необходимы после локального развёртывания?
- Сколько будет стоить проект с учётом внедрения и дальнейшей эксплуатации?
- Какая схема резервирования соответствует требованиям бизнеса?
On-premises имеет смысл там, где бизнесу действительно важны контроль над клиентскими данными, архитектурой и доступностью системы. Если окажется, что собственный контур пока избыточен, можно рассмотреть промежуточный вариант. Один из них — Private Cloud: выделенная инфраструктура без «соседей» и без необходимости размещать платформу на своём оборудовании.
Сейчас для подключения Altcraft On-Premises действуют индивидуальные условия. С нашими экспертами можно обсудить требования к инфраструктуре, схему размещения, стоимость и экономический эффект от проекта, а также варианты максимальной изоляции платформы от внешней сети — запишитесь на встречу.
Вам может быть интересно:
В новой статье рассказываем как с помощью автоматизации маркетинга и платформы Altkraft Marketing группа «АльфаСтрахование» увеличила уровень повторных покупок на 49%.
О том, как PREMIER настроил броадкасты и автоматизировал цепочки коммуникаций.
Перевели статью Talkwalker о лучших маркетинговых digital-стратегиях для сферы финансовых услуг. О том, как продвигать банки, страховые и брокерские компании, читайте в нашей статье.
