Serverless Nedir? Cold Start ve Sunucusuz Mimarinin Gerçek Maliyeti

Serverless nedir?

Serverless, sunucuları kendiniz kurup yönetmeden kod çalıştırmanızı sağlayan bulut modelidir. Sağlayıcı altyapıyı, ölçeklemeyi ve güncellemeleri üstlenir. Kodunuz bir olay geldiğinde çalışır, iş bitince durur. Genellikle çalışma süresi ve çağrı sayısı kadar ödeme yaparsınız; boşta bekleyen kapasite için sabit ücret ödemezsiniz.

Türkçede bu modele sunucusuz mimari de deriz. Ad biraz yanıltıcıdır, çünkü sunucular hâlâ vardır. Fark şurada: onları siz değil, sağlayıcı yönetir.

Bu yazıda serverless nedir sorusunu ve onunla birlikte anılan cold start (soğuk başlatma) kavramını ele alıyoruz. Komşu terimleri, örneğin event-driven mimariyi ve WebAssembly'yi, yalnızca kısaca anıyor ve ayrı yazılarımıza yönlendiriyoruz.

Hedefimiz basit: yazıyı bitirdiğinizde serverless'ın size ne verdiğini, neyi sakladığını ve hangi işte uygun olduğunu net biçimde söyleyebilmeniz. Teknik ayrıntıları kavram düzeyinde tutuyor, sayısal sınırları ise sağlayıcıların resmi belgelerine bırakıyoruz.

Serverless nedir sorusunu bir benzetmeyle nasıl açıklarız?

Bir şehirde araç ihtiyacınız olsun. Kendi aracınızı almak, sigortalamak, bakımını yapmak ve park yeri aramak sizin işinizdir. Taksi çağırdığınızda ise yalnızca gittiğiniz yol için ödersiniz. Aracın bakımı sizi ilgilendirmez.

Klasik sunucu, kendi aracınıza benzer. Gece boyunca garajda dursa bile masrafı sürer. Serverless ise taksiye benzer: çağırdığınızda gelir, işiniz bitince gider.

Bu benzetmenin bir de bedeli var. Taksiyi ilk çağırdığınızda biraz beklersiniz. Cold start tam olarak bu bekleme süresidir. Aracı garajda tutmak beklemeyi sıfırlar, ama masrafı geri getirir.

Dolayısıyla serverless nedir sorusunun dürüst cevabı, rahatlığı da bu takası da içerir. Taksi her yolculukta ucuz olmaz; sürekli kullanıyorsanız kendi aracınız daha mantıklı hale gelebilir.

Serverless gerçekten sunucusuz mu?

Hayır. Kodunuz yine bir fiziksel makinede, çoğunlukla izole bir ortamda çalışır. Değişen şey sorumluluk dağılımıdır. İşletim sistemi güncellemesi, güvenlik yaması, kapasite planı ve ölçekleme kararları sağlayıcıya geçer.

Sizin tarafınızda ise kod, yapılandırma, yetkiler ve veri kalır. Serverless nedir sorusunu yanıtlarken bu paylaşımı bir sınır çizgisi gibi düşünebilirsiniz. Yani yönetim yükü azalır, ama sorumluluk bitmez. Kodunuzdaki bir güvenlik açığı ya da hatalı bir izin ayarı yine size aittir.

Bu ayrımı baştan netleştirmek önemlidir. Çünkü serverless bir sihir değil, iş bölümüdür. Kimin neyi üstlendiğini bilen ekip, hem maliyeti hem riski daha doğru tartar.

Üstelik bu bakış, sağlayıcıyla konuşurken de işinize yarar. Bir sorun çıktığında hangi katmanın kimde olduğunu bildiğiniz için doğru yere başvurursunuz.

Serverless nasıl çalışır?

Mantığı dört adımda özetleyebiliriz. Önce bir olay gelir: bir web isteği, bir dosya yüklemesi, bir zamanlayıcı ya da bir kuyruk mesajı olabilir. Ardından sağlayıcı bu olay için hazır bir çalışma ortamı arar.

1. Olay: Bir tetikleyici fonksiyonunuzu çağırır.
2. Ortam hazırlığı: Sağlayıcı kodunuzu alır, çalışma ortamını açar ve başlangıç kodunuzu çalıştırır.
3. Çalıştırma: Fonksiyonunuz isteği işler ve cevabı döndürür.
4. Bekleme ya da kapanış: Sağlayıcı ortamı bir süre bekletir; yeni istek gelmezse kapatır.

Önemli olan üçüncü ve dördüncü adım arasındaki ilişkidir. Ortam bekletilirken yeni bir istek gelirse sağlayıcı aynı ortamı yeniden kullanır. Böylece ikinci istek genellikle daha hızlı biter.

AWS Lambda belgeleri bu yaşam döngüsünü başlatma, çağırma ve kapanış aşamalarıyla anlatır. Ayrıca sağlayıcı ortamları belirli aralıklarla yeniler. Bu yüzden ortamın sonsuza kadar yaşayacağını varsaymamalısınız. Fonksiyonunuzu her çağrıda sıfırdan başlayabilecek şekilde yazın, sıcak ortamın sağladığı hızı ise bir ödül olarak görün.

FaaS ve BaaS nedir, serverless ile ilişkisi ne?

Serverless çatısı altında iki ana kavram dolaşır. Sık karıştırıldıkları için ayırmakta yarar var.

• FaaS (Function as a Service, hizmet olarak fonksiyon): Küçük kod parçalarını olaya bağlı çalıştırırsınız. Ortamı sağlayıcı yönetir.
• BaaS (Backend as a Service, hizmet olarak arka uç): Kimlik doğrulama, veritabanı ve dosya depolama gibi hazır servisleri API üzerinden kullanırsınız. Kendi sunucu kodunuzu yazmanız gerekmez.

Pratikte iki kavram yan yana çalışır. Örneğin bir mobil uygulama giriş işlemini BaaS ile çözer, özel iş kuralını ise bir FaaS fonksiyonunda çalıştırır.

Genel anlamda serverless nedir diye sorarsanız, çoğu kişi FaaS'ı kastediyor. Ancak tanım BaaS'ı da kapsar. Ortak nokta, altyapıyı yönetmemenizdir.

Bir farkı da not edin: FaaS'ta kodu siz yazarsınız, BaaS'ta çoğu kodu sağlayıcı yazmıştır. Bu yüzden BaaS daha hızlı başlar, ama esnekliği daha dardır.

Serverless hangi bulut sağlayıcılarında bulunur?

Büyük bulut sağlayıcılarının hepsi bu modeli sunar. Örneğin AWS Lambda, Azure Functions ve Google Cloud'un Cloud Run gibi servisleri aynı fikri farklı adlarla uygular. Kavram ortaktır: kodu yüklersiniz, tetikleyiciyi bağlarsınız, ölçeklemeyi sağlayıcı yapar.

Farklar ayrıntıda çıkar. Her sağlayıcının çalışma süresi sınırı, desteklenen diller, tetikleyici türleri ve fiyat yapısı farklıdır. Hatta aynı sağlayıcı, zaman içinde ürün adlarını ve planlarını değiştirebilir.

Bu yüzden ürün adlarına ve sınır değerlerine yaslanmayın. Karar anında sağlayıcının resmi belgesini açın ve güncel planı oradan okuyun.

Biz bu yazıda belirli bir sağlayıcıyı öne çıkarmıyoruz. Amacımız, hangisini seçerseniz seçin geçerli olacak kavramları anlatmak. Serverless nedir sorusunun cevabı sağlayıcıdan bağımsızdır; değişen yalnızca düğmelerin ve fiyat tablolarının adıdır.

Cold start (soğuk başlatma) nedir ve neden olur?

Cold start, uzun süredir çalışmayan bir fonksiyona ilk istek geldiğinde yaşanan ek gecikmedir. Çünkü o anda hazır bir çalışma ortamı yoktur. Sağlayıcı kodunuzu indirir, ortamı başlatır ve başlangıç kodunuzu çalıştırır. Ancak bundan sonra isteğiniz işlenir.

Aynı ortamı kısa süre sonra yeniden kullanırsa buna warm start (sıcak başlatma) deriz. Bu durumda hazırlık adımlarını atlar ve cevap daha çabuk gelir.

AWS belgeleri, cold start'ın isteklerin küçük bir bölümünde görüldüğünü ve düşük trafikli geliştirme ortamlarında daha sık yaşandığını anlatır. Sebep basit: az çağrılan fonksiyonun ortamı bekletilmeden kapanır.

Yani cold start bir hata değil, modelin doğal sonucudur. Asıl soru, onun kullanıcı deneyimine ne kadar yansıdığıdır. Kimse fark etmiyorsa, uğraşmanıza gerek yoktur. Örneğin gece çalışan bir veri temizleme işinde birkaç saniyelik hazırlık kimseyi rahatsız etmez. Buna karşılık ödeme sayfasındaki bir fonksiyonda aynı gecikme kullanıcıyı vazgeçirebilir.

Cold start süresini hangi etkenler belirler?

Tek bir sabit süre yoktur. Gecikme, kodunuzun ve ortamın özelliklerine göre değişir. AWS belgeleri, başlatma gecikmesinin en büyük payını başlangıç kodunun oluşturduğunu söyler.

• Paket boyutu: Ne kadar çok kütüphane ve bağımlılık eklerseniz, indirme ve yükleme o kadar uzar.
• Başlangıç işi: Fonksiyon dışında çalışan kod, bağlantı kurma ve yapılandırma okuma gibi işleri içerir.
• Çalışma zamanı (runtime): Bazı diller ve çerçeveler daha ağır bir hazırlık ister.
• Ağ ayarları: Özel ağa bağlanan fonksiyonlar ek hazırlık gerektirebilir.
• Bellek ve işlemci payı: Fonksiyona ayırdığınız kaynak, hazırlık süresini etkileyebilir.

Bu etkenlerin kesin değerleri sağlayıcıya ve zamana göre değişir. Dolayısıyla rakam aramak yerine kendi fonksiyonunuzu ölçmek en güvenilir yoldur.

Ölçerken yalnızca ortalamaya bakmayın. Cold start az sayıda isteği etkilediği için ortalamada kaybolur. En yavaş isteklere bakan bir ölçüm, gerçek resmi gösterir.

Cold start nasıl azaltılır?

Çözümler iki gruba ayrılır: başlatma işini hafifletmek ve ortamı hazır tutmak. Önce ücretsiz olanlarla başlamak mantıklıdır.

• Paketi küçültün: Yalnızca gerçekten kullandığınız kütüphaneleri ekleyin. Büyük bir fonksiyonu daha küçük, amaca özel fonksiyonlara bölmek de yardımcı olur.
• Başlangıç kodunu sadeleştirin: Her istekte gerekmeyen işleri ilk ihtiyaç anına erteleyin. Buna lazy loading (ihtiyaç anında yükleme) deriz.
• Bağlantıları yeniden kullanın: Veritabanı bağlantısı gibi kaynakları fonksiyon dışında açın ki sıcak ortamlar onları tekrar kullansın.
• Hazır örnek tutun: AWS'de provisioned concurrency, Azure'da always ready örnekler, Google Cloud Run'da minimum örnek sayısı bu işe yarar.
• Anlık görüntü kullanın: AWS SnapStart gibi özellikler, hazırlanmış ortamın görüntüsünü saklar ve oradan devam eder.

Hazır örnek tutmanın ücretsiz olmadığını unutmayın. Google da minimum örneklerin boşta bile ücret doğurduğunu belirtir.

Hazır örnek tutmak ne zaman değer?

Hazır örnek, cold start'ı azaltır ama sabit bir maliyet getirir. Böylece serverless'ın en çekici özelliklerinden biri, yani boşta ödememe avantajı kısmen kaybolur. Bu takas her fonksiyon için değerli değildir.

Şu sorular karar vermenize yardım eder:

• Fonksiyon kullanıcının doğrudan beklediği yolda mı?
• Gecikme dönüşümü ya da deneyimi gözle görülür ölçüde etkiliyor mu?
• Trafik zamana göre tahmin edilebiliyor mu, yani yalnızca yoğun saatlerde mi hazır tutmak yeter?
• Arka plan işi mi, yoksa kullanıcı isteği mi?

Arka plan işlerinde hazır örnek çoğu zaman gereksizdir. Kullanıcı yolunda ise küçük bir hazır havuz, tutarlı bir deneyim sağlar.

Önce ölçün, sonra karar verin. Ölçmeden hazır örnek eklemek, bir sorunu çözmek yerine yalnızca fatura kalemi eklemek olabilir. Ayrıca bir deneme süresi tanımlayın: örneğin iki hafta boyunca gerçek kullanıcı gecikmesini izleyin, sonra hazır örnek sayısını bu veriyle belirleyin.

Cold start sitenizin hızına ve SEO'ya nasıl yansır?

Bir sayfanız ya da API'niz serverless fonksiyonla çalışıyorsa, cold start ilk bayt süresine eklenir. Böylece sayfanın yüklenme hissi yavaşlayabilir. Bu da Core Web Vitals ölçümlerinde kendini gösterebilir.

Ancak her fonksiyon kullanıcı yoluna girmez. Gece çalışan bir rapor işinde küçük bir ek gecikme önemsizdir. Oysa ürün sayfasını üreten bir fonksiyonda aynı gecikmeyi kullanıcı fark eder.

Bu yüzden fonksiyonlarınızı ikiye ayırın: kullanıcının beklediği yol ve arka plan işleri. İlkinde gecikmeye duyarlı davranın. İkincisinde cold start'a aldırmayın.

Genel hız mantığını site hızı SEO'yu nasıl etkiler yazımızda ayrıca anlattık. Sayfaları önceden üretip önbelleğe almak da cold start'ın kullanıcıya yansımasını azaltan yaygın bir yoldur. Böylece fonksiyon yalnızca önbellekte olmayan istekler için çalışır ve çoğu ziyaretçi hazır cevabı görür. Arama motoru botları da hızlı cevap aldığı için tarama deneyimi iyileşir.

Edge function serverless fonksiyondan nasıl ayrılır?

Edge function (uç fonksiyon), kodunuzu tek bir merkez bölgede değil, kullanıcıya yakın dağıtık noktalarda çalıştıran serverless türüdür. Amaç, mesafeden doğan gecikmeyi azaltmaktır. Gecikmenin temel mantığını ping ve latency yazımızda bulabilirsiniz.

Fark şu noktalarda ortaya çıkar:

• Konum: Klasik fonksiyon seçtiğiniz bölgede çalışır. Edge fonksiyon ağın ucunda çalışır.
• Başlatma: Edge ortamları genellikle daha hafif olacak şekilde tasarlandığı için hazırlık süresi kısa kalma eğilimindedir.
• Kısıtlar: Kullanabileceğiniz kütüphaneler, çalışma süresi ve bellek çoğu zaman daha dardır.
• Kullanım: Yönlendirme, kimlik kontrolü, başlık düzenleme ve basit kişiselleştirme için uygundur.

Edge, ağır veritabanı işlemleri için doğru yer değildir. Veri tek bölgede duruyorsa, kod uçta olsa bile veriye gidiş gecikmeyi geri getirir.

Serverless, VPS ve konteyner arasındaki fark nedir?

Üç model de kod çalıştırır, ama sorumluluk ve fatura mantıkları farklıdır. Aşağıdaki tablo kavramsal bir karşılaştırmadır. Rakam içermez, çünkü fiyatlar sağlayıcıya göre değişir.

Konteynerin mantığını Docker nedir yazımızda, VPS ile bulut sunucu farkını ise VPS, VDS ve bulut sunucu rehberimizde anlattık.

Üç modelin hiçbiri kesin kazanan değildir. İş yükünüzün şekli, ekibinizin deneyimi ve bütçenizin esnekliği tabloyu değiştirir. Sabit sunucuda bir uygulamayı yayına almak isterseniz Next.js VPS kurulum rehberimiz iyi bir karşılaştırma noktasıdır.

Serverless nedir diye soranlar için maliyet modeli nasıl işler?

Serverless'ta fatura genellikle iki kalemden oluşur: çağrı sayısı ve çalışma süresiyle birleşen kaynak kullanımı. Hiç istek gelmezse fatura da büyük ölçüde düşer. Bu, trafiği öngörülemeyen ya da dalgalı projeler için çekicidir.

Sabit ve yoğun trafikte tablo değişebilir. Fonksiyon gün boyu sürekli çalışıyorsa, kullanım başına ödeme sabit bir sunucudan pahalıya gelebilir. Çünkü o sunucuyu zaten doldurmuş olacaktınız.

Örnek senaryo: Kampanya dönemlerinde yoğunlaşan, diğer günlerde sakin kalan bir form servisi düşünün. Boşta kaldığı zamanlarda ücret ödememek büyük avantaj sağlar. Her saniye aynı yükü taşıyan bir API ise sabit kapasiteyle daha öngörülebilir olabilir.

Gizli kalemleri de unutmayın. Veri çıkışı, günlük saklama, kuyruk ve API ağ geçidi gibi yan servisler faturaya ayrıca yansıyabilir. Güncel fiyatları ve ücretsiz kullanım sınırlarını mutlaka sağlayıcının resmi fiyat sayfasından kontrol edin.

Satıcıya bağımlılık (vendor lock-in) serverless'ta neden daha belirgindir?

Her sağlayıcının tetikleyicileri, yapılandırma biçimi, izin sistemi ve yardımcı servisleri farklıdır. Fonksiyon kodunuz taşınabilir görünse bile, onu çevreleyen kuyruk, depolama ve kimlik katmanını başka yere götüremezsiniz. Bu bağlılığa vendor lock-in (satıcıya bağımlılık) deriz.

Bağımlılığı tümüyle yok edemezsiniz, ama azaltabilirsiniz:

• İş mantığını sağlayıcıdan bağımsız, düz kod olarak ayrı tutun.
• Sağlayıcıya özel kodu ince bir bağdaştırıcı katmanında toplayın.
• Açık standartları, örneğin HTTP ve standart olay biçimlerini tercih edin.
• Geçiş maliyetini önceden, yaklaşık düzeyde değerlendirin.

Bazen bağımlılık kabul edilebilir bir bedeldir. Hız kazanıyorsanız ve çıkış yolunu biliyorsanız, risk yönetilebilir kalır. Önemli olan bunu bilinçli seçmektir.

Konteyner tabanlı kurulumlar bu konuda daha esnektir. Aynı konteyneri farklı ortamlara taşıyabildiğiniz için çıkış kapısı daha geniştir.

Serverless'ın sınırları ve riskleri nelerdir?

Serverless her sorunu çözmez; bazı kısıtlarla birlikte gelir. Bunları baştan bilmek, sonradan pahalı yeniden yazımları önler.

• Çalışma süresi sınırı: Bir fonksiyon belirli bir süreden uzun çalışamaz. Uzun işleri parçalara bölmeniz gerekir.
• Durumsuzluk: Ortam her an kapanabilir, bu yüzden kalıcı veriyi fonksiyonun içinde tutamazsınız. Veriyi dış depolamaya yazın.
• Bağlantı sayısı: Çok sayıda eşzamanlı fonksiyon, veritabanını çok sayıda bağlantıyla yorabilir.
• Gözlemlenebilirlik: Dağınık fonksiyonlarda hatayı izlemek için iyi günlük ve izleme kurmanız gerekir.
• Tekrar denemeler: Birçok tetikleyici hata durumunda işi yeniden dener. Aynı işlemi iki kez yapmamak için idempotency ilkesini uygulayın.
• Yerel geliştirme: Bulut ortamını yerelde birebir taklit etmek zor olabilir.

Bu kısıtların hiçbiri engel değildir. Ancak her biri bir tasarım kararı ister. Örneğin çalışma süresi sınırına takılan bir dosya işleme görevini, küçük parçalara bölüp kuyrukla birbirine bağlayabilirsiniz. Böylece her parça sınırın içinde kalır ve bir parça başarısız olursa yalnızca o parçayı yeniden denersiniz.

Serverless güvenlik açısından nelere dikkat ister?

Sağlayıcı altyapıyı korur, ama uygulamanın güvenliği sizde kalır. Bu paylaşılan sorumluluk modeli, serverless için de geçerlidir.

• En az yetki ilkesi: Her fonksiyona yalnızca ihtiyaç duyduğu izinleri verin. Geniş yetkili tek bir rol, olası bir açığı büyütür.
• Gizli bilgiler: Parolaları ve anahtarları kodun içine yazmayın. Sağlayıcının gizli bilgi servisini kullanın.
• Girdi doğrulama: Fonksiyon dışarıdan gelen her veriyi güvenilmez sayar ve doğrular.
• Bağımlılıklar: Kullandığınız kütüphaneleri güncel tutun, çünkü her fonksiyon kendi paketini taşır.
• Maliyet saldırıları: Sınırsız ölçeklenen bir fonksiyon, kötü niyetli yoğun trafikte faturayı şişirebilir. Hız sınırı ve bütçe uyarısı koyun.

Bu liste kapsamlı bir güvenlik denetimi değildir. Üretime çıkmadan önce sağlayıcının güvenlik önerilerini okuyun. Ayrıca fonksiyonlarınızın erişebildiği kaynakları düzenli aralıklarla gözden geçirin, çünkü zamanla gereksiz izinler birikir.

Serverless uygulamayı nasıl izler ve test edersiniz?

Dağınık fonksiyonlarda sorunu bulmak, tek bir sunucudakinden zordur. Bu yüzden izleme işini en baştan kurmanız gerekir.

Önce her fonksiyonun günlüklerini merkezi bir yerde toplayın. Ardından başlatma süresini, hata oranını ve çalışma süresini ayrı ayrı izleyin. Sağlayıcılar genellikle cold start için ayrı bir kayıt alanı sunar. Bu sayede sorunun başlatmadan mı, kodunuzdan mı geldiğini ayırabilirsiniz.

Test tarafında üç katman işe yarar:

1. İş mantığını bulut olmadan, düz birim testlerle sınayın.
2. Fonksiyonu sağlayıcının yerel emülatörüyle ya da küçük bir deneme ortamında çalıştırın.
3. Gerçek trafiğe yakın bir yükle cold start ve ölçeklemeyi ölçün.

Son adımı atlamayın. Cold start yalnızca gerçek bulut ortamında ortaya çıkar, yerel testte görünmez. Bu yüzden serverless nedir sorusuna yalnızca kodla değil, canlı ölçümle de cevap vermelisiniz.

Serverless ile event-driven mimari nasıl birlikte çalışır?

Serverless fonksiyonların çoğu bir olaya tepki verir. Bu yüzden serverless ile olay güdümlü mimari doğal ortaktır. Olay bir kuyruğa ya da konuya düşer, fonksiyon onu alır ve işler.

Bu birlikteliğin faydası gevşek bağlılıktır. Üreten taraf, olayı kimin işleyeceğini bilmek zorunda kalmaz. Yeni bir tüketici eklemek için mevcut parçayı değiştirmezsiniz.

Bedeli de var. Olaylar sırayla gelmeyebilir, bazıları iki kez teslim edilebilir. Dolayısıyla fonksiyonlarınızı tekrara dayanıklı yazmanız gerekir.

Olay, kuyruk ve konu kavramlarının ayrıntısı bu yazının konusu değil. Onlar için event-driven mimari nedir yazımıza bakın. Burada yalnızca şunu not edelim: serverless bir mimari desen değil, çalıştırma modelidir; olay güdümlü tasarım ise onun en rahat çalıştığı desendir.

Serverless, mikroservis ve monolit arasında nasıl seçim yaparsınız?

Bu üç kavram farklı sorulara cevap verir. Monolit ve mikroservis, kodu nasıl böldüğünüzle ilgilidir. Serverless ise kodu nerede ve nasıl çalıştırdığınızla ilgilidir. Yani biri diğerinin alternatifi değildir.

Küçük bir ürün için tek parça bir uygulama çoğu zaman en sade çözümdür. Onu sabit bir sunucuda ya da konteynerde çalıştırabilirsiniz. Daha sonra yalnızca dalgalı yük alan parçaları serverless fonksiyonlara ayırırsınız.

Başlangıçta her şeyi fonksiyonlara bölmek cazip görünür. Ancak çok sayıda küçük fonksiyon, izlemeyi ve sürüm yönetimini zorlaştırır. Bu yüzden önce sınırları net olan, bağımsız parçaları seçin. Örneğin bildirim gönderme ya da görsel işleme, çoğu üründe doğal olarak ayrılan iki parçadır.

Basit bir kural işe yarar: bir parça yük, gecikme ve ölçek açısından diğerlerinden belirgin biçimde farklıysa onu ayırın. Aksi halde bölmek yalnızca karmaşıklık ekler.

Serverless hakkında sık yapılan yanlış anlamalar nelerdir?

Konuyu ilk duyanlar birkaç kalıba takılır. Bunları baştan düzeltmek, yanlış beklentiyi önler.

• "Sunucu yok, o hâlde yönetim yok." Sunucuyu siz yönetmezsiniz, ama yapılandırma, izin ve izleme sizde kalır.
• "Her zaman ucuzdur." Dalgalı yükte ucuzdur. Sabit ve yoğun yükte öyle olmayabilir.
• "Cold start çözülemez." Azaltabilirsiniz, ama bazı yöntemler maliyet getirir.
• "Her uygulama için uygundur." Uzun işlemler ve durum tutan bağlantılar zor uyum sağlar.
• "Taşınması kolaydır." Kod taşınır, ama çevresindeki servisler taşınmaz.

Bu yanlış anlamaların ortak kaynağı, modelin yalnızca iyi yüzünü anlatan kısa tanıtımlardır. Oysa doğru karar için hem avantajı hem de sınırı bilmek gerekir.

Küçük bir işletme sitesinde serverless nasıl kullanılır?

Bu bir örnek senaryodur, gerçek bir müşteri vakası değildir. Amacımız, serverless nedir sorusunu somut bir iş akışında göstermek. Bir yerel işletmenin kurumsal sitesi olduğunu ve iletişim formundan gelen mesajların e-postayla iletilmesini istediğini düşünün.

Site statik dosyalardan oluşuyor. Form gönderildiğinde bir serverless fonksiyon tetikleniyor, veriyi doğruluyor ve mesajı iletiyor. Böylece form için ayrı bir sunucu kiralamıyorsunuz. Trafik azsa maliyet de düşük kalıyor.

Aynı site, yüklenen görselleri küçültmek isterse, bu işi de bir olay fonksiyonuna verebilir. Gerekirse ağır işleme için WebAssembly gibi tekniklerden de yararlanırsınız.

Ancak sitenin tüm sayfa üretimini serverless'a bağlamadan önce cold start etkisini ölçün. Sitenizin hangi altyapıyı kullandığını görmek için site altyapı tespiti aracını deneyebilirsiniz.

Serverless'a geçmeden önce hangi kontrol listesini uygularsınız?

Karar vermeden önce şu soruları sırayla yanıtlayın. Her cevap sizi doğru seçime biraz daha yaklaştırır.

1. İş yükü olay güdümlü ve aralıklı mı, yoksa sürekli mi?
2. Kullanıcının beklediği yolda cold start gecikmesi kabul edilebilir mi?
3. Bir fonksiyonun çalışma süresi, sağlayıcının sınırı içinde kalıyor mu?
4. Kalıcı veriyi dış bir depoda mı tutuyorsunuz?
5. Tekrar denemelere karşı işlemleriniz idempotent mi?
6. Hata izleme ve günlük altyapınız hazır mı?
7. Satıcıya bağımlılığı azaltan bir katman planladınız mı?
8. Güncel fiyat, sınır ve ücretsiz kullanım değerlerini sağlayıcının resmi sayfasından kontrol ettiniz mi?
9. Gerçek trafiğe yakın bir yükle cold start ölçtünüz mü?

Bu listede iki ya da üç madde belirsizse, küçük bir pilotla başlayın. Bir fonksiyonu taşıyın, ölçün, sonra karar verin.

Yazılım mimarisi kararlarında destek isterseniz özel yazılım geliştirme sayfamıza göz atabilirsiniz.

Serverless nedir sorusunun kısa özeti ve resmi kaynaklar neler?

Kısaca özetleyelim. Serverless, altyapı yönetimini sağlayıcıya bırakıp kodu olay başına çalıştıran modeldir. Cold start ise bu modelin hazırlık gecikmesidir. Hazır örnekler, küçük paketler ve sade başlangıç kodu bu gecikmeyi azaltır.

Edge fonksiyonlar mesafeyi, hazır örnekler gecikmeyi, ölçüm ise belirsizliği küçültür. Ancak her araç bir bedel taşır. Dengeyi iş yükünüzün gerçek davranışı belirler.

Ayrıntılar için sağlayıcıların resmi belgelerini okuyun. AWS'nin Lambda çalışma ortamı yaşam döngüsü sayfası cold start ve sıcak ortam mantığını anlatır. Microsoft'un Azure Functions barındırma seçenekleri sayfası plan farklarını ve cold start davranışını karşılaştırır. Google'ın Cloud Run minimum örnek belgesi hazır örnek yaklaşımını açıklar.

Bu yazı mimari, hukuki ya da mali danışmanlık değildir. Sınırlar ve fiyatlar zamanla değişir.