Bir ekip yeni servisini “serverless first” kararıyla AWS Lambda üzerine kurdu. Oysa trafik sabit ve öngörülebilirdi — gün boyu aşağı yukarı aynı. Ay sonunda fatura, aynı işi yapan tek bir VPS’in birkaç katı çıktı; üstelik p95 latency de daha kötüydü.

Serverless yanlış bir teknoloji değil. Yanlış iş yüküne uygulanmış bir teknolojiydi.

Serverless ne satın alır

FaaS’ın (Function as a Service) gerçek getirileri var:

  • Sunucu yönetimi yok. Yama, ölçekleme, kapasite planı sağlayıcıda.
  • Sıfıra inen ölçek. İstek yoksa çalışan hiçbir şey yok, ödenen hiçbir şey yok.
  • Kullanım başına ödeme. Atıl kapasite için para ödemezsiniz.

Bu üçü, doğru iş yükünde gerçekten kazandırır. Mesele, o iş yükünü doğru teşhis etmek.

Cold-start’ın gerçek maliyeti

Bir fonksiyon bir süredir çağrılmadıysa, sağlayıcı onu sıfırdan ayağa kaldırır: runtime yüklenir, bağımlılıklar init olur, kod çalışır. Bu cold-start, çalışan bir process’e göre yüzlerce milisaniyeden saniyelere kadar ek gecikmedir.

Önemli ayrım: cold-start, düşük trafikli bir endpoint için istisna değil kuraldır. Saatte birkaç çağrı alan bir fonksiyonda neredeyse her istek cold’dur. “Ölçeğe göre ödeme” cazip gelir, ama sıfıra yakın trafikte ödediğiniz şey, kullanıcının her seferinde gördüğü gecikmedir. Latency’ye duyarlı bir kullanıcı yolunda bu doğrudan bir UX maliyetidir.

Vendor lock-in

Lock-in yalnızca runtime değildir; asıl bağ etrafındaki yapıştırıcıdadır. Bir serverless uygulaması zamanla şunlara da bağlanır: sağlayıcının event kaynakları, kimlik/yetki modeli (IAM), yönetilen kuyruğu, API gateway’i, dağıtım araçları.

Tek bir fonksiyonu taşımak kolaydır. Ama gerçek bir sistemde “serverless’tan çıkmak” çoğu zaman bir taşıma değil, bir yeniden yazımdır. Bu, boring architecture yazısındaki innovation token mantığıyla doğrudan ilgili: tek bir karar gibi görünen şey, aslında geri alınması pahalı bir bağdır.

Hangi iş yükünde kazandırır

Serverless, yükün değişken ve seyrek olduğu yerde parlar:

  • Zamanlanmış işler — gecelik raporlar, cron benzeri görevler.
  • Webhook alıcıları — ne zaman, ne sıklıkta geleceği belirsiz.
  • Düşük hacimli iç araçlar — günde birkaç kez kullanılan paneller.
  • Ani patlamalı (bursty) batch işleri — saatte bir, kısa süreliğine yüksek paralellik.

Bu yüklerde sıfıra inen ölçek gerçek para tasarrufudur ve cold-start çoğu zaman önemsizdir — kimse bir gece raporunun 800 ms geç başlamasını dert etmez.

Hangi iş yükünde kaybettirir

Bunun tersi de net:

  • Sabit, sürekli trafik. Her zaman çalışan bir API’de “kullanım başına ödeme”, “her saniye ödeme”ye dönüşür — ve genelde sürekli çalışan bir sunucudan pahalıdır.
  • Latency’ye duyarlı yollar. Cold-start, kullanıcının beklediği bir istekte kabul edilemez.
  • Uzun süren işler. FaaS’ın çalışma süresi sınırları vardır; uzun işler ya bölünür ya da uymaz.

Bu profildeki bir iş yükü için sıkıcı bir VPS — tek VPS üzerinde çoklu proje yazısındaki kurulum gibi — hem daha ucuz hem daha öngörülebilirdir. Sabit yükün maliyeti, sabit bir sunucuyla eşleşir.

Laravel ve serverless

Laravel tarafında Laravel Vapor, uygulamayı Lambda üzerinde çalıştırmayı mümkün kılar ve iyi de çalışır. Ama çalışması, doğru karar olduğu anlamına gelmez: Vapor’la birlikte cold-start’ı ve AWS bağını da miras alırsınız.

Karar yine iş yüküdür. Trafiği patlamalı, seyrek ya da öngörülemez bir Laravel uygulaması için Vapor mantıklı. Sürekli ve latency’ye duyarlı bir uygulama için, klasik bir sunucu hâlâ daha sade ve ucuz cevaptır.

Karışık kullanın

Bu ikili bir seçim değil. Sürekli yükü taşıyan sıkıcı bir sunucu + yalnızca seyrek/patlamalı işleri (webhook, gece raporu) serverless’a vermek çoğu zaman en dürüst dağılımdır. Her iş yükünü, kendi maliyet profiline ait olduğu yere koyun.

Serverless bir mimari modası değil, belirli bir iş yükü profili için bir araçtır. O profil sizde varsa kazandırır; yoksa cold-start ve lock-in olarak geri ödenir.

Önce yükünüzü ölçün; araç sonra gelir.