<p>We have a lot of the long running, memory/cpu intensive jobs in k8s which are run with celery on kubernetes on google cloud platform. However we have big problems with scaling/retrying/monitoring/alerting/guarantee of delivery. We want to move from celery to some more advanced framework. </p>

<p>There is a comparison: <a href="https://github.com/argoproj/argo/issues/849" rel="noreferrer">https://github.com/argoproj/argo/issues/849</a> but it's not enough.</p>

<p>Airflow:</p>

<ul>
<li>has better support in community ~400 vs ~12 tags on SO, 13k stars vs
~3.5k stars</li>
<li>python way of defining flows feels better than using just yamls</li>
<li>support in GCP as a product: Cloud Composer</li>
<li>better dashboard</li>
<li>some nice operators like email operator</li>
</ul>

<p>Argoproj:</p>

<ul>
<li>Native support of Kubernetes (which i suppose is somehow better)</li>
<li>Supports CI/CD/events which could useful in the future</li>
<li>(Probably) better support for passing results from one job to the another one (in Airflow xcom mechanism)</li>
</ul>

<p>Our DAGs are not that much complicated. Which of those frameworks should we choose? </p>

sacherus
<p>Idiomatic Airflow isn't really designed to execute long-running jobs by itself. Rather, Airflow is meant to serve as the facilitator for kicking off compute jobs within another service (this is done with Operators) while monitoring the status of the given compute job (this is done with Sensors).</p>

<p>Given your example, any compute task necessary within Airflow would be initiated with the appropriate Operator for the given service being used (Airflow has GCP hooks for simplifying this) and the appropriate Sensor would determine when the task was completed and no longer blocked downstream tasks dependent on that operation.</p>

<p>While not intimately familiar on the details of Argoproj, it appears to be less of a "scheduling system" like Airflow and more of a system used to orchestrate and actually execute much of the compute.</p>
