Холодный старт против масштабирования до нулевого компромисса в FaaS

Question

Прежде чем я начну, скажу, что я не был уверен на 100%, является ли SO подходящим SX для этого вопроса. Дайте мне знать, если я должен спросить это на каком-то другом SX.

Вопрос в целом касается FaaS, но если вы можете лучше объяснить это в контексте конкретной платформы / провайдера FaaS, это тоже замечательно.

В настоящее время я читаю о бессерверных вычислениях (FaaS, чтобы быть более точным c) и пытаюсь освоиться с предметом. Теперь почти везде, куда бы я ни обратился, я сталкиваюсь со следующими утверждениями о FaaS:
1) Большинство платформ FaaS поддерживают масштабирование с нуля;
2) Поставщики FaaS взимают плату со своих пользователей на основе времени выполнения их функций (обычно измеряется в мс);
3) Потенциальные холодные запуски (т. е. создание нового экземпляра вместо повторного использования существующего) являются проблемой в FaaS, поскольку они значительно ухудшают производительность вашего приложения;

Точки 1 и 2 Рассматриваемые преимущества - вы получаете именно то, что вам нужно (в том числе вообще ничего, если применимо), и вы платите именно за то, что получаете.
Пункт 3 считается недостатком - выполнение запроса занимает значительно больше времени. Я видел авторов, описывающих холодный старт как признак того, что платформы FaaS еще не достигли зрелости. Я видел, как практикующие говорили, что они задают периодические c запросы, чтобы не дать своим функциям стать неактивными и «провалиться», что вызывает холодный старт при следующем вызове.

Мой вопрос - почему холодные запуски рассматриваются как нежелательные, а не как компромисс ?
Я имею в виду, учитывая, что пользователь платит за время выполнения в FaaS, разве это обычно не в его интересах избежать теплых, но неработающих экземпляров функций? Мне кажется, что это решение по сравнению с решением высокой доступности. Я что-то неправильно понимаю? Имеет ли теплый, но бездействующий экземпляр функции не время для выполнения? Даже если это так:
a) не является ли это нежелательным с точки зрения провайдеров (когда приходится выделять ресурсы, которые не используются и не оплачиваются)?
b) обязательно отправлять периодические c запросы (как упомянуто выше) вам стоит, верно?

Answer 1

Для этого ответа я расскажу о Azure функциях. Ответ будет более или менее передан другим безсерверным провайдерам.

Проблема холодного запуска приводит к задержке выполнения запроса, сделанного конкретным клиентом, а время обслуживания запроса во время холодного запуска - приблизительно от 5 до 50 секунд. Это плохо по следующим причинам:
1. Многие функции ограничены по времени, т.е. их выполнение останавливается, если время выполнения превышает определенный лимит. Поэтому некоторые пользователи не обслуживают свои запросы.
2. Время обслуживания конкретного пользователя весьма различно, и это всегда нежелательно при разработке приложения, поскольку согласованность является ключевым фактором.

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

Azure функция взимает с пользователей плату за потребленные ресурсы (потребление ресурсов рассчитывается путем умножения среднего объема памяти в гигабайтах на время в миллисекундах, которое требуется для выполнения функции), а также за количество обращений. Так что да, функция pinging, созданная для поддержания функций в тепле, стоит дороже, но стоимость не является основным пунктом для перехода на модель FaaS. Модель FaaS в основном используется для создания Fault Tolerant Services, поэтому, если одна часть вашего API испортит все приложение, не нужно выключать go.