Sunucusuz Mimari: Soğuk Başlangıç, Gerçek Maliyet ve Uygun Kullanım Alanları

Sunucusuz mimari (serverless), adının aksine sunucuları ortadan kaldırmaz — yalnızca onları yönetme sorumluluğunu sağlayıcıya devreder. Kod, bir olay geldiğinde çalışır, işini bitirir ve kapanır; boşta beklerken ücret ödemezsiniz. Bu model bazı iş yüklerinde şaşırtıcı derecede iyi çalışır, bazılarında ise hem pahalı hem sorunlu hâle gelir. Ayrım noktalarını netleştirelim.

Soğuk başlangıç: en çok konuşulan konu

Bir işlev uzun süre çağrılmadığında bulut sağlayıcı çalışma ortamını kapatır. Sonraki istek geldiğinde ortam yeniden kurulur ve bu, kullanıcının beklediği süreye eklenir. Etkinin büyüklüğü çalışma zamanına ve paket boyutuna bağlıdır; hafif çalışma zamanlarında yüz milisaniyeler mertebesindeyken, ağır bağımlılık yüklü ortamlarda saniyelere çıkabilir.

Pratik açıdan doğru soru "soğuk başlangıç var mı" değil, "bu iş yükü için önemli mi"dir. Gece çalışan bir rapor işi için tamamen önemsizdir. Kullanıcının form gönderdiği bir uç için ise doğrudan deneyimi etkiler. Azaltma yolları vardır — paketi küçültmek, bağımlılıkları azaltmak, sağlanmış eşzamanlılık kullanmak — ancak sonuncusu, sunucusuzun temel vaadi olan "boşta ödeme yapmama" ilkesini kısmen ortadan kaldırır.

Veritabanı bağlantıları: en sık atlanan tuzak

Geleneksel bir uygulama sunucusu, sınırlı sayıda veritabanı bağlantısını havuzda tutar ve yeniden kullanır. Sunucusuz modelde ise her eşzamanlı çağrı kendi ortamında çalışır; ani bir trafik artışında yüzlerce ayrı bağlantı açılmaya çalışılır ve veritabanı bağlantı limitine dayanır.

Sonuç ironiktir: ölçeklenmesi kolay olsun diye seçilen mimari, veritabanı yüzünden ölçeklenemez. Çözüm, araya bir bağlantı havuzu/proxy katmanı koymak veya HTTP üzerinden çalışan veri servisleri kullanmaktır. Bu, mimari kararı verirken hesaba katılmadığında sonradan pahalıya mal olan bir kısıttır ve sonsuz ölçeklenme yanılsaması yazımızda anlattığımız gerçek sınırların iyi bir örneğidir.

Çalışma süresi ve durum

Sunucusuz işlevlerin çalışma süresi sınırlıdır. Uzun süren video işleme, büyük veri aktarımı veya saatlerce süren raporlar bu modele doğrudan sığmaz; işi parçalara bölmek ve adımları bir iş akışıyla yönetmek gerekir. Bu her zaman kötü değildir — parçalama, işi daha dayanıklı hâle de getirir — ama ek karmaşıklık demektir.

Benzer biçimde işlevler durumsuzdur: bellekte tutulan hiçbir şeyin bir sonraki çağrıda var olacağı garanti edilemez. Oturum, sayaç ve önbellek gibi ihtiyaçlar dışarıdaki bir servise taşınmalıdır.

Maliyet: eğri nerede kesişiyor?

Sunucusuzun maliyet vaadi, düşük ve düzensiz yükte gerçektir: günde birkaç yüz çağrı alan bir uç, ayakta duran bir sunucudan neredeyse her zaman ucuzdur. Ancak istek başına ücretlendirme, yüksek ve sürekli trafikte tersine döner; belirli bir eşiğin üzerinde sabit kapasiteli bir sunucu belirgin biçimde daha ekonomik olur.

Hesaplamada sık atlanan kalem, işlev ücretinin yanındaki diğer servislerdir: ağ geçidi, günlük saklama, izleme ve veri transferi. Fatura sürprizlerinin çoğu buradan gelir; bulut faturasını şişiren kalemler yazımız bu başlıkları ayrıntılandırıyor. Genel karar çerçevesi için bulut mu kendi sunucunuz mu karşılaştırmamıza bakabilirsiniz.

Nerede gerçekten parlıyor?

Sunucusuz mimarinin en güçlü olduğu senaryolar bellidir:

• Olay tabanlı arka plan işleri: Dosya yüklendiğinde küçük resim üretmek, kuyruğa düşen mesajı işlemek, zamanlanmış temizlik görevleri.
• Ani ve öngörülemez yük: Kampanya anında yüz katına çıkan, sonra sıfıra dönen trafik.
• Yapıştırıcı kod: İki servis arasında küçük bir dönüştürme veya webhook alıcısı — bunun için tam bir uygulama sunucusu ayakta tutmak israftır.
• Nadiren kullanılan uçlar: Ayda birkaç kez çalışan yönetimsel işlemler.

Buna karşılık sürekli yüksek trafikli ana uygulama, düşük gecikme garantisi gereken uçlar ve uzun süren işlemler için geleneksel model hâlâ daha uygundur.

İşletim tarafı: kolaylaşmaz, değişir

Sunucu yönetmemek, işletim yükünün bittiği anlamına gelmez. İzleme ve hata ayıklama dağıtık hâle gelir: tek bir isteğin birden çok işlev üzerinden geçtiği bir akışta, izleme kimliği olmadan sorunu bulmak son derece zordur. Yerel geliştirme ortamı da farklılaşır; bulut servislerini yerelde birebir taklit etmek her zaman mümkün olmaz. Dağıtım ve geri alma stratejisi de yeniden düşünülmelidir; altyapıyı kod olarak yönetmek bu ortamda tercih değil zorunluluk hâline gelir. Servis sınırları ve kotalar için bulut sağlayıcı dokümantasyonu düzenli kontrol edilmelidir.

Sonuç

Sunucusuz mimari, sunucuları yok eden bir devrim değil; maliyet ve sorumluluk modelini değiştiren bir takastır. Düzensiz yük, olay tabanlı işler ve nadiren çalışan uçlarda açık ara kazandırır; sürekli yüksek trafikte, uzun süren işlerde ve geleneksel veritabanı bağlantılarıyla çalışan sistemlerde ise beklenmedik maliyet ve karmaşıklık üretir. Karar vermeden önce üç sayıyı yazın: aylık çağrı adediniz, isteğin kabul edilebilir en uzun süresi ve eşzamanlı veritabanı bağlantısı limitiniz. Bu üç sayı, cevabı çoğu zaman kendiliğinden verir.