кому интересны эти кожаные ублюдки когда есть облака? 😊

то есть хочешь использовать самые современные и крутые штуки? тогда тебе никуда не деться от Kubernetes и облаков) выбора нет - или сидишь со старыми решениями типа Celery и Dramatiq или учишь K8s и облака и используешь всё новое и современное) [ну, или не учишь, а берёшь готовое как сервис у тех же IaaS]

мне не понять вашего хайпа

спасибо

Да не за что)

одну и ту же задачу можно решать разными способами) некоторые вещи типа вот тех задач на Celery можно решить более прикольным способом через serverless, было время, когда люди говорили "зачем нам ваши контейнеры, они нам не нужны", сейчас наступило другое время, "если у вас нет среды для запуска контейнеров, то часть софта вы не сможете поставить и использовать", это уже не хайп, это новая эра, в которой появились свои технические решения, которые просто недоступны тем, кто в эту новую эру не перешёл) для тех, кто не перешёл, осталась Celery, она решает задачи и с ней можно жить [пока по крайней мере])

а чем конкретно сейчас заменяют celery?

ну, зависит от задач)

вот serverless частично или целиком может заменить всё то, что крутится на Celery

например, https://fission.io/

а есть примеры? просто я умею запускать фоновые задачи в селери из джанги, всё просто, понятно, привычно. увидел, что их чем-то можно заменить стало интересно, но что гуглить вообще не понятно

это системы, которые запускают функции

функции могут вызываться триггерами

в роли триггера может быть сообщение, отправленное через какую-нибудь Kafka

или крон или запрос по http

для OpenFaaS подойдёт обычный докер, остальные, более продвинутые системы требуют Kubernetes

а без контейнеров вообще ни одна из этих систем не заработает официально

и тут три выбора: или ничего не делать и оставаться с условным Celery/Dramatiq/RQ/Q и дальше, или брать на AWS/GCP это как сервисы (в итоге там будет некий vendor lock-in, но зато быстро и просто) или разворачивать эти сервисы самому в своём Kubernetes-кластере (без этого кластера они не запустятся даже)

путь AWS - это путь сервисов и vendor lock-in'а, путь Google Cloud [субъективное мнение, возможно, я не прав] - это путь "мы дадим вам крутой managed Kubernetes (и вы сами туда поставите то, что вам нужно), а все остальные compute сервисы у нас так себе"

и там и там есть вполне себе переносимые решения, надо уметь их готовить

на Google Cloud до сих пор эндпоинты к Cloud Functions не приделали