Смотри. Можно, допустим, очередь взять YMQ у нее есть возможность сразу писать триггеры (это такие специализированные функции). Допустим приходит сообщение в такую очередь и срабатывает триггер, которые обрабатывает сообщение. Если сразу много сообщений, то эти триггеры масштабируются. Тогда реббита не будет. Очередь и триггеры будут по схеме Serverless работать.
Модель работы как раз предполагает комбинирование с уже запущенными приложениями и сервисами. Допустим, уже работает приложение в виртуалке и вы складываете данные в рядом поднятую БД. Легко пишется функция, которая ходит в БД и работает с этими данными.
Первая: техническая безопасность здания. Тут сложно будет ответить вместо инженеров обслуживающих ДЦ. Кажется, что для клиентов раньше делали экскурсии, и на подобные вопросы отвечали прямо во время оной. Думаю можно устроить разведопрос и рассказать как все устроено, если это интересно конечно.
Вторая: инфраструктурная безопасность сервисов. Тут все просто и сложно одновременно. Есть сервисы, которые сразу живут в нескольких дата центрах. Такие сервисы разрабатываются с установкой — жить без одного ДЦ в аварийной ситуации. И в случае «учений», живут. Однако вопрос доступности это ответственность не только провайдера, но и клиента.
Например. Бывает, что вместо кластера Managed Service for PostgreSQL с узлами в трех зонах доступности и регулярными бекапами клиент сколхозил все на одной виртуалке без бекапов. Очевидно, что риски в такой ситуации весьма приличные. У каждого крупного провайдера, каждый день умирает некоторая часть железа, ибо железо не вечно и всякое случается.
Но вопрос большой, и одним коментом на него не ответить. Хорошая идея для большой статьи, спасибо.
Мысль «наделали на миллион долларов» многим не очевидна. Тут же дело в том что это кост на оказание какой-то услуги или предоставления какого-то сервиса. И эти косты очень просто складываются в P&L табличку, но обычно этим оперирует уже бизнес и потому эти вещи не матчатся у многих.
Мы в Yandex Serverless Ecosystem время от времени проводим zoombar, было бы круто послушать ваш опыт. Совершенно не важно на базе какого провайдера вы работаете.
Почти у всех провайдеров есть программы типа free tier и если реально сесть и посчитать то большинство рутинных операций укладывается в предоставленные лимиты для хоббийного применения.
Но если у вас есть реальная нагрузка и вы понимаете ее паттерн, то конечно легко можно посчитать что вам выгоднее.
Когда освоил и эффективно работаешь с основным инструментом то можно заняться и дополнительными. Вот допустим, можно отпилить кусок доски пилой европейского типа, можно воспользоваться японской, а можно применить торцовку. Результат примерно один и тот-же, но диапазон применения, скорость, накладные расходы и эффективность в разных случаях будет разной. И каждый раз от строителя, монтажника дверей, столяра и плотника будешь слышать: вот я всю жизнь пользуюсь одной пилой остальное ненужно. В итоге, просто нужно выбирать инструмент из реальной потребности, а для этого им надо хоть немного попользоваться.
Если вы равномерно плотно займете весь озвученный объем вызовами круглосуточно то конечно чистое железо обойдется вам значительно дешевле, на вскидку в два раза у любого провайдера.
Но будем честными, скорее всего реальной работы ваш сервер делает не так много, и нагрузка имеет свое определенный паттерн. Есть паттерны при которых вызовы функций будут многократно эффективнее, есть в которых будут значительно проигрывать. Просто инструмент, которым нужно пользоваться осмысленно.
Вы правы, началось все с FaaS, но стало понятно что одними функциями нельзя ограничиваться. Тогда нашли название, под которое можно собрать ряд сервисов с похожим способом использования. Под капотом как и прежде работают сервера и от этого никуда не уйти.
я бы сказал что это зонтичный термин объединяющий набор сервисов для реализации приложений в event based идеологии, конечно, основанный на дополнительной абстракции исключающей взаимодействие с серверами на прямую.
Если есть работающая система на lambda, то думаю сейлзы Yandex.Cloud пересчитают всю систему легко, это же их работа таким заниматься. Но кажется, в целом на круг экономия может составить от 20% до 50%, это конечно потолочные данные, но я бы реально просто пришел пообщаться с ними на эту тему.
AWS Lambda умеют, Yandex Cloud Functions пока нет. Разработчики хотят сделать и чтобы оно быстрее впрыгнуло в план, помогите, оставьте свой фичереквест тут — cloud.yandex.ru/features
Думаю будет интересно посмотреть на платформу Serverless от Yandex. При этом — это полноценная самостоятельная разработка, а не купленная у Huawei инсталляция. Для примера пара материалов:
Программный комитет скаутит по зарубежным конференциям, чтобы найти лучших спикеров и затащить их в орбиту наших конференций. Думаю коллеги делают они из лучших конференций в мире, через это многие англоязычные товарищи видят прекрасную возможность выступить. Работа со всеми поданными докладами, как мне кажется, идет одинаковым способом.
Русскоязычных докладов подается прилично, просто до финала доходит маловато. Зарубежные спикеры в этом вопросе слегка более прокачены. Есть большая разница между тем чтобы написать заявку и выдать финальный результат. Много работы, к которой многие просто не готовы.
Давно конечно было, все не упомнить +) я когда писал камбеки, пересмотрел много годных докладов (не все доклады с конференции конечно). И раз такая есть претензия, тут мне кажется есть возможности для подачи своего доклада на JPoint 2020
Первая: техническая безопасность здания. Тут сложно будет ответить вместо инженеров обслуживающих ДЦ. Кажется, что для клиентов раньше делали экскурсии, и на подобные вопросы отвечали прямо во время оной. Думаю можно устроить разведопрос и рассказать как все устроено, если это интересно конечно.
Вторая: инфраструктурная безопасность сервисов. Тут все просто и сложно одновременно. Есть сервисы, которые сразу живут в нескольких дата центрах. Такие сервисы разрабатываются с установкой — жить без одного ДЦ в аварийной ситуации. И в случае «учений», живут. Однако вопрос доступности это ответственность не только провайдера, но и клиента.
Например. Бывает, что вместо кластера Managed Service for PostgreSQL с узлами в трех зонах доступности и регулярными бекапами клиент сколхозил все на одной виртуалке без бекапов. Очевидно, что риски в такой ситуации весьма приличные. У каждого крупного провайдера, каждый день умирает некоторая часть железа, ибо железо не вечно и всякое случается.
Но вопрос большой, и одним коментом на него не ответить. Хорошая идея для большой статьи, спасибо.
Но если у вас есть реальная нагрузка и вы понимаете ее паттерн, то конечно легко можно посчитать что вам выгоднее.
Но будем честными, скорее всего реальной работы ваш сервер делает не так много, и нагрузка имеет свое определенный паттерн. Есть паттерны при которых вызовы функций будут многократно эффективнее, есть в которых будут значительно проигрывать. Просто инструмент, которым нужно пользоваться осмысленно.
aws.amazon.com/ru/lambda/pricing
cloud.yandex.ru/docs/functions/pricing
Но так в лоб сравнивать сложно, нужно подходить комплексно по всему объему используемых компонентов. Разница получится сильно больше.
Глеб Борисов рассказывает о Yandex Cloud Functions, IoT, API Gateway www.youtube.com/watch?v=rExb5NRl1T0
Андрей Фомичев рассказывает о Yandex Database Serverless www.youtube.com/watch?v=o0-IpbkQKjc
Михаил Костин рассказывает про Object Storage www.youtube.com/watch?v=qsmfFgTtkiE
И приятный бонус для всех кто хочет попробовать Serverless — уровень нетарифицируемого использования (free tier) для сервисов экосистемы бессерверных вычислений cloud.yandex.ru/docs/billing/concepts/serverless-free-tier включает:
О, и приходите к нас в телеграм-чат задавать вопросы: t.me/YandexCloudFunctions
Русскоязычных докладов подается прилично, просто до финала доходит маловато. Зарубежные спикеры в этом вопросе слегка более прокачены. Есть большая разница между тем чтобы написать заявку и выдать финальный результат. Много работы, к которой многие просто не готовы.