Будущее SaaS: кастомизация, маркетплейсы дополнений, PaaS

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

Почему технологии SaaS быстро развиваются

Ведущий: Какое будущее у SaaS? Что будет после?

Александр:

Важным препятствием для развития SaaS был интернет: его доступность, надежность, скорость и прочее. Сейчас все развивается, появился 4G, дальше будет 5G. Практически в любой квартире несколько провайдеров, а интернет становится такой инфраструктурной штукой, как электричество. То есть отключение интернета — это, скорее, форс-мажор.

Сегодня так работают игры и стриминг — не нужно обсчитывать тяжелые графические операции, вместо этого просто передаешь видеопоток на текущих скоростях. Это направление развивают NVIDIA и Google, скоро оно придет во все сферы.

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

Илья:

Да. Пока для меня SaaS связан, в первую очередь, с браузером и мобильным приложением. А дальше появятся девайсы для дополненной реальности и другие, которые сильнее встроены в жизнь человека. Например, те же очки — как раз следующий шаг. Или приложения, которые автоматически обслуживают сервисы, исходя из контекста.

Устройства ввода стали беспроводными, интернет доступен, теперь можно и передавать видео, и обрабатывать онлайн огромное количество внешней информации. Это открывает огромные возможности.

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

SaaS и коробочные сервисы: особенности разработки

Александр:

Обобщенно — при разработке SaaS больше ответственности. Исходя из самой концепции SaaS, нужно сразу разрабатывать сервисы с готовностью масштабироваться.

Рассмотрим на примере. До 2012 года мы разрабатывали софт — CMS и корпоративные порталы, которые были исключительно коробочными. Мы отдавали клиенту решение, он ставил его себе. Сколько он добавил сервисных мощностей, столько софта и работает.

В 2012 году мы запустили SaaS «Битрикс24» и поняли, что клиенты могут импортировать больше данных, чем мы рассчитывали. Также самих клиентов может прийти больше, чем мы рассчитывали, например, после акции.

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

Илья:

Мультитенантность SaaS, то есть возможность изолированно обслуживать независимых пользователей в рамках одного сервиса, тоже меняет парадигму разработки.

Когда одно приложение запускается над данными одного клиента — это один подход. Второй подход — когда один инстанс обрабатывает сотни клиентов, данные идут через один API, который должен правильно их разделять с точки зрения того, к кому они должны прийти, безопасности, гарантированно предотвращать смешивание.

Этот подход усложняет проектирование. Я сталкивался с ситуациями, когда перевод на мультитенантность убивал производительность софта.

Мультитенантность нужно закладывать изначально. Сложно немультитенантную систему сделать мультитенантной, не переписывая полностью.

Александр:

Нам пришлось вносить изменения в отношении возможностей сервиса: устойчивость, масштабируемость, запуск на разных инстансах с резервированием, возможности выноса статических данных в объектное хранилище, переключения и резервирования.

У нас есть SaaS, но остались коробочные продукты, которые пользователи могут поставить себе. Чтобы не разрабатывать два разных продукта, мы делаем их на одном ядре, на одной платформе.

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

Как SaaS-сервисы конкурируют с коробочными версиями

Ведущий: Вы планируете перейти на SaaS полностью, отказаться от коробочной версии?

Александр:

Нет, наличие «коробки» — огромный плюс для клиентов! Даже если они не планируют переехать на коробочную версию, они понимают, что всегда могут это сделать. Так мы закрываем большое количество страхов при использовании сервиса. Клиент знает, что у него есть выбор.

У нас софт в виде открытого ПО, его можно дописывать, дополнять новыми модулями и интеграциями. Те, у кого есть такая потребность, берут «коробку» и используют ее для своих целей.

Илья:

Да, у SaaS проблема с кастомизацией, из-за которой сложно полностью отказаться от коробочных версий. SaaS — это программа, которая дает CRM или другое приложение, написанное по одному на всех алгоритму. И это сложно кастомизировать. Вся ценность модели в том, что одно и то же масштабируется на всех, поэтому это выгодно и дешево. Если сервис кастомизировать каждому клиенту, модель SaaS рушится, экономика перестает сходиться.

Будущее — за кастомизированными SaaS

Илья:

Будущее за тем, чтобы сделать SaaS, которые могут кастомизироваться под пользователя с любой сложностью сценариев. Сейчас так: хочешь кастом — неси к себе, дорабатывай, это будет только твое.

А можно сделать облачный сервис, как Salesforce, который стал конструктором сервисов SaaS. Он решает сложные задачи по модели доступа, безопасности, масштабируемости. В плане детальности кастомизации в будущем все будет так, словно это софт on-premise.

Сейчас вопрос решается модулями, аддонами, с помощью которых можно что-то менять. Причем вендор SaaS пытается угадать, где в сервисе клиентам может понадобиться кастомизация, и в этих отдельных точках открывает возможность добавлять аддоны. Но, видимо, скоро парадигма разработки станет такой, что аддоны можно будет крепить на любое место SaaS.

Александр:

Вспомним о концепции API-first. Когда сервис разрабатывает новую фичу или продукт, все отталкивается от API. Возьмем «Битрикс24», какие в нем есть функциональности: задачи, CRM, в задачах есть ответственный исполнитель, в CRM есть лиды, сделки и так далее. Если каждую новую сущность разрабатывать с возможностью работы через API, это и будет движение к тому самому будущему.

Я знаю, что так Amazon запускал многие веб-сервисы. У них возможность управления появлялась сначала в API и консоли, только потом — в веб-интерфейсе.

Развитие SaaS: внутренние маркетплейсы дополнений

Илья:

При использовании API получается, что IT-экспертиза выносится на клиента, который пользуется сервисом. Если в «Битрикс24» клиенту нужно получить API, значит, кто-то должен быть технически грамотным, чтобы потом реализовать свои функции над API.

Александр:

Здесь две возможности. У конечного клиента, если он технически грамотен, есть специалист, который может изучить API, затем на нем сделать нужные дополнения.

Есть разработчики, которые делают свои решения и размещают в маркетплейсе дополнений для «Битрикс24». Они предлагают эти решения клиентам платно или бесплатно, ориентируясь на то, что они дальше окажут услуги консалтинга и сделают допродажу своих услуг.

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

Чтобы эта модель хорошо работала просто делаешь API, делаешь маркетплейс и даешь возможности по расширению.

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

Илья:

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

Будущее с API first и PaaS

Александр:

Как раз про API first. Сейчас в центре разработки продукт: сначала появляется он, потом к нему открывают API для разработчиков, добавляют новые методы, сущности и так далее. Но если фантазировать, в новой парадигме сначала открывают API всем разработчикам, а потом сами строят свой продукт на своем открытом API.

Илья:

Но как эту бизнес-модель продавать? Предположим, я без готового продукта создал API для какой-то предметной области, на котором дальше кто угодно может строить продукты. С точки зрения пиара, я должен иметь доступ к какому-то сообществу разработчиков, которые начнут креативить на основе моего API. Это, наверное, может позволить себе Google. А если ты ― неизвестный стартап, никто в такое ввязываться не будет.

Ведущий: Возможно, API станут какими-то общими стандартами, когда ты выбираешь из уже существующих и адаптируешь под себя. Как это было с графическими движками. Во времена моей юности каждая компьютерная игра писала для себя графический движок. Был Unreal Engine, у Quake был квековый движок. Сейчас движков, которые все используют, — два, их берут и дорабатывают. С API, возможно, будет также. Разработчики не будут заниматься этой рутиной, а возьмут готовое решение и смогут креативить.

Илья:

Да, будут большие репозитории API. Технологическая часть будет закрыта, можно креативить, приземлять проблему пользователя в готовый элемент автоматизации, с помощью которого получится что-то оптимизировать или привнести. И такую же ценность для разработки дают PaaSы (platform as a service), которые мы очень любим, потому что сами их создаем на VK.

PaaS — это как раз будущее. Вся практика создания инфраструктур сходится к тому, что нужны платформы, так как в них сконцентрировано огромное количество экспертизы и опыта, они уже созданы. Дальше их можно использовать под конкретные задачи. В целом идея с платформами сейчас максимально развивается в IT.

Александр:

Платформы дают возможность быстро и много экспериментировать. Когда возникает идея нового продукта или сервиса, не нужно с нуля тратить много времени, сил, разработки и денег, чтобы получить MVP (минимально жизнеспособный продукт) для проверки гипотезы: взлетает продукт или нет.

В зависимости от сложности: за считанные дни, недели, месяцы, можно запускать прототипы и смотреть дальше — идет оно или нет.

Что ждет SaaS в будущем?

1. SaaS сосуществует с коробочными версиями. С софтом по коробочной лицензии клиент понимает, что у него есть возможность выбора. Иногда выбор коробочного решения обусловлен политикой безопасности или потребностями бизнеса.
2. Будущее в том, чтобы сделать SaaS, которые могут кастомизироваться под пользователя без лишней доработки. Может быть, появятся облачные сервисы — конструкторы SaaS.
3. Модель маркетплейса позволяет вендору SaaS построить партнёрскую экосистему разарботки и закрыть своим сервисом гораздо больше потребностей пользователей. К разработке привлекаются партнеры, которые создают дополнения к основному SaaS-сервису для более нишевых пользователей. Для этого вендору нужно сделать API, создать маркетплейс и пригласить партнёров.
4. Будущее за PaaS. Пользователи PaaS получают от вендора в сконцентрированном виде огромное количество экспертизы и опыта.