Serverless Hosting gerçekten gelecek mi? Abartı mı, plan mı?

Serverless hosting (Function as a Service, FaaS) son yıllarda “sıfır operasyon” vaadiyle hızlı yayıldı. Ancak pratikte maliyet modeli, soğuk başlangıç (cold start) gecikmesi, log/izleme alışkanlığı ve platform bağımlılığı (vendor lock-in) gibi somut riskler doğurur. Bu rehberde serverless’in geleceğiyle ilgili “abartı mı?” sorusunu; ölçülebilir metrikler ve karar çerçevesi üzerinden netleştiriyoruz. Okuduktan sonra hangi iş yüklerinde serverless kullanacağınızı, hangi iş yüklerinde VDS/VPS tarafına dönmeniz gerektiğini net planlayabilirsiniz.

Serverless hosting tam olarak neyi “sunar”?

Serverless, sunucuyu fiziksel olarak yönetmenizi istemeyen bir bulut modelidir. Kodunuzu (ör. Node.js/Python) fonksiyon olarak deploy edersiniz; platform istekleri karşılamak için kaynakları dinamik ölçekler.

Burada kritik nokta: “sunucu yok” değildir. Sunucular ve orkestrasyon katmanı vardır; ancak kapasite planlaması ve işletim (patch, ölçekleme, bazı güvenlik konuları) sizin yerine platform tarafından yürütülür.

FaaS hangi bileşenlerle çalışır?

Genellikle aşağıdaki parçalar birlikte kullanılır: - API Gateway / HTTP endpoint: İstekleri fonksiyona yönlendirir. - Fonksiyon (FaaS): Çalışan kod birimleri. - Olay tetikleyici (event trigger): Kuyruk, dosya yükleme, scheduled job gibi. - Managed servisler: Cache, kuyruk, veritabanı, depolama gibi.

Serverless ile gelen “gizli” değişkenler

Serverless’i değerlendirirken şu değişkenler doğrudan tasarımı etkiler: - Cold start: Fonksiyon kullanılmadığında örnek (instance) kapatılabilir; yeniden çağrıda başlatma gecikmesi yaşanır. - İstek başına faturalama: Saniye başına veya çağrı başına maliyet çıkar. - CPU/RAM limitleri ve runtime süre sınırları: Fonksiyonlar genellikle maksimum çalışma süresiyle kısıtlanır. - Etkileşimli servis bağımlılığı: Örneğin her istekte dış servis çağırırsanız maliyet ve gecikme artar.

Abartı nerede başlar? Serverless’in maliyet ve performans gerçekleri

Serverless “her şeyi ucuza getirir” gibi anlatılınca yanlış beklenti oluşur. Doğru yaklaşım, iş yükünüzü istek deseni ve performans gereksinimi açısından ayrıştırmaktır.

Maliyet: “Sıfır sunucu” maliyetinin karşılığı nedir?

Serverless’te genelde iki ana kalem görürsünüz: 1) Fonksiyon çağrı (request) ve çalışılan süre (duration) 2) Transfer ve managed servisler (veritabanı, kuyruk, depolama, gateway)

Bu yüzden serverless’i maliyet açısından net kıyaslamak için şu verileri çıkarın: - Ortalama aylık request sayısı - Ortalama fonksiyon çalışma süresi (ms) - Kuyruk/worker gibi bileşenlerde iş başına ortalama süre - Veri tabanı çağrı sayısı (her fonksiyon kendi başına query atıyorsa maliyet doğrudan artar)

Aşağıdaki karar tablosu işinizi hızlandırır:

Performans: Soğuk başlangıç (cold start) hangi noktada problem olur?

Cold start problemi şu şartlarda belirginleşir: - Fonksiyonlar düşük çağrıda “boşta” kalır. - Fonksiyon paketi büyükse veya runtime başlatma maliyeti yüksekse. - Her istek veritabanına ve birden fazla servise bağımlıysa.

Cold start etkisini azaltmak için serverless platformlarında genelde şu teknikler kullanılır (isimler sağlayıcıya göre değişebilir): - Provisioned concurrency / minimum instances - Warm-up stratejileri - Fonksiyon paket boyutunu küçültme (dependency optimizasyonu)

Bu noktada net kural şudur: Gecikme hedefi olan iş yükünde “ben cold start yaşamam” demek yerine, kendi endpoint’ini gerçek trafik benzetimiyle ölçmek gerekir.

Vendor lock-in (platform bağımlılığı) gerçekten önemli mi?

Evet; serverless kararlarının en sık gözden kaçan kısmı budur. Kod mantığı taşınabilir görünse de; entegrasyonlar, olay akışları, izleme ve otomasyonlar sağlayıcıya özgü olabilir.

Lock-in’i artıran unsurlar

• Özel olarak tanımlanmış event kaynakları (kuyruk, scheduler, event bus)
• Sağlayıcının kendi log/trace ekosistemi
• Özel auth entegrasyonları ve gateway kuralları
• Managed servis kombinasyonları (ör. belirli bir cache/DB türü)

Lock-in’i azaltan unsurlar

• Fonksiyon içinde “core business” kodunu bağımsız tutma
• Dış servisleri standart arayüzlerle çağırma (HTTP/REST veya iyi soyutlanmış SDK)
• Olay akışlarını tasarlarken “tek sağlayıcıya gömülmeden” okunabilir mimari
• Çıkış planı: En azından fonksiyonların giriş/çıkış sözleşmesini dokümante etme

NetKıyas perspektifinden bakarsak: Serverless’e geçmeden önce “alternatif mimariye nasıl çıkarım?” sorusunun cevabı yazılı olmalıdır. Bu yazılı cevap yoksa lock-in riski sadece teknik değil, operasyonel bir borca dönüşür.

Güvenlik ve gözlemlenebilirlik: Serverless yönetimi kolay mı?

Serverless’te güvenlik, klasik sunucu güvenliğinden farklı katmanlarda ilerler. Patch yönetimi sizde değildir; ancak IAM, ağ erişimi, gizli anahtarlar ve log politikası sizde doğru tasarlanmalıdır.

Kimlik ve erişim (IAM) en kritik kalem

En sık yapılan hata: geniş yetkili (over-permissioned) roller. - Fonksiyonun ihtiyacı kadar yetki verin. - Her fonksiyon için ayrı rol/izin sınırları kullanın. - Gizli bilgiler için “kod içine” gömme yerine secret yönetimi kullanın.

Ağ (network) tasarımı: Varsayılanlar yetmez

Bazı iş yüklerinde fonksiyonlar internete açık olur ve bu saldırı yüzeyini büyütür. - Özel ağ erişimi (VPC / private networking) gerekip gerekmediğini net belirleyin. - Egress trafiğini kısıtlayın (outbound IP/ACL politikası). - WAF ve rate limit kurallarını endpoint seviyesinde tanımlayın.

İzleme ve log (observability) olmadan serverless “kör uçuş” olur

Serverless’te hata ayıklama genellikle loglardan yapılır. Bu yüzden şu metrikler net olmalı: - Hata oranı (5xx/exception rate) - Fonksiyon süresi dağılımı (p50, p95, p99) - Cold start oranı - Kuyruk gecikmesi (queue latency)

Uygulamada minimum hedef şu olmalı: Her fonksiyon çağrısı için correlation ID ile izlenebilirlik. Böylece “hangi çağrı neden yavaşladı?” sorusunu saatler içinde çözersiniz.

Ne zaman serverless? Ne zaman VDS/VPS/dedicated daha mantıklı?

Aşağıdaki çerçeve, “gelecek mi abartı mı?” ikilemini somut karara çevirir.

Serverless’in çok güçlü olduğu durumlar

• Trafik düzensiz ve ölçek otomasyonu gerektirir.
• İş yükü modülerdir: endpoint başına küçük işler, event tabanlı akışlar.
• Managed servis kombinasyonları zaten kullanılacaksa (kuyruk, cache, DB).
• Ekip küçük ve operasyon yükünü azaltmak öncelikse.

Serverless’in genelde zorlandığı durumlar

• Çok düşük gecikme ve yüksek throughput (saniyede yüksek istek) hedefleri varsa.
• Sürekli yüksek CPU gerektiren işler; maliyet öngörülebilirliğini düşürür.
• Ağ topolojisi, özel kernel gereksinimleri veya uzun süreli servis mantığı gerekiyorsa.
• Ortamı sağlayıcıdan bağımsız taşımak kritikse (çok katmanlı lock-in oluşur).

Pratik seçim kuralı (net)

Şu kuralı uygulayın: - Eğer iş yükünüzün en az %70’i “event-driven, parça iş” ise serverless ile başlayın. - Eğer iş yükünüzün en az %70’i “uzun süre çalışan, sürekli kaynak kullanan, düşük gecikme kritik” ise VDS/VPS/managed container daha doğru yoldur.

Net bir geçiş/deney planı: Kanıt üretmeden karar vermeyin

Serverless’i tamamen benimsemek ya da tamamen reddetmek yerine, riskleri kontrol ederek ilerleyin.

1) Pilot kapsamını daraltın

Pilot olarak seçilecek en doğru parça: - Trafiği sınırlı ama ölçülebilir bir endpoint - “Tek fonksiyon” ile tamamlanabilen bir iş - Başarısız olursa düşük riskli bir modül

2) Ölçüm matrisi oluşturun

Şunları aynı hafta içinde kıyaslayın: - Ortalama yanıt süresi (p50) - 95. yüzdelik (p95) - Hata oranı - Bir istek başına ortalama maliyet (gateway + duration + egress + DB çağrıları)

3) Load testiyle cold start etkisini dahil edin

Test yalnızca “warm” çalıştırmayla sınırlı olmamalı. - Testten önce ölçeği sıfıra yaklaştırıp yeniden çağırın. - Endpoint’in özellikle p95/p99 davranışını raporlayın.

4) Çıkış planını yazılı hale getirin

Şu 3 soruya net cevap verin: - Fonksiyon giriş/çıkış sözleşmesi nasıl taşınır? - Olay akışları hangi bağımlılıklara sahip? - Veri katmanı (DB/cache) hangi soyutlamayla kullanılacak?

Sonuç: Serverless gelecek—ama her iş için değil

Serverless hosting; düzensiz trafik, event tabanlı işler ve operasyon yükünü azaltmak isteyen ekipler için net bir ilerleme sağlar. Buna karşın sabit ve yüksek throughput, düşük gecikme garantisi ve uzun süreli kaynak kullanımı gerektiren iş yüklerinde serverless çoğu zaman maliyet/performans açısından zorlanır. En doğru aksiyon: Bir fonksiyon/pilot endpoint seçin, p95 gecikme ve istek başına maliyeti soğuk başlangıç dahil ölçün; sonuçlar beklediğiniz çerçeveye uyuyorsa ölçekleyin, uymuyorsa VDS/VPS tabanlı mimariye dönün.