Serverless *

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

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

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

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

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

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

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

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

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

В Телеграме из коробки можно посмотреть какие‑то графики. Но, например, количество подписчиков отображается с точностью до дня, что не очень удобно. Сделать оттуда 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. Примеры включают приложения электронной коммерции для интернет-магазинов, интегрирующихся с платежными шлюзами, логистические компании или приложения в секторах здравоохранения и банковской сферы.

Интегрируем Okta с Firebase, что позволит аутентифицировать своих пользователей с помощью Firebase, используя Okta SSO, по протоколу OpenID Connect (OIDC).

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

Тогда я задался вопросом: сколько работы потребуется, чтобы создать нечто подобное с помощью современного DL-стека? Можно ли сделать это за выходные?

⚠️ Disclaimer: обычно я заканчиваю свои статьи фразой о том, что всё написанное может оказаться дичайшим овер-инжинирингом. В случае с этой статьёй я вынужден предупредить читателя об этой опасности заранее.

Если коротко, то это история о том, как я попытался сохранить выращенный урожай при помощи подручных средств: ОСП, утеплителя, ESP8266, керамического рептилического нагревателя и сервисов Yandex.Cloud. Успешно ли — покажет только весна.