Serverless Nedir? Avantajları ve Kullanım Alanları

Serverless nedir, gerçekten sunucusuz mudur?

Gece vardiyasında, günde yalnızca birkaç dakika çalışan küçük bir webhook servisi için ayrılmış VPS’e bakarken bu soruya takılmıştım: Bu servis kısa süre çalışıyor, geri kalan zamanda neden işletim sistemi, web sunucusu ve izleme düzeni ayakta duruyor? Sunucunun boşta beklemesi tek başına sorun değil. Yama, kapasite planlaması, log rotasyonu, yedek ve güvenlik sorumluluğu yine devam ediyor.

Serverless, bu operasyon yükünün büyük bölümünün bulut sağlayıcısına bırakıldığı bir çalışma modelidir. Adı sunucusuz olsa da fiziksel ve sanal sunucular ortadan kaybolmaz. Kodunuz hâlâ bir makinede çalışır; yalnızca o makinenin işletim sistemi, kapasitesi, ağ katmanı ve çoğu zaman çalışma zamanı sizin tarafınızdan yönetilmez.

Benim için serverless nedir sorusunun kısa cevabı şu: Uygulamayı sürekli çalışan bir sunucu yerine HTTP istekleriyle veya olaylarla tetiklenen küçük çalışma birimleri şeklinde çalıştırmaktır. Sağlayıcı bu birimleri ihtiyaç oldukça başlatır, kaynak tahsis eder ve çalışmadıkları zaman çoğu kullanım modelinde ücretlendirmeyi azaltır ya da durdurur.

Modelin iki temel parçası

Serverless denince genellikle iki farklı hizmet grubu aynı cümlede anılıyor. Bunları ayırmak, mimari karar verirken kafayı biraz daha rahat tutuyor.

Function as a Service: FaaS

FaaS modelinde uygulama kodunu bir fonksiyon olarak yüklersiniz. Fonksiyon bir HTTP isteği, kuyruk mesajı, dosya yükleme veya zamanlayıcı tarafından tetiklenebilir. AWS Lambda, Google Cloud Functions ve Azure Functions bu yaklaşımın bilinen örnekleridir.

Fonksiyonun yaşam döngüsü klasik bir VPS servisi gibi değildir. Bir işlem birkaç saniye çalışıp bitebilir. Trafik arttığında aynı fonksiyon paralel örneklerle çoğalabilir; trafik düşünce bu örneklerin bir kısmı kapatılır.

Backend as a Service: BaaS

Kimlik doğrulama, nesne depolama, veritabanı, mesaj kuyruğu veya bildirim gönderimi gibi backend parçalarını yönetilen servis olarak kullanmak da serverless mimarinin bir parçası sayılır. Firebase, Amazon DynamoDB, S3 ve çeşitli yönetilen kimlik servisleri bu grupta düşünülebilir.

Serverless kullanmak, her şeyi tek bir sağlayıcıdan almak zorunda olduğunuz anlamına gelmez. Servisler birbirine sıkı bağlandıkça platform değiştirmek zorlaşır. Bu bedeli baştan bilmek yeterince değerlidir.

Geleneksel VPS’ten farkı ne?

Bir VPS kiraladığınızda işletim sistemi ve servislerin sorumluluğu sizdedir. Nginx kurar, uygulama kullanıcısı açar, güvenlik güncellemelerini yapar, disk doluluğunu izler ve gerektiğinde servisi yeniden başlatırsınız. Serverless modelinde bu işlerin büyük kısmı sağlayıcıya geçer; sizin odağınız fonksiyon kodu, veri akışı ve uygulamanın davranışı olur.

Bu tablo serverless’ın her durumda daha ucuz veya daha iyi olduğunu göstermez. Sürekli çalışan ve trafiği tahmin edilebilir bir uygulamada uygun fiyatlı VPS daha sade, hatta daha ekonomik olabilir. Trafiği düzensiz bir API’de ise boşta bekleyen kapasite için ödeme yapmamak anlamlı bir avantaj sağlar.

VPS ile serverless arasındaki seçimi değerlendirirken Bulut Sunucu vs VPS: Hangi Senaryoda Doğru Tercih yazısındaki kaynak ve kontrol karşılaştırmasına da bakabilirsiniz.

İstekten fonksiyona: çalışma akışı

Basit bir HTTP fonksiyonunda akış çoğunlukla şöyledir:

1. Kullanıcı veya başka bir servis HTTP isteği gönderir.
2. API geçidi isteği ilgili fonksiyona yönlendirir.
3. Sağlayıcı uygun çalışma ortamını hazırlar veya sıcak bir ortamı yeniden kullanır.
4. Fonksiyon kodu çalışır ve veritabanına ya da başka bir servise erişir.
5. Yanıt döner; çalışma ortamı bir süre sonra kapatılabilir.

İlk adımla son adım arasındaki süre, kullanıcının hissettiği performansı doğrudan etkiler. Fonksiyon uzun süre çağrılmadıysa yeni çalışma ortamının hazırlanması gerekir. Buna cold start denir. Hazır bir ortam yeniden kullanılırsa warm start yaşanır ve başlangıç gecikmesi genellikle azalır.

Cold start; kullanılan dile, bağımlılıkların boyutuna, bellek ayarına ve sağlayıcının çalışma zamanına göre değişir. Bu yüzden serverless için tek bir gecikme değeri vermek doğru olmaz. Ben ölçmeden performans iddiasında bulunmam. Siz de önce gerçek trafik modelinizi görün.

Avantajları nerede ortaya çıkıyor?

Sunucu operasyonu azalıyor

İşletim sistemi güncellemesi, fiziksel disk arızası, sanal makinenin kapasite planlaması ve temel ağ bileşenleriyle uğraşmazsınız. Bu, operasyon işinin tamamen ortadan kalktığı anlamına gelmez. Yetki yönetimi, uygulama güncellemeleri, gizli anahtarlar, loglar ve maliyet takibi hâlâ sizin sorumluluğunuzdadır.

Hosting tarafında küçük servislerin zamanını çoğu zaman uygulama kodu değil, etrafındaki bakım işleri tüketiyor. Bir fonksiyon hizmetine geçiş bu yükü azaltabilir. Tek bir endpoint için ayrı VPS işletmek gereksiz hâle gelebilir.

Değişken trafikle başa çıkmak

Bir kampanya, haber paylaşımı veya dönemsel raporlama servisi gün içinde çok farklı trafik alabilir. Serverless fonksiyonları bu dalgalanmayı yönetilen ölçekleme mekanizmalarıyla karşılar. Önceden worker ayırmak yerine ihtiyaç oluştuğunda yeni örnekler açılır.

Otomatik ölçekleme sınırsız değildir. Eşzamanlılık limitleri, API geçidi kotaları, veritabanı bağlantı sınırları ve kuyruk kapasitesi birlikte düşünülmelidir. Fonksiyon sayısını artırırken arka taraftaki MySQL bağlantı havuzunu unutursanız ölçekleme veritabanına çekiçle dokunur. VPS’te MySQL Kurulumu ve Güvenli Yapılandırma rehberinde bağlantı ve yetki tarafındaki temel noktaları ayrıca ele almıştım.

Kullanım kadar ödeme

Serverless servislerde ücret çoğunlukla istek sayısı, fonksiyonun çalışma süresi, ayrılan bellek ve kullanılan ek servisler üzerinden hesaplanır. Düşük ve düzensiz trafik için bu model avantajlı olabilir.

Faturayı yalnızca fonksiyon çağrıları belirlemez. Log depolama, dışarıya veri transferi, API geçidi, veritabanı okuma-yazma işlemleri ve NAT gibi parçalar toplam maliyeti büyütebilir. İlk ay küçük görünen bir deneme, izleme kurulmadan bırakılırsa sürpriz bir faturaya dönüşebilir.

Serverless hangi işlerde daha rahat eder?

Webhook ve hafif API uçları

Ödeme bildirimi, Git deposu olayı, form gönderimi veya üçüncü taraf bir servisten gelen webhook’lar iyi adaylardır. İstek gelir, doğrulama yapılır, veri kuyruğa bırakılır ve hızlı bir yanıt döndürülür.

Webhook işleyicisini uzun süren işlerle doldurmayın. Görsel dönüştürme, PDF üretme veya büyük rapor hazırlama gibi işleri doğrudan HTTP isteği içinde yapmak yerine kuyruğa yazıp ayrı bir worker fonksiyonla işlemek daha güvenlidir.

Dosya yükleme ve medya işleme

Kullanıcı bir dosyayı nesne depolamaya yüklediğinde tetiklenen fonksiyon küçük resim üretebilir, metadata okuyabilir veya virüs taraması başlatabilir. Trafik yalnızca dosya yüklenirken oluştuğu için sürekli açık bir worker yerine olay tabanlı yapı mantıklıdır.

Büyük dosyalar ve uzun süren video işlemleri için sağlayıcının fonksiyon çalışma süresini, geçici disk alanını ve bellek limitlerini kontrol edin. Her medya işi serverless’a sığmaz. Bazen kuyruk tüketen bir VPS veya container daha doğru seçimdir.

Zamanlanmış görevler

Her gece rapor üretmek, eski kayıtları temizlemek veya bir API’den veri çekmek için cron benzeri zamanlayıcılar kullanılabilir. Serverless cron yaklaşımında sunucuda crontab düzenlemek yerine sağlayıcının scheduler servisi fonksiyonu tetikler.

Bu görevleri idempotent tasarlayın. Aynı tetikleme iki kez gerçekleşirse kayıtlar bozulmamalı, iki kez e-posta gönderilmemeli. Dağıtık sistemlerde tam bir kez çalışır varsayımı, benim birkaç kez gördüğüm gibi, pahalı bir varsayımdır.

IoT ve olay işleme

Sensör verisi, kuyruk mesajı veya uygulama logu bir olay olarak fonksiyona aktarılabilir. Fonksiyon veriyi filtreler, alarm üretir ya da zaman serisi veritabanına yazar. Çok yüksek hacimli ve sürekli veri akışında kuyruk, stream ve depolama maliyetlerini birlikte hesaplamak gerekir.

Gerçek hayatta yaptığım küçük bir zamanlayıcı hatası

Serverless kararlarını değerlendirirken zamanlanmış görevlerin görünmez risklerini özellikle kontrol ediyorum. Bunun nedeni, birkaç yıl önce cron’a fazladan bir yıldız yazdığım bir gece. Yedek scripti saatlik çalışacak sanıyordum; hatalı ifade yüzünden her dakika tetiklendi ve kısa sürede posta kuyruğunda yaklaşık 40 bin bildirim birikti.

İlk refleksim servisi yeniden başlatmak oldu. Neyse ki loglara baktım ve journalctl ile scriptin gerçekten her dakika çalıştığını gördüm. Kuyruğu körlemesine silmek yerine scripti durdurdum, gönderilmeyi bekleyen iletileri ayırdım ve cron ifadesini düzelttim. Sonra staging ortamında birkaç saat gözlem yaptım.

Serverless scheduler kullanırken crontab hatası yaşamazsınız; fakat aynı sınıftaki sorunlar yine vardır. Yanlış aralık, tekrar teslim edilen olay, başarısız işin otomatik yeniden denenmesi veya paralel çalışan görevler beklenmedik maliyet ve veri tekrarları yaratabilir. Zamanlayıcıyı kurmak kolaydır. Davranışını sınamak gerekir.

Sınırlar ve can sıkabilecek taraflar

Cold start ve gecikme

Kullanıcı her istekte sabit ve çok düşük gecikme bekliyorsa cold start kabul edilemeyebilir. Sağlayıcıların provisioned concurrency veya benzeri seçenekleri bu durumu azaltabilir; hazır kapasitenin de maliyeti vardır.

Fonksiyon paketlerini küçültmek, gereksiz bağımlılıkları kaldırmak ve ağır başlangıç işlemlerini azaltmak daha temel çözümlerdir. Tek endpoint için bir framework’ü alışkanlıkla pakete eklemek gereksiz yük yaratabilir.

Durum saklama ve veritabanı bağlantıları

Fonksiyon çalışma alanının kalıcı disk gibi davranacağını varsaymayın. Geçici dosyalar ortam kapandığında silinebilir. Kalıcı veriyi nesne depolama, yönetilen veritabanı veya ayrı bir depolama katmanında tutun.

Her yeni fonksiyon örneğinin veritabanına yeni bağlantılar açması da tehlikelidir. Bağlantı havuzu, kuyruk ve önbellek tasarımı olmadan ölçekleme veritabanını boğabilir. Serverless uygulamanın arkasında hâlâ dikkatle yönetilmesi gereken bir veri katmanı bulunur.

Sağlayıcıya bağımlılık

Bir sağlayıcının event formatı, kimlik servisi, özel veritabanı sorguları veya dağıtım araçları kullanıldıkça taşıma maliyeti artar. Bu bağımlılık her zaman yanlış değildir. Küçük bir ekip için yönetilen servisin sağladığı hız, olası taşıma maliyetinden daha değerli olabilir.

Kritik iş mantığını sağlayıcıya özgü koddan ayırmak, veri dışa aktarma yöntemini bilmek ve fonksiyonları yerel ortamda test edebilmek iyi bir sigortadır. Ben yeni bir servise geçerken önce “yarın bunu nasıl geri alırım?” diye soruyorum.

İzleme ve hata ayıklama

VPS üzerinde journalctl, Nginx access logu ve süreç listesiyle iz sürdüğünüz bir arıza serverless ortamında birkaç servise dağılabilir. İstek kimliği, korelasyon ID’si, yapılandırılmış log ve dağıtık izleme ihtiyacı burada daha belirgin hâle gelir.

Fonksiyonun başarılı dönmesi işin gerçekten tamamlandığını göstermeyebilir. Kuyruk mesajı başarısız olmuş, veritabanı yazımı geri alınmış veya üçüncü taraf API yanıt vermemiş olabilir. Başarı metriğini yalnızca HTTP 200 ile sınırlamayın.

Güvenlik tarafında neleri kontrol ederim?

Serverless hizmette sunucuya SSH ile girmemek saldırı yüzeyinin tamamının ortadan kalktığı anlamına gelmez. Fonksiyonun hangi kaynaklara eriştiğini açıkça tanımlayın. Görüntü işleme fonksiyonunun tüm veritabanına yazma yetkisi olmamalı; yalnızca gereken bucket ve tabloya erişebilmelidir.

• Gizli anahtarları kaynak koduna veya düz metin yapılandırma dosyasına koymayın.
• Fonksiyon başına en az yetki prensibini uygulayın.
• Gelen webhook imzasını doğrulayın ve tekrar oynatma saldırılarını düşünün.
• İstek gövdesi, dosya boyutu ve çalışma süresi için limit belirleyin.
• Başarısız çağrılar ve olağan dışı maliyet artışları için alarm kurun.
• Bağımlılıkları düzenli güncelleyin ve üretim paketini gereksiz dosyalardan arındırın.

Serverless güvenliğini sağlayıcının sorumluluğuna bırakmak doğru değildir. Sağlayıcı fiziksel altyapıyı ve platformu korur; uygulama izinleri, verinin gizliliği ve kodun güvenliği yine sizin alanınızdadır.

Serverless mı, container mı, VPS mi?

Kararı teknoloji modasına göre değil, iş yükünün davranışına göre veriyorum. Kısa süre çalışan, olayla tetiklenen ve stateless tasarlanabilen bir iş için serverless güçlü adaydır. Sürekli bağlantı tutan, özel sistem paketlerine ihtiyaç duyan veya uzun süre çalışan bir servis için container ya da VPS daha rahat olabilir.

Container kullanmak, sunucu yönetiminin tamamını ortadan kaldırmaz; uygulamanın paketlenmesini ve taşınmasını kolaylaştırır. Kendi VPS’inizde Docker kullanacaksanız VPS’te Docker Kurulumu ve İlk Konteyneri Çalıştırma rehberindeki temel güvenlik adımlarına bakabilirsiniz.

Sunucu üzerinde tam kontrol, sabit aylık maliyet, özel ağ yapılandırması veya sürekli çalışan bir veritabanı gerekiyorsa VPS hâlâ güçlü bir çözümdür. Serverless’ı sunucunun yeni ve her zaman daha iyi hâli gibi görmeyin. Belirli iş akışlarına uygun bir çalışma modelidir.

İlk denemeden önce kontrol ettiklerim

1. İş yükünün neyle tetiklendiğini yazın: HTTP, kuyruk, dosya olayı veya zamanlayıcı.
2. Fonksiyonun en uzun çalışma süresini ve beklenen bellek ihtiyacını ölçün.
3. Tekrar çalıştırma, zaman aşımı ve kısmi hata senaryolarını tasarlayın.
4. Veriyi nerede kalıcı tutacağınızı ve bağlantı limitlerini belirleyin.
5. İstek, log, depolama ve ağ maliyetlerini birlikte hesaplayın.
6. Yerel test, staging ve üretim ortamlarını birbirinden ayırın.
7. Alarm, log arama ve gerektiğinde geri alma prosedürünü çalıştırın.

İlk denemeyi küçük bir webhook veya görüntü metadata işleyicisiyle yapmak mantıklı olabilir. Üretim hesabında sınırsız izinlerle deneme yapmak yerine ayrı bir proje, bütçe alarmı ve dar yetkili servis hesabı açın. Cron hatamdan sonra zamanlayıcıları yalnızca kurup bırakmıyorum; kaç kez çalıştığını ve başarısız olduğunda ne yaptığını da izliyorum.

Sık Sorulan Sorular

Serverless ücretsiz midir?

Genellikle tamamen ücretsiz değildir. Bazı sağlayıcılar düşük kullanım için ücretsiz kota sunar; fakat istek, çalışma süresi, log, veri aktarımı ve kullanılan veritabanı gibi kalemleri ayrıca kontrol etmek gerekir.

Serverless uygulama için VPS gerekir mi?

Fonksiyonun çalışması için ayrıca VPS kiralamanız gerekmez. Özel bir veritabanı, VPN, sürekli çalışan worker veya sağlayıcının sunmadığı bir bileşen gerekiyorsa mimarinin bir bölümünde VPS ya da container kullanabilirsiniz.

Serverless yüksek trafikte çalışır mı?

Çalışabilir; otomatik ölçekleme bu modelin güçlü taraflarından biridir. Kota, eşzamanlılık, veritabanı bağlantıları, kuyruk kapasitesi ve maliyet limitleri test edilmeden yüksek trafik varsayımıyla üretime çıkmayın.

Serverless ile cold start nasıl azaltılır?

Fonksiyon paketini ve bağımlılıkları küçültmek, başlangıçta yapılan işi azaltmak ve uygun çalışma zamanı seçmek ilk adımlardır. Daha düşük cold start için sağlayıcının sürekli hazır örnek seçenekleri kullanılabilir; karşılığında ek ücret oluşabilir.