Microsoft Bot Framework: конец эпохи Technology Preview – часть 1
Введение
Всем привет,
Как мы писали в нашем блоге, у нас в компании уже несколько месяцев работает виртуальная помощница Лиза Ботти. С той поры она очень похорошела собой и многому научилась. Реализована она на Microsoft Bot Framework. Помогает нам автоматизировать технологические процессы в компании.
И вот некоторое время назад в консоли управления ботами https://dev.botframework.com/bots появилась вот такое предупреждение:
With the launch of the new Azure Bot Service, we are migrating all bots to the new service by 3/31/2018.
И выглядит это предупреждение — вот так:
Сегодня мы разберемся в том, что это означает, что, куда и зачем мигрируется, каковы последствия и, наконец, как это правильно делать.
Пошаговых инструкций по миграции, о которой написано в сообщении, в интернете полно, однако они не рассказывают зачем вообще нужна эта миграция, в чем ее смысл, причины, и о некоторых подводных камнях, о которых желательно подумать заранее.
Эта статья будет состоять из двух частей:
- Теоретическая часть - Суть предлагаемой миграции, причины и последствия.
- Практическая инструкция - Пошаговая инструкция и некоторые моменты, которые надо учесть до и после миграции.
Теоретическая часть
Для того чтобы описать, что именно меняется, нужно сначала понять как минимум на уровне идеи, из чего состоит бот.
Так и из чего же он состоит?
Бот в Microsoft Bot Framework представляет конструкцию, состоящую из 4х частей:
- сервис логики бота, полностью пишется автором бота
- инфраструктура Microsoft Bot Framework
- каналы
- регистрация самого бота и каналов бота
Сервис логики бота – это пользовательский веб сервис, который, как следует из названия, реализует логику бота, возможно с использованием для этого любых внешних прикладных сервисов и/или сервисов искусственного интеллекта из Azure (распознавание речи или изображений, например), и обрабатывающий сообщения, поступающие от пользователей к боту в виде REST запросов к нему. Справедливости ради надо отметить, что бот может также быть и проактивным, т.е. сервис бота может инициировать сообщения пользователям не только в ответ на внешние запросы, но и сам, в любой момент времени обращаясь к API Bot Framework.
Инфраструктура Microsoft Bot Framework – это посредник между каналами и сервисом бота, транслирует активность пользователей в каналах в REST запросы к сервису бота, сглаживая разницу в форматах и логике работы разных каналов, приводя ее к единому (насколько это возможно) интерфейсу и семантике работы. А также предоставляет API, через которое сервис бота может в обратную сторону взаимодействовать с каналами.
Каналы – это логическая единицы взаимодействия бота с внешним миром, или внешнего мира с ботом, как на это посмотреть, поддерживаемые и интегрированные разными способами с Bot Framework, такие как Skype, Telegram, Slack и много других. Их число наверняка будет расти в дальнейшем по мере популяризации платформы и реализации интеграционных решений для других систем и сервисов.
Регистрация бота и его каналов – по сути является метаданными, которые определяют логику взаимодействия инфраструктуры Bot Framework и сервиса бота. Они связывают физическую реализацию того или иного канала с сервисом бота.
Для реализации своего бота нужно его зарегистрировать, зарегистрировать для него каналы, написать свой сервис логики и захостить его.
На этапе Preview Microsoft Bot Framework управлялся на отдельном портале, где можно было управлять только одним из перечисленных компонент бота, а именно регистрацией бота и его каналов. Вопрос хостинга сервиса бота не входил в компетенции этого портала. Использование этого портала, как и самих регистрационных данных бота было бесплатно.
Сервис бота можно было хостить как в своей инфраструктуре, так и в Azure как обычный веб сервис. Наш бот, например, хостится на Azure..
Это очень краткое описание, минимально достаточное чтобы понять суть происходящих изменений. Более подробно см тут: https://docs.microsoft.com/en-us/bot-framework/
Что же меняется и зачем?
Начиная с апреля 2018 года Microsoft Bot Framework полностью переходит из статуса Preview в Production. На практике это означает несколько моментов.
Первое - халява кончилась. Да, да. Ранее можно было своих ботов заводить и использовать совершенно бесплатно и без ограничений. Теперь же использование Bot Framework встраивается в систему монетизации и тарификации Azure. Настала пора платить деньги.
Второе – управление ботами и каналами полностью переезжает с портала Bot Framework в общую консоль управления Azure. Т.е. Bot Framework полностью интегрируется в Azure. На самом деле для новых ботов уже туда все переехало, и вопрос как раз стоит о миграции ранее созданных ботов.
Какие тут плюсы для потребителя? Это сложный вопрос. Выделю следующие:
- Единая консоль управления
- Единый биллинг
- Поддержка (ранее по сути была только поддержка в блогах и комьюнити)
- Монетизация сервиса дает надежду, что поигравшись с ним пару тройку лет Microsoft не забросит его, как это уже бывало, вспомним хотя бы Silverlight.
Минус пока видится только один:
- Дополнительная статья расходов
И сколько же это будет стоить?
По сути дела, стоимость бота теперь состоит из двух частей:
- Как и раньше, это стоимость ресурсов, потребляемых сервисом бота, если он также хостится в Azure (а это, как уже выше упоминалось, не обязательно). Это осталось без изменений.
- Новая составляющая - стоимость обслуживания регистрации бота и его каналов, т.е. плата за каналы и сообщения.
Для каналов и сообщений вводится два варианта ценообразования:
Отличие Free от S1, как видно из таблицы, в стоимости и лимитах на сообщения. Есть также разница в SLA на доступность каналов.
Тут есть три замечания:
* в консоли управления Azure Free Tier обозначается как F0, а не Free, это немного путает
** а что считать за message? Это грустная новость, но за message считаются как входящие сообщения, так и исходящие. Т.е. банально минимальный вопрос – ответ это в любом случае 2 сообщения.
*** на момент написания данного материала информация о том, что такое Premium каналы весьма туманна. Создается ощущение, что DirectLine and Web Chat являются premium, но написано это странно: The premium channels allow your bot to reliably communicate with users within your own application or on your website. These channels allow you to customize the client experience for your users by customizing the open source DirectLine and Web Chat clients. Please refer to the Bot Service documentation for details. И если directline можно считать за premium, т.к. это дает возможности кастомной интеграции ботов в другие системы, то причем тут web chat - непонятно.
Смотрим подробное описание и пруфы тут: https://azure.microsoft.com/en-us/pricing/details/bot-service. Особенно обращаем внимание на FAQ внизу страницы.
Какие варианты ботов были раньше и какие сейчас?
Хостинг и регистрация ботов в Azure осуществляется одним из следующих вариантов (это само по себе не новость):
- в парадигме веб приложения (ресурсы Web App Bot + App Service)App Service - это реализация логики ботаWeb App Bot - это описание самого бота и его каналов
- парадигме Azure Function App, т.е. serverless бот (ресурсы Functions Bot + App Service)App Service - это реализация логики бота, вернее ее описание (Functions)Functions Bot - это описание самого бота и его каналов
- или же любым сторонним способом как некий абстрактный веб сервис с REST API плюс ресурс Bot Channels Registration, который соответствует не самому хостингу бота, не подразумевает никакого конкретного варианта реализации бота, а представляет собой лишь метаданные, описывающие только бота и его каналыBot Channels Registration - это описание бота и его каналов
Принципиальная разница между первыми двумя и третьим способом заключается в том, что для случая Web App Bot и Functions Bot Azure “знает” как реализован сервис бота и управляет этим, а в случае Bot Channels Registration – ничего про него не знает. Т.е. регистрация и реализация отделены друг от друга полностью.
Подробнее про это можно прочитать в документации по Azure, ссылки будут в конце статьи.
Кстати, наш бот был сделан еще до появления Azure Bot Service, поэтому он реализован в виде обычного веб сервиса, который также хостится в Azure как обычный App Service. С таким же успехом, с точки зрения Azure Bot Framework, его можно было задеплоить на виртуалке или вообще даже на физическом компьютере.
Это самый legacy вариант, именно с него многие разработчики ботов начинали знакомство с Microsoft Bot Framework, и, поэтому, пример миграции во второй части статьи мы будем разбирать именно на нем.
Что дальше?
В следующей части рассмотрим практическую сторону миграции и подводные камни, которые, как водится, заботливо разложены в фарватере.
Полезные ссылки
https://dev.botframework.com/bots - портал Microsoft Bot Framework
https://portal.azure.com – портал управления Azure
https://azure.microsoft.com/en-us/pricing/details/bot-service - цены на боты в Azure
https://docs.microsoft.com/en-us/bot-framework -документация по Bot Framework
https://docs.microsoft.com/en-us/bot-framework/bot-service-concept-templates - варианты ботов
https://docs.microsoft.com/en-us/bot-framework/bot-service-overview-introduction - описание концепции ботов
https://docs.microsoft.com/en-us/bot-framework/bot-service-quickstart-registration - регистрация бота