Некоторые неочевидные преимущества Serverless для DevOps

[Tiendil]

>отказ от схемы имя: порт — одно и ключевых преимуществ для DevOps
По-моему это далеко не самая большая проблема девопсов…

[lleo_aha]

Просто ключевое преимущество решает такуюсебе проблему :)

[Matohin]

Serverless функции не имеют никаких доменных имен, никаких TCP/IP адресов и даже не слушают никакие порты.

Автору явно никогда не приходилось создавать сабнет, чтоб организовать доступ лямбды к интернету. Оно может и правда, но только в простых случаях. А так-то и серверу IP назначить не сложно.

[bbelky]

А где и зачем нужно делать сабнет в случае function as a service? Провайдер генерирует вам ссылку на API функции и вы ее дергаете.

[Matohin]

Для доступа к внешним ресурсам из лямбды.
aws.amazon.com/ru/premiumsupport/knowledge-center/internet-access-lambda-function

[bbelky]

Это особенность именно aws lambda. В других платформах, например, гугле, ibm, в нашем swifty, такого нет.

[Stas911]

Это только для лямбд, которые задеплоены в VPC (например, чтобы лазить в базу). Если не требуется лазить в VPC, то не стоит функции туда деплоить, тк они медленнее работают при этом.

[click0]

Как только появится необходимость debug'a работающего сервиса, так сразу вспомните про IP, домены, URI и порты.

[bbelky]

Честно говоря, не представляю ситуацию, когда для бекенда сделанного на serverless придется разделять сервисы по портам или чему-то подобному. Ну нет такого сценария. Знаете — расскажите, а мы исправимся и допилим, что нужно будет допилить!

У нас есть функция, которая решает конкретную задачу, например, post и get в mongodb. У нее есть одна единственная ссылка на API, которая дергает эту функцию и только ее. Если есть вторая функция, которая загружает данные в другую коллекцию или другую mongo, то у нее есть своя функция со своей ссылкой. И никаким образом вы не достучитесь к первой базе, зная ссылку только на вторую функцию.

А что касается трафика внутри платформы, то тут мы рулим сами и, если накосячим, то сами и будем разруливать порты.

[click0]

Начнем с того, что у MongoDB изменилась лицензия.

«MongoDB ранее лицензировался под GNU AGPL v3, это означало, что компании, которые хотели запускать MongoDB как публичный сервис, должны были открыть исходный код своего ПО или получить коммерческую лицензию от MongoDB»

В случае сервиса API с get и post, непонятно где чекать ошибки в ДНС ресолвинге, http запросах.

[ctacka]

Не надо ничего создавать, если вам не надо ходить к ресурсам внутри VPC.

[Matohin]

А если надо? А если надо в интернет? Моя мысль в том, что с ростом требований сложность конфигурации растет.

[ctacka]

Если надо в интернет, но не надо в VPC, то ничего не надо настраивать. Если надо в VPC и в интернет, то сажаете в правильную подсеть. Собственно, у лямбды из настроек только подсети.

[Matohin]

Если надо в интернет, но не надо в VPC

Вы ошибаетесь, см. ссылку в дискуссии выше.

[Stas911]

Дык по ссылке как раз про VPC-enabled речь.