Хаб Serverless на Хабре
Совместно с редакцией Хабра запустили хаб Serverless. На этой открытой площадке вместе с другими участниками рынка мы постараемся консолидировать все материалы необходимые разработчикам для понимания идей бессерверных технологий. Со своей стороны планируем регулярно публиковать переводы, интервью, статьи и туториалы, чтобы строить знание о нашей Serverless Ecosystem.
Присоединяйтесь к комьюнити разработчиков, которым близки идеи Serverless!
habr.com/ru/hub/serverless/

Новый сервис Yandex Cloud DNS
Новый сервис Yandex Cloud DNS вышел в стадии Preview. С Cloud DNS вы можете управлять ресурсными записями и доменными именами из облака и настраивать внутренние и публичные DNS-зоны в консоли, API, CLI и Terraform. Сервис упростит делегирование доменов и позволит создавать разные окружения внутри вашего проекта без вложений в собственные DNS-сервера.
cloud.yandex.ru/services/dns

Решение Cloud Advisor для аудита облачной инфраструктуры
Cloud Advisor — партнерское решение для аудита и оптимизации облачной инфраструктуры, расположенной в Yandex.Cloud. С его помощью можно проверить, защищено ли ваше облако от актуальных угроз, соответствует ли оно практикам использования облачных сервисов и рекомендациям провайдера.
cloud.yandex.ru/blog/posts/2021/03/cloud-advisor-review

Плагин для гибридной работы с Citrix Virtual Apps and Desktops
Команда Yandex.Cloud в партнерстве с Citrix разработала плагин для гибридной работы с Citrix Virtual Apps and Desktops. С его помощью VDI Citrix интегрируется с облачной платформой и позволяет развернуть гибридное решение, предоставив больше мощности для локальной инфраструктуры виртуальных рабочих столов и приложений, или запустить CVAD с нуля в облаке Yandex.Cloud.
cloud.yandex.ru/blog/posts/2021/03/citrix-plugin

Schlumberger и Yandex.Cloud заключили соглашение о партнерстве
Schlumberger и Yandex.Cloud заключили соглашение, в рамках которого платформа искусственного интеллекта и цифровых инструментов DELFI будет размещена в Yandex.Cloud. Теперь российские энергетические компании смогут воспользоваться новыми цифровыми сервисами и технологиями в области искусственного интеллекта и больших данных для повышения эффективности бизнеса.
cloud.yandex.ru/blog/posts/2021/03/schlumberger-partnership

Мониторинг в мобильном приложении
Мы добавили мониторинг в мобильное приложение Yandex.Cloud — теперь вы можете контролировать статусы всех своих сервисов, узнавать об их доступности и контролировать появляющиеся ошибки. Если вы ещё не пользуетесь — сейчас самое время начать!
cloud.yandex.ru/mobile-app

Сравнение стоимости управляемых баз данных с on‑premise и самостоятельной установкой в облаке
Рассказали, как управляемые базы данных помогают сократить нагрузку на персонал, сэкономить деньги и сосредоточиться на задачах бизнеса. Сделали расчеты, сколько стоит владение каждым из вариантов: on-premise, виртуальной машиной в облаке и управляемой базой данных.
cloud.yandex.ru/blog/posts/2021/03/mdb-advantages

Новости сервисов
Yandex Managed Service for Kubernetes
Теперь вы можете рассчитать стоимость кластера Kubernetes меньше, чем за минуту. Воспользуйтесь калькулятором в разделе Тарифы или на странице сервиса.
cloud.yandex.ru/services/managed-kubernetes

Monitoring
С помощью агентa для поставки метрик в мониторинг Yandex Unified Agent вы можете собирать и отправлять в Monitoring:

• системные метрики (CPU, RAM, сеть, диски) для Linux-совместимых ОС;
• метрики с собственных клиентских приложений;
• метрики сторонних приложений.

Агент поддерживает сбор метрик в формате Prometheus.

Новые образы в Marketplace

• PostgreSQL Pro 12.6.1
• HashiCorp Vault с поддержкой Yandex KMS
• Дашборд DataLens «Социальная реклама в Яндексе»

Публикации в СМИ
Яндекс поможет отрядам «ЛизаАлерт» искать пропавших людей по снимкам с дронов
Поисковый отряд будет загружать фотографии с дронов в облачный сервис Yandex.Cloud, оттуда снимки попадут в сервис Яндекс.Толока, где исполнители просмотрят все кадры и отметят те, на которых виден человек. Читать в источнике → tass.ru/obschestvo/10944095

Как стартап ProctorEdu следит, чтобы студенты и менеджеры России, Индии и Израиля не списывали
ProctorEdu вырос из небольшого проекта для НИУ ВШЭ. ВУЗу нужна была система для распознавания нечестного поведения студентов на экзаменах. Потом были инвестиции, 5 крупных акселераторов и несколько стран с пилотами. Подробно рассказываем о прокторинге и деятельности еще одного участника программы Yandex Cloud Boost. Читать на VC → vc.ru/services/221710-kak-startap-proctoredu-sledit-chtoby-studenty-i-menedzhery-rossii-indii-i-izrailya-ne-spisyvali

Нейронная мимикрия: насколько хорошо ИИ предсказывает музыку
Завершить «Реквием» за Моцарта или продлить саундтрек к Gravity Falls в 5 раз нейросетью… Да, возможно, но сможет ли ИИ справиться с этим хорошо или даже лучше живого музыканта? Команда AI Community при поддержке Yandex.Cloud провела конкурс среди дата-сайентистов и получила несколько инсайтов. Читать на VC → vc.ru/ml/219573-neyronnaya-mimikriya-naskolko-horosho-ii-predskazyvaet-muzyku

Виртуальные компьютерные классы и единая среда для программирования
Факультет компьютерных наук НИУ ВШЭ использовал сервисы платформы Yandex.Cloud для запуска учебных курсов. Например, с помощью Yandex DataSphere удалось создать единую среду для обучения и сократить издержки за счет бесшовного переключения конфигураций в зависимости от сложности вычислений. Читать в источнике → cs.hse.ru/news/450921539.html

Истории успеха
Как HiPer IT повысила эффективность работы систем эксплуатации
HiPer IT — разработчик решений для повышения эффективности эксплуатации инженерных систем на основе собственной IIoT-платформы HiPerWare и оборудования для сбора больших данных. Система собирает миллионы значений тысяч переменных о работе инженерных систем объектов недвижимости, анализирует их и формирует рекомендации по оптимизации работы. С помощью Yandex.Cloud компания смогла увеличить эффективность работы систем и масштабироваться.
cloud.yandex.ru/cases/hiper-it

НефтеТрансСервис: IoT-решения Yandex.Cloud для промышленного бизнес-анализа
Транспортная группа НефтеТрансСервис обратилась к компании GlowByte для проведения исследовательского проекта. С помощью сервиса Yandex DataLens они смогли обнаружить нарушения в производственном процессе, нашли резерв производственных мощностей и выявили много коротких, но частых простоев станков. Это помогло проверить изначальные гипотезы клиента и убедиться, что цифровая бизнес-аналитика может применяться в самых разных задачах.
cloud.yandex.ru/cases/ntstrans

Развернуть инфраструктуру для робота-помощника за один день
Центр цифровой трансформации Республики Татарстан полностью отвечает за автоматизацию и цифровизацию электронных сервисов Татарстана, а также занимается разработкой новых продуктов, направленных на улучшение качества жизни жителей республики. В Yandex.Cloud им удалось за один день развернуть рабочую инфраструктуру для робота-помощника Лилии, правильно спроектировать платформу на уровне архитектуры ИС и провести поверхностный аудит решения.
cloud.yandex.ru/cases/digital-tatarstan

Как сервис Anywayanyday расширил аналитику и сократил затраты с инструментами Yandex.Cloud
Платформа BI на основе Yandex Managed Service for ClickHouse и DataLens сделала мониторинг и анализ показателей бизнеса доступным для всех сотрудников. Существенно ускорились принятие решений и реакция на отклонения показателей. ИТ-отдел сократил трудозатраты на поддержку системы отчетности на 20%.
cloud.yandex.ru/cases/anywayanyday

Мероприятия
about: cloud — всё о Платформе данных
На вебинаре мы рассказали о новых сервисах платформы данных: Managed Service for Apache Kafka, Data Transfer и Managed Service for Elasticsearch. И, конечно, о новых возможностях в сервисе Managed SQL Server: восстановление на произвольную точку времени (PITR), Scaling и мониторинг: и о важных обновлениях DataLens, бесплатном тарифе для пользователей управляемых баз данных, а также о других возможностях платформы.
cloud.yandex.ru/events/342

Напишите навык для Алисы на Serverless
Научили создавать новые навыки Алисы с помощью Serverless. Писали на Go и использовали сервисы Yandex Cloud Function, Yandex DataBase, Yandex API-gateway и Object Storage. В итоге получился новый навык под названием To-Do List. С помощью голосового управления он создаёт и редактирует списки задач. Пример можно легко адаптировать к своему любимому языку программирования.
cloud.yandex.ru/events/340

Работайте над проектами, как в Яндексе
Рассказали, какие возможности есть у сервиса для организации работы Yandex Tracker, чем она может быть полезна для компаний из различных отраслей, как с помощью Tracker можно автоматизировать рутинные процессы и что меняется в продукте с переходом в Yandex.Cloud.
cloud.yandex.ru/events/339

Заоблачные продажи — ищем первого клиента
Вебинар для новичков облачного бизнеса. Разобрали основные инструменты поиска клиентов, которые есть в Yandex.Cloud, и рассказали, как лучше начать поиск и на что важно обратить внимание на первых порах.
cloud.yandex.ru/events/338

Настройки ролевых моделей и политик для Managed Service for Kubernetes
На этом вебинаре мы разобрали инфраструктуру приложения, в которой есть продуктивный и непродуктивный контуры, и настроили:

• RBAC в сервисе Managed Service for Kubernetes, используя интеграцию с IAM;
• политики работы с ресурсами Kubernetes и Docker-образами.

Можно ли создавать приложения и сервисы, забыв про серверы? Да, и скоро эта возможность будет реализована в «Облачных функциях Selectel» — платформе бессерверных вычислений. Разбейте логику приложений на микрозадачи, создайте под каждую функции и настройте их запуск по срабатыванию триггера. Больше не нужно настраивать сервер — просто пишите код.
Технология позволяет:

• Забыть про администрирование серверов и сосредоточиться на написании кода.
• Не думать о масштабировании — услуга сделает его за вас.
• Анализировать статистику и мониторить каждую выполняемую функцию.

Оптимизируйте работу своего бизнеса:

• Ускорьте процесс вывода продукта на рынок благодаря гибкому развертыванию приложения на уровне одной функции.
• Быстро обрабатывайте данные, не беспокоясь о настройке высокой доступности.
• Экономьте за счет платы только за используемые ресурсы (pay-as-you-go).

Сейчас мы находимся в стадии разработки продукта, поэтому ваша обратная связь очень нужна. Напишите нам и расскажите, есть ли у вас опыт работы с бессерверными вычислениями. А чтобы следить за прогрессом по услуге — подпишитесь на обновления.
selectel.ru/services/cloud/serverless/

Serverless ― это не про физическое отсутствие серверов. Это не «убийца» контейнеров и не мимолетный тренд. Это новый подход к построению систем в облаке. В сегодняшней статье коснемся архитектуры Serverless-приложений, посмотрим, какую роль играет провайдер Serverless-услуги и open-source проекты. В конце поговорим о вопросах применения Serverless.

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

А что если взять эфемерные контейнеры, в которых требуемые зависимости уже предустановлены, а сами контейнеры изолированы друг от друга и от ОС хоста? Монолит разобьем на микросервисы, каждый из которых можно обновлять и масштабировать независимо от других. Поместив код в такой контейнер, я смогу запускать его на любой инфраструктуре. Уже лучше.

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

Такие мысли привели меня к бессерверным вычислениям. Serverless в данном случае означает не физическое отсутствие серверов, а отсутствие головной боли по управлению инфраструктурой.

Идея в том, что логика приложения разбивается на независимые функции. Они имеют событийную структуру. Каждая из функций выполняет одну «микрозадачу». Все, что требуется от разработчика ― загрузить функции в предоставленную облачным провайдером консоль и соотнести их с источниками событий. Код будет исполняться по запросу в автоматически подготовленном контейнере, а я заплачу только за время исполнения.

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

Со стороны разработчика
Ранее мы начали говорить про приложение для интернет-магазина. В традиционном подходе основную логику системы выполняет монолитное приложение. И сервер с приложением запущен постоянно, даже если нагрузки нет.

Чтобы перейти к Serverless, разбиваем приложение на микрозадачи. Под каждую из них пишем свою функцию. Функции независимы друг от друга и не хранят информацию о состоянии (stateless). Они даже могут быть написаны на разных языках. Если одна из них «упадет», приложение целиком не остановится. Архитектура приложения будет выглядеть вот так:


Деление на функции в Serverless похоже на работу с микросервисами. Но микросервис может выполнять несколько задач, а функция в идеале должна выполнять одну. Представим, что стоит задача собирать статистику и выводить по запросу пользователя. В микросервисном подходе задачу выполняет один сервис с двумя точками входа: на запись и на чтение. В бессерверных вычислениях это будут две разные функции, несвязанные между собой. Разработчик экономит вычислительные ресурсы, если, например, статистика обновляется чаще, чем выгружается.

Serverless-функции должны выполняться за короткий промежуток времени (timeout), который определяет провайдер услуги. Например, для AWS timeout составляет 15 минут. Значит, долгоживущие функции (long-lived) придется изменить под требования ― этим Serverless отличается от других популярных сегодня технологий (контейнеров и Platform as a Service).

Каждой функции назначаем событие. Событие ― это триггер для действия:


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

Архитектуру проработали, и приложение почти стало Serverless. Дальше идем к провайдеру услуги.

Со стороны провайдера
Обычно бессерверные вычисления предлагают провайдеры облачных услуг. Называют по-разному: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

Пользоваться услугой будем через консоль или личный кабинет провайдера. Код функций можно загрузить одним из способов:

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

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


Провайдер на своей инфраструктуре построил и автоматизировал систему Function as a Service (FaaS):

• Код функций попадает в хранилище на стороне провайдера.
• Когда появляется событие, на сервере автоматически разворачиваются контейнеры с подготовленным окружением. Каждому экземпляру функции ― свой изолированный контейнер.
• Из хранилища функция отправляется в контейнер, вычисляется, отдает результат.
• Число параллельных событий растет ― растет количество контейнеров. Система автоматически масштабируется. Если пользователи не обращаются к функции, она будет неактивна.
• Провайдер задает время простоя контейнеров ― если в течение этого времени функции не появляются в контейнере, он уничтожается.

Таким образом мы получаем Serverless «из коробки». Платить за услугу будем по модели pay-as-you-go и только за те функции, которые используются, и только за то время, когда они использовались.

Чтобы познакомить разработчиков с услугой, провайдеры предлагают до 12 месяцев бесплатного тестирования, но ограничивают общее время вычислений, количество запросов в месяц, денежные средства или потребляемые мощности.

Основное преимущество работы с провайдером ― возможность не беспокоиться об инфраструктуре (серверах, виртуальных машинах, контейнерах). Со своей стороны провайдер может реализовать FaaS как на собственных разработках, так и с помощью open-source инструментов. О них и поговорим дальше.

Со стороны open source
Последние пару лет сообщество open-source активно работает над инструментами Serverless. В том числе вклад в развитие бессерверных платформ вносят крупнейшие игроки рынка:

• Google предлагает разработчикам свой open-source инструмент ― Knative. В его разработке участвовали IBM, RedHat, Pivotal и SAP;
• IBM работали над Serverless-платформой OpenWhisk, которая затем стала проектом Apache Foundation;
• Microsoft частично открыли код платформы Azure Functions.

Разработки ведутся и в направлении serverless-фреймворков. Kubeless и Fission разворачиваются внутри заранее подготовленных Kubernetes-кластеров, OpenFaaS работает как с Kubernetes, так и с Docker Swarm. Фреймворк выступает в роли своеобразного контроллера ― по запросу готовит внутри кластера среду выполнения, потом запускает там функцию.

Фреймворки оставляют простор для конфигурации инструмента под свои нужды. Так, в Kubeless разработчик может настроить timeout выполнения функции (дефолтное значение ― 180 секунд). Fission в попытке решить проблему холодного старта предлагает часть контейнеров держать все время запущенными (хоть это и влечет затраты на простой ресурсов). А OpenFaaS предлагает набор триггеров на любой вкус и цвет: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs и другие.

Инструкции к началу работы можно найти в официальной документации фреймворков. Работа с ними подразумевает наличие чуть большего количества навыков, чем при работе с провайдером ― это как минимум умение запустить Kubernetes-кластер через CLI. Максимум, включить в работу другие open-source инструменты (допустим, менеджер очередей Kafka).

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

Google предлагает разработчикам свой open-source инструмент ― Knative. В его разработке участвовали IBM, RedHat, Pivotal и SAP;
IBM работали над Serverless-платформой OpenWhisk, которая затем стала проектом Apache Foundation;
Microsoft частично открыли код платформы Azure Functions.
Разработки ведутся и в направлении serverless-фреймворков. Kubeless и Fission разворачиваются внутри заранее подготовленных Kubernetes-кластеров, OpenFaaS работает как с Kubernetes, так и с Docker Swarm. Фреймворк выступает в роли своеобразного контроллера ― по запросу готовит внутри кластера среду выполнения, потом запускает там функцию.

Фреймворки оставляют простор для конфигурации инструмента под свои нужды. Так, в Kubeless разработчик может настроить timeout выполнения функции (дефолтное значение ― 180 секунд). Fission в попытке решить проблему холодного старта предлагает часть контейнеров держать все время запущенными (хоть это и влечет затраты на простой ресурсов). А OpenFaaS предлагает набор триггеров на любой вкус и цвет: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs и другие.

Инструкции к началу работы можно найти в официальной документации фреймворков. Работа с ними подразумевает наличие чуть большего количества навыков, чем при работе с провайдером ― это как минимум умение запустить Kubernetes-кластер через CLI. Максимум, включить в работу другие open-source инструменты (допустим, менеджер очередей Kafka).

Вне зависимости от того, каким способом мы будем работать с Serverless ― через провайдера или с помощью open-source, мы получим ряд преимуществ и недостатков Serverless-подхода.

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

• Serverless сокращает время разработки еще больше, позволяя разработчику сосредоточиться исключительно на бизнес-логике приложения и написании кода. Как следствие, время выхода разработок на рынок сокращается.
• Бонусом мы получаем автоматическое масштабирование под нагрузку, а платим только за используемые ресурсы и только в то время, когда они используются.

Как и любая технология, Serverless имеет недостатки.

• Например, таким недостатком может быть время холодного старта (в среднем до 1 секунды для таких языков как JavaScript, Python, Go, Java, Ruby).

С одной стороны, на деле время холодного старта зависит от многих переменных: язык, на котором написана функция, количество библиотек, объем кода, общение с дополнительными ресурсами (те же базы данных или серверы аутентификации). Поскольку разработчик управляет этими переменными, он может сократить время старта. Но с другой стороны, разработчик не может управлять временем запуска контейнера ― здесь все зависит от провайдера.

Холодный старт может превратиться в теплый, когда функция переиспользует запущенный предыдущим ивентом контейнер. Такая ситуация возникнет в трех случаях:

• если клиенты часто используют сервис и растет количество обращений к функции;
• если провайдер, платформа или фреймворк позволяют держать часть контейнеров запущенными все время;
• если разработчик запускает функции по таймеру (скажем, каждые 3 минуты).

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

• Следующим недостатком Serverless называют короткое время жизни функции (timeout, за который функция должна выполниться).

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

• Не все системы смогут работать по Serverless-схеме.

Некоторые приложения по-прежнему будут хранить данные и состояние во время выполнения. Некоторые архитектуры останутся монолитными, а некоторые функции будут долгоживущими. Однако (как когда-то облачные технологии, а затем и контейнеры), Serverless ― технология с большим будущим.

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

Со стороны применения
За 2018 год процент использования Serverless вырос в полтора раза. Среди компаний, которые уже внедрили технологию в свои сервисы, такие гиганты рынка как Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. При этом нужно понимать, что Serverless ― не панацея, а инструмент для решения определенного круга задач:

• Сократить простой ресурсов. Не надо постоянно держать виртуальную машину под сервисы, к которым мало обращений.
• «На лету» обработать данные. Сжимать картинки, вырезать фон, менять кодировку видео, работать с датчиками IoT, выполнять математические операции.
• «Склеить» между собой другие сервисы. Git-репозиторий с внутренними программами, чат-бот в Slack с Jira и с календарем.
• Балансировать нагрузку. Здесь остановимся подробнее.

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

Можно включить в систему балансировщик, который будет распределять нагрузку, скажем, на три виртуальные машины. На данном этапе мы не можем точно спрогнозировать нагрузку, поэтому какое-то количество ресурсов держим запущенными «про запас». И переплачиваем за простой.

В такой ситуации мы можем оптимизировать систему через гибридный подход: за балансировщиком нагрузки оставляем одну виртуальную машину и ставим ссылку на Serverless Endpoint с функциями. Если нагрузка превышает порог ― балансировщик запускает экземпляры функций, которые берут на себя часть обработки запросов.


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

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

Serverless и Selectel
В Selectel мы уже упростили работу с Kubernetes через нашу панель управления. Теперь мы строим собственную FaaS-платформу. Мы хотим, чтобы разработчики могли решать свои задачи с помощью Serverless через удобный, гибкий интерфейс.

Если у вас есть идеи, какой должна быть идеальная FaaS-платформа и как вы хотите использовать Serverless в своих проектах, поделитесь ими в комментариях. Мы учтем ваши пожелания при разработке платформы.

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

На днях мы запустили первое в России serverless облако — Rusonyx Serverless на базе платформы Swifty. Первые три месяца использования платформой бесплатны, так что все желающие могут попробовать serverless подход в деле.

В статье я расскажу, как создать простое todo приложение с аутентификацией, профилем пользователя, хранением картинок и, собственно, управлением задачами используя serverless подход. Мы, естественно, будем делать это на Swifty, но подход здесь примерно одинаков для всех serverless решений. Пример готового приложения можно посмотреть здесь. Фронтенд написан на vue.js, запускать который мы будем на встроенном Object Storage (S3), бекенд будем делать на функциях на Go и Python.

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

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


Теперь, когда у вас есть аккаунт можно приступать к созданию самих функций. Swifty включает сервис аутентификации — Authentication, который дает базовые операции signup, signin и logout, а также возможность создавать, изменять, получать и удалять профиль пользователя. В нем есть также интеграция с Facebook и возможность связывать уже созданный профиль с профилем Facebook. Но они нам пока не понадобятся. Maybe later.

Создаем сервис аутентификации:

• Открываем Swifty -> Authentication Services.
• Нажимаем Create Auth Database и называем базу todoapp. Я в дальнейшем буду использовать это название, но вы можете назвать свою базу по-желанию.

В результате будет создано много чего:

• Функция todoapp.base — делает signup, signin и logout пользователей, реализует OAuth 2.0 протокол.
• Функция todoapp.fb — позволяет аутентифицировать пользователей через fb.
• Функция todoapp.link — связывает аккаунты уже созданных пользователей с их аккаунтами на fb.
• Функция todoapp.profiles — создает, обновляет, удаляет профили пользователей в MongoDB.
• БД todoapp_mgo — Mongo для хранения аккаунтов пользователей.
• БД todoapp_profiles — Mongo для хранения профилей пользователей.
• Authentication Middleware (AuthMW) — прокси, который позволяет при обращении к API функции проверять аутентификацию пользователя через проверку его JWT токена, который ему выдала функция todoapp.base. Нет токена или он не верен — запрос к API будет отброшен.

Мы используем “.” в наименовании функций для разделения их по папкам. Поэтому если вы создадите новую функцию с именем todoapp.newfunction, то она автоматически попадет в папку todoapp и отобразится там с именем newfunction. Ваш список функций теперь должен содержать следующий набор (см.картинку).


Можно пропустить, но лучше прочитать
Этот параграф, в принципе, можно пропустить. Или нет, если вы хотите понять, как работает наш сервис аутентификации и чуть больше понять о принципах работы Swifty. Функция todoapp.base, написанная на Go, дает базовые возможности аутентификации, но ничто не мешает вам расширить ее возможности в соответствии с потребностями вашего приложения. Как бы вы ее не меняли, не трогая signin и signout, она все-равно будет делать свою работу. В функции есть переменная SWIFTY_AUTH_NAME, которая хранит название AuthMW. Функции также нужен доступ к MongoDB и собственно AuthMW, которые прописаны на вкладке Access в свойствах функции. Также у нее есть REST API триггер у которого есть ссылка, которую и нужно вызывать, чтобы получить доступ к функции.

Функция todoapp.base ожидает, что вы передадите ей userid и password в виде аргументов запроса. При этом пароль шифруется.

Вот примеры таких запросов:

* Sign up:
https://api.swifty.cloud:8686/call/012.../signup&userid=user@yourmail.com&password=xxxxxxxx
* Sign in:
https://api.swifty.cloud:8686/call/012.../signin&userid=user@yourmail.com&password=xxxxxxxx
* Log out:
https://api.swifty.cloud:8686/call/012.../leave&userid=user@yourmail.com

Если, например, signin был успешен (функция успешно проверила переданный пароль), то вы получите JSON с JWT токеном, который нужно будет использовать каждый раз при обращении к функциям, для которых включена аутентификация. JWT токен создается на базе Bearer Authentication схемы. Подробнее про OAuth 2.0 и Bearer cхему можно прочитать тут.

Если аутентификация не успешна, то вызываемая функция не запускается и запрос возвращает код 401.

Управление профилем пользователя
Итак, у каждой функции есть REST API url, ссылка, которую нужно вызвать, чтобы запустить функцию. Чтобы получить эту ссылку для функции аутентификации, откройте функцию todoapp.base, перейдите на вкладку Triggers, скопируйте REST API url и сохраните его как AUTH_URL где-нибудь. Чуть дальше нам потребуется вставить эту ссылку в конфигурационный файл фронтенда нашего приложения.


Также нам нужен API URL для todoapp.profiles, чтобы наше приложение могло управлять профилями пользователей. Откройте эту функцию, перейдите на вкладку Triggers, скопируйте REST API url и сохраните его как PROFILE_URL.

Управление аватаром пользователя
Наше приложение также позволяет загрузить аватар пользователя и продемонстрировать, как можно хранить файлы на встроенном Object Storage. Картинка пользователя загружается с помощью специальной функции и хранится на встроенном Object Storage. Доступ к картинке можно получить через функцию или с помощью стандартного S3 API, ключи доступа к которому можно получить на вкладке управления Object Storage в UI.

Чтобы создать функцию управления картинками:

• Переходим на вкладку Functions -> New Function -> From repo (Templates). Мы храним все шаблоны функций в публичном git репозитории swifty.demo. Этот репозиторий должен быть выбран по умолчанию.
• Выберите функцию Avatar management (python), нажмите Next и введите имя новой функции todoapp.avatar. Нажмите Create.
• Далее перейдите на вкладку Triggers, нажмите Add Trigger, выберете REST API (URL). Скопируйте появившуюся ссылку и сохраните ее как PICTURE_URL.

Далее нужно создать бакет в Object Storage для хранения картинок пользователей:

• Переходим на вкладку Object Storage -> Create Bucket. Назовите новый бакет todoappimages.
• Переходим на вкладку Functions -> todoapp.avatar -> Access -> нажимаем Add, выбираем Object Storage, вновь созданный бакет todoappimgaes и жмем Add.

Теперь наша функция имеет доступ к указанному бакету. Так просто и нам не нужно прописывать никакие доступы к бакету внутри функции. Единственное, мы должны указать функции, в каком бакете хранить картинки с помощью переменной окружения:

• Переходим на вкладку Functions -> todoapp.avatar -> Variables и нажимаем Create Variable.
• Вводим имя переменной — BUCKET_NAME, и ее значение — todoappimages.

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

Создаем функцию:

• Переходим на вкладку Functions -> New Function -> From repo (Templates).
• Выберите функцию TODO application (python), нажмите Next и введите имя новой функции todoapp.tasks. Нажмите Create.
• Далее перейдите на вкладку Triggers, нажмите Add Trigger, выберете REST API (URL). Скопируйте появившуюся ссылку и сохраните ее как TASKS_URL.

Далее нам нужна база данных, чтобы хранить наши задачи. Самый простой вариант — MongoDB.

• Переходим на вкладку Mongo Database -> Create Database и создаем базу с именем todoapp_tasks.
• Переходим на вкладку Functions -> todoapp.tasks -> Access -> Add и добавляем новую базу.

Теперь наша функция имеет доступ к БД todoapp_tasks и мы можем обратиться к ней из функции с помощью библиотеки swifty, например так:

db = swifty.MongoDatabase(os.getenv('TASKS_DB_NAME’))

Нам осталось только прописать переменную окружения с именем базы данных:

• Переходим на вкладку Functions -> todoapp.tasks -> Variables и нажимаем Create Variable.
• Вводим имя переменной — TASKS_DB_NAME, и ее значение — todoapp_tasks.
• Включаем аутентификацию для функций

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

Как включить проверку токенов для определенных функций:

• Переходим на вкладку Functions и выбираем функции todoapp.tasks и todoapp.avatar.
• Нажимаем Manage Authentication и выбираем сервис todoapp, нажимаем Enable.
• Теперь, функции todoapp.tasks и todoapp.avatar будут выполнены только для пользователей с правильным JWT токеном сгенерированным с помощью todoapp.base.

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


Публикация приложения
Займемся фронтендом нашего приложения. Фронтенд написан на vue.js и нам нужно всего лишь добавить ссылки на наши функции в его конфигурационный файлик и пересобрать приложение с этой обновленной конфигурацией. Здесь все просто и никаких знаний vue.js и JavaScript не понадобиться.

Для того, чтобы пересобрать приложение вам нужен установленный node.js. Если у вас его нет, то используйте, пожалуйста, официальный гайд, чтобы его поставить. Если у вас mac, то есть хороший гайд здесь. Также вам понадобиться git, чтобы стянуть репозиторий себе на компьютер. Пожалуйста, сделайте:

# git clone https://github.com/swiftycloud/swifty.todoapp

После этого перейдите в папку /swifty.todoapp/src и откройте файл config.js в вашем любимом редакторе. Вам нужно поменять содержащиеся там переменные на на те, которые вы сохранили ранее:

export const AUTH_URL = "https://api.swifty.cloud/call/991..."
export const PROFILE_URL = "https://api.swifty.cloud/call/281..."
export const PICTURE_URL = "https://api.swifty.cloud/call/e6a..."
export const TASKS_URL = "https://api.swifty.cloud/call/4b1..."

Переменные связанные с FB нам пока не нужны.

Затем вам нужно пересобрать приложение:

# npm run build
…
DONE Build complete. The dist directory is ready to be deployed.

Прежде чем собрать приложение вы можете также протестировать его локально:

# npm run serve

и зайти в него через браузер по адресу localhost:8080

Мы используем Object Storage для хранения статических файлов нашего приложения. Перейдите на вкладку Object Storage, создайте бакет todoapp и загрузите в него файлы из папки /swifty.todoapp/dist/ соблюдая именование папок (их придется создать руками).

Последний шаг — публикация приложения. Нажмите More -> HTTP Server Settings и включите HTTP Server для вашего бакета. Скопируйте появившуюся ссылку и перейдите по ней — это и есть ваше приложение!


Теперь вы можете создать в нем аккаунт и попробовать его в действии. Если теперь перейти на экран функций, то вы увидите, что функции были только что запущены — для аутентификации, загрузки профиля и тд.

Что дальше?
Мы показали простой пример, как использовать serverless для создания приложений. У нас еще много шаблонов популярных функций, а у вас, я уверен, еще много идей для новых приложений. Пробуйте шаблоны, пишите свои функции и make your ideas come app.

Ну и конечно же, обращайтесь, если у вас есть какие-то вопросы по serverless вообще и Swifty в частности.
www.rusonyx.ru/swifty/

Каждый раз, когда приходится читать про очередного новорожденного убийцу айфона или фейсбука, невольно начинаешь улыбаться. За эти годы столько их уже было, а воз и ныне там. Поэтому, наткнувшись на очередную публикацию, где ключевой мыслью была идея о том, что наступающая эпоха бессерверных вычислений приложений (Serverless) «съест» DevOps, скепсису не было предела.

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

Появление концепции Serverless, предполагающей создание и запуск приложений без необходимости настраивать серверную часть на этом фоне кажется вполне логичным. Несмотря на популярность названия «Serverless», встречается также аббревиатура FaaS («Functions as a Service»). Так вот, вас не должно вводить в заблуждение пресловутое Serverless. Оно вовсе не означает полный отказ от серверов. Как известно: «Если что-то убыло, значит где-то прибыло». В данном случае, речь идет о том, что железо уходит на сторону Amazon, Microsoft и других монстров индустрии, предоставляя рядовым разработчикам возможность творить без оглядки на размер серверного шкафа и хороших отношений с командой DevOps.



Основные преимущества концепции Serverless:

Простота создания и развертывания продукта;
Возможность быстро и просто масштабировать ваш проект;
Высокая доступность и отказоустойчивость бекенда;
Отсутствие необходимости управления серверной инфраструктурой и как следствие снижение ваших затрат на поддержку ее работоспособности;
Ускорение разработки приложений;
Сокращение затрат на инфраструктуру и DevOps (и вам больше не нужен Docker);

Больше информации по теме можно почерпнуть, например, здесь, здесь и здесь.

DevOps умер, да здравствует DevOps?

Serverless является отличным дополнением к автоматизации. Любой хороший DevOps, использующий AWS, Azure, IBM Cloud или GCP, способен применить соответствующие бессерверные решения для повышения управляемости приложений. Но чем насыщенней среда, тем нужнее люди способные к ней адаптироваться. Иными словами, DevOps, конечно же не умрет, но требования к знаниям и навыкам специалистов неизбежно эволюционируют.

Тем более, что сфера применения serverless уже сейчас очень широка:

• Финансы
• Ритейл
• IoT
• Социальные медиа
• Чаты
• Uber-like приложения

Где на serverless можно реализовывать очень разные сценарии:

• Backend для приложений и сайтов
• Data Processing (images, video, логи)
• IoT (включая SmartCity)
• Serverless веб-сайты
• Автоматизированные задачи (включая бекапы)
• Cloudlet
• (data preprocessing)
• Чат-боты
• Окружения для обучения программированию

Кто здесь?
Крупные игроки уже на этом рынке: Amazon AWS, Azure, IBM Cloud, Google Cloud, Oracle. Имея значительные ресурсы, ИТ-гиганты способны работать в перспективных направлениях, улавливая тренды и существенно опережая отрасль в своем развитии. Плюс, есть множество Open Source проектов, в той или иной степени реализующие serverless. Тем интереснее российский ландшафт.


Сегодня мы имеем довольно пеструю картину. С одной стороны, как и во всем мире, доминируют решения от лидеров рынка типа Microsoft, Amazon и Google, а с другой стороны, возникают по-настоящему интересные альтернативы.

К таковым можно отнести первое в России serverless облако — Rusonyx serverless на базе swifty.cloud. Эта штука – простой путь к махровому крутому, масштабируемому бекенду.

Rusonyx serverless на базе swifty.cloud фактически — out-of-the-box платформа для бекендов приложений, сайтов и чат-ботов, но при этом не лимитированная возможностями традиционных Backend-as-a-Service решений. Она включает в себя большинство необходимых сервисов:

• Serverless функции
• SQL и noSQL базы данных
• Object Storage
• Authentication-as-a-Service
• Симпатичный UI, API, CLI для Mac/Linux
• Шаблоны функций и целых сервисов

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

Вместо заключения
Мы всё дальше уходим от набора навыков, которые ассоциируется с традиционным DevOps. Технологии меняются, а вместе с ними должны меняться и мы. При этом, даже если за вас всё делает облачный провайдер, функция контроля качества продукта никуда не денется. Автоматизация освобождает вас от каждодневной рутины, предоставляя возможность заняться тем, что вы, возможно, долгое время откладывали в долгий ящик.

Make your ideas come app, как говорят ребята из swifty.cloud