Информация об изменениях

Сообщение Re[3]: Сloud functions и ограничения по ЯП от 31.07.2023 14:24

Изменено 31.07.2023 14:33 vsb

Re[3]: Сloud functions и ограничения по ЯП
Здравствуйте, Shmj, Вы писали:

vsb>>С чего ты взял? Создаётся.


S>А с того, что там плата за каждый запрос, причем не большая. Фактически за 0.3 сек. успевают выполнить код. Если под каждый запрос создавать отдельную вирт. машину с нуля — не успеют все проинициализировать за 0.3 сек и слишком дорого будет, даже просто необходимое количество памяти выделить + провести инициализацию окружения — оно же требует установленной ОС.


Почему не успеют? Что там инициализировать? Всё быстро работает. Там же не дебиан в виртуалбоксе, а оптимизированный стек, в котором ничего лишнего.

https://github.com/firecracker-microvm/firecracker/blob/main/FAQ.md

< 125 ms startup time and a < 5 MiB memory footprint

Это с обычным ядром. В своих рантаймах у них вряд ли обычное ядро. Думаю, грузятся за единицы миллисекунд.

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

S>>> а изоляция достигается средствами ограничения API (как то стандартные функции записи в файл — не доступны или урезаны (как-то читать можно только из своей папки)).


vsb>>API тут не при чём, любые ограничения API можно обойти, тем более на языках вроде Go или Rust, где ты можешь просто написать машинный код в память и выполнить его.


S>Так там, скорее всего, запрещены инструкции машинного кода. Думаю что как-то это можно сделать в Rust.


S>Возможно там нужно дать исходники на Rust и как-то проверяют, что нет небезопасных секций. С Go — не знаю.


Ты туда деплоишь скомпилированный бинарник. Им твои исходники не нужны. Ничего они не проверяют и не могут проверять.
Re[3]: Сloud functions и ограничения по ЯП
Здравствуйте, Shmj, Вы писали:

vsb>>С чего ты взял? Создаётся.


S>А с того, что там плата за каждый запрос, причем не большая. Фактически за 0.3 сек. успевают выполнить код. Если под каждый запрос создавать отдельную вирт. машину с нуля — не успеют все проинициализировать за 0.3 сек и слишком дорого будет, даже просто необходимое количество памяти выделить + провести инициализацию окружения — оно же требует установленной ОС.


Почему не успеют? Что там инициализировать? Всё быстро работает. Там же не дебиан в виртуалбоксе, а оптимизированный стек, в котором ничего лишнего.

https://github.com/firecracker-microvm/firecracker/blob/main/FAQ.md

< 125 ms startup time and a < 5 MiB memory footprint

Это с обычным ядром. В своих рантаймах у них вряд ли обычное ядро. Думаю, грузятся за единицы миллисекунд.

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

S>>> а изоляция достигается средствами ограничения API (как то стандартные функции записи в файл — не доступны или урезаны (как-то читать можно только из своей папки)).


vsb>>API тут не при чём, любые ограничения API можно обойти, тем более на языках вроде Go или Rust, где ты можешь просто написать машинный код в память и выполнить его.


S>Так там, скорее всего, запрещены инструкции машинного кода. Думаю что как-то это можно сделать в Rust.


S>Возможно там нужно дать исходники на Rust и как-то проверяют, что нет небезопасных секций. С Go — не знаю.


Ты туда деплоишь скомпилированный бинарник. Им твои исходники не нужны. Ничего они не проверяют и не могут проверять.