Иван Волченсков, управляющий директор, Рентсофт (RentSoft)
Национальный Институт стандартов и технологий (NIST, США) сформулировал следующее определение облачных вычислений. Это модель обеспечения повсеместного и удобного сетевого доступа по требованию к общему пулу конфигурируемых вычислительных ресурсов (например, сетям передачи данных, серверам, устройствам хранения данных, приложениям и сервисам), которые могут быть оперативно предоставлены и освобождены с минимальными эксплуатационными затратами и обращениями к провайдеру услуг (сервис-провайдеру).
Стоит обратить внимание на часть определения, которая гласит, что эксплуатационные затраты и количество обращений к провайдеру в рамках заказа и всего последующего жизненного цикла услуги должны быть минимальны. Таким образом, можно сделать вывод, что обязательным атрибутом современного провайдера облачных услуг являются инструменты автоматизации предоставления облачных ресурсов конечному пользователю. С помощью этих инструментов конечный пользователь должен иметь возможность в режиме реального времени, без необходимости вступать в контакт с сотрудниками сервис-провайдера, приобретать, пользоваться и управлять своими виртуальными ресурсами.
Конечно, цепочка продаж (все, с чем клиент сталкивается от первого обращения до покупки) у разных сервис-провайдеров для разных типов клиентов может быть разной. Например, для крупных корпоративных клиентов в цепочке продаж среди прочего важно предусмотреть общение с менеджером по продажам и техническим консультантом, а в цепочке продаж для клиента из SMB или SOHO (низкие средний счет и маржинальность) такой необходимости нет. Для этих сегментов более важно, чтобы количество действий на сайте и время от начала заказа до момента получения виртуальных ресурсов были минимальными. Но это просто различия в цепочках продаж, которые должны быть учтены в процессе построения и настройки программного комплекса.
Кстати, автоматизация продажи облачных сервисов важна не только для публичного облака. Существуют компании, которые в рамках своего частного облака организуют автоматизацию продаж вычислительных ресурсов внутренним заказчикам, т. е. своим внутренним подразделениям либо компаниям из той же группы, которые в своей работе используют облачные сервисы или облачные ресурсы. Подобная схема позволяет добавить прозрачности в компании с точки зрения затрат и доходов, а также еще на один шаг приблизиться к полноценной реализации парадигмы «ИT как сервис».
Безусловно, при проектировании облачного сервиса не стоит полагаться только на определение NIST, надо учитывать и запросы конечных пользователей, которые уже привыкли к тому, что тот или иной товар либо услуга в Интернете находится от них на расстоянии нескольких кликов.
Платформа автоматизации продаж облачных сервисов
Одним из элементов программного комплекса сервис-провайдера, обеспечивающего такую возможность конечным пользователям, является биллинг.
Если у нескольких людей спросить, что такое биллинг и какую функцию он выполняет, то, скорее всего, мы получим самые различные ответы. Дело в том, что словом «биллинг» зачастую называют комплексные системы автоматизации продаж товаров и услуг с элементами системы управления предприятием. На самом же деле, базовая функция биллинга – это способность рассчитать стоимость приобретаемой конечным пользователем услуги, исходя из набора входящей информации, и списать ее со счета пользователя. Например, входящей информации для биллинга могут служить: дата начала расчетного периода, стоимость услуги, объем потребления за расчетный период, действующие маркетинговые акции и др.
Хотя данная функция и является базовой для биллинга, ее недостаточно для автоматизации процесса продаж. В идеале необходимо автоматизировать всю цепочку, а не только процедуру расчета стоимости услуги и списание ее со счета пользователя. Эта автоматизация может быть выполнена как одним единым продуктом, так и интегрированным комплексом специализированных продуктов, каждый из которых является либо лучшим в своем классе, либо оптимально подходит для решения данной конкретной задачи. У каждого варианта есть свои плюсы и минусы, которые следует учитывать при выборе инструментов автоматизации.
Единый продукт для полной автоматизации
Чем хороши продукты, которые способны автоматизировать если и не всю цепочку продаж облачных сервисов, то ее существенную часть? Ответ прост: чем меньше продуктов от разных вендоров используется в системе, тем проще настройка, эксплуатация и поддержка данной системы. Как правило, разработкой такого продукта занимается одна компания, которая имеет единый план развития платформы, распространяющийся на все ее составляющие. Это должно обеспечивать скоординированные действия при разработке платформы, отсутствие дублирующих функций, гармоничное развитие всех частей платформы, сквозную поддержку нового функционала во всех требуемых элементах платформы. Заказчик всегда может обратиться в службу поддержки такого разработчика с любым вопросом относительно функционала системы без риска получить ответ, что данный вопрос находится вне компетенции данной платформы и данного разработчика. Особенностью единых систем является тот факт, что если рассматривать единую систему как набор отдельных продуктов и сравнивать их с имеющимися на рынке соответствующими специализированными продуктами, выполняющими только аналогичные функции, то, скорее всего, специализированные продукты будут выигрывать в сравнении с соответствующими частями единого продукта. Например, если единый продукт обладает модулем автоматизации работы службы поддержки пользователей, то сравнение возможностей данного модуля с имеющимся на рынке специализированным продуктом для автоматизации службы поддержки, скорее всего, выявит преимущество специализированного продукта. Причина в том, что разработчик единого продукта должен охватить имеющимися у него ресурсами все части продукта сразу, и если продукт комплексный, то придется потратить немало времени и ресурсов на каждый его элемент. Разработчики специализированных продуктов концентрируются на одной области, пытаясь довести свой продукт до совершенства в сравнении с конкурентами. При этом недостатки отдельных частей единого продукта в сравнении со специализированными продуктами могут и должны компенсироваться способностью единого продукта решать конкретную задачу автоматизации продаж облачных сервисов в целом.
Интегрированный комплекс специализированных продуктов
Вариант построения системы из набора специализированных продуктов кажется более привлекательным, поскольку при проектировании системы есть возможность выбрать лучшие специализированные продукты для решения конкретных задач. Однако при интеграции и эксплуатации таких систем может возникнуть немало проблем: программные продукты разрабатываются разными компаниями без синхронизированных планов развития, интеграция может быть затруднена, а где-то и невозможна, из-за отсутствия согласованных программных интерфейсов нет единой службы поддержки, функционал может дублироваться и быть избыточным для решения конкретной задачи автоматизации продаж облачных сервисов. Но на самом деле не все так печально. На рынке существует практика партнерства между разработчиками программных продуктов. Путем объединения усилий, интеграции между своими продуктами и синхронизации планов развития они могут принести дополнительную ценность своим заказчикам, предложив им объединенный функционал двух систем, каждая из которых будет выполнять свою задачу максимально эффективно. В некоторых случаях разработчики одной системы могут оказывать поддержку не только в рамках своего программного продукта, но и по продуктам тех компаний, с которыми у них есть партнерские отношения и официально поддерживаемая интеграция.
Особенность биллинга облачных услуг
В любом случае, будь то единый продукт для автоматизации всей цепочки продаж или набор интегрированных продуктов, если мы говорим о продажах облачных сервисов, то обязательным элементом таких систем автоматизации является биллинг.
Функционал биллинга, используемого для продаж облачных сервисов, должен удовлетворять несколько требований, которые позволяют облачному сервис-провайдеру конкурентным образом оказывать свои услуги конечным пользователям.
Стандартными операциями для периодического биллинга являются, например, ежемесячные списания за фиксированный объем ресурсов, предоставляемых пользователю в аренду, возможность предоставить услугу по предоплате или постоплате либо в тестовый период (бесплатно на определенный промежуток времени) и дать скидку на пару месяцев. Однако современный облачный сервис-провайдер должен иметь возможность предложить услугу своему конечному пользователю по схеме оплаты за объем использованных ресурсов. Это более сложная логика расчетов, требующая дополнительных ресурсов, учтенных при проектировании биллинговой платформы.
Оплата услуг по фактическому потреблению более интересна конечному пользователю, так как ему становятся доступны мощные вычислительные ресурсы и существенные объемы места для хранения информации не по предварительной оплате, когда он еще не знает, сколько именно ресурсов и когда понадобится, а по результатам их потребления и именно за тот объем, который реально был использован.
Какому пользователю может быть интересная такая схема оплаты?
Например, пользователь – это разработчик сервиса, который позволяет своим клиентам осуществлять расчет 3D-графики или результатов видеомонтажа. Данные операции являются очень ресурсоемкими, и разработчику сервиса для обеспечения высокого качества предоставления своих услуг приходится оказывать их на мощных серверах. Но мощные серверы дорого стоят, если арендовать их на базе ежемесячных платежей за фиксированный объем ресурсов. А что, если количество клиентов в этом месяце будет меньше запланированного? Тогда впустую будут потрачены средства на оплату неиспользованных ресурсов. Гораздо интересней иметь столько ресурсов, сколько нужно, но оплату за их них производить по результатам их использования. Скажем, за день сервисом воспользовались десять клиентов, каждый из которых оплатил и использовал определенный (различный) объем ресурсов. Тогда получится, что разработчик данного сервиса окажет услугу своим пользователям, используя мощные вычислительные ресурсы, при этом заплатит за них ровно в том объеме, в котором они были использованы его клиентами.
Или, например, пользователь – средняя компания, которая решила для внутренних нужд использовать виртуальные ресурсы, предоставляемые дата-центром. Тогда она может установить некоторые лимиты, в рамках которых ее сотрудники смогут пользоваться виртуальными ресурсами дата-центра, а оплата будет производиться по факту использования ресурсов.
Данная модель оплаты предъявляет определенные требования к биллингу по учету проведения маркетинговых акций. Биллинг должен иметь возможность для предоставления преференций пользователю с учетом объема использованных им ресурсов. Например, акция может выглядеть следующим образом: 5%-ная скидка предоставляется всем, кто использовал выделенный ресурс CPU более чем на половину.
Еще одна особенность биллинга для публичного облака – возможность определять периодичность расчета стоимости использованных ресурсов. Если для крупных компаний достаточно производить такой расчет, например, один раз в месяц, то для небольших организаций оптимален режим, приближенный к реальному времени, например один раз в пять минут или раз в минуту.
Какая система биллинга лучше?
Простого ответа на этот вопрос не существует. Каждый сервис-провайдер имеет свои бизнес-стратегию, план развития сервиса, способы продвижения продукта и работает в определенной конкурентной среде. Чтобы быть успешнее конкурентов, необходимо иметь возможность реализовывать свои текущие планы, быть гибким в возможностях их модификации, а система автоматизации продаж облачных сервисов не должна быть препятствием для их реализации. Правильный биллинг должен решать маркетинговые задачи, а не поддерживать технологические ограничения.
Так что же нужно сделать, чтобы понять, какую систему или комплекс систем следует приобрести? Необходимо подробно изучить системы, имеющиеся на рынке, понять, какой функционал они предоставляют, какие процессы автоматизируют, насколько гибко может настраиваться система без привлечения разработчиков, какие варианты тарификации сервисов поддерживает система, какие цепочки продаж можно выстраивать, используя данную систему, насколько система отвечает требованиям, которые уже сформированы у сервис-провайдера, где именно уже используется система и сколько она стоит.
На российском рынке сегодня представлено немало биллинговых и хостинговых систем, которые стоит рассмотреть в процессе выбора, – Hostbill, Flexiant, WHMCS, eVapt, onApp, Zuora, Aria, Chargify, но наиболее активно представлены системы автоматизации продаж облачных сервисов от компаний RentSoft и Paralles. В предложении этих компаний не только функционал своих систем, но и набор реализованных интеграций с продуктами партнерских компаний, которые добавляют ценный функционал в общую систему. Например, продукт компании RentSoft, помимо прочего, интегрирован с такими системами, как IBM SmartCloud Orchestrator, Cisco UCS Director и HP Cloud Service Automation, которые обеспечивают мощный слой автоматизации управления облачными ресурсами.
Таким образом, процесс выбора – это довольно длительный и трудоемкий путь, который следует пройти всем сервис-провайдерам, планирующим предоставлять своим клиентам облачные сервисы.
