В этом году мы переводили добротную статью про концепцию Serverless: автор показывал «на пальцах», что это такое и зачем. А еще мы знаем и помним, что наши евпропейские партнеры давно окрестили нашу платформу как Serverless CPaaS – чтобы явным образом подтвердить это, наш CEO Алексей Айларов выступил 16 октября на конференции API Days в Амстердаме. Алексей рассказал, почему Serverless CPaaS скоро будет повсеместным и как получилось, что Voximplant – внезапно – с самого начала олицетворял этот подход. Под катом вас ждет текстовая адаптация выступления, выдержки из презентации прилагаются. Welcome!
До CPaaS бизнес был вынужден проделывать огромную подготовительную работу: для начала надо было выбрать телеком-оператора. Затем следовало выбрать бэкенд и создать инфраструктуру под всё это (например, взять программную АТС Asterisk/FreeSWITCH и напильник). В помощь этой АТС также поднять бэкенд на условном node.js… И уже только после этого решить, где и как будет имплементирована бизнес-логика, а потом ее задеплоить, настроить мониторинг и следить, чтобы это всё не рушилось в процессе работы. На запуск готового решения могло уходить по полгода или больше.
CPaaS дал возможность пропустить низкоуровневые шаги и сразу приступить к бизнес-логике: для этого клиенту надо было изучить коммуникационную платформу, а далее… инфраструктура, деплой, мониторинг. С одной стороны, уже не надо думать, какой будет бэкенд и искать телеком-оператора. За счет этого время запуска уменьшается без потери качества. С другой стороны, предстоит сделать еще многое на своей стороне.
А потом случился Serverless. И вот тут надо заострить внимание на ключевом моменте – почему less? Вычисления же должны где-то выполняться.
Для девопс чаще всего берут serverless-фреймворк (например, Fn Project или serverless – oh, irony), который упрощает разработку и сборку приложений. Также фреймворк может дать ручки для ивентов; это удобно, потому что serverless это как раз event-based концепция (примеры из телефонии: пришел звонок — это ивент, ответили на звонок – это ивент и т.д.).
Добавляем фичи Serverless к CPaaS и получаем условный Voximplant. В итоге исчезает шаг «инфраструктура» – бизнес изучает конкретный Serverless CPaaS, реализует на нем бизнес-логику и спокойно мониторит, как это всё работает, не заботясь о покупке стоек, серверов, поиске помещения под серверную и т.д. Конечно, это идеальный случай и каждое решение уникально: не исключено, что клиенту может понадобится какое-то железо на своей стороне, но Serverless всячески способствует тому, чтобы у клиентов таких нужд не было.
Иногда Serverless-платформы делают т.н. Functions – это посредники между клиентом и прочими сервисами (концепция FaaS). Например, Functions можно поручить принимать HTTP-запросы и отдавать ответ, либо взаимодействовать по HTTP со сторонними сервисами. Здесь же могут обрабатываться вебхуки и телеком-специфичные взаимодействия.
Однако у такой прослойки есть ограничения:
Архитектура Voximplant с самого начала делала рантайм доступным для клиентов, поэтому управление звонками происходит с помощью JS-сценариев, а не сухо по HTTP. Интегрированный рантайм дает ряд преимуществ:
Event-based особенно важен, потому что а) это унифицированный подход б) добавляет гибкость. Любое действие можно трактовать как событие и обработать его в облачном JS-сценарии: ответить на входящий звонок синтезом голоса, распознать голосовую почту и положить трубку, прокинуть звонок на SIP, стриггерить push-уведомление и т.д.
В итоге наша Serverless-платформа снижает задержки (latency), улучшает пользовательский опыт и, в конечном счете, максимально сокращает время запуска готового продукта: если в «доCPaaS’ную эпоху» это могло быть полгода, то с Voximplant можно уложиться в 1 месяц (включая все согласования и встречи, непосредственное время разработки еще меньше).
Коммуникационные платформы на принципе Serverless будут все более востребованы, потому что спрос на эти услуги растет, равно как и расширяется функциональность самих платформ. Скоро Serverless CPaaS смогут предложить хранение данных, глубокую интеграцию с внешними системами (хороший пример – наш Dialogflow Connector), функциональность веб-сервера, наконец :) Перспективы радужные, остается только следить за реализацией и радоваться прогрессу концепции Serverless.
Раньше было лучше (с)
До CPaaS бизнес был вынужден проделывать огромную подготовительную работу: для начала надо было выбрать телеком-оператора. Затем следовало выбрать бэкенд и создать инфраструктуру под всё это (например, взять программную АТС Asterisk/FreeSWITCH и напильник). В помощь этой АТС также поднять бэкенд на условном node.js… И уже только после этого решить, где и как будет имплементирована бизнес-логика, а потом ее задеплоить, настроить мониторинг и следить, чтобы это всё не рушилось в процессе работы. На запуск готового решения могло уходить по полгода или больше.
CPaaS дал возможность пропустить низкоуровневые шаги и сразу приступить к бизнес-логике: для этого клиенту надо было изучить коммуникационную платформу, а далее… инфраструктура, деплой, мониторинг. С одной стороны, уже не надо думать, какой будет бэкенд и искать телеком-оператора. За счет этого время запуска уменьшается без потери качества. С другой стороны, предстоит сделать еще многое на своей стороне.
Приветствуем Serverless
А потом случился Serverless. И вот тут надо заострить внимание на ключевом моменте – почему less? Вычисления же должны где-то выполняться.
Serverless означает не отсутствие серверов вообще, а их отсутствие на стороне клиента.Концепция подразумевает связку compute provider + devops на стороне клиента. Клиенту не нужно содержать собственную инфраструктуру, ему достаточно платить compute provider'у за… вычисления :) То есть расходы есть только тогда, когда есть необходимость вычислений – это гораздо выгоднее, чем, к примеру, оплачивать аренду серверов 24/7 когда нет реальной потребности использовать эти серверы 24/7. Отсутствие инфраструктуры ведет ко второму важному плюсу подхода: можно не думать о масштабируемости, т.к. провайдер обеспечивает автомасштабирование.
Для девопс чаще всего берут serverless-фреймворк (например, Fn Project или serverless – oh, irony), который упрощает разработку и сборку приложений. Также фреймворк может дать ручки для ивентов; это удобно, потому что serverless это как раз event-based концепция (примеры из телефонии: пришел звонок — это ивент, ответили на звонок – это ивент и т.д.).
Добавляем фичи Serverless к CPaaS и получаем условный Voximplant. В итоге исчезает шаг «инфраструктура» – бизнес изучает конкретный Serverless CPaaS, реализует на нем бизнес-логику и спокойно мониторит, как это всё работает, не заботясь о покупке стоек, серверов, поиске помещения под серверную и т.д. Конечно, это идеальный случай и каждое решение уникально: не исключено, что клиенту может понадобится какое-то железо на своей стороне, но Serverless всячески способствует тому, чтобы у клиентов таких нужд не было.
Улучшаем пользовательский опыт
Иногда Serverless-платформы делают т.н. Functions – это посредники между клиентом и прочими сервисами (концепция FaaS). Например, Functions можно поручить принимать HTTP-запросы и отдавать ответ, либо взаимодействовать по HTTP со сторонними сервисами. Здесь же могут обрабатываться вебхуки и телеком-специфичные взаимодействия.
Однако у такой прослойки есть ограничения:
- ограниченное время выполнения;
- неизменяемый контекст (stateless);
- обработка звонков оторвана от рантайма платформы, потому что коммуникация идет по HTTP.
Архитектура Voximplant с самого начала делала рантайм доступным для клиентов, поэтому управление звонками происходит с помощью JS-сценариев, а не сухо по HTTP. Интегрированный рантайм дает ряд преимуществ:
- облачные JS-сценарии поддерживают последний стандарт языка – ECMA2018;
- в сценариях используется нативный API платформы;
- управление в реальном времени: обработка событий и выполнение функций происходят мгновенно;
- можно пользоваться отладчиком с остановом и 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 месяц (включая все согласования и встречи, непосредственное время разработки еще меньше).
Будущее
Коммуникационные платформы на принципе Serverless будут все более востребованы, потому что спрос на эти услуги растет, равно как и расширяется функциональность самих платформ. Скоро Serverless CPaaS смогут предложить хранение данных, глубокую интеграцию с внешними системами (хороший пример – наш Dialogflow Connector), функциональность веб-сервера, наконец :) Перспективы радужные, остается только следить за реализацией и радоваться прогрессу концепции Serverless.