บทความนี้น่าสนใจดีครับ สมเหตุสมผล คู่ควรแก่เวลาอ่าน 
เป็นบทความที่เค้าบอกว่าทำไมเค้าถึงไม่ชอบ Airflow และปัญหาอยู่ตรงไหนบ้าง ซึ่งจะกล่าวถึง value ในอนาคตเกี่ยวกับ data teams ที่ว่าการสร้าง workflow จะต้องเร็วขึ้น ง่ายขึ้น และ decentralized มากขึ้น
Credit: รูปจากบทความข้างต้น
ผมคิดว่าสมเหตุสมผลเพราะว่า Airflow ไม่ได้ถูกออกแบบมาในแบบนั้นตั้งแต่แรก ตัวมันเองเป็น centralized workflow management ที่ชัดเจนมาก ซึ่งถ้าจะไปในแบบ decentralized หรือแนว domain-driven design ก็อาจจะหมายความว่าแต่ละทีมต้องดูแล Airflow instance ของตัวเอง (ซึ่งก็เหนื่อยอยู่นะ 
) และถ้าจะให้ทุกคนสามารถเข้ามาใช้งาน Airflow ได้แบบง่าย ๆ เราก็ต้องพัฒนาเครื่องมือขึ้นมาครอบอีกที
เรื่อง data lineage ของ Airflow ก็ต้องเอาเครื่องมือตัวอื่น ๆ อย่างเช่น Marquez มาช่วย
เรื่องพวกนี้ส่วนใหญ่ ถ้าไปใช้ Fully Managed Apache Airflow Service อย่าง Astronomer ก็น่าจะแก้ปัญหาได้ในระดับหนึ่ง เพราะว่าเราสามารถแยก Airflow instance ไปในแต่ละทีมได้ แล้วก็ integrate กับ Marquez ให้ด้วย
เท่าที่ผมเข้าใจ ผู้เขียนเค้าไม่ชอบ Airflow แต่ดูเหมือนเค้าจะ OK กับ Astronomer เพราะว่าทำ “control plane” มาครอบไว้แล้ว (ซึ่งก็เหมือนกับทาง Dagster กับ Prefect)
ปล. ผู้เขียนดูจะเชียร์ dbt ด้วย เพราะว่า dbt เป็นการสร้าง semantic abstraction layer ครอบ modern data platforms ไว้ และดูเป็น native data app จริง ๆ ซึ่งผมก็เชียร์ อิอิ 
แต่ก็เข้าใจนะ ว่า บางทีมมีแต่คนที่เขียน sql เป็น