1. GİRİŞ

"Serverless" veya Türkçesiyle sunucusuz mimari, altyapı yönetimini soyutlayıp geliştiricilerin iş mantığına odaklanmasını sağlayan bir yaklaşımdır. Ancak "sunucusuz" terimi fiziksel sunucuların olmadığı anlamına gelmez; tersine altyapının yönetimi bulut sağlayıcısı tarafından üstlenilir. Son yıllarda FaaS (Functions as a Service) ve BaaS (Backend as a Service) hizmetlerinin olgunlaşmasıyla birlikte sunucusuz yaklaşımlar, hızlı prototipleme, maliyet verimliliği ve otomatik ölçeklenebilirlik arayan ekipler için çekici hâle geldi.

Bu konu neden bugün önemli?

• Bulut maliyet optimizasyonu ve operasyonel yükün azaltılması modern organizasyonlar için stratejik önem taşıyor.
• Otomatik ölçeklenebilirlik ve event‑driven modeller mikroservislerden farklı bir esneklik sunuyor.
• Serverless, edge computing ve managed services'in birleşmesiyle uygulama mimarileri hızla evriliyor.

Kimler için önemli?

• Backend geliştiriciler ve platform mühendisleri
• SRE, DevOps ve maliyet kontrolünden sorumlu ekipler
• Ürün ekipleri: hızlı teslimat ve sık iterasyon gerektiren takımlar

Hangi problemleri çözüyor?

• İnfrastruktur yönetimini azaltarak geliştirme hızını artırır.
• Ölçeklenebilirliği otomatikleştirir—trafik patladığında anlık kaynak arttırımı sağlar.
• Peğerse düşük kullanım senaryolarında sadece tüketilen kaynak kadar ödeme imkânı verir (pay‑per‑use).

2. KAVRAMSAL TEMELLER

2.1 Serverless nedir — net tanım

Serverless, uygulamanın çalıştırılması için gerekli altyapı yönetiminin geliştiriciden ziyade sağlayıcı tarafından gerçekleştirildiği bir bulut modelidir. İki ana bileşen öne çıkar:

• FaaS (Functions as a Service): Kısa süreli, olay tetikli fonksiyonlar (AWS Lambda, Azure Functions, Google Cloud Functions).
• BaaS (Backend as a Service): Authentication, database, storage, messaging gibi yönetilen servisler (Firebase, Auth0, DynamoDB, Aurora Serverless).

2.2 Temel terminoloji

• Cold start: Fonksiyonun ilk çalıştırılmasında veya uzun süre boş kaldığında oluşan başlangıç gecikmesi.
• Provisioned concurrency: Cold start'ı azaltmak için önceden hazır tutulan çalışma konteynerleri.
• Event‑driven: Fonksiyonların HTTP, mesajlaşma, dosya yükleme, zamanlanmış tetikleyiciler gibi olaylara göre çalışması.
• FaaS lifecycle: Initialization (cold start), invocation, scaling, termination.

2.3 Sunucusuzın sınıflandırılması

• Function‑centric: İş mantığı fonksiyonlara bölünür (FaaS).
• Service‑centric (BaaS): Yönetilen veri servisleri, kimlik, bildirim gibi backend fonksiyonları hizmet olarak kullanılır.
• Hybrid: Kritik parçalar self‑hosted bırakılırken, diğerleri serverless ile çalışır; genelde gerçek dünyada tercih edilen yaklaşımdır.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE AKIŞ

3.1 Sistem mimarisi — event‑driven core

Sunucusuz mimariler genelde event‑driven toplama dayanır: bir olay (HTTP istek, dosya yükleme, veritabanı değişikliği, mesaj kuyruk olayı) tetiklenir ve ilgili fonksiyon çalışır. Fonksiyon kısa sürede işi yapar, gerekli managed servislere erişir ve sonuçları bırakır. Bu yapı, loose coupling ve yüksek paralellik sunar.

3.2 Örnek akış — resim işleme pipeline'ı

1. Kullanıcı dosya yükler — dosya doğrudan S3/GCS'ye yazar.
2. Storage servis event üretir (object created) — bu event FaaS fonksiyonunu tetikler.
3. Fonksiyon resmi işler (thumbnail, metadata extract) ve sonuçları başka bir bucket veya DB'ye yazar.
4. Gerekirse downstream queue'ya event gönderilir — async processing veya notification tetiklenir.

3.3 State management ve idempotency

Fonksiyonlar kısa ömürlü ve genelde stateless olduğu için state external sistemlerde saklanır (DynamoDB, CosmosDB, Redis). Idempotency ve at‑least‑once delivery semantics için idempotency keys, dedupe tables veya transactional outbox pattern'ları kullanmak önemlidir.

3.4 Dependency ve packaging

Fonksiyon paketleri minimal tutulmalı; cold start sürelerini azaltmak için bağımlılıklar optimize edilmelidir. Büyük kütüphaneler yerine lightweight utility'ler, native layer'lar veya container tabanlı functions (AWS Lambda Container Image support) tercih edilebilir.

3.5 Observability ve debugging

Serverless ortamlarında log, trace ve metrik toplama merkezi öneme sahiptir. OpenTelemetry, provider‑native tracing (AWS X‑Ray, Azure Monitor), ve centralized logging (CloudWatch, Stackdriver) kullanımı önerilir. Distributed tracing ile fonksiyon çağrıları ve downstream servis istekleri korele edilmelidir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix, Coca‑Cola ve büyük ölçek örnekleri

Netflix ve benzeri büyük şirketler genelde serverless'i belli işlevler için kullanır: event processing, data enrichment, scheduled jobs. Tamamen serverless olmak yerine hybrid yaklaşımla core veri akışları ve stateful parçalar kontrol altında tutulur. Coca‑Cola gibi IoT heavy kullanımında veri ingest ve preprocessing katmanları serverless ile hızlandırılır.

4.2 Startuplar ve MVP'ler

Hızlı prototipleme ve maliyet kontrolü isteyen startuplar sıkça serverless tercih eder. Authentication, push notification, file storage gibi BaaS servisleri ile minimum altyapı yatırımıyla ürün ortaya konur.

4.3 Veri işleme ve ETL

Gerçek zamanlı veya near‑real‑time ETL pipeline'ları (CDC, log processing) serverless ile etkin şekilde kurulur. Mesajlaşma tabanlı tetikleyicilerle küçük fonksiyonlar veri filtreleme, enrich ve yönlendirme görevlerini yerine getirir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Operasyonel yük azalır: Sunucu patching, scaling, capacity planning sağlayıcı tarafından yönetilir.
• Maliyet verimliliği: Düşük ve dalgalı kullanımda pay‑per‑use model maliyet avantajı sağlar.
• Hızlı geliştirme: Geliştiriciler altyapı yerine iş mantığına odaklanır.
• Otomatik ölçeklenebilirlik: Yük arttıkça provider kaynakları otomatik artırır.

Sınırlamalar

• Cold start ve latency: Kritik düşük gecikmeli path'lerde sorun olabilir.
• Vendor lock‑in: Provider‑specific özelliklere bağımlılık riskini artırır.
• State yönetimi: Stateful uygulamalar doğal olarak serverless'e uymayabilir.
• Observability ve debugging zorluğu: Dağıtık, event‑driven doğası debug'u karmaşıklaştırır.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Hybrid yaklaşımı benimseyin: her şey serverless olmak zorunda değil—kritik stateful parçaları kontrol altında tutun.
• Cold start impact'ini ölçün ve gereken fonksiyonlarda provisioned concurrency veya warmers uygulayın.
• Idempotency ve error handling politikalarını katmanlı olarak tasarlayın (retry with backoff, DLQ, compensating actions).

Performans optimizasyonu

• Fonksiyonları ince taneli ve tek iş sorumluluğu ile tasarlayın; büyük monolitik fonksiyonlardan kaçının.
• Bağımlılıkları minimize edin; native runtime'lar veya katmanlar (layers) kullanarak paket boyutunu küçültün.
• Cache, CDN ve edge compute ile hot path'leri optimize edin.

Güvenlik

• Least privilege ilkesiyle IAM politikalarını sıkı uygulayın; fonksiyon bazlı rol atamaları yapın.
• Sekret yönetimini managed secret store (AWS Secrets Manager, Azure Key Vault) ile yapın; environment variable'lara doğrudan hassas veri koymayın.
• Network izolasyonu gerektiğinde VPC integration ve private endpoints kullanın.

Observability

• Distributed tracing, structured logging ve metrik toplama ile fonksiyon akışlarını korele edin.
• SLI/SLA tanımları ve alert'leri fonksiyon seviyesinde belirleyin (invocation latency, error rate, cold start p90 gibi).

8. SIK YAPILAN HATALAR

• Tüm sistemi serverless yapmaya çalışma—stateful ve latency‑kritik parçaları uygun analiz olmadan taşımak hata olur.
• Idempotency veya deduplication mekanizmalarını atlamak—mesaj tekrarı durumları işletmeyi bozabilir.
• Observability'i sonradan eklemeye çalışmak—başlangıçtan itibaren tracing ve logging planlayın.
• Vendor‑specific API'lere sıkı bağımlılık—taşınabilirliği zorlaştırır ve lock‑in riskini yükseltir.

9. GELECEK TRENDLER

1. Edge serverless: FaaS'in daha fazla edge ile entegre olması; düşük gecikmeli uygulamalarda fonksiyonların istemciye yakın çalışması.
2. Serverless ve AI: Model inference'ların serverless üzerinde daha verimli çalışması ve model hosting'in managed olarak sağlanması.
3. Standardization ve portability: CloudEvents, Knative ve benzeri standartlar serverless uygulamaların taşınabilirliğini artıracak.
4. Cost intelligence: Otomatik maliyet optimizasyonu, öneri ve anomaly detection sağlayan araçların yaygınlaşması.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Serverless ile her uygulama için maliyet avantajı sağlanır mı?

   Hayır. Düşük ve düzensiz yükler için genelde maliyet avantajı olur. Sürekli yüksek yükler ve uzun CPU süreleri olan işlerde container veya VM tabanlı çözümler daha ekonomik olabilir.

2. 2. Cold start'ı tamamen ortadan kaldırabilir miyiz?

   Tamamen ortadan kaldırmak zordur; ancak provisioned concurrency, fonksiyon boyutunu küçültme, runtime seçimi ve warmers ile etkisi azaltılabilir.

3. 3. Serverless uygulamalarda nasıl test yapılmalı?

   Unit testler domain mantığını doğrulamalı; adapter ve integration testler mocked provider veya test container ile yapılmalı. End‑to‑end testler staging ortamında gerçek managed servislere karşı çalıştırılmalıdır.

4. 4. Stateful uygulamaları serverless'e taşıyabilir miyiz?

   State externalize edilerek (managed DB, distributed cache) taşınabilir. Ancak latency ve consistency gereksinimleri analiz edilmelidir; bazı durumlarda stateful servisleri ayrı tutmak daha doğru olur.

5. 5. Vendor lock‑in'i nasıl azaltırım?

   Abstractions kullanın: event schemas (CloudEvents), async messaging, portable runtimes (knative) ve infrastructure as code ile provider‑agnostic yaklaşımlar tercih edin.

6. 6. Serverless ile güvenlik riskleri nelerdir?

   Fonksiyonların geniş IAM izinlerine sahip olması, secrets'ın yanlış kullanımı ve network exposure ana risklerdir. Least‑privilege, secret store ve VPC integration ile azaltın.

7. 7. Observability için hangi metrikler kritiktir?

   Invocation count, duration (p50/p90/p99), error rate, cold start rate, downstream latency ve DLQ counts gibi metrikler izlenmelidir.

8. 8. Serverless migration için nasıl başlarım?

   Küçük, bağımsız ve event‑driven bileşenlerle başlayın. Proof of concept yapın, observability ve cost tracking ekleyin, ardından daha büyük parçaları kademeli taşıyın.

Anahtar Kavramlar

FaaS

Functions as a Service — olay tetikli, kısa süreli fonksiyon çalıştırma modeli.

BaaS

Backend as a Service — managed authentication, database, storage gibi servisler.

Cold start

Fonksiyonun ilk çağrısındaki gecikme; runtime init ve dependency yüklemesinden kaynaklanır.

Provisioned concurrency

Önceden hazır tutulan çalışma konteynerleri ile cold start etkisini azaltma yöntemi.

DLQ

Dead‑letter queue — işlenemeyen mesajların tutulduğu kuyruk.

Öğrenme Yol Haritası

1. 0–1 ay: FaaS ve BaaS temel kavramlarını öğrenin; basit bir Lambda/Azure Function örneği oluşturun.
2. 1–3 ay: Event‑driven pattern'ları, idempotency, DLQ ve retry stratejilerini uygulayın; managed DB ve secret store kullanın.
3. 3–6 ay: Observability (tracing, logging, metrik), cold start optimizasyonu ve provisioning stratejileri üzerine çalışmalar yapın.
4. 6–12 ay: Hybrid ve multi‑cloud serverless tasarımları, Knative/CloudEvents gibi portable teknolojiler ve cost governance pratiklerini implement edin.