Serverless *

Если у вас имеется собственный контактный центр, задача найти упоминание чего-либо конкретного в большом количестве аудиозаписей возникает регулярно. Недавно я опубликовал статью о том, как настраивать это решение с нуля. Во второй части я хочу показать, какие решения мне пришлось разработать дополнительно для использования речевой аналитики Яндекс SpeechSense, какие дополнительные задачи при этом появились и как их решать.

Задача, которую я решал, формулировалась вот так. Необходимо проанализировать 25000 аудиозаписей разговоров оператора с клиентом по телефону, найти и вывести список всех аудиозаписей, где есть поздравления с праздниками.

Если у вас имеется собственный контактный центр, задача найти упоминание чего-либо конкретного в большом количестве аудиофрагментов возникает регулярно. Недавно нам удовлетворили заявку на доступ к prewiev режиму сервиса Яндекса SpeechSense и я решил попробовать одну из таких задач решить при помощи этого сервиса.

Все трудности, тонкие моменты и полный путь от начала настройки и до победы описаны в этой статье.

В принципе в документации описан функционал, который мало отличается от других систем речевой аналитики, и это только на первый взгляд. Сюрпризом стало полное отсутствие собственных средств загрузки аудиофрагментов в систему. Всю загрузку необходимо реализовать самостоятельно. В документации описан только один способ, при помощи bash и Python под unix. Поэтому в этой статье я еще и опишу, как такие инструкции адаптировать под Windows и PowerShell.

Сама инструкция довольно короткая https://yandex.cloud/ru/docs/speechsense/operations/data/upload-data я рассчитывал справиться за пару часов, это мне не удалось. Так что Ваша выгода от прочтения статьи может составлять 2-3 рабочих дня. Или больше.

H3 отмечает, что Express.js - старый и малоразвивающийся фреймворк, являющийся не оптимальным выбором для новых проектов из-за потенциальных проблем безопасности и утечек памяти, что, к слову, касается и Koa.

В нашей статье мы сделаем акцент на фреймворках, поддерживающих запуск service workers на серверной стороне и современный стандарт Fetch API, поскольку это позволяет им работать в бессерверных и Edge-окружениях, таких как Cloudflare Workers. Это, к слову, и причина, почему Fastify не будет рассматриваться в нашей статье, несмотря на эксперимент fastify-edge, который продолжался два года (кстати, была написана интересная статья о переходе от Node к средам рабочих процессов, с которой я рекомендую ознакомиться).

Worker Runtimes воплощают первоначальное обещание NodeJS: использование одного языка и возможность обмена кодом между клиентом и сервером. Однако на практике это не осуществилось, и API Node и браузеров пошли по разным путям. Worker Runtimes вновь объединяют эти возможности. Больше информации здесь.

Hono, H3, HatTip и Elysia - это современные фреймворки HTTP-серверов, также известные как промежуточные программы веб-сервера нового поколения. Они работают везде, на любом JS-рантайме, включая бессерверные и Edge-среды выполнения. Это означает, что они могут быть использованы не только на серверах Node.js. Кроме того, все они поддерживают TypeScript.

Далее мы поговорим о каждом их них по отдельности и сравним некоторые различия.

Все они поддерживают Web Fetch API (объекты Request/Response), но здесь я покажу их API, наиболее похожие на Express, чтобы было проще ориентироваться.

Демо

Демо здесь.

Зачем

GitHub Copilot доступен бесплатно для подтверждённых учащихся, преподавателей и мейнтейнеров популярных проектов с открытым исходным кодом.

• Учащиеся и преподаватели: см. Преимущества для всех в школе [en].
• Мейнтейнеры: проверьте https://github.com/github-copilot/free_signup
  Если Copilot недоступен, значит ваш проект не соответствует критериям, т.е. ему нужно больше звёзд.

Даже если вы не подходите под указанные выше критерии, стоимость платной подписки
(Individual) более доступна, чем аналогичное предложение от OpenAI.
Она стоит всего 10 долларов и при этом обеспечивает доступ к GPT-4.

Если вышеперечисленные варианты вам не подходят — попробуйте полностью бесплатную альтернативу: openai-gemini.

Для чего

GitHub Copilot чат доступен исключительно в избранных IDE.

Проект openai-github-copilot позволяет использовать его с намного более широким спектром инструментов: предоставляется общий API, совместимый с OpenAI, который можно развернуть бесплатно.
(Однако подписка на GitHub Copilot всё так же требуется.)

API Gemini бесплатен, но существует множество инструментов, которые работают исключительно с API OpenAI.

Проект openai-gemini даёт позволяет с лёгкостью создать персональный Gemini API-endpoint, совместимый с OpenAI, бесплатно.

Возьмем пример: Как создать бота в Telegram

Если вы когда нибудь читали документацию Яндекс облака, вы в курсе. Для остальных могу пояснить. Возьмите лапидарный текст, удалите из него ясность и чёткость и вы получите документацию Яндекс облака.

В статье я хочу поделиться теми моментами которые всплыли при разработке бота в телеграм, но не описаны в документации.

Давно я приглядывался к Serverless технологиям, но все не доходили руки. Как и во многих компаниях, там где я работаю есть строгое разделение на бэкендеров и фронтендеров. Проблемы у этого известные и самая неприятная — надо договариваться, а разработчики далеко не всегда самые общительные люди.

Как менеджер продукта и один из амбассадоров serverless я регулярно рассказываю о преимуществах этого подхода и показываю, как с помощью бессерверных вычислений повысить эффективность затрат на инфраструктуру. Но как и у любого подхода, у serverless есть свои ограничения, которые важно учесть в своей IT-стратегии.

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

Serverless на бюджете: Делаем FaaS (функция-как-сервис) с помощью OpenWhisk, чтобы было как в облаках.

Привет, Хабр! Меня зовут Вадим Владимиров, я разработчик и у меня есть свой канал в Телеграме. Как и многие уважающие себя телеграм‑админы, я хочу следить за статистикой: оценивать эффективность, когда что‑то делаю для привлечения подписчиков, мониторить прирост аудитории и знать, какие именно пользователи и когда подписались/отписались.

В Телеграме из коробки можно посмотреть какие‑то графики. Но, например, количество подписчиков отображается с точностью до дня, что не очень удобно. Сделать оттуда drill down до конкретного действия тоже нельзя.

При этом как администратор канала через API я могу получить гораздо больше нужной информации. В этой статье покажу, какие кастомные графики и как я собрал с использованием доступных инструментов: YDB в режиме serverless и DataLens.

В этой статье я расскажу, как засунуть F# в Yandex Cloud Functions. Навыка работы с Serverless у меня нет, так что это будет не компиляция моего опыта, а отчет о вполне успешном эксперименте.

Судя по всему, разработчики Yandex Cloud Functions считают, что dotnet = C#. Поэтому документация для dotnet написана только c позиции C#-разработчика. О том, что делать F#-разрабу - ни слова. Однако это не означает, что это невозможно в принципе.

В предыдущих статьях я рассказала, как быстро создать инфраструктуру для диалогового бота на основе Yandex Serverless Functions и базы данных YDB, а также показала, как реализовать новые команды, добавив код в шаблон. В качестве примера использовался примитивный бот, реализованный в моём репозитории ydb_serverless_telegram_bot.

В обеих статьях я обещала рассказать подробности про структуру шаблона, которая делает создание бота простым и удобным. Наконец, момент настал! В этой статье обсудим реализацию фильтров по пользовательским стейтам для обработки контекста сообщения, корректную работу с базой данных и удобное логирование. Я по-прежнему буду говорить о боте в специфичной инфраструктуре, однако идеи можно легко перенести и на другие реализации.

В предыдущей статье я рассказала, как быстро создать инфраструктуру для диалогового бота на основе Yandex Serverless Functions и базы данных YDB. В качестве примера использовался примитивный бот, реализованный в моём репозитории ydb_serverless_telegram_bot.

Это вторая статья цикла – в ней я покажу, как воспользоваться шаблоном и добавить боту новые команды. В результате читатели смогут реализовать своего собственного бота на основе шаблона.

У меня есть хобби — я учу финский язык. Просто так зубрить новые слова сложно, поэтому я решила написать бота для геймификации процесса. Бот поддерживает разные режимы тренировок, скоринг слов и объединение слов по темам, в общем — имеет довольно сложную ветвистую логику. В процессе создания бота мне удалось создать структуру кода и ресурсов, которая позволяет легко написать диалогового бота любой сложности, не рискуя запутаться и не беспокоясь о создании инфраструктуры. Ею и хочу с вами поделиться.

Это первая статья цикла, в ней я расскажу, как создать базу — шаблонного serverless бота на Python с использованием Yandex Cloud Functions и базы данных YDB с нуля.

В следующих статьях расскажу о том, как добавить боту свои команды, о структуре кода, настройке и обработке пользовательских стейтов, безопасной работе с базой данных, удобном логировании и тестировании бота, которые реализованы в шаблоне. В качестве примера буду использовать примитивного бота, реализованного в моём репозитории ydb_serverless_telegram_bot.

Всем привет! Меня зовут Максим Еремин, я занимаюсь развитием платформенных продуктов в beeline cloud. В этой статье поговорим про контейнерную разработку в облаках, рассмотрим, в каких реалиях живут облачные провайдеры, включая российских игроков и гигантов зарубежного рынка. 

Отдельно расскажу про особенности serverless-подхода. А если вы хотите узнать о serverless больше, погрузиться в DevOps-практику и посмотреть демо по управлению контейнерами — жду вас на вебинаре «Easy to use: управление контейнерами в облаке», который пройдет 30 мая в 11:00 мск. Приходите — пообщаемся в онлайне ?

Всем привет! Меня зовут Антон Брехов. Я инженер в Yandex Cloud. Сегодня хочу рассказать о том, как дешевле всего задеплоить своего телеграм-бота. Возможно, этот опыт пригодится и для других решений.

Готовых фреймворков для телеграм-ботов уже достаточно много на любых языках. Однако после написания кода встает вопрос: а как теперь заставить бота работать постоянно, сделать доступным 24/7?

Новички оставляют персональный компьютер работающим и опрашивают сервер телеграма с некоторой частотой. У опытных, скорее всего, есть свой VPS-сервер с reverse proxy для деплоя приложений. Первое решение не является высокодоступным, а отдельный сервер, даже в облаке, — это слишком дорого для деплоя одного бота. В статье расскажу об альтернативном решении.

Эта заметка является переводом поста в блоге Дэвида Ханссона под заголовком «Even Amazon can't make sense of serverless or microservices». Здесь минимум редактуры для сохранения оригинальной авторской подачи.

Команда Prime Video из Amazon опубликовала довольно примечательное тематическое исследование, посвящённое их решению отказаться от своей микросервисной serverless-архитектуры и заменить её монолитом. Этот шаг сэкономил им ошеломляющие 90% (!!) эксплуатационных расходов, а также упростил систему. Какая победа!

Но помимо восхваления их здравого смысла, я думаю, что здесь есть более важный момент, который применим ко всей нашей отрасли...

В Prime Video мы предлагаем нашим клиентам тысячи прямых трансляций. Чтобы гарантировать, что клиенты беспрепятственно получают контент, Prime Video создала инструмент для мониторинга каждого потока, просматриваемого клиентами. Этот инструмент позволяет нам автоматически выявлять проблемы с качеством воспринимаемого контента (например, повреждение блока или проблемы с синхронизацией аудио / видео) и запускать процесс их устранения.

У нашей команды анализа качества видео (VQA) в Prime Video уже был инструмент для проверки качества аудио / видео, но мы никогда не планировали и не проектировали его для масштабной работы (нашей целью было отслеживать тысячи одновременных потоков и увеличивать это число со временем). Подключая к сервису больше потоков, мы заметили, что масштабная эксплуатация инфраструктуры обходится очень дорого. Мы также заметили узкие места в масштабировании, которые мешали нам отслеживать тысячи потоков. Итак, мы сделали шаг назад и пересмотрели архитектуру существующего сервиса, сосредоточив внимание на стоимости и узких местах масштабирования...

Внешние API могут помочь организациям оптимизировать операции, снизить затраты и улучшить качество услуг для своих клиентов. Однако при интеграции со сторонними вендорами мы можем столкнуться с различными проблемами, такими как безопасность, отказоустойчивость и стоимость.

Организации должны быть уверены в том, что их системы способны справляться с проблемами производительности и простоев. В некоторых случаях вызов внешнего API может быть связан с дополнительными расходами, такими как плата за лицензию. Если с поставщиком внешнего API заключен контракт о соблюдении максимального RPS (количества запросов в секунду), система должна соответствующим образом адаптироваться.

В этой посте мы покажем вам, как будет выглядеть архитектура для вызова внешнего API с помощью AWS Step Functions, с упором на надежность.

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