Comments 48
Я встречал пользователей, которые готовы использоваться ПО модели SaaS при условии, что данные будут храниться на стороне клиента. Кто-нибудь предлагает сейчас такое решение?

Что-то не так с Хабром, если авторы статей не могут сами их публиковать.
Мы думали над таким вариантом, но к какой-то концепции не пришли, не смогли придумать роль собственно сервиса. Обработка данных? Если клиенты нам её доверяют, то почему бы не доверить данные, если нет, то данные мы всё равно получаем для обработки и кто нам помешает их ещё и сохранять для себя? Если данные и обрабатывать у клиентов, то в чём отличие SaaS от локального приложения? Проверка оплачен ли аккаунт? :) Кроме того, при хранении данных теряется одно из преимуществ SaaS — мобильность, работа с любого места, где есть интернет.

Но проблема есть, да, мы думаем не только предоставлять сервис, но и продавать практически его же как «коробочное» решение для intranet.

Простейший пример SaaS — сервис по распознаванию документов. Или переводу. Данные на сервере не хранятся.

Проблема не в том, что люди не готовы доверить свои данные (если они готовы доверить свою кредитку сайту 392.168.1.23/visa.com/payment, то уж документы сайту они точно доверят).

Проблема в том, что они не доверяют ХРАНЕНИЕ документов. Это совсем другая область с другой оценкой сервиса. И описывается она так: а если я не смогу запустить браузер/выйти в интернет, то у меня не будет документов? Точка, всё, уносите сервис.

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

Насчёт локального хранения реплики (или кеша) как раз в случае отсутствия доступа к инету тоже думали, но сразу возникает вопрос — хранить на каждом клиенте? Если нет, то вариантов куча и часть из них сводятся к интранет клиент-сервер, а функция сервиса к проверке аккаунта…
Нет, вы не понимаете. Никакого автоматического бэкапа. Это момент не технический, а психологический. Документы ХРАНЯТСЯ на компьютере пользователя. А на сайте всего лишь их КОПИЯ.

Вот пока не будет этого, будет настороженное настроение по отношению к сервису.
Сервис выступает в роли координатора синхронизации данных между N компьютерами пользователя и желательно в реальном времени? Плюс обеспечивает логику предметной области или логика тоже компьютерах пользователя, чтобы он мог работать и в оффлайне?
UFO landed and left these words here
Завтра вам в голову попадает метеорит — и где данные?
Завтра вы поменяете интерфейс, и пользоваться станет некомфортно — и что делать?

Ну и так далее.
Открыть снимок базы ежедневно и/или по требованию приходящий на почту в Excel/Calc и продолжать работать как работали :)
Видите, я вам как раз про это и говорю. Никого не волнует, как вы это реализуете, главное ощущение пользователя, что документ ТУТ, а не ТАМ.
Ощущение (не декларируя его как факт) создать можно. Реализовать его, по-моему, без очень серьёзных затрат не реально — насколько я знаю MS с её автономными файлами/папками нормально (читай — прозрачно для пользователя привыкшего иметь дело только с локальными файлами) реализовать не удалось (кроме несколькихх вырожденных ситуаций, типа файлы только для чтения или пользователь, точно згающий механизм работы синхронизации и не игнорирующий его)
Ну, если про реализацию, то мне кажется, что файловая система в виде fuse-синхронизатора вполне может прокатить. Да и вопрос не в том, как это реализовано, а в том, как это выглядит для человека. Что там внутри — транзацкионная ФС с синхронизацией, реплицирующий сервис или что ещё — это уже головная боль программистов.
Главная сложность, что если для человека это выглядит как данные на его компьютере, то и поступать он с ними будет соответственно, причём не взирая на то есть ли соединение с интернетом и работает ли там какой-то сервер. Последствия, например — две версии одного документа с разным содержанием, и технические нюансы конфликта версий не столь важны, как юридические, когда, например, налоговая увидит два документа с одним номером.
Меня эти заезженные картинки страшно раздражают. Особенно в разделе «разработчики ПО». Мало того что штамп (эдакие сферические деловые люди в вакууме), так еще и не в тему, на девелоперов совсем не похожи.
да-да, там ни одного программиста, сплошные офис-менеджеры и менеджеры по продажам.
А что, программисты — это такие бородатые дяди в бифокальных очках и безразмерных свитерах?
Скорее гики в футболках и джинсах, которые срали на офисный этикет, галстуки и американскую улыбку с показом собеседнику обнажённых зубов.
Вы о чём? И с каких это пор сейл-менеджер в галстуке, скалящий зубы, стал символизировать собой «прекрасное»?
UFO landed and left these words here
UFO landed and left these words here
Вы забыли ещё одну причину: есть пользователи, которые не хотят платить за софт. Особенно, на повременной основе.
С такими пользователями (которые не хотят платить вообще) — труднее всего. Хотя, как показывает опыт, если цена соответсвует некому «безболезненному» уровню пользователя, то он скорее всего не будет заморачиваться с поиском серийников или вареза.
Проще отдать 10 копеек и пользоваться всеми благами — актуальными версиями, поддержкой и.т.д.
Совершенно правильно, никто не будет заморачиваться с поиском серийников, когда есть aptitude install и репозиторий готового софта.

Сколько бы не говорили про SaaS, но я не воспринимаю софт как сервис. Если сервис — то это именно сервис, а не программа в браузере, которая более лаглива и капризна, чем её аналог на винте.

Сервис — это когда кто-то делает работу. Например, услуга человеческой вычитки — это вполне сервис. Оформление заказа — сервис. Даже актуальная информация по какому-то вопросу — сервис. А просто ПО по обработке — зачем морочиться с вебом, когда можно в течение 10-30с его установить локально? Без всяких серийников, опасений «а что это они там с моими документами делают?», мыслей о том «а если они разорятся, что я делать буду?» и т.д.
Концепция SaaS — подразумевает сервис как модель распространения ПО, нежели как автономный производящий что-то сервис. В чем преимущество сервиса — нужно — взял, не нужно, отказался.

Репозитории свободного готового ПО — это здорово, но к сожаление не все необходимые ПО можно там найти.

Ну а вопрос доверия к сервису и его надежности — это вопрос времени. Это репутация, которую необходимо заработать. Посмотрите на SaleForce — крупнейшие компании доверяют им свои данные и не просто данные — а данные о клиентах и партнерах. Так что надежность, защищенность — необходимо доказать временем.
О, отлично. А теперь подумайте, насколько легко отказаться от предлагаемых SaaS-сервисов, не потеряв созданного с их помощью. Вот вам и вторая причина сопротивления SaaS.
Нормальная SaaS, имхо, обязательно должна предоставлять пользователю возможность экспорта данных хотя бы в одном распространённом формате.
Не «данных». Всей инфраструктуры. Я могу сменить использование майкрософт офиса на опенофис без малейших проблем — удалил одну программу, установил другую. Документы где лежали, там и лежат.

Что может предложить SaaS с подобным уровнем кросс-совместимости? Вышел с одного сайта, зашёл на другой, продолжаешь работать?
Экспортировал документы к себе на комп, перешёл на другой сайт, там их импортировал и продолжаешь работать :)

Но вообще смена всей инфраструктуры не в случае офиса (да и с ним тоже бывает) это большая головная боль. Сменить одну систему документооборота на другую, сменить одну систему оперативного и/или бухгалтерского учёта на другую, даже сменить используемую в одной из них СУБД на другую (хотя бы в целях унификации и снижения издержек, не говоря уж о глубокой интеграции) не получится, как правило, путем «удалил одну программу, установил другую». Простой пример с офисом — наши потенциальные клиенты широко используют для оперативного учёта Excel c VB вставками — как им перейти на Calc?
Э… Напомните, как выглядит экспортирование 10000 документов в 100+ папках с средней вложенностью 4-5?

А с сохранением даты последней модификации?
Мы сначала хотели создать обычный коробочный «стэндэлон» софт, потом, немного подумав, решили сделать толстый клиент — сервер, еще немного браузер — веб-сервер, затем взять на себя хостинг веб-сервера и его администрирование и брать абонентскую плату, ане единоразовую, ну а я потом узнал на хабре, что это называется SaaS :) (то есть я знал, что гугдокс, например, это саас, но к нашему приложению не относил). Можете считать, что сервис это хостинг, администрирование и поддержка, ну а разработка как бы бесплатная
Согласен с формулировкой. Да, за обслуживание системы можно платить… А можно не платить и обслуживать самим.

И? Как это сделать?

Вот ещё одна дырка в модели SaaS. Если вы предоставляете сервис по обслуживанию ПО, то почему другие не могут использовать ваше ПО так, как хотят? (оставим в стороне копирастические бредни, я про обсуждаемый принцип).

А для меня, например, при выборе решения, бывает очень важно посмотреть на софт изнутри. Речь даже не про сырцы, а про то, насколько софт грамотно написан (обычно это можно заметить ещё на этапе установки или начального конфигурирования).

SaaS же это всё скрывает и я не могу сказать насколько грамотно спланировано приложение (может, у вас всё с консоли разработчика запускается, потому что программист так и не освоил премудрости runlevel'ов в юниксе? А я и не такие кривые костыли видел.)
В нашем конкретном случае мы предполагаем две модели продаж — SaaS и «коробочный» сервер (то же ядро, но без биллинга и прочих сервисных вещей, причём ядро скорее всего с сорцами, но не свободное). Документация по установке и конфигурированию будет в паблике (скорее всего будет предполагаться, что установить и настроить веб-сервер и СУБД пользователь сможет сам, в крайнем случае на примере debian или ubuntu эти процессы будут описаны в стиле howto и copypaste). Цена сервера будет раз в 100 больше цены месячного обслуживания (что тем не менее раза в 3 меньше цены основных «коробочных» конкурентов)

И, кстати, модель SaaS не так уж нова. Лично я ей пользуюсь лет 10 — называется «виртуальный хостинг»/«виртуальный сервер» ;)
Виртуальный хостинг — не SaaS. Если говорить «модными» словами — то, скорее уж, PaaS. ;))
А выделенный сервер, пускай и виртуальный — IaaS? ;) Различия между SaaS, PaaS и IaaS (в «бытовом» смысле, как называют «AJAX» решения в которых нет, как минимум, Х, а то и J :) ) то ли надуманные, то ли зависят от того с чьей колокольни смотреть, в общем слишком абстрактны, по-моему, а определения из разных источников разнятся. Некоторые считают, что в *aaS использование облачных технологий необходимо по определению, а некоторые видят в них только модель продаж, не заморачиваясь с технологиями реализации.
Вообще в россии мне кажется у SaaS есть две большие проблемы, которые взаимосвязанны друг с дургом:
1. Пиратское ПО
2. Тяжелая обучаемость новым интерфейсам
Распишу все на примере обычных пользователей: Пользователи привыкли использовать программы бесплатно, причем программы которые в рельности они используют на 5-10% от общего функционала, при это когда ему предлагают альтернативу которая возможно подходит ему под его конкретные задачи на 100% у пользователя возникает проблема что интерфейс этой программы отличается от того интерфейса который, он привык использовать годами, а когда ему говорят что это еще и платно, хоть и стоит копейки, выбор делаеться в пользу пиратского ПО.
Имеено поэтмоу в России и получаеться замкнутый круг Производителям выгоднее предоставлять услугу как SaaS, но в россии скорее всгео спрос будет довльно низкий и конкурировать с декстопными приложениями она не сможет. Как мне кажеться лучший вариант выпускать в двух вариантах свой продукт, как сейчас начинает делать ABBYY.
Я, например, пользуюсь лицензией, но всегда при возможности выбора предпочту десктопное приложение саасу. Нервы дороже.
Если не секрет на какии програмные продукты пользуетесь лицензией? Я думаю таких как вы единицы!
SaaS как раз позволяет решить 1-ю проблему. Если приложение физически работает на сервере, то и пиратить тут невозможно.
А насчет новых интерфейсов — это сильно зависит от подхода к SaaS. Елси для софта пишется новая web «морда» — то это неудобно. Мы в своем проекте доставляем обычный интерфейс не требуя никакой доработки или переделки.

Наличие «ломанных» и пиратских версий позволяет разработчикам «проникать» к пользователями подсаживать их на свои решени. Посмотрите на 1С — она защищенна ключами HASP, которые при правильном использовании обойти невозможно. 1С использует старые модели ключей, для которых есть эмуляторы и все об этом знают, но никто не торопится исправлять ситуацию. Такое положение позволяет «подсадить» новых пользователей на ломанное ПО и затем перетянуть их на лицензию теми или иными способами.
«Если приложение физически работает на сервере, то и пиратить тут невозможно» — ошибаетесь. Вспомните хотя бы «левые» сервера WoW.
Сравнение несколько неверное, так как WOW без толстого клиента не работает в принципе, а сервер сам по себе не так уж и сложен, по этому данное сравнение не уместно. Говорю как игрок WOW…
Ну, боюсь, что первый пункт относится больше к физ. лицам. Юрики как-то более менее стараются брать лицензию, а если дорого, то готовы смотреть в сторону облачных сервисов, например, тот же виртуальный колл-центр.
Only those users with full accounts are able to leave comments. Log in, please.