İş akışı orkestrasyonu nedir? Cron'dan Airflow'a, Airflow'dan Kestra'ya

Sorun: Birbirine bağlı işler

Şöyle bir zincir düşün: Her gece bir API’den veri çek, temizle, veritabanına yükle, sonra bir rapor üret. Her adım bir öncekinin bitmesini bekliyor.

İlk akla gelen cron: Belli saatte bir komut çalıştıran klasik Unix zamanlayıcısı. Tek bir işi zamanlamak için harika. Ama zincirin ortasında bir adım hata verince sorun başlıyor. Cron tekrar denemez, sonraki adımı durdurmaz, neyin neden bozulduğunu sana göstermez. Ertesi sabah eksik bir raporla uyanırsın.

Orkestratör ne yapar?

İş akışı orkestrasyonu (workflow orchestration), bu zincirleri yöneten araçların genel adı. Bir orkestratör sana şunları verir:

• Bağımlılık: Hangi adımın hangisinden sonra çalışacağını bilir, birbirinden bağımsız adımları paralel çalıştırır.
• Yeniden deneme ve zaman aşımı: Bir API bir anlık cevap vermezse birkaç kez tekrar dener, sonsuza kadar takılan adımı keser.
• Kayıt ve arayüz: Her çalıştırmanın her adımının logunu ve süresini tek ekranda gösterir.
• Tetikleyiciler: İşi sadece saatle değil, bir dosya geldiğinde, bir webhook çağrıldığında ya da başka bir akış bittiğinde de başlatır.

Airflow: Akış bir Python programı

Bu alanın en bilinen aracı Apache Airflow. Airflow’da her akış bir DAG: “directed acyclic graph”, yani yönlü ve döngüsüz bir graf. Adımlar düğümler, oklar da “bu bitince şu başlasın” bağlantıları. Airflow’da DAG’ı Python koduyla yazarsın.

Bunun gücü esneklik: Python’la ne yazabiliyorsan akışın içinde de yapabilirsin. Bedeli ise şu: Her akış bakımı yapılacak, hata ayıklanacak bir program oluyor. Videoya göre Airflow’u kendi bilgisayarında ayağa kaldırmak da hiç keyifli değil.

Kestra: Akış bir ayar dosyası

Kestra açık kaynak (Apache 2.0) bir orkestratör ve farklı bir fikri savunuyor: Akış bir program değil, bir tanım olmalı. Bir akış (flow) bir YAML dosyası. İçinde bir kimlik, bir namespace (projeleri ve ekipleri ayıran klasör benzeri bir grup) ve sırayla çalışacak tasks listesi var. Basit bir örnek:

id: gece_raporu
namespace: sirket.veri
tasks:
  - id: selam
    type: io.kestra.plugin.core.log.Log
    message: Rapor hazırlanıyor
triggers:
  - id: her_gece
    type: io.kestra.plugin.core.trigger.Schedule
    cron: "0 2 * * *"

Buna bildirimsel (declarative) yaklaşım deniyor: Nasıl yapılacağını değil, ne istediğini yazıyorsun. Adımlar Python, shell, SQL ya da bir Docker konteyneri olabilir; Kestra hangi dilde yazıldığına karışmıyor. Tarayıcıdaki editörde YAML’ı değiştirince görsel diyagram da güncelleniyor, tersi de geçerli. Videonun vurguladığı artı da bu: Python bilmeyen bir ekip arkadaşın bile akışı okuyup bir değişikliği onaylayabiliyor.

Kusurları

• Kaynak ihtiyacı: Java ile yazılmış. Belgelere göre en az 2 vCPU ve 4 GiB bellek istiyor.
• Karmaşık mantık: Düz, sıralı akışlarda YAML çok temiz. Videoya göre çok sayıda dinamik dallanma gerektiğinde Python tabanlı araçlar daha rahat.
• Açık çekirdek (open core): Motor açık kaynak, ama tek oturum açma (SSO), rol bazlı yetki (RBAC) ve denetim kayıtları ücretli sürümde. Açık kaynak sürümde ortak bir kullanıcı adı ve şifre var.

Ne zaman hangisi?

Tek bir işi saat başı çalıştırıyorsan cron yeter. Verin zaten Postgres’teyse pg_cron ya da yarıda kalan işi kaldığı yerden sürdüren pg_durable de iş görebilir. Birden fazla sistemi birbirine bağlayan, hatası pahalıya patlayan zincirlerin varsa bir orkestratör düşünmenin zamanı gelmiştir.

Sonra ne oldu?

Kestra Eylül 2026’da 2.0 sürümünü çıkardı. Akışları blok blok kurmaya yarayan kodsuz bir editör ve akışları yapay zekâ ajanlarının çağırabileceği araçlara çeviren bir MCP sunucusu bu sürümün öne çıkanları arasında.

Düşün

• Projende “cron’la çalışıyor, umarım bozulmaz” dediğin bir iş var mı?
• Akışı kod olarak mı, ayar dosyası olarak mı yazmak sana daha güvenli geliyor? Neden?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.