Serverless (Backend as a service)

Добрый день коллеги, кто игрался с этой штукой поделитесь опытом.
Интересны случаи использования из Java/.NET мира. (openwhisk.org например)
Как производительность ?

Serverless Web Request
Within a serverless infrastructure, each request corresponds to it’s own server. After the server processes the function, it is immediately destroyed. For example, here’s how Jones’s Zappa handles a web request:

The request comes in through an API Gateway.
The API request is mapped to a dictionary using Velocity Template Language (VTL).
A server is created.
The server then converts the dictionary to a standard Python WSGI and feeds it into the application.
The application returns it, and it passess it through the API Gateway.
The server is destroyed.
Astoundingly, all this occurs under 30 milliseconds, so that “by the time the user actually sees the [content appear on the] page, the server has disappeared... which is actually a pretty zen thing if you think about it,” says Jones.

(nordicapis.com/...​a-serverless-api-backend)

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А на какую проблему направлено это решение?

Скажем, я могу себе представить «бутылочное горлышко», в количестве входящих соединений в «листенер». Когда в BSD-сокетах открывается 1 центральный сокет, ставится на прослушивание — и далее, все входящие соединения обрабатываются в отдельных сокетах, создаваемых accept() под каждого клиента. Если количество одновременных входящих соединений становится велико, на accept() случается затык (т.к. он не масштабируется).

Всё дальнейшее масштабируется. Hовый сокет (для клиента), может быть создан в отдельном треде, выплюнуть ответ в сокет может даже процесс/тред на другой машине. Такое выплёвывание может быть и «serverless» (т.е. выплёвывающий процесс/тред будет прибит, сразу после выплёвывания респонса).

P.S. В более продвинутом варианте пользуют «non-blocking sockets» (при помощи select()). Но не уверен, что это решит проблему с тысячами одновременных соединений. Впрочем, я не пробовал. :)

при помощи select()).
При помощи epoll скорее.

Serverless и BaaS немного разные понятия, насколько мне известно, хотя принцип по сути тот же. Под serverless обычно действительно подразумевают AWS Lambda и наверное вот то что вы скинули — судя по описанию, ты описываешь набор «функций» которые тебе нужны на бекенде и потом с клиента вызываешь по апи. Тут описывают «server created — ... — server destroyed», но думаю это не стоит воспринимать буквально, да и клиенту без разницы.
BaaS же — это просто сервер с набором общей функциональности, которые написан и поддерживается кем-то другим. Обычно еще есть возможность расширения функциональности своим кодом, т.е. BaaS как бы включает в себя амазон лямбды.
Плюсы и минусы очевидны — экономия ресурсов из-за того что не нужно писать и поддерживать серверную часть, и практически полная зависимость от того кто это предоставляет: если проблемы у сервиса, то проблемы и у вас (независимо от того технические это проблемы или финансовые).
Ну и отдельно про производительность — в общем случае можно сказать, что разницы для среднестатистического приложения или веб-сервиса вы не заметите. Для чего-то более требовательного стоит дважды задуматься, но в то же время часто своими руками получится не лучше.

Ну и отдельно про производительность
Зато в цене разница есть, и значительная. Но если highload попрет, то AWS Lambda получиться очень дорогой.

Ну, подобные сервисы рассчитаны на то, что если у вас попрет хайлоад — то вы сможете достаточно на нем заработать :)

В основном под этим подразумевают AWS Lambda. Используют когда хотят сэкономить в слабонагруженных серовисах.

Или AWS CoudFormation стеки конфигурить, когда надо сделать что-то хитрое.

Підписатись на коментарі