Смотри. Можно, допустим, очередь взять 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 инсталляция. Для примера пара материалов:
Первая: техническая безопасность здания. Тут сложно будет ответить вместо инженеров обслуживающих ДЦ. Кажется, что для клиентов раньше делали экскурсии, и на подобные вопросы отвечали прямо во время оной. Думаю можно устроить разведопрос и рассказать как все устроено, если это интересно конечно.
Вторая: инфраструктурная безопасность сервисов. Тут все просто и сложно одновременно. Есть сервисы, которые сразу живут в нескольких дата центрах. Такие сервисы разрабатываются с установкой — жить без одного ДЦ в аварийной ситуации. И в случае «учений», живут. Однако вопрос доступности это ответственность не только провайдера, но и клиента.
Например. Бывает, что вместо кластера 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