Serverless *

Бессерверные сервисы облачных вычислений появились в 2014 году с AWS Lambda, которая позволяла запускать код без выделения серверов или управления ими. AWS Lambda — пример функции как услуги (FaaS), где результат обработки событий не зависит от состояния памяти сервера и содержимого локальной файловой системы. Такие эластичные вычисления позволяли быстро наращивать и высвобождать ресурсы процессоров, памяти и средств хранения без необходимости что-то планировать и предпринимать меры для обработки пиковых нагрузок.

За AWS Lambda быстро последовали решения от Microsoft Azure и Google Cloud. Позже облачные провайдеры начали предлагать и другие услуги в бессерверной форме. Это последний, новый взгляд на облачные сервисы, и на практике бессерверные архитектуры за счет возможностей масштабирования часто обходятся в разы дешевле, чем постоянные серверы, предназначенные для выполнения тех же нагрузок.

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

Итак, Serverless. Крупным планом.

В предыдущих частях я сделал приложения, которое работает с БД, GitHub API. Все компоненты разворачиваются при помощи AWS SAM. Можно запускать реализованные функции локально. Все функции собраны воедино в одно API:

Первые шаги. Первая лямбда (Часть 1)

Разворачиваем БД (Часть 2)

Как подружиться с БД (Часть 3)

Создаем REST API (Часть 4)

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

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

В предыдущих частях я сделал кубики, из которых состоит serverless приложение:

Часть 1. Первые шаги. Первая лямбда

Часть 2. Разворачиваем БД

Часть 3. Как подружиться с БД

Реализовано 4 функции, развернута БД. Функции интегрированы с БД, запускаются локально в режиме отладки. Вся инфраструктура поднимается буквально с помощью нескольких SAM команд.

Но пока это мало похоже на какое-то целостное приложение, т.к. у приложения нет API. Мои лямбда функции не умеют обрабатывать http запросы. Так что  в этой части займусь вопросами, связанными с построениями настоящего API. Также сделаю интеграцию с github api.

В статье расскажу про serverless computing и какие есть Open Source-реализации self-hosted-фреймворков с поддержкой Kubernetes, об их возможностях и ограничениях. Еще поделюсь опытом нашего клиента, который использует одно из таких решений (OpenFaaS). Идея обзора как раз и возникла в процессе изучения этого кейса.

Привет, Хабр! Сегодня поговорим о принципах асинхронной работы с сообщениями и их очередями в распределенной и бессерверной архитектуре. У Amazon для этого есть веб-сервисы Simple Notification Service (SNS) и Simple Queue Service (SQS): они позволяют обмениваться сообщениями между микросервисами. В этой статье разберём, чем они отличаются, что могут и какие есть ещё предложения на этом рынке.

В предыдущих частях я создал и развернул в облаке лямбда функцию и БД, настроил VPC, в которой работают мои ресурсы.

В этой части я напишу код лямбда функции, который будет взаимодействовать с БД. Этот код по-прежнему будет запускаться локально в режиме отладки. Вместе с первой настоящей логикой появятся первые юнит тесты. Для удобства при развертывании кода в этой части я буду использовать отдельный стек serverless-bugtracker-ch3.

Создание поисковой системы, безусловно, не самая простая задача. Чтобы пользователь мог быстро получить релевантный ответ на свой запрос, вы должны непрерывно добывать данные с веб-страниц и индексировать их содержимое. Главная цель при реализации — избежать чрезмерной сложности инфраструктуры, сохранив гибкость решения. Какой же должна быть при этом архитектура? Ответ на этот вопрос не очевиден. В этой статье мы расскажем о бессерверной поисковой системе, способной масштабироваться с целью обхода и индексирования крупных сайтов.

В предыдущей части я создал первую лямбда функцию, которая разворачивается при помощи SAM: Часть 1. Первые шаги. Первая лямбда

Эта лямбда работает в облаке, может запускаться локально. Сегодня я займусь базой данных. Я буду концентрироваться на подготовке окружения для БД и её развертывании в облаке. Тут не будет кодинга на nodejs, но будет много SAM/Cloudformation кода.

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

Преимущества выглядят заманчивыми и многообещающими. Так ли все это? Пришло время познакомиться с serverless технологиями. Буду разбираться с новым подходом через призму опыта создания “классических” приложений. Это значит, что обязательно должны быть тесты, возможность запускать локально, возможность дебажить, несколько окружений, логи, метрики и т.д. Нет смысла знакомиться на уровне hello world приложений, которые красиво выглядят на экране. Я возьму задачу с похожими на реальность сценариями. Конечно, в сети очень много разных статей и инструкций, но нет таких, после которых ты сможешь сделать как надо, подумав обо всех проблемах заранее, а не после релиза. Поехали.

Предыстория проста. В нашем банке существует множество продуктов, контент которых нуждается в едином способе управления. Одни продукты построены на классических CMS, другие вовсе требуют усилий разработчиков для обновления информации на портале. Ситуация усугубляется требованием миграции всех продуктов в банковскую облачную платформу, построенную по принципу PaaS. Это означает, что поддержка какого то определённого сервиса (Kafka, Elasticsearch, PorstreSQL, и т. д.) или, тем более, системы (WordPress, Magento, Drupal, и т. д.) требует согласования и разработки в рамках платформы. И если абсолютно всех и в долгосрочной перспективе устраивает пресловутый WordPress, то с учетом прочих приоритетов его поддержка будет реализована со временем.

В силу этих сложностей было принято решение углубиться в тему Систем Управления Контентом. И найти легковесные альтернативы, которые бы не требовали ни от банковской платформы, ни от имеющихся продуктов существенных доработок. Данная статья являясь, по большей части, обзором различных архитектур Систем Управления Контентом может служить подспорьем в выборе подходящего под конкретные требования варианта.

Ежегодный AWS re:Invent, проходивший в конце 2021 года, принёс массу новостей про бессерверные технологии Янашёл самые интересные: и под катом мы поговорим про запуск функций на Graviton2, новых возможностях для машинного обучения, перенос разработки в облако и визуальный редактор для step-функций.

Всем привет! Не так давно я запустил игру Emozle, вдохновившись идеей Wordle. Посетители сайта видят лишь html, несколько js и css файлов, а я бы хотел поделиться с вами тем, что скрыто! Ну и кому может быть интересна диаграмма AWS архитектуры, если не Хабру?

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

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

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

Зачастую возникает вопрос: «Как надежно и безопасно внедрять секреты в бессерверные приложения?»

В одной из прошлых статей о NestJS + GraphQL + Lambda я получил очень интересный комментарий. Поэтому и решил поделится своими мыслями и опытом о том, когда все-таки стоит использовать Lambda функцию, а когда - нет.

Привет, Хабр! Меня зовут Антон Черноусов, я куратор хаба Serverless. В этом посте я расскажу, что интересного тут было про бессерверные технологии за год. Разложил их по нескольким группам и выстроил от теории к практике: сначала посты про саму технологию, затем про старт работы, про инструменты, про важные особенности, и в конце сделал подборку интересных кейсов.

Под катом 20+ публикаций про Serverless за 2021 год.

Модельная разработка - это метод разработки мобильных приложений, при котором мы изначально ставим задачу в виде типизируемой модели(схемы) TypeScript и GraphQL, на уровне создания тикета в таск-менеджере.

Довольно прозаичный и понятный в быту термин порой все еще вызывает вопросы в IT. Зачем при разработке приложений использовать очереди или сервисы очередей, чтобы автоматизировать этот процесс? Ответим на этот вопрос практическими примером — напишем в serverless-стеке Yandex.Cloud сервис для конвертации видео в GIF, используя Yandex Message Queue — ту самую очередь.

Рассмотрим задачу хостинга статичного веб-сайта, например, Leaflet карты с заранее посчитанными данными на ней или статичной 3D модели. Для этих целей можно воспользоваться статическим хостингом файлов на Google Cloud Storage. Кроме того, этот способ позволяет весьма просто ограничить доступ к сайту в веб-интерфейсе Google Cloud, указывая емайлы пользователей, которым доступ разрешен. За счет Google CDN и кэширования файлов можно не беспокоиться об обработке большой нагрузки, а добавление или удаление файлов доступно с помощью консольной утилиты gsutil и в веб-интерфейсе Google Cloud. Также не нужно заниматься получением и обновлением SSL сертификатов и созданием для них доменных имен. Буквально в несколько консольных команд получается масштабируемое и легко поддерживаемое решение с хранением данных в облаке Google и гарантией защиты данных.