Size: a a a

2019 November 12

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
то есть можно писать так, чтобы функция деплоилась и на Lambda, и на OpenFaaS и на Cloud Functions, но это абстрагирование от облака заставляет нас не использовать какие-либо специфические вещи, например, вот эти триггеры облачных хранилок
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
Kirill Penzin
Так, а если у нас Кубер и мы уже платим за кластер, то в чём профит FaaS?
я так понял, вопрос был про vendor lock-in? я на него отвечал с тех позиций, что делать функции - это не отдавать себя в руки AWS/Google'а, при желании их легко утащить из облака к себе
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
а если смотреть с позиции цен - ну, вот сейчас есть Google Cloud Run, контейнеры как serverless, можно туда OpenFaaS поставить 😊
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
и будет и с одной стороны не связано с гуглом, а с другой стороны, будет плата только за использование
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
Cloud Run - это managed Kubernetes+Knative
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
а сами функции могут там запускаться на каком-нибудь Flask'е или чём-то таком, я не помню, что там у OpenFaaS для питона
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
FaaS - это больше про другой подход к разработке систем, которые более cloud-native
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
чем про что-то другое
источник

KP

Kirill Penzin in PiterPy Idle
To minimize the impact of cold starts, Cloud Run may maintain a reserve of idle container instances for your revision. These instances are ready to handle requests in case of a sudden traffic spike. Note that for Cloud Run (fully managed), you are not billed for this.

А вот это уже выглядит интересно
https://cloud.google.com/run/docs/about-instance-autoscaling
источник

KP

Kirill Penzin in PiterPy Idle
Они обещают, что можно разогретое что-то держать бесплатно
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
ну да, Cloud Run хорошая штука
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
я про неё часто пишу
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
собственно, проблема Cloud Run'а по сравнению с Cloud Functions в том, что тут нам нужно поддерживать Dockerfile
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
а не только лишь requirements.txt
источник

AO

Alexander Ovchinnikov 🦁 in PiterPy Idle
наверное, это единственный минус - сервис не такой managed, как нам бы хотелось, делать образы контейнеров - это тоже некое админство своего рода, а cloud-native подход - это аутсорснуть всё облаку
источник

D

Dmitriy in PiterPy Idle
Интересно можно ли выдрать orm из Django и к примеру часть REST view перевести на него с Flask или CherryPy чтобы быстрее работало. Так сказать не рвать связь с Django совсем, тем более когда кода много.
источник

D

Dmitriy in PiterPy Idle
Может быть им надо было Django сделать таким разложить по ряду отдельных пакетов его.
источник

D

Dmitriy in PiterPy Idle
То что для Instagram Django не подоходит, вполне может быть там же безумный high load по IO скорее всего. Нужны Java или C#. Там и коллекция мусора будет на порядок эффективней.
источник

D

Dmitriy in PiterPy Idle
Но таких огромных веб проектов мало, это редкий случай.
источник

SS

Sergey Sokolov in PiterPy Idle
Dmitriy
То что для Instagram Django не подоходит, вполне может быть там же безумный high load по IO скорее всего. Нужны Java или C#. Там и коллекция мусора будет на порядок эффективней.
Сборка мусора? В моем инстаграме? Што? 🌚🌚🌚
источник