Celery-Kubernetes-Operator VS huey

The take-out from that course is: don't deploy anything stateful on Kubernetes in production, period. Even disregarding that, don't deploy anything stateful that doesn't come in a form of an operator. For celery, https://github.com/celery/Celery-Kubernetes-Operator is a WIP, so obviously not suitable for anything.

I've considered using Nextflow for bioinformatics pipelines but have yet to take the plunge. At work, I develop a proteomics pipeline that is composed of huey¹ tasks (Python library; simple alternative to Celery) which either use subprocess to call out to some external tool, or are just pure python. It runs in a worker container which is created by docker swarm, and all containers pull jobs from redis. For our scale, it works great. However, I don't have control over the resource utilization of individual steps, and in the past I've had issues with the pipeline blocking as a result of how I was chaining tasks together. I think something like Nextflow would remove these limitations, but one thing I think I would miss is the ability to debug individual pipeline steps locally with an interactive debugger. As far as I can tell, Nextflow has logging/tracing facilities but nothing quite like an interactive debugger. I'd be happy to be told I'm wrong, or even that I'm doing it wrong.

____

¹ https://github.com/coleifer/huey/

Other options are DjangoQ and Huey, which tend to work ok. Of the two I prefer DjangoQ. Database backed, don't require the Redis/Celery rigmarole.

Funny, just this moment i finally switched from Celery to huey. And so far I don't regret. huey looks very promising, has good documentation and is well integrated into DJango. You should give it a try: https://github.com/coleifer/huey

huey – a little task queue for python

Huey -> Same again?

Huey: https://github.com/coleifer/huey

huey

same, I ran into an issue cos of django-background-tasks. I am thinking to replace it with huey