Онлайн образование. Serverless вычисления

1.

О Н Л А Й Н - О Б РА З О В А Н И Е

2.

Serverless вычисления

3.

Меня хорошо слышно
&& видно?
Напишите в чат, если есть проблемы!
Ставьте + если все хорошо

4.

Содержание
Что такое serverless вычисления
Виды serverless услуг
Примеры
Плюсы и минусы serverless решений
Кейсы использования
4

5.

Что такое serverless?

6.

Модели дистрибуции
• SAAS (Software-as-a-service): Предоставляет доступ к какому
либо приложению. SAAS может разрабатываться на PAAS и
IAAS. Примеры: GitHub, Bitrix, Jira, DropBox
• PAAS (Platform-as-a-service): Предоставляет доступ к какойлибо платформе. Может быть реализован над IAAS. Примеры:
Heroku, AWS LightSail
• IAAS (Infrastructure-as-a-service): Предоставляет доступ к
инфраструктуре, в которой можно запускать свои сервисы.
Примеры: AWS EC2, GCE
• *AAS (component-as-a-service): остальные, узкоспециализированные типы услуг (DBAAS, FAAS…)
6

7.

Зона ответственности
7

8.

Бессерверные вычисления
• Бессерверные вычисления - это решение (модель дистрибуции),
в котором выполнение кода / программы полностью управляется
облачным провайдером, а не традиционным способом разработки
приложений и их развертывания на серверах.
8

9.

Виды serverless услуг
Functions

10.

Function as a service
• FAAS – это вид услуги, в которой вы можете организовать ваш код в
виде функции, а все накладные расходы возьмет на себя провайдер
10

11.

За что платим?
• Pay as you go – платим только за то, что используем. Отсюда
стоимость использования функции вычисляется на основе: времени
исполнения функции, ресурсов на выполнение (память, cpu),
трафик
• Стоимость можно рассчитать в TCO калькуляторе
11

12.

Зона ответственности провайдера
• Масштабируемость – должна быть возможность запускать
достаточное кол-во копий функции (но есть ограничения) для того,
чтобы справиться с нагрузкой
• Мониторинг – провайдер должен предоставить инструменты
мониторинга. Иначе не очевидно, успешно ли отработала функция,
и за сколько времени (для расчета стоимости)
• Отказоустойчивость – все инфраструктурные задачи ложатся на
провайдера. Касательно гарантированной работы нужно смотреть
SLA
12

13.

Кейсы использования
• Private REST API – функция, которую могут дергать ваши сервисы.
Например, это может быть система уведомлений без
гарантированной доставки (как PUSH-уведомления)
• Batch processing – выполнение отложенной работы. Например,
отложенный парсинг файлов (загрузили файл, отправили
сообщение в очередь, функция взяла сообщение из очереди, и
распарсила файл в БД).
• Public REST API* – реализация полностью serverless бэкенда для
ваших пользователей. Хороший пример – a cloud guru
• Cloud integration – функция может использоваться как элемент
интеграции между сервисами. Например, при отправке сообщения в
очередь, включается виртуальная машина
13

14.

На что стоит обратить внимание
• Экосистема – что идет вокруг функций (триггеры, network, queues,
auth, etc.)
• Виды стартов – поддержка горячего старта
• Поддержка ЯП* – какие яп поддерживаются (не во всех случаях это
важно)
• Виды функций – как можно реализовать функцию
14

15.

Экосистема. Триггеры
• Триггеры – Это интерфейс, по которому могут запускаться ваши
функции
Примеры триггеров в AWS:
Kinesis
DynamoDB
SQS Application
Load Balancer
Alexa API Gateway
SNS
CloudFormation
CloudWatch Logs / Events
Events S3
15

16.

Экосистема. Networking
• VPC – возможно ли использовать приватную сеть внутри облака
(для соединения с БД)
• Можно ли использовать приватную сеть внутри кластера
(например на Kubernetes). Если да, то можно ли использовать alias?
16

17.

Виды стартов
• Холодный старт – приложение запускается в первый раз. А значит
ему нужно загрузить все зависимости (если они есть)
• Горячий старт – Образуется нагрузка (много обращений к
функции). В этом случае, функция отработала, но приложение не
вышло – а взяло в обработку следующий запрос. Как следствие –
экономия на старте приложения.
17

18.

Виды стартов. Горячий старт
• Проблема конкурентного доступа – допустим, функция
запустилась. Вы работайте с СУБД. Для работы с базой, вам надо
открыть сессию. Конкурентное открытие сессии – может вызвать
ошибку. Вывод – использовать примитивы синхронизации.
• Не патчите библиотеки в runtime
• Глобальный контекст- стараемся делать stateless, иначе
примитивы синхронизации в помощь
18

19.

Поддержка ЯП и виды функций
• Провайдер может иметь возможность реализовать функции по
разному – пример GCP Cloud Functions и Cloud Run
• Поддержка ЯП – важна, если вы не управляйте runtime
19

20.

Ограничения функций
Максимальное время исполнения
Число одновременно запущенных функций
Возможно не будет триггера под ваш кейс
Возможно вас не устроит поддержка VPC
Ваш ЯП может не поддерживаться
Могут не устроить поддерживаемые версии runtime
Может быть сложное администрирование (деплой, замена
версий, откат версии)
20

21.

Плюсы функций
• Прозрачное масштабирование
• Если никто не пользуется вашим сервисам – вы не платите за
простой
• Настроенный мониторинг
• Не надо думать об отказоустойчивости
• Можно хорошо распараллелить работу
21

22.

Как правильно проектировать?
• Функции должны загружаться как можно быстрее
• Функции должны выполнять одну единственную функцию – не надо
пихать туда вещи, типа сервера на graphql
• Функции должны быть ограничены по времени исполнения –
функция должна исполняться за одинаковое время (то есть за
линейное кол-во времени)
• У вас должны быть примерные метрики в голове, прежде чем вы
решите использовать функции (то есть время исполнения, среднее
кол-во запросов), иначе можно попасть на большой чек, или провал
в нагрузке
22

23.

Виды serverless услуг
Computing

24.

Application as a service
• AAAS – это вид услуги, в которой вы можете задеплоить ваше
приложение, без нужды администрирования инфраструктуры
24

25.

Реализации
• GCP app engine
• AWS beanstalk
25

26.

За что платим?
• Pay as you go – платим только за то, что используем (включая up
time приложения 24/7). Отсюда стоимость использования
вычисляется на основе: времени исполнения, ресурсов на
выполнение (память, cpu), трафик
• Стоимость можно рассчитать в TCO калькуляторе
26

27.

Зона ответственности провайдера
• Масштабируемость – должна быть возможность запускать
достаточное кол-во копий приложения для того, чтобы справиться с
нагрузкой
• Мониторинг – провайдер должен предоставить инструменты
мониторинга. Иначе не очевидно, успешно ли отработала функция,
и за сколько времени (для расчета стоимости)
• Отказоустойчивость – все инфраструктурные задачи ложатся на
провайдера. Касательно гарантированной работы нужно смотреть
SLA
27

28.

Ограничения
Возможно вас не устроит поддержка VPC
Ваш ЯП может не поддерживаться
Могут не устроить поддерживаемые версии runtime
Может быть сложное администрирование (деплой, замена
версий, откат версии)
28

29.

Плюсы
Прозрачное масштабирование
Настроенный мониторинг (но не во всех случаях)
Не надо думать об отказоустойчивости
Можно быстро развернуть приложение. Хороший кейс – если у вас
не сложный проект (например просто интернет магазин, или сайт
на wordpress)
29

30.

Виды serverless услуг
Storage

31.

Database as a service
• DBAAS – это вид услуги, вы можете арендовать базу данных у
облачного провайдера. Также, некоторые провайдеры предлагают
полностью управляемое ими решение (то есть мы даже не
указываем, сколько ресурсов выделять на БД).Такие БД и есть
serverless
31

32.

Реализации
GCP BigTable
GCP BigQuery
GCP FireStore
GCP Spanner
AWS Dynamo
AWS Neptune
32

33.

За что платим?
• Pay as you go – платим только за то, что используем. Отсюда
стоимость использования функции вычисляется на основе: трафик
(входящий / исходящий), размер данных, размер индексов, время
исполнения запросов
• Стоимость можно рассчитать в TCO калькуляторе
33

34.

Когда есть смысл использовать?
• Эти решения не для маленьких проектов!
• У вас много данных (больше 10TB), и вам надо с ними работать
(то есть не архивные данные)
• Стоимость поддержки вашей инфраструктуры на стандартных
СУБД существенно выше, чем расчет использования cloud native
баз данных через TCO
34

35.

Опрос
https://otus.ru/polls/7761/
35

36.

Спасибо
за внимание!