Serverless Otomasyonun Sınırı: Neden Kalıcı Bir Örnek Gerekir

Serverless otomasyon cazip görünür: sıfır sunucu, kullandığın kadar öde. Bir tetikleyici gelir, fonksiyon ayağa kalkar, işi yapar, durur. Basit, değil mi?

Basit — ta ki ilk cron göreviniz sessizce kaybolana kadar. Ya da bir webhook isteğinin cold-start yüzünden 15 saniyelik gecikmeyle zaman aşımına uğradığına şahit olana kadar. Ya da dünkü bir webhook'tan gelen bağlamın bugünkü iş akışında neden sıfırlandığını merak edene kadar.

Bu yazı, serverless otomasyonun yapısal kısıtlarını açıklıyor ve hangi durumlarda 7/24 açık kalan kalıcı bir örneğin tek gerçekçi seçenek olduğunu gösteriyor.

Serverless Modelin Tam Olarak Ne Yaptığı

Serverless platformlarda (AWS Lambda, Vercel Functions, Google Cloud Run vb.) her çağrı teknik olarak bağımsızdır. Platform, gelen istek olmadığında örneği "dondurur" — hatta tamamen kaldırır. Bir sonraki çağrıda yeni bir konteyner ayağa kalkar; bu süreç cold-start olarak bilinir.

Sonuçları şöyle sıralanabilir:

• Bellek sıfırlanır. İki çağrı arasında herhangi bir in-memory durum tutamazsınız. Workflow çalıştığında bir önceki çalışmanın bağlamına erişilemez.
• Cron güvenilmezleşir. Bir zamanlanmış tetikleyici teorik olarak çalışsa bile, örnek "uyku"daysa ilk tetikleyici paketleri düşebilir. Daha kötüsü: her dakika çalışması gereken bir görev, tetiklenme başına ücretlendirildiğinde beklenmedik maliyet üretir.
• Uzun süreçleri çalıştıramazsınız. Serverless fonksiyonların maksimum yürütme süresi genellikle 15-30 dakikadır. Büyük bir veri seti çeken, bir PDF oluşturan ya da sıralı adımlarla ilerleyen bir akış kolayca bu sınırı aşar.
• Webhook güvenilirliği düşer. Dış bir servis (GitHub, Stripe, Shopify) webhook tetiklediğinde platforma önceden haber vermez. Konteyner soğuksa ilk istek zaman aşımına girebilir ya da hata kodu döner.

"Ama veritabanına yazarım, sorun olmaz" Yanılgısı

Yaygın bir çözüm şudur: durumu veritabanına ya da Redis'e taşı, serverless'ın durumsuzluğunu telafi et. Bu kısmen işe yarar — bir workflow'un son çıktısını kaydedebilirsiniz.

Ama bazı şeyler DB'ye yazılarak telafi edilemez:

1. Bağlam penceresindeki diyalog geçmişi — bir AI asistan "dünkü tartışmayı hatırlamalı" diyorsanız, bu bağlamın canlı tutulması gerekir. Her yeni çağrıda tüm geçmişi yeniden yükleyip modele göndermek hem yavaş hem pahalıdır.
2. Filesystem durumu — bir script indirdiği dosyayı bir sonraki adımda okuyorsa, her iki adımın aynı ortamda çalışması şarttır.
3. Yerel soket veya bağlantı havuzları — websocket bağlantısı, SSH tüneli gibi yapılar kalıcı bir süreç gerektirir.

Kalıcı Örnek Ne Demek?

Kalıcı örnek (persistent instance), sürekli çalışan bir süreç barındıran, boşta kalınca dondurulmayan, kaldırılmayan bir ortam demektir.

Serverless:      [tetik geldi → konteyner başlat → çalıştır → durdur]
Kalıcı örnek:    [her zaman açık → tetik geldi → çalıştır → bekle → tekrar çalıştır]

Farkın pratikte önemi şuradan gelir:

Senaryo	Serverless	Kalıcı Örnek
Her 5 dakikada bir çalışan cron	Tetiklenme başına maliyet, kayma riski	Tam saatinde, güvenilir
Webhook + anında yanıt	Cold-start = gecikme veya zaman aşımı	Milisaniyelerde yanıt
AI asistan — diyalog hafızası	Her çağrıda sıfırlanır	Bağlam canlı kalır
Uzun ETL / büyük dosya işleme	15-30 dk limit	Sınır yok
Filesystem bağımlılığı	Paylaşımlı disk yok	Kalıcı volume

n8n Özelinde: Neden Kendi Örneğiniz Olmalı?

n8n'i serverless bir ortamda çalıştırmak teknik olarak mümkündür ama doğru değildir. n8n, kalıcı bir süreç olarak tasarlanmıştır: kendi iç zamanlamasını yönetir, webhook sunucusu açık tutar, queue modda worker'larını besler.

Bir serverless platform üzerinde n8n çalıştırdığınızda şunlar olur:

• Aktif webhook bağlantıları kapanır ve yeniden açılması gecikebilir.
• Cron (Schedule Trigger) görevleri tetik gelmeden başlayamaz; dolayısıyla gerçek anlamda zamanlama yapamazsınız.
• n8n'in SQLite ya da PostgreSQL üzerindeki execution history'si tutarsızlaşır.

n8n'in kendi belgelerinde de belirtildiği gibi: önerilen kurulum, her zaman çalışan bir node process'idir.

Hermes ve OpenClaw: Hafızanın Neden Kalıcı Olması Şart

Hermes ve OpenClaw, yapısal olarak kalıcı bir ortama ihtiyaç duyan framework'lerdir:

• Hermes — AI asistan. Dünkü araştırma özetini hatırlar, sabah 8'de haber gönderir, gelen Telegram mesajlarını kuyruklar. Bunların hepsi bir sürecin uyku moduna girmeden beklemesine dayanır.
• OpenClaw — 7/24 Telegram üzerinden erişilen kişisel asistan. Konuşma geçmişi, yüklenen dosyalar, oturum durumu — bunların hiçbirini her mesajda "sıfırdan başlat" mantığıyla kurmak mümkün değildir.

Her iki framework de kalıcı bir ortam gerektirir: örnek durduğunda bağlam kaybolur.

AgentRoost'ta Nasıl Çalışıyor?

AgentRoost, her kullanıcı için ayrılmış, 7/24 açık kalan bir örnek çalıştırır. Dondurma yok, cold-start yok, paylaşımlı ortam yok.

n8n için akış:

1. Hesap oluştur → framework olarak n8n seç → instance'a bir ad ver.
2. Yaklaşık 2 dakika içinde kendi n8n editörün https://<senin-id>.agentroost.app adresinde açılır.
3. AI node'ları (OpenAI, Anthropic, Gemini...) zaten yapılandırılmıştır — API anahtarı girmen gerekmez, AI kredisi planına dahildir.
4. Schedule Trigger koy, HTTP Request veya Webhook ekle, workflow'u kaydet. Sunucu uyku moduna girmediğinden tetikler tam zamanında ateşlenir.

Hermes / OpenClaw için akış:

1. Hesap oluştur → framework seç → bir isim ver.
2. AgentRoost manager bot üzerinden /start komutunu ver; ajanın Telegram botu otomatik olarak sağlanır.
3. Birkaç dakika içinde konuşmaya başlayabilirsin; AI kredisi dahil.

Fiyatlandırma $19.99/ay'dan başlar; sunucu maliyeti ve AI kredisi tek pakette. 14 gün içinde memnun kalmazsan iade garantisi var, yıllık taahhüt yok.

Planları karşılaştır → n8n örneğini incele → Hermes'i keşfet →

Serverless'ı Ne Zaman Kullanmalı?

Adil olmak gerekirse, serverless her zaman yanlış değildir:

• Ayda birkaç kez tetiklenen, 1-2 saniyelik saf HTTP dönüşümleri için iyidir.
• Formdan e-posta gönder, webhook'u Slack'e ilet gibi stateless ve kısa işlemler için uygundur.
• Zamanlanmış görev yoksa, hafıza gerekmiyorsa, cold-start kabul edilebilirse sorun çıkarmaz.

Ama bir otomasyon şu özelliklerden birini taşıyorsa — cron güvenilirliği, AI hafızası, uzun süreçler, anlık webhook yanıtı, filesystem bağımlılığı — kalıcı örnek tek doğru seçimdir.

Özet

Serverless otomasyonun "kullandığın kadar öde" vaadi gerçektir. Ama bu modelin bedeli, her çağrıda sıfırlanan bir ortamda çalışmaktır. Zamanlanmış görevler kayar, diyalog hafızası tutulmaz, webhook'lar cold-start yüzünden zaman aşımına girer.

Eğer kurduğunuz otomasyon sabah 7'de haber özeti gönderecekse, bir kullanıcı mesajına saniyeler içinde yanıt verecekse ya da dünkü bağlamı yarın hatırlayacaksa — o örneğin uyku moduna geçmemesi gerekir.

Hemen başla — DevOps olmadan, AI kredisi dahil →