Современные LLM‑агенты могут обходиться без внешних вызовов — выдавать ответы исключительно на основе prompt’а. Но когда речь идёт о живых данных (трассы вызовов, результаты SQL‑запросов, исходный код из GitLab), нужно динамически обогащать контекст модели и давать ей «функции» для вызова.
Много было сказано про Serverless в нагрузках без сохранения состояния. Действительно, когда у вас есть контейнеры или функции их легко почти мгновенно масштабировать и нет большой разницы, на какой именно машине это делать.
Но данные имеют очень конкретную привязку к диску, на котором размещены. Что создает немало сложностей к самой концепции бессерверных вычислений.
В этой статье я хочу показать, где бессерверная архитектура может быть применима, и рассмотрю несколько новых, и весьма перспективных решений в этой области, таких как Neon, Warpstream и TiDB.
В последнее время активно занимаюсь разработкой Telegram-бота с использованием Serverless-подхода в Timeweb и Vercel сервисах.
В этом посте я расскажу, как на практике за пару часов реализовал serverless OCR-сервис на AWS, используя AWS Lambda и модель из Amazon Bedrock. Статья ориентирована на опытных AWS-архитекторов, поэтому мы углубимся в архитектуру, покажу код (Terraform для инфраструктуры и Python для Lambda), обсудим масштабирование, ограничения и прикинем стоимость решения в регионе eu-central-1 (Франкфурт).
Месяц назад я баловался с сервисом Lovable — мне показался прикольным инструментом, а главное, что он предложил мне настроить БД на Supabase с помощью пары кликов. База Postgres уже крутится, таблицы создаются, в админке всё прозрачно и, главное, что вск это бесплатно в пределах небольших квот.
Пока щёлкал UI заметил раздел Functions. «Что‑то похожее на AWS Lambda, только прямо рядом с базой». Отложил идею «попробовать на боте» в долгий ящик.
И тут несколько дней назад релиз OpenAI Images API. Захотелось сделать простого бота фотку за пару тапов, а не лезть постоянно в Playground. Вспомнил про Supabase → идеальный шанс обкатать edge‑функции без боли с серверами.
Как обычно для себя, накидал мысли по тому, как должен работать бот и на чем, и попросил ChatGPT накидать первые черновики ТЗ. Несколько правок и плюс-минус полное описание задачи было на руках. Затем пошёл в Claude через OpenRouter — он выплюнул скелет кода под Supabase edge functions. Имея на руках написанный код я пошел его править локально и запускать постепенно погружаясь в Deno и работу функций.
Архитектура решения
Всем знакома история, когда менеджер спрашивает: сколько времени нужно, чтобы реализовать ту или иную фичу? Менеджеры или заказчики смотрят на это просто: разработка пишет код, эксплуатация деплоит его и следит, чтобы всё надёжно и хорошо работало. Но в жизни всё оказывается гораздо сложнее, при этом разработка и эксплуатация не стоят на месте и развиваются в инструментарии и подходах.
Меня зовут Виктор Кузённый, и за 15 лет в IT я работал Java‑разработчиком на гособоронзаказ, делал высоконагруженные бэкенды в Кинопоиске, а затем подружился с Serverless в Yandex Cloud, и этот опыт позволил мне познакомиться с разными инструментами разработки, языками программирования, а также инструментами деплоя и управления инфраструктурой.
В статье разберёмся детальнее, что такое IfC, в чём его преимущества и недостатки, а также чем он отличается от IaС и как его дополняет.
Чем хорош TRMNL — так это возможностью выводить что-то своё за считанные минуты.
Но сервер позволяет только простые GET и POST запросы, то есть в лоб OAuth2 не реализуешь. Оно и понятно: они не очень хотят хранить данные авторизации для всех.
Но всегда можно обойтись малой кровью: например, бесплатным CloudFlare.
Современные web-фреймворки для реализации управления состоянием используют библиотеки, такие, например, как Redux для React или Pinia для Vue. У традиционной реализации управления состоянием есть недостатки. Store в таком варианте является частью скрипта страницы, и его данные при её перезагрузке теряются. Кроме того, если нам в приложении нужно организовать управление отображением контента в нескольких окнах браузера, оказывается, что традиционный Store не может этого обеспечить.
Для целого ряда задач полезно использовать Serverless подход.
В этой статье мы кратко рассмотрим основные решения, их достоинства, и главное, недостатки. А также рассмотрим несколько интересных Open Source решений.
В этой статье я постарался обобщить свой опыт в создании документации для различных архитектур, таких как монолитная и микросервисная. Я описал, какие диаграммы и схемы действительно полезны для системных аналитиков, архитекторов и разработчиков в зависимости от выбранной архитектуры проекта, а также какие моменты часто упускаются на практике.
Серверную инфраструктуру, как и многие другие услуги, можно получить в облаке и передать все задачи по управлению, поддержке и масштабированию серверов провайдеру. Лев Немировский, руководитель направления по развитию инструментов внедрения ПСБ, рассказал, как работает архитектура Serverless и почему стоит попробовать это решение.
Event Driven Architecture, или EDA — довольно популярный архитектурный подход, в буквальном переводе «архитектура на основе событий», где мы строим приложение вокруг событий, которые генерируются в системе. В самом распространённом случае, у нас есть много пользователей, которые генерируют много событий, и эти события маршрутизируются в сервисы‑потребители.
Реализовать такое приложение в облаке можно несколькими способами. Так что сегодня покажу типовые варианты архитектуры для одного и того же сценария. А чтобы сравнивать было приятнее, возьмём для сопоставления архитектур один и тот же кейс — автоматизацию ухода в отпуск.
В статье объясню специфику Яндекс Функций. Покажу свой эксперимент с запуском приложений, которые опубликованы разными способами — в том числе с использованием AOT-компиляции. А в конце — сравнение результатов и выводы.
Интересны особенности работы .NET в Yandex Cloud Functions? Добро пожаловать под кат.
Меня зовут Екатерина Александрова, я интернет‑маркетолог, выпускница курса «Интернет‑маркетолог» и «SMM‑продвижение в Телеграмм», и Станислав Козырев — ведущий инженер‑программист, дата‑аналитик и саентист ЦУНБ им. Некрасова, выпускник курса «Специалист по Data Science».
Наша команда «Проактивные практики», состоящая из пяти увлеченных и энергичных участников, проходит обучение в амбассадорской программе Яндекса. Заключительным этапом программы стала выпускная работа.
Если у вас имеется собственный контактный центр, задача найти упоминание чего-либо конкретного в большом количестве аудиозаписей возникает регулярно. Недавно я опубликовал статью о том, как настраивать это решение с нуля. Во второй части я хочу показать, какие решения мне пришлось разработать дополнительно для использования речевой аналитики Яндекс 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 доступен бесплатно для подтверждённых учащихся, преподавателей и мейнтейнеров популярных проектов с открытым исходным кодом.
Даже если вы не подходите под указанные выше критерии, стоимость платной подписки
(Individual) более доступна, чем аналогичное предложение от OpenAI.
Она стоит всего 10 долларов и при этом обеспечивает доступ к передовым моделям OpenAI, Anthropic и Google.
Если вышеперечисленные варианты вам не подходят — попробуйте полностью бесплатную альтернативу: openai-gemini.
GitHub Copilot чат доступен исключительно в избранных IDE.
Проект openai-github-copilot позволяет использовать его с намного более широким спектром инструментов: предоставляется общий API, совместимый с OpenAI, который можно развернуть бесплатно.
(Однако подписка на GitHub Copilot всё так же требуется.)
API Gemini бесплатен, но существует множество инструментов, которые работают исключительно с API OpenAI.
Проект openai-gemini даёт позволяет с лёгкостью создать персональный Gemini API-endpoint, совместимый с OpenAI, бесплатно.
