TL; DR 1: миф может быть правдив в одних условиях и ложным в других
TL; DR 2: увидел холивар – присмотрись и увидишь людей, которые не хотят слышать друг друга
Читая очередную статью, написанную предвзятыми людьми на указанную тему, решил выдать свою точку зрения. Может кому полезно будет. Да и мне удобнее давать ссылку на статью вместо того, чтобы много рассказывать.
Мне эта тема близка – мы создаём контакт-центры, предлагая их по обеим моделям, как будет лучше для клиента.
Под SaaS в этой статье имеется в виду модель распространения ПО, когда сервер находится в общем облаке, а пользователи подключаются удалённо, чаще всего через интернет, через web-интерфейс.
Под on-premise в этой статье имеется в виду модель распространения ПО, когда оно устанавливается на сервер клиента, а пользователи подключаются локально, чаще всего используя интерфейс windows-приложения
Часть первая. Мифы
Миф 1.1. SaaS дороже on-premise
Миф 1.2. On-premise дороже SaaS
Продавцы SaaS часто говорят, что старт использования их ПО обходится значительно ниже. Всего-то Х долларов в месяц за пользователя. Намного дешевле, чем ХХХ у on-premise.
Продавцы on-premise умножают цену SaaS на много месяцев и говорят, что их ПО дешевле. Даже графики рисуют. Неправильные.
Неправильный график не учитывает, что цена лицензий – ещё не всё. Есть ещё цена работ по настройке. И затрат на обучение. И цена ошибок недообученных сотрудников. Есть цена админа, который обсуживает сервер. Есть цена апгрейда сервера и ремонта сгоревшего БП или HDD. Короче, не получается прямых линий ни там, ни там.
В реальности, дешевле или дороже зависит, например, от длительности периода, когда не ожидается больших изменений. Например, когда наш клиент точно знает, сколько человек ему надо и чем они будут заниматься – ему выгоднее on-premise. Если для него контакт-центр – своего рода эксперимент, ему лучше выбрать SaaS. Тем более, сменить одно на другое, если что у нас можно без потери данных.
Так что дешевле? Для одних случаев – одно, для других — другое
Миф 2.1. SaaS безопаснее on-premise
Миф 2.2. On-premise безопаснее SaaS
Наши клиенты делятся на две большие, примерно равные группы. Одни говорят «чтобы мои данные были где-то в интернете? Боже упаси! А вдруг злобные хакеры взломают, украдут или удалят? Нет, пусть они будут на моём сервере, тут, у меня в офисе». Другие: «чтобы мои данные были тут, в офисе? Боже упаси! А вдруг пожар, кража или маски-шоу? Нет, пусть они будут где-то в интернете».
В реальности безопасность – понятие многофакторное, местонахождение сервера – лишь один из многих факторов, говорить что одно безопаснее другого не серьёзно.
Так что безопаснее? Для одних случаев – одно, для других — другое
Миф 3. SaaS плохо кастомизируется
В теории, для on-premise можно дописать в коде то, что надо для конкретного клиента. На практике это приведёт к разрастанию количества версий. Стоимость сопровождение взлетит до небес, и никто старается ничего подобного не делать. Вместо этого подгружается какой-то конфиг и приложение любого вида настроит само себя.
В реальности кастомизируемость зависит от зрелости ПО и от предусмотрительности разработчика. А не от способа распространения.
Так что лучше кастомизируется? В одних случаях – одно, в других — другое
Есть и другие мифы, менее популярные. Но столь же ошибочные. Но пока, для иллюстрации, и этих хватит
Часть вторая. Холивар
Есть такое понятие как «число Мюллера» — количество сущностей, которыми мы можем оперировать. 7+-2. У каждого своё, в стрессе может уменьшаться вплоть до 1.
Если сущностей много, мы начинаем упрощать и обобщать. Вот тут кроется подвох – упрощаем и обобщаем мы каждый на свой лад, а слова используем одни и те же.
Вообще, в любом холиваре видны как минимум одна из двух ошибок. А чаще обе сразу:
1. Разные значения одних и тех же слов
Например, для кого-то в два раза дешевле = лучше. Потому что ему воспользоваться надо всего 1 раз. А другой смотрит, за счёт чего цена такая, и видит, что сделана шняга дендро-фекальным методом, что для него неприемлемо. Для него лучше = дороже, но нормально. Потом они спорят, забыв уточнить, что имеется в виду под «лучше».
2. Не все готовы увидеть в другом человеке ДРУГОГО человека и признать, что у него свои цели и приоритеты
Кому-то важны технические характеристики, а кому-то – удобство в использовании. Реально важнее, в его ситуации неудобно = «меньше денег в месяц заработаю» или «буду раздражительный и рычать на домашних». Ему важно переплатить несколько процентов своего дохода за многие часы хорошего настроения свои, жены и детей. А кто-то сам живёт, ему лишние несколько сотен долларов – важны, а бесить дома некого. Если эти двое не хотят друг друга слышать, то встречайте холивар типа «Mac vs Windows» или что-то подобное.
Кстати, «не хотят друг друга слышать» — очень часто САМАЯ главная причина холивара. К сожалению. Как только захотят, окажется что можно пожать плечами, сказать «ну да, в твоём случае так» и сменить тему.
Замечали такое? Или, наоборот, замечали что-то другое?
Комментарии (9)
kirillrst
12.05.2019 10:53А чего холиварить? У бизнеса есть задача зарабатывать деньги в определенных условиях. От этих условий зависит выбор. Приведу критерии:
- Конфеденциальность – это отсутствие возможности доступа к данным третьей стороной включая вендора. Если конфеденциальность критична – выбираем on-permise. Обычно это определяется политикой бизнеса, либо требованиями регулятора.
- Безопасность – защита от злонамеренных действий третьей стороны. Почти всегда ведор обеспеспечивает лучшую безопасность своего SaaS продукта, чем клиент с on-permise. Если, конечно, у клиета it-команда не круче, чем у вендора.
- Цена, в которую обязательно следует включить сопровождение (интеграцию, обновление, обеспечение доступности, проблемы масштабирования). Называется "совокупная стоимость владения" (TCO). Для клиента SaaS TCO всегда ниже, т.к. вендор на себя забирает все эти расходы и экономит на эффекте масштаба. Грубо говоря, на одном сервере может быть много клиентов.
- OPEX vs CAPEX – это уже вопрос фин отдела. Кому-то удобнее помесячно платить в случае SaaS, а кому-то один раз. Хотя часто с вендором можно по-разному договориться.
Есть, конечно, и и другие факторы и полутона, но эти основные. Соответственно, если у вас нет высоких требований к конфеденциальности, крутой команды сопровождения – выбирайте SaaS.
kirillrst
12.05.2019 11:06- Скорость внедрения – для многих критичный фактор. При SaaS в течение дня можно принять решение – подходит или не подходит. Для on-permise могут пройти недели.
HellKaim
12.05.2019 13:32Статья 100% верная во всем.
Мы сами начинаем всегда с saas и потом уходим на on-permise.
В нашем случае выгоднее держать все у себя, так как постоянно происходит глубокая интеграция, что сложно (часто) сдлеать с saas. Плюс таким образом мы избавляемся от зависимости от провайдера (канала) — все седят в локалке и даже падение и переключение на другой канал проходят менее болезненно. Лишь часть функций "икает", а не вся работа встает.
Но у нас свои devops'ы и нам так проще.HellKaim
12.05.2019 13:33С другой стороны, когда мы пойдем в распределенные офисы — нужно будет инвестировать в отказоустойчивость каналов связи на много больше, чем сей час. Но это — копейки, по сравнению с интеграцией saas решений.
nApoBo3
12.05.2019 20:20При использовании SaaS требования к каналам связи не ниже. Я бы сказал, для современного бизнеса отказоустойчивые каналы связи уже необходимость они нужны в любом случае.
HellKaim
12.05.2019 22:10Вопрос в том, какую модель угроз вы используете и какой у вас бизнес. Мы считаем, что падение почты и мессенджеров на 30 минут для нас приемлемо.
Голос у нас через GSM так что это вообще не зависит от канала.
aram_pakhchanian
Когда много лет тому назад в институте мы учили английский, то чтобы выкрутиться, отвечая на вопросы, начинали с “it depends”, чем приводили англичанок в бешенство. Потому что когда ответ на конкретный вопрос звучит как ни о чем, это вызывает ощущение, что тебя дурят.
salkat Автор
Конечно, Вы правы. Когда клиент меня спрашивает, какой вариант лучше конкретно для него — я ему с аргументами отвечаю, что именно ему стоит предпочесть и почему. Тут же я хотел показать, что нельзя заявлять «этот вариант точно лучше всегда для всех случаев»