Две недели назад мы провели вторую конференцию INTERCOM о голосовых и видео коммуникациях. WebRTC, звонки через браузер, machine learning, big data – вся вот эта популярная история. Одним из приглашенных спикеров был Цахи Левент-Леви, более известный как автор bloggeek.me – ультимативного источника информации о WebRTC в современных браузерах. В докладе (кстати, у меня есть видеозапись) Цахи рассказывал про состояние индустрии и что сейчас можно делать с голосом и видео в браузерах. А вернувшись в Израиль написал интересную статью про «Serverless»-технологии при работе с коммуникационными платформами. Адаптированный для Хабра перевод предлагаю под катом.

Когда я проводил исследования для своего первого отчета о платформах с WebRTC API, одной из изучаемых компаний была Voximplant. Они особо выделяли штуку, которую называли «VoxEngine». Как написано на сайте, это «система, которая выполняет ваш JavaScript-код в облаке Voximplant». Это Serverless.

Идея мне понравилась, но тогда я о ней особо не задумывался. Просто новая интересная штука.

Что такое «Serverless Computing»?

Если вы не следили за эволюцией API, то могли пропустить появление «Serverless». Это подход, при котором код, который вы пишете, выполняется в облаке. Напрямую. Не нужно поднимать OS, виртуалку или контейнер. Пишете код и он выполняется. Магия.

Если посмотреть на «Что-то-там-aaS», то вы можете нагуглить вот такую картинку:

• Если вы используете собственные сервера, то вы отвечаете ЗА ВСЕ
• В случае IaaS, все до операционной системы обеспечивает «кто-то еще». Amazon, Google, Microsoft – ну вы поняли
• Затем PaaS. Все до runtime делают за вас. Вы же беспокоитесь только о данных и приложении. А к runtime подключаетесь с помощью API (по крайней мере, в большинстве случаев)
• SaaS – это когда нам предлагают готовое приложение или сервис. Как программисту нам не о чем заботиться

Как в эту картину вписывается Serverless?


В случае Serverless вы так же разрабатываете приложение, но оно и его данные управляется и поддерживается не вами. Что вы получаете от такого решения?

• Масштабируемость – о ней больше не нужно заботиться. За вас это теперь делает кто-то другой. Вы описали в коде что нужно делать, и теперь это забота платформы выполнять ваш код на нужном количестве серверов.
• Поддержка – меньше кода нужно писать, следовательно, меньше кода нужно поддерживать. По сути вы выкидываете все, что отделяет «staging» код от «production». Ваш прототип уже можно запускать в production.
• Безопасность – если предположить, что вендор PaaS хорошо разбирается в обеспечении безопасности приложений, то у вас одной головной болью становится меньше.
• Время выхода на рынок – меньше кода для написания также означает, что вы можете быстрее показать свое решение пользователям.
• Задержка – так как ваш код выполняется в том же облаке, которое предоставляет API, то задержка между вашими командами и реакцией платформы минимальная. Для кого-то это важно, для кого-то нет – просто еще один факт.

Что мы в результате получаем? Экономию на масштабировании. Вендор, предлагающий PaaS-решение, уже обеспечивает масштабирование, поддержку сервиса и безопасность для вас (и для многих других клиентов). Теоретически он может это делать даже лучше, чем вы сами. Это освобождает ваши ресурсы чтобы реализовывать оптимальные UX-решения для ваших пользователей, сделать приложение лучше и быстрее вывести его на рынок. Дополнительный бонус: код выполняется максимально близко к API платформы, которую использует сервис (serverless обычно используется как дополнительная возможность для платформы, предоставляющей какой-то сервис и API к нему. Например, API работы с голосом, видео и сообщениями. – прим. переводчика).

Serverless = Functions

Несмотря на популярность названия «Serverless», можно встретить и другое: FaaS, «Functions as a Service», которое нашло свое отражение в таких продуктах как Google Cloud Functions, PubNub Functions и Twilio Function, наверняка есть другие.

Самый распространенный пример это, наверное, AWS Lambda; а еще есть Open Source решение Apache OpenWhisk.

Многие компании, предоставляющие сервисы с API, начали предлагать Serverless-возможности. Вам больше не нужен собственный сервер, общающийся с их сервисом, достаточно выполнить ваш код в их «XXX Functions» продукте.

В ряде случаев «Functions» сервисы доступны бесплатно, но чаще всего вендоры хотят за них оплату по модели «pay per usage».

Serverless CPaaS

Вернемся к CPaaS (communications platform as a service – прим. переводчика) и посмотрим, что у них с Serverless.

Полагаю, сейчас на рынке только два вендора CPaaS предлагают Serverless-решения:

1. Voximplant с VoxEngine
2. Twilio с Twilio Functions

На последней конференции Signal в Лондоне Jeff Lawson упомянул, что «Functions» является самым быстрорастущим продуктом Twilio с момента запуска сервиса. Эта функциональность нужна рынку.

CPaaS сейчас довольно сложны, и тем важнее разобраться, как в них применяется serverless. Разобьем CPaaS на несколько уровней API и ряд продуктов:

Уровни API

• Скриптовые языки, такие как TwiML и NCCO
• REST API
• SDK на стороне клиента (для совершения и приема звонков из браузеров, мобильных приложений, холодильников и так далее. – прим. переводчика)

Продукты

• SMS и голос (с помощью телефонных номеров)
• IP сообщения, чат и омниканальная работа с сообщениями
• VoIP (голос и видео с помощью WebRTC)

В какой-то степени проприетарный уровень API скриптовых языков можно рассматривать как очень грубую форму serverless. Вы описываете нужное поведение как реагирующий на события скрипт и отдаете его платформе с помощью WebHooks.

REST API хорошо работают в serverless-архитектуре: вместо того, чтобы делать запросы на авторизацию, безопасность или масштабирование между серверами, их можно делать на том же сервере, на котором они будут выполняться.

А еще есть клиентские SDK. Они выполняются на конечных устройствах, поэтому трудно представить, как к ним применима концепция serverless. SDK созданы для взаимодействия с бэкендом CPaaS, так что мы их рассматривать не будем.

Так как CPaaS можно сгруппировать по типам используемых API слоев, то можно сделать вот такой вывод:


Несколько комментариев:

IP Messaging имеет смысл использовать в serverless-варианте при больших объемах трафика и требованиях к низким задержкам.

Задержка обычно не так важна, когда дело касается SMS и голоса (только в простейшем случае «абонент А звонит абоненту Б». Как только появляется распознавание, синтез речи, голосовые меню и прочие интересные штуки, задержка между вызовом API в вашем коде и реакцией платформы делает разницу между «какая полезная штука» и «а что оно тупит постоянно». – прим. переводчика).

У VoIP есть свой собственный набор решений, частично делающий то же, что и serverless. Обычно это готовые виджеты и iframe'ы для размещения на веб страницах (но это тема для отдельной статьи).

С точки зрения вендоров, serverless сейчас становится все более важной технологией. Почему?

Потому что это одно из предложений Twilio. Быстрорастущее предложение Twilio. На месте конкурента я бы не хотел отставать.

Я могу использовать FaaS-сервис от вендоров IaaS?

Очень хотелось поместить эти два акронима в одно предложение :)

Все основные IaaS-вендоры (Azure, AWS, Google Cloud) сейчас предлагают serverless в том или ином виде. Зачем serverless в CPaaS? Мы не можем просто подключить IaaS serverless к CPaaS?

Можем. Но это будут уже два разных вендора. Использование чего-то вроде AWS Lambda имеет смысл, если вы уже используете другие сервисы AWS.

Если вы решаете вопросы коммуникаций, то разумнее использовать serverless CPaaS. Вместе с ним вы получаете уменьшение задержек и лучшую безопасность по сравнению с внешними serverless-решениями.

CPaaS становится serverless

Если вы вендор CPaaS и задаетесь вопросом «что будет дальше» – добавляйте serverless в список того, что надо срочно сделать и предлагать клиентам.

Если вы разработчик и используете CPaaS – посмотрите, как решения serverless помогут вам создавать приложения быстрее.

От переводчика

Раз в неделю меня спрашивают, зачем мы в Voximplant потратили столько усилий, чтобы JavaScript по управлению коммуникациями выполнялся в нашем облаке. «Не нужен свой сервер», – это, конечно, хорошо. Но, положа руку на сердце: поднять ноду, пайтон или даже php в публичном облаке – это полчаса времени для опытного fullstack разработчика. Оно того стоит?

Задержки. Цахи много про них говорит, но не рассматривает как основное преимущество serverless-подхода. По моему опыту, именно отсутствие задержки между вызовами API и реакциями платформы, такими как синтез и распознавание голоса, играет ключевую роль. На конференции многие компании рассказывали и показывали автоматические системы, общающиеся с клиентами и помогающие решать задачи без помощи специалистов колл-центра.

JS-код выполняется на том же сервере, который управляет голосовыми и видеопотоками и убирает паузы/задержки во время разговора, делая общение с автоматикой естественной.

Особенно чувствительны к задержкам такие штуки как распознавание в реальном времени. Не так давно мы писали на Хабре как собрать потоковое распознавание в несколько строк JS кода. Попробуйте и оцените, насколько быстро оно работает!