Sunucusuz (Serverless) Mimari: Ne Zaman Doğru Seçim, Ne Zaman Değil?

“Sunucusuz” adı biraz yanıltıcı: sunucular hâlâ orada, sadece artık sizin sorununuz değiller. Kodunuzu bir fonksiyon olarak yüklüyorsunuz; bulut sağlayıcı onu gerektiğinde çalıştırıyor, yük arttığında çoğaltıyor ve kullanılmadığında ücret almıyor. AWS üzerinde Lambda, Glue, Athena ve S3 ile tamamen bulut tabanlı çalışan sistemler geliştirirken bu modelin hem ne kadar güçlü hem de nerede zorlayıcı olduğunu yakından gördüm.

Serverless ne vaat ediyor?

• Operasyon yükü yok: İşletim sistemi güncellemesi, güvenlik yaması ya da kapasite planlaması sizin işiniz değil.

• Otomatik ölçeklenme: Saniyede bir istekten binlerce isteğe kadar ek ayar gerekmeden.

• Kullandığın kadar öde: Boşta bekleyen kapasite için para ödemezsiniz.

• Hızlı başlangıç: Küçük bir ekip, altyapı kurmakla uğraşmadan üretime çıkabilir.

Nerede parlıyor?

Olay güdümlü işler

Bir dosya depolamaya yüklendiğinde küçük resmini oluşturmak, bir kuyruğa düşen mesajı işlemek, bir webhook'a yanıt vermek… Kısa süren ve birbirinden bağımsız bu tür işler, serverless'in doğal alanıdır.

Düzensiz ya da öngörülemeyen trafik

Gün içinde birkaç kez yoğunlaşan, gece neredeyse sıfıra inen bir şirket içi araç ya da kampanya dönemlerinde patlayan bir API için sürekli açık duran sunucular israftır.

Veri işleme ve analitik

Ham veriyi nesne depolamada tutup ETL işlerini yönetilen servislerle çalıştırmak ve bunu sorgu başına ödeme yapılan bir analiz katmanıyla birleştirmek, küçük bir ekip için bile güçlü bir veri platformu ortaya çıkarır. Panoları besleyen sorgular yalnızca çalıştıklarında maliyet üretir.

Gizli maliyetler ve sınırlar

Serverless karmaşıklığı ortadan kaldırmaz; onu altyapıdan mimariye taşır.

• Soğuk başlangıç (cold start): Bir süredir çağrılmayan bir fonksiyonun ilk isteği daha yavaş yanıt verir. Çoğu iş için önemsizdir; düşük gecikmenin şart olduğu API'lerde ise mutlaka ölçülmelidir.

• Süre ve boyut limitleri: Örneğin AWS Lambda'da tek bir çağrı en fazla 15 dakika sürebilir ve senkron isteklerin gövde boyutu sınırlıdır. Büyük dosyalar için istemcinin doğrudan depolamaya yüklemesini sağlayan imzalı URL gibi kalıplar gerekir.

• Sürekli yüksek yükte maliyet: Trafik hep yüksek ve öngörülebilirse, sürekli çalışan konteynerler çoğu zaman daha ucuzdur.

• Gözlemlenebilirlik: Bir istek beş farklı servisten geçtiğinde hatanın nerede olduğunu bulmak zorlaşır. Merkezi loglama, dağıtık izleme (tracing) ve anlamlı alarmlar en baştan kurulmalı.

• Sağlayıcıya bağımlılık: Servislerin kendine özgü API'leri taşınabilirliği azaltır. İş mantığını sağlayıcıdan bağımsız katmanlarda tutmak bu riski yönetilebilir kılar.

• Yerel geliştirme ve test: Bulut servislerini yerelde birebir taklit etmek her zaman mümkün değildir; entegrasyon testleri için ayrı bir test ortamı neredeyse zorunludur.

Altyapıyı kod olarak yönetin

Serverless sistemler çok sayıda küçük parçadan oluşur: fonksiyonlar, izinler, kuyruklar, tetikleyiciler. Bunları konsoldan elle oluşturmak, kısa sürede kimsenin tam olarak anlamadığı bir yapı demektir. Terraform gibi araçlarla tüm altyapıyı kodla tanımlamak ortamları tekrarlanabilir, değişiklikleri incelenebilir ve geri alınabilir kılar. Benim için bu, serverless'in vazgeçilmez tamamlayıcısı.

Karar verirken sorulacak sorular

1. İş yükü kısa süreli ve olay güdümlü mü, yoksa uzun süre çalışan bir süreç mi?

2. Trafik düzensiz mi, yoksa sürekli ve öngörülebilir mi?

3. Gecikmeye ne kadar duyarlı? Ara sıra yaşanan bir soğuk başlangıç kabul edilebilir mi?

4. Ekibin operasyon tecrübesi ve buna ayırabileceği zaman ne kadar?

5. Belirli bir bulut sağlayıcıya bağlanmak uzun vadede sorun yaratır mı?

Çoğu gerçek sistem için doğru cevap “ya hep ya hiç” değildir. Olay güdümlü işler ve veri hatları serverless'te, sürekli yük altındaki çekirdek servisler konteynerlerde çalışabilir. Önemli olan, teknolojiyi moda olduğu için değil, iş yükünün doğasına uyduğu için seçmek.