Serverless CPaaS – как Voximplant предвосхитил этот хайп

В этом году мы переводили добротную статью ^[1] про концепцию Serverless: автор показывал «на пальцах», что это такое и зачем. А еще мы знаем и помним, что наши евпропейские партнеры давно окрестили нашу платформу как Serverless CPaaS ^[2] – чтобы явным образом подтвердить это, наш CEO Алексей Айларов выступил 16 октября на конференции API Days ^[3] в Амстердаме. Алексей рассказал, почему Serverless CPaaS скоро будет повсеместным и как получилось, что Voximplant – внезапно – с самого начала олицетворял этот подход. Под катом вас ждет текстовая адаптация выступления, выдержки из презентации прилагаются. Welcome!

Раньше было лучше (с)

До CPaaS бизнес был вынужден проделывать огромную подготовительную работу: для начала надо было выбрать телеком-оператора. Затем следовало выбрать бэкенд и создать инфраструктуру под всё это (например, взять программную АТС Asterisk/FreeSWITCH и напильник). В помощь этой АТС также поднять бэкенд на условном node.js… И уже только после этого решить, где и как будет имплементирована бизнес-логика, а потом ее задеплоить, настроить мониторинг и следить, чтобы это всё не рушилось в процессе работы. На запуск готового решения могло уходить по полгода или больше.

CPaaS дал возможность пропустить низкоуровневые шаги и сразу приступить к бизнес-логике: для этого клиенту надо было изучить коммуникационную платформу, а далее… инфраструктура, деплой, мониторинг. С одной стороны, уже не надо думать, какой будет бэкенд и искать телеком-оператора. За счет этого время запуска уменьшается без потери качества. С другой стороны, предстоит сделать еще многое на своей стороне.

Приветствуем Serverless

А потом случился Serverless. И вот тут надо заострить внимание на ключевом моменте – почему less? Вычисления же должны где-то выполняться.

Serverless означает не отсутствие серверов вообще, а их отсутствие на стороне клиента.

Концепция подразумевает связку compute provider + devops на стороне клиента. Клиенту не нужно содержать собственную инфраструктуру, ему достаточно платить compute provider'у за… вычисления :) То есть расходы есть только тогда, когда есть необходимость вычислений – это гораздо выгоднее, чем, к примеру, оплачивать аренду серверов 24/7 когда нет реальной потребности использовать эти серверы 24/7. Отсутствие инфраструктуры ведет ко второму важному плюсу подхода: можно не думать о масштабируемости, т.к. провайдер обеспечивает автомасштабирование.

Для девопс чаще всего берут serverless-фреймворк (например, Fn Project ^[4] или serverless ^[5] – oh, irony), который упрощает разработку и сборку приложений. Также фреймворк может дать ручки для ивентов; это удобно, потому что serverless это как раз event-based концепция (примеры из телефонии: пришел звонок — это ивент, ответили на звонок – это ивент и т.д.).

Добаляем фичи Serverless к CPaaS и получаем условный Voximplant. В итоге исчезает шаг «инфраструктура» – бизнес изучает конкретный Serverless CPaaS, реализует на нем бизнес-логику и спокойно мониторит, как это всё работает, не заботясь о покупке стоек, серверов, поиске помещения под серверную и т.д. Конечно, это идеальный случай и каждое решение уникально: не исключено, что клиенту может понадобится какое-то железо на своей стороне, но Serverless всячески способствует тому, чтобы у клиентов таких нужд не было.

Улучшаем пользовательский опыт

Иногда Serverless-платформы делают т.н. Functions – это посредники между клиентом и прочими сервисами (концепция FaaS ^[6]). Например, Functions можно поручить принимать HTTP-запросы и отдавать ответ, либо взаимодействовать по HTTP со сторонними сервисами. Здесь же могут обрабатываться вебхуки и телеком-специфичные взаимодействия.

Однако у такой прослойки есть ограничения:

• ограниченное время выполнения;
• неизменяемый контекст (stateless);
• обработка звонков оторвана от рантайма платформы, потому что коммуникация идет по HTTP.

Архитектура Voximplant с самого начала делала рантайм доступным для клиентов, поэтому управление звонками происходит с помощью JS-сценариев, а не сухо по HTTP. Интегрированный рантайм дает ряд преимуществ:

• облачные JS-сценарии поддерживают последний стандарт языка – ECMA2018;
• в сценариях используется нативный API платформы ^[7];
• управление в реальном времени: обработка событий и выполнение функций происходят мгновенно;
• можно пользоваться отладчиком с остановом и state’ами;
• на обработку ошибок можно навешать что угодно, включая голосовое оповещения для человека. Пример event-based обработки ошибки:

  function onHttpRequestFailed() {
    call.say(“Unfortunately, we couldn’t process your request, please try again later”, Language.US_ENGLISH_FEMALE)
    call.addEventListener(CallEvents.PlaybackFinished,(e) => {
      if (destroy) VoxEngine.terminate()
      else tryAgain()
    })
  }

Event-based особенно важен, потому что а) это унифицированный подход б) добавляет гибкость. Любое действие можно трактовать как событие и обработать его в облачном JS-сценарии: ответить на входящий звонок синтезом голоса, распознать голосовую почту и положить трубку, прокинуть звонок на SIP, стриггерить push-уведомление и т.д.

В итоге наша Serverless-платформа снижает задержки (latency), улучшает пользовательский опыт и, в конечном счете, максимально сокращает время запуска готового продукта: если в «доCPaaS’ную эпоху» это могло быть полгода, то с Voximplant можно уложиться в 1 месяц ^[8] (включая все согласования и встречи, непосредственное время разработки еще меньше).

Будущее

Коммуникационные платформы на принципе Serverless будут все более востребованы, потому что спрос на эти услуги растет, равно как и расширяется функциональность самих платформ. Скоро Serverless CPaaS смогут предложить хранение данных, глубокую интеграцию с внешними системами (хороший пример – наш Dialogflow Connector ^[9]), функциональность веб-сервера, наконец :) Перспективы радужные, остается только следить за реализацией и радоваться прогрессу концепции Serverless.

Автор: AlikGold

Источник ^[10]