- PVSM.RU - https://www.pvsm.ru -
Две недели назад мы провели вторую конференцию INTERCOM о голосовых и видео коммуникациях. WebRTC, звонки через браузер, machine learning, big data – вся вот эта популярная история. Одним из приглашенных спикеров был Цахи Левент-Леви, более известный как автор bloggeek.me [1] – ультимативного источника информации о WebRTC в современных браузерах. В докладе (кстати, у меня есть видеозапись [2]) Цахи рассказывал про состояние индустрии и что сейчас можно делать с голосом и видео в браузерах. А вернувшись в Израиль написал интересную статью про «Serverless»-технологии при работе с коммуникационными платформами. Адаптированный для Хабра перевод предлагаю под катом.
Когда я проводил исследования для своего первого отчета [3] о платформах с WebRTC API, одной из изучаемых компаний была Voximplant [4]. Они особо выделяли штуку, которую называли «VoxEngine». Как написано на сайте, это «система, которая выполняет ваш JavaScript-код в облаке Voximplant». Это Serverless.
Идея мне понравилась, но тогда я о ней особо не задумывался. Просто новая интересная штука.
Если вы не следили за эволюцией API, то могли пропустить появление «Serverless». Это подход, при котором код, который вы пишете, выполняется в облаке. Напрямую. Не нужно поднимать OS, виртуалку или контейнер. Пишете код и он выполняется. Магия.
Если посмотреть на «Что-то-там-aaS», то вы можете нагуглить вот такую картинку:
Как в эту картину вписывается Serverless?
В случае Serverless вы так же разрабатываете приложение, но оно и его данные управляется и поддерживается не вами. Что вы получаете от такого решения?
Что мы в результате получаем? Экономию на масштабировании. Вендор, предлагающий PaaS-решение, уже обеспечивает масштабирование, поддержку сервиса и безопасность для вас (и для многих других клиентов). Теоретически он может это делать даже лучше, чем вы сами. Это освобождает ваши ресурсы чтобы реализовывать оптимальные UX-решения для ваших пользователей, сделать приложение лучше и быстрее вывести его на рынок. Дополнительный бонус: код выполняется максимально близко к API платформы, которую использует сервис (serverless обычно используется как дополнительная возможность для платформы, предоставляющей какой-то сервис и API к нему. Например, API работы с голосом, видео и сообщениями. – прим. переводчика).
Несмотря на популярность названия «Serverless», можно встретить и другое: FaaS, «Functions as a Service», которое нашло свое отражение в таких продуктах как Google Cloud Functions [5], PubNub Functions [6] и Twilio Function [7], наверняка есть другие.
Самый распространенный пример это, наверное, AWS Lambda [8]; а еще есть Open Source решение Apache OpenWhisk [9].
Многие компании, предоставляющие сервисы с API, начали предлагать Serverless-возможности. Вам больше не нужен собственный сервер, общающийся с их сервисом, достаточно выполнить ваш код в их «XXX Functions» продукте.
В ряде случаев «Functions» сервисы доступны бесплатно, но чаще всего вендоры хотят за них оплату по модели «pay per usage».
Вернемся к CPaaS (communications platform as a service – прим. переводчика) и посмотрим, что у них с Serverless.
Полагаю, сейчас на рынке только два вендора CPaaS предлагают Serverless-решения:
На последней конференции Signal в Лондоне Jeff Lawson упомянул, что «Functions» является самым быстрорастущим продуктом Twilio с момента запуска сервиса. Эта функциональность нужна рынку.
CPaaS сейчас довольно сложны, и тем важнее разобраться, как в них применяется serverless. Разобьем CPaaS на несколько уровней API и ряд продуктов:
Уровни API
Продукты
В какой-то степени проприетарный уровень API скриптовых языков можно рассматривать как очень грубую форму serverless. Вы описываете нужное поведение как реагирующий на события скрипт и отдаете его платформе с помощью WebHooks.
REST API хорошо работают в serverless-архитектуре: вместо того, чтобы делать запросы на авторизацию, безопасность или масштабирование между серверами, их можно делать на том же сервере, на котором они будут выполняться.
А еще есть клиентские SDK. Они выполняются на конечных устройствах, поэтому трудно представить, как к ним применима концепция serverless. SDK созданы для взаимодействия с бэкендом CPaaS, так что мы их рассматривать не будем.
Так как CPaaS можно сгруппировать по типам используемых API слоев, то можно сделать вот такой вывод:
Несколько комментариев:
IP Messaging имеет смысл использовать в serverless-варианте при больших объемах трафика и требованиях к низким задержкам.
Задержка обычно не так важна, когда дело касается SMS и голоса (только в простейшем случае «абонент А звонит абоненту Б». Как только появляется распознавание, синтез речи, голосовые меню и прочие интересные штуки, задержка между вызовом API в вашем коде и реакцией платформы делает разницу между «какая полезная штука» и «а что оно тупит постоянно». – прим. переводчика).
У VoIP есть свой собственный набор решений, частично делающий то же, что и serverless. Обычно это готовые виджеты и iframe'ы для размещения на веб страницах (но это тема для отдельной статьи).
С точки зрения вендоров, serverless сейчас становится все более важной технологией. Почему?
Потому что это одно из предложений Twilio. Быстрорастущее предложение Twilio. На месте конкурента я бы не хотел отставать.
Очень хотелось поместить эти два акронима в одно предложение :)
Все основные IaaS-вендоры (Azure, AWS, Google Cloud) сейчас предлагают serverless в том или ином виде. Зачем serverless в CPaaS? Мы не можем просто подключить IaaS serverless к CPaaS?
Можем. Но это будут уже два разных вендора. Использование чего-то вроде AWS Lambda имеет смысл, если вы уже используете другие сервисы AWS.
Если вы решаете вопросы коммуникаций, то разумнее использовать serverless CPaaS. Вместе с ним вы получаете уменьшение задержек и лучшую безопасность по сравнению с внешними serverless-решениями.
Если вы вендор CPaaS и задаетесь вопросом «что будет дальше» – добавляйте serverless в список того, что надо срочно сделать и предлагать клиентам.
Если вы разработчик и используете CPaaS – посмотрите, как решения serverless помогут вам создавать приложения быстрее.
Раз в неделю меня спрашивают, зачем мы в Voximplant потратили столько усилий, чтобы JavaScript по управлению коммуникациями выполнялся в нашем облаке. «Не нужен свой сервер», – это, конечно, хорошо. Но, положа руку на сердце: поднять ноду, пайтон или даже php в публичном облаке – это полчаса времени для опытного fullstack разработчика. Оно того стоит?
Задержки. Цахи много про них говорит, но не рассматривает как основное преимущество serverless-подхода. По моему опыту, именно отсутствие задержки между вызовами API и реакциями платформы, такими как синтез и распознавание голоса, играет ключевую роль. На конференции многие компании рассказывали и показывали автоматические системы, общающиеся с клиентами и помогающие решать задачи без помощи специалистов колл-центра.
JS-код выполняется на том же сервере, который управляет голосовыми и видеопотоками и убирает паузы/задержки во время разговора, делая общение с автоматикой естественной.
Особенно чувствительны к задержкам такие штуки как распознавание в реальном времени. Не так давно мы писали на Хабре как собрать потоковое распознавание в несколько строк JS кода. Попробуйте и оцените, насколько быстро оно работает!
Автор: eyeofhell
Источник [12]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/javascript/269805
Ссылки в тексте:
[1] bloggeek.me: https://bloggeek.me/
[2] видеозапись: https://www.youtube.com/watch?v=t7-832m8xGo&index=12&list=PLe3Nq0ymzoBHO2YBpFizNOXkr4vNZvU2u
[3] отчета: https://bloggeek.me/webrtc-paas-report/
[4] Voximplant: http://voximplant.com/docs/references/appengine/
[5] Google Cloud Functions: https://cloud.google.com/functions/
[6] PubNub Functions: https://www.pubnub.com/products/functions/
[7] Twilio Function: https://www.twilio.com/functions
[8] AWS Lambda: https://aws.amazon.com/lambda/
[9] Apache OpenWhisk: https://openwhisk.apache.org/
[10] TwiML: https://www.twilio.com/docs/api/twiml
[11] NCCO: https://developer.nexmo.com/api/voice/ncco
[12] Источник: https://habrahabr.ru/post/343678/
Нажмите здесь для печати.