Serverless (Sunucusuz) Mimari Nedir

Geleneksel bulut bilişim ve sunucu yönetimi modellerinde, bir web uygulamasını veya API servisini yayına almak için öncelikle sanal makineler (EC2, VPS) kiralamak, işletim sistemi güvenlik yamalarını takip etmek, ters vekil (Reverse Proxy / Nginx) yapılandırmalarını kurmak ve en önemlisi yılın en yoğun trafik anını (peak traffic) tahmin ederek 7/24 açık kalacak sunucu kapasitesi tahsis etmek zorundaydık. Oysa gerçek dünyada kurumsal iş yüklerinin büyük çoğunluğu düz bir çizgide ilerlemez; gece saatlerinde sıfıra yaklaşan trafik, bir kampanya bildirimi veya fatura kesim döneminde saniyeler içinde 100 katına çıkabilir. İşte Serverless (Sunucusuz) Mimari ve FaaS (Function-as-a-Service - Hizmet Olarak Fonksiyon) paradigması, geliştiricileri altyapı orkestrasyonundan tamamen kurtararak yalnızca iş mantığını (business logic) barındıran kod parçacıklarına odaklanmalarını sağlayan modern bir bulut devrimidir.

Bu kapsamlı mimari rehberde; Serverless bilişimin çalışma prensiplerini, Sıfıra Ölçekleme (Scale-to-Zero) ekonomisini, mikro-sanal makineler (Firecracker MicroVM) ile V8 Isolates (Edge Functions) arasındaki izolasyon farklarını, Cold Start (Soğuk Başlangıç) gecikmelerini sıfıra indirme tekniklerini, ilişkisel veritabanlarında Connection Pooling (Bağlantı Havuzu) krizini ve hangi senaryolarda Serverless yerine konteyner mimarilerine (Kubernetes/ECS) dönülmesi gerektiğini tüm mühendislik detaylarıyla inceliyoruz. Yazılım dünyasındaki diğer modern mimari yaklaşımlar için Uygulama ve Yazılım kategorimizi ziyaret edebilirsiniz.

1. Serverless (Sunucusuz) Mimari Nedir? Gerçekten Sunucu Yok mu?

İsminin yarattığı ilk izlenimin aksine, Serverless mimaride kodlarınız elbette yine fiziksel işlemciler ve RAM modülleri barındıran veri merkezlerindeki sunucular üzerinde çalışır. Buradaki "sunucusuz" kavramı, fiziksel donanımın yokluğunu değil; sunucu tedariki, kapasite planlaması, işletim sistemi bakımı, küme (cluster) ölçekleme ve boşta duran kapasite (idle capacity) maliyetinin geliştirici ve kurum açısından tamamen görünmez hale gelmesini ifade eder.

Modern Serverless ekosistemi iki temel sütun üzerine inşa edilmiştir:

• FaaS (Function-as-a-Service): Uygulama kodunun küçük, tek bir görevi yerine getiren, durumsuz (stateless) ve olay güdümlü (event-driven) fonksiyonlar halinde çalıştırıldığı hesaplama katmanıdır. (Örn: AWS Lambda, Cloudflare Workers, Google Cloud Functions, Vercel Functions, Azure Functions).
• BaaS (Backend-as-a-Service) ve Sunucusuz Veritabanları: Fonksiyonların ihtiyaç duyduğu veri depolama, mesaj kuyruğu, kimlik doğrulama ve dosya barındırma gibi arka uç hizmetlerinin de istek başına fiyatlandırılan yönetilen servisler olarak sunulmasıdır. (Örn: AWS DynamoDB, Neon Serverless Postgres, Upstash Redis, Supabase, Cloudflare D1).

Temel Mühendislik Prensibi: Klasik IaaS/PaaS mimarisinde sunucunun açık kaldığı süre (uptime) için ödeme yaparsınız; Serverless mimaride ise yalnızca kodunuzun bir olay tarafından tetiklenip çalıştığı milisaniye cinsinden işlem süresi ve bellek tüketimi için ödeme yaparsınız.

2. FaaS (Function-as-a-Service) Yaşam Döngüsü ve Olay Güdümlü (Event-Driven) Tetikleme

Bir FaaS fonksiyonu, geleneksel bir Node.js, Python veya Go arka uç uygulaması gibi 8080 portunu dinleyen sonsuz bir döngü (daemon process) halinde çalışmaz. Sistemde hiçbir istek yokken fonksiyonunuz bellekte yer kaplamaz; yani aktif örnek (instance) sayısı sıfırdır (Scale-to-Zero).

Adım Adım Bir Serverless Fonksiyonun Çalışma Akışı

1. Olay Kaynağı (Event Source / Trigger): Bir kullanıcı HTTP/REST isteği gönderdiğinde (API Gateway), bir S3 kovasına fatura PDF'i yüklendiğinde, bir Kafka/SQS kuyruğuna yeni sipariş mesajı düştüğünde veya bir Cron zamanlayıcısı tetiklendiğinde olay paketi (Event Payload) JSON formatında Serverless orkestratörüne iletilir.
2. İzolasyon Ortamının Hazırlanması (Sandbox Initialization): Bulut sağlayıcısı, fonksiyon kodunuzu ve bağımlılıklarını içeren hafif bir çalışma ortamı (Firecracker MicroVM veya V8 Isolate) ayağa kaldırır.
3. Handler Fonksiyonunun Yürütülmesi (Execution): Çalışma zamanı (Runtime), tanımladığınız giriş fonksiyonunu (örneğin export async function handler(event, context)) çağırır. Fonksiyon iş mantığını yürütür ve yanıtı döndürür.
4. Sıcak Bekleme (Warm State / Freeze): Fonksiyon yanıtı döndürdükten hemen sonra çalışma ortamı anında silinmez. Gelecek birkaç dakika içinde yeni bir istek gelme ihtimaline karşı ortam "dondurulur" (CPU tahsisi kesilir). Eğer kısa süre içinde ikinci bir istek gelirse, mevcut sıcak ortam (Warm Container) milisaniyeler içinde çözülerek yeniden kullanılır.
5. Sıfıra Ölçekleme (Scale-to-Zero / Eviction): Belirli bir süre (örneğin 5-15 dakika) boyunca yeni istek gelmezse çalışma ortamı tamamen kapatılır ve faturalandırma sıfırlanır. Aynı anda 5.000 paralel istek gelirse, platform otomatik olarak 5.000 izole ortamı paralel olarak ayağa kaldırır.

// Cloudflare Workers / Vercel Edge üzerinde örnek bir Serverless Handler
export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    if (url.pathname === "/api/siparis-dogrula" && request.method === "POST") {
      const payload = await request.json();
      
      // Asenkron loglama işlemini yanıtı geciktirmeden arka plana at (waitUntil)
      ctx.waitUntil(env.AUDIT_QUEUE.send({
        siparisId: payload.id,
        zaman: Date.now()
      }));

      return Response.json({
        durum: "onaylandi",
        islemBolgesi: request.cf?.colo || "edge-global"
      }, { status: 200 });
    }
    return new Response("Bulunamadı", { status: 404 });
  }
};

3. En Büyük Teknik Darboğaz: Cold Start (Soğuk Başlangıç) Nedir ve Nasıl Çözülür?

Serverless mimarinin sunduğu sıfıra ölçekleme avantajının doğal bir yan etkisi vardır: Cold Start (Soğuk Başlangıç). Uzun süredir çağrılmamış bir fonksiyona ilk istek geldiğinde veya mevcut sıcak örneklerin tamamı meşgulken ani bir trafik sıçraması (spike) yaşandığında, bulut sağlayıcısının sıfırdan yeni bir izole ortam oluşturması, kodu diske/belleğe indirmesi, çalışma zamanını (Node.js, Python, JVM, .NET) başlatması ve global değişkenleri ilklendirmesi gerekir.

Bu hazırlık süresi Cold Start gecikmesi olarak adlandırılır. Seçilen programlama diline ve paket boyutuna göre bu süre 100 milisaniye ile 3-5 saniye arasında değişebilir. Bir e-ticaret ödeme sayfasında veya gerçek zamanlı API'de 3 saniyelik ek gecikme kabul edilemez. Cold Start problemini çözmek için uygulanan modern mühendislik stratejileri şunlardır:

• Hafif Çalışma Zamanları (Runtime Seçimi): Java (JVM) ve C# (.NET) gibi ağır sanal makine ilklendirmesi gerektiren diller (SnapStart veya Native AOT derlemesi kullanılmadığı sürece) en yüksek Cold Start süresine sahiptir. Buna karşılık Rust, Go, Node.js ve Python çalışma zamanları çok daha hızlı ayağa kalkar.
• Paket Boyutunu Küçültme (Tree-Shaking & Minification): Fonksiyon paketinizin (deployment zip/bundle) boyutu 150 MB ise ağ üzerinden çalışma ortamına indirilmesi bile yüzlerce milisaniye sürer. esbuild veya swc kullanarak yalnızca kullanılan modülleri paketlemek ve paket boyutunu 1-5 MB altında tutmak Cold Start süresini %70'e kadar düşürür.
• Global Kapsam (Global Scope) Optimizasyonu ve Tembel Yükleme (Lazy Loading): Veritabanı istemcisi veya SDK başlatma işlemlerini handler fonksiyonunun dışında (global scope) tanımlayarak sıcak çağrılarda yeniden kullanılmasını sağlayın; ancak her çağrıda gerekmeyen ağır kütüphaneleri yalnızca ihtiyaç duyulan kod dallarında (dynamic import) yükleyin.
• Provisioned Concurrency (Önceden Hazırlanmış Eşzamanlılık): Kritik ödeme veya kimlik doğrulama uç noktaları için belirli sayıda fonksiyon örneğinin (örneğin 5 adet) her zaman sıcak (pre-warmed) tutulmasını yapılandırabilirsiniz.

4. Firecracker MicroVM vs. V8 Isolates: Bulut Fonksiyonları ve Edge Functions Farkı

Son yıllarda Serverless dünyasında büyük bir mimari kırılım yaşanmıştır: Geleneksel bölge merkezli (Regional) FaaS platformları ile dünya genelinde 300'den fazla uç noktada çalışan Edge Functions (Uç Fonksiyonlar) arasındaki ayrım. Bu iki yaklaşımın temel farkı, kullandıkları sanallaştırma teknolojisinde yatar.

AWS Lambda ve Firecracker MicroVM Mimarisi

AWS Lambda gibi birinci nesil kurumsal FaaS sistemleri, farklı müşterilerin kodlarını birbirinden tamamen izole etmek için KVM tabanlı Firecracker mikro-sanal makinelerini (MicroVM) kullanır. Her fonksiyon örneği kendi minimal Linux çekirdeğine, dosya sistemine ve ayrılmış RAM alanına sahiptir. Bu yaklaşım muazzam bir güvenlik izolasyonu ve işletim sistemi seviyesinde ikili (binary) kütüphane çalıştırma özgürlüğü sunar; ancak her yeni örnek için mikro bir işletim sistemi ayağa kaldırıldığından 100-500 ms civarında bir Cold Start maliyeti doğurur.

Cloudflare Workers ve V8 Isolates (Edge) Mimarisi

Cloudflare Workers, Deno Deploy ve Vercel Edge Functions ise sanal makine veya konteyner ayağa kaldırmak yerine Google Chrome tarayıcısına güç veren V8 JavaScript/WebAssembly Motorunun Isolates (İzole Bağlamlar) teknolojisini kullanır. Tek bir işletim sistemi süreci (process) içerisinde binlerce hafif V8 Isolate aynı anda güvenle çalışabilir. Yeni bir Isolate başlatmak yalnızca 2 ila 5 milisaniye sürer ve birkaç kilobayt bellek tüketir. Bu sayede Cold Start kavramı pratikte ortadan kalkar ve kodunuz İstanbul, Frankfurt veya Tokyo'daki kullanıcılara en yakın veri merkezinde (Edge PoP) anında çalışır. Merkeziyetsiz ve uç nokta odaklı web mimarilerinin geleceği hakkında daha geniş bir perspektif için Web3 ve Merkezsiz Web: Geleceğin Web Siteleri makalemizi inceleyebilirsiniz.

5. Durumsuzluk (Statelessness) ve İlişkisel Veritabanlarında Bağlantı Havuzu (Connection Pooling) Krizi

Serverless mimariye geçen yazılım ekiplerinin üretim ortamında yaşadığı en büyük teknik şok, geleneksel ilişkisel veritabanlarının (PostgreSQL, MySQL) bağlantı limitlerinin tükenmesidir.

Geleneksel bir monolitik veya konteyner mimarisinde 4 adet uygulama sunucunuz vardır ve her sunucu PostgreSQL'e 10 adet kalıcı TCP bağlantısı içeren bir bağlantı havuzu (Connection Pool) açar; toplamda 40 aktif bağlantı kullanılır. Ancak Serverless mimaride ani bir trafik artışında aynı anda 1.500 adet bağımsız Lambda fonksiyonu ayağa kalkabilir. Durumsuz (stateless) olan bu 1.500 fonksiyonun her biri kendi içinde PostgreSQL'e doğrudan yeni bir TCP/TLS bağlantısı açmaya çalıştığında:

• PostgreSQL'in max_connections sınırı saniyeler içinde aşılır ve sistem FATAL: sorry, too many clients already hatasıyla çöker.
• PostgreSQL'de her yeni bağlantı işletim sisteminde ayrı bir süreç (process) oluşturup yaklaşık 5-10 MB RAM tükettiği için veritabanı sunucusunun CPU ve RAM kaynakları yalnızca el sıkışma (handshake) işlemleriyle tükenir.

Çözüm Reçeteleri

1. Harici Bağlantı Havuzlayıcıları (PgBouncer / AWS RDS Proxy / Supabase Supavisor): Fonksiyonlar doğrudan veritabanına değil, binlerce hafif bağlantıyı karşılayıp veritabanına yalnızca 50-100 adet kalıcı bağlantı üzerinden işlem (transaction mode) ileten bir vekil (proxy) katmanına bağlanır.
2. HTTP / WebSocket Tabanlı Serverless Sürücüler: Neon Serverless Driver veya PlanetScale gibi modern platformlar, TCP bağlantısı yerine HTTP veya WebSocket üzerinden tek paketlik sorgu iletimi sağlayarak Edge ortamlarından bile sıfır bağlantı yüküyle SQL çalıştırılmasına olanak tanır.
3. Dağıtık NoSQL ve HTTP Veritabanları: Durum bilgisi, oturum (session) ve önbellekleme için TCP tabanlı klasik Redis yerine HTTP/REST tabanlı Upstash Redis veya AWS DynamoDB tercih edilir.

6. Mimari Karşılaştırma: Serverless (FaaS) vs. Edge Functions vs. Containers (Kubernetes) vs. PaaS

Her iş yükü Serverless için uygun değildir. Aşağıdaki karşılaştırma tablosu, kurumsal yazılım mimarlarının hangi iş yükünü hangi altyapı üzerinde konumlandırması gerektiğini netleştirmektedir:

Kriter / Özellik	Bölgesel FaaS (AWS Lambda, GCP Functions)	Edge Functions (Cloudflare Workers, Vercel Edge)	Konteyner / Kubernetes (AWS ECS, EKS, Cloud Run)	Geleneksel VM / PaaS (EC2, DigitalOcean, Heroku)
Sıfıra Ölçekleme (Scale-to-Zero)	Tam Destek (İstek yoksa maliyet 0$)	Tam Destek (Anlık başlatma)	Kısmi (Knative / Cloud Run destekler, standart K8s desteklemez)	Yok (7/24 sabit sunucu maliyeti)
Cold Start Gecikmesi	Orta (100 ms - 2.5 sn arası)	Sıfıra Yakın (< 5 ms - V8 Isolates)	Yüksek (Konteyner imajı çekme: 3 - 30 sn)	Yok (Sunucu sürekli açık)
Maksimum Çalışma Süresi	Kısıtlı (Örn. AWS Lambda'da maks. 15 dakika)	CPU Süresi Kısıtlı (Genellikle 30 sn - 5 dk)	Sınırsız (Saatler veya günler süren işler)	Sınırsız
Çalışma Ortamı Esnekliği	Yüksek (Standart diller + Özel Docker İmajları)	Sınırlı (JS/TS, WebAssembly, Python/Rust alt kümesi)	Tam Özgürlük (Her türlü OS paketi, GPU, FFmpeg vb.)	Tam Özgürlük
İdeal Kullanım Senaryosu	Olay güdümlü API'ler, webhook işleme, asenkron kuyruk tüketicileri	Kimlik doğrulama (JWT), A/B testi, yönlendirme, düşük gecikmeli API	Tahmin edilebilir yüksek trafikli mikroservisler, video işleme, AI çıkarımı	Monolitik kurumsal uygulamalar, kalıcı WebSocket sunucuları

7. Maliyet Ekonomisi (FinOps): Serverless Ne Zaman Ucuz, Ne Zaman Pahalıdır?

Serverless mimarinin "her zaman en ucuz seçenek olduğu" düşüncesi yaygın bir yanılgıdır. FinOps (Bulut Finansal Yönetimi) açısından Serverless maliyet eğrisi, trafiğinizin şekline ve yoğunluğuna doğrudan bağlıdır:

• Serverless'ın Rakipsiz Olduğu Senaryolar: Yeni başlayan SaaS ürünleri, MVP projeleri, mesai saatleri dışında trafiği duran B2B kurumsal portallar (örneğin B2B Bayi Portalı uygulamaları), günde birkaç bin kez tetiklenen webhook'lar ve düzensiz/patlamalı (spiky) trafiğe sahip sistemler. Bu senaryolarda 7/24 açık bir Kubernetes kümesi yönetmek yerine Serverless kullanmak altyapı faturasını %80 ila %95 oranında düşürür.
• Serverless'ın Pahalılaştığı Kırılım Noktası: Uygulamanız 7/24 boyunca saniyede 2.000 (2K RPS) sabit ve yüksek hacimli istek alıyorsa ve her istek yüksek CPU/RAM tüketiyorsa, milisaniye başına ödenen FaaS birim fiyatı, ayrılmış (Reserved) sanal makinelerin veya konteyner kümelerinin sabit fiyatını 2-3 kat aşabilir.
• LLM ve Yapay Zeka Bekleme Tuzağı (I/O Wait Trap): Geleneksel AWS Lambda fiyatlandırmasında, fonksiyonunuz bir dış API'den (örneğin OpenAI veya yavaş bir banka servisinden) yanıt beklerken CPU hiçbir iş yapmasa bile geçen duvar saati süresi (wall-clock time) üzerinden ücretlendirilirsiniz. Bu tür I/O ağırlıklı iş yüklerinde yalnızca aktif CPU süresi (Active CPU Time) üzerinden ücretlendirme yapan Cloudflare Workers veya eşzamanlılık (concurrency) destekli çalışma modelleri tercih edilmelidir. Yapay zeka destekli kurumsal sistemlerin geliştirilmesi hakkında LUMAQ ile Kurumsal Yazılım Geliştirme ve Yapay Zeka ile Tersine Mühendislik makalelerimize de başvurabilirsiniz.

8. Serverless Mimarilerde Gözlemlenebilirlik (Observability), Dağıtık İzleme ve Güvenlik

Tek bir monolitik uygulamada oluşan hatayı bulmak için sunucuya bağlanıp tek bir log dosyasını incelemek yeterlidir. Ancak yüzlerce bağımsız Serverless fonksiyonun, mesaj kuyruklarının (SQS/EventBridge) ve API ağ geçitlerinin birbirini asenkron olarak tetiklediği dağıtık bir mimaride hata ayıklamak (debugging) bambaşka bir disiplin gerektirir:

• Dağıtık İzleme (Distributed Tracing & OpenTelemetry): Kullanıcının başlattığı bir HTTP isteğine ilk giriş noktasında benzersiz bir trace_id (veya x-correlation-id) atanmalı ve bu kimlik tüm fonksiyon çağrıları ile mesaj kuyruğu başlıklarında (headers) taşınmalıdır. Bu sayede 5. adımdaki bir fatura oluşturma fonksiyonu hata verdiğinde, isteğin tüm yolculuğu uçtan uca izlenebilir.
• Yapılandırılmış Loglama (Structured JSON Logging): console.log("Hata oluştu: " + err) gibi düz metin loglar yerine, log toplama sistemlerinin (Datadog, AWS CloudWatch Logs Insights, Grafana Loki) indeksleyip sorgulayabileceği JSON formatında ({"level": "ERROR", "orderId": 4921, "durationMs": 142}) çıktı üretilmelidir.
• En Az Yetki Prensibi (Least Privilege IAM) ve Sonsuz Döngü Koruması: Her Serverless fonksiyonuna tüm veritabanlarına erişen tek bir genel IAM rolü vermek büyük bir güvenlik açığıdır. Her fonksiyon yalnızca kendi görevi için gereken tabloya ve kuyruğa erişebilmelidir. Ayrıca bir S3 kovasına dosya yazıldığında tetiklenen bir fonksiyonun tekrar aynı S3 kovasına dosya yazması sonsuz özyinelemeli döngü (recursive loop) yaratarak saatler içinde on binlerce dolarlık fatura çıkarabilir; bu nedenle mutlaka özyineleme algılama ve eşzamanlılık üst sınırları (Reserved Concurrency Limits) tanımlanmalıdır.

9. Olay Güdümlü Mimaride Hata Toleransı: Idempotency (Eşkuvvetlilik) ve Dead-Letter Queue (DLQ)

Dağıtık Serverless sistemlerde ağ kesintileri, üçüncü parti API zaman aşımları veya anlık veritabanı kilitlenmeleri kaçınılmazdır. AWS Lambda, EventBridge, SQS veya Cloudflare Queues gibi olay güdümlü platformların neredeyse tamamı "En Az Bir Kez Teslimat" (At-Least-Once Delivery) garantisiyle çalışır. Bu şu anlama gelir: Bir olay (örneğin "Sipariş #8492 için kredi kartından 4.500 TL çek" mesajı) kuyruktan okunup işlenirken fonksiyon son saniyede zaman aşımına uğrarsa veya yanıt döndüremezse, mesaj kuyruğu aynı olayı birkaç saniye sonra ikinci kez tetikler.

Eğer yazdığınız Serverless fonksiyonu Idempotent (Eşkuvvetli) değilse, aynı müşterinin kredi kartından iki kez para çekilir veya aynı müşteriye iki kez e-fatura kesilir. Üretim seviyesinde dayanıklı (resilient) bir Serverless mimari kurmak için şu üç altın kural uygulanmalıdır:

1. Idempotency Key (Tekillik Anahtarı) Kontrolü: Her olay mesajı benzersiz bir event_id veya idempotency_key taşımalıdır. Fonksiyon çalışmaya başladığında ilk iş olarak hızlı bir anahtar-değer deposunda (DynamoDB veya Upstash Redis) atomik bir koşullu yazma (Conditional Put / SET NX) işlemiyle bu anahtarın daha önce işlenip işlenmediğini kontrol etmelidir. Eğer anahtar zaten COMPLETED durumundaysa, işlemi tekrarlamadan kaydedilmiş önceki sonucu döndürmelidir.
2. Üstel Geri Çekilme ve Rastgelelik (Exponential Backoff with Jitter): Geçici bir hata (örneğin karşı sunucunun 429 Too Many Requests veya 503 Service Unavailable döndürmesi) alındığında fonksiyon hemen milisaniyeler içinde tekrar denememelidir. Tüm başarısız fonksiyonların aynı anda tekrar denemesi "Thundering Herd" (Sürü Hücumu) etkisi yaratarak karşı sistemi tamamen çökertir. Bunun yerine deneme aralıkları katlanarak (2 sn, 4 sn, 8 sn, 16 sn) ve üzerine rastgele milisaniyeler (jitter) eklenerek geciktirilmelidir.
3. Dead-Letter Queue (DLQ - Ölü Mektup Kuyruğu): Belirlenen maksimum deneme sayısına (örneğin 3 veya 5 deneme) rağmen işlenemeyen bozuk mesajlar (Poison Pill Messages) ana kuyruğu tıkamamalı ve sessizce kaybolmamalıdır. Bu mesajlar otomatik olarak bir DLQ (Ölü Mektup Kuyruğu)'na aktarılmalı, Slack/PagerDuty üzerinden mühendislik ekibine uyarı gönderilmeli ve hata düzeltildikten sonra tek tuşla ana kuyruğa geri sürülerek (Redrive) veri kaybı sıfırlanmalıdır.

10. Monolitik Sistemlerden Serverless Mimariye Geçiş: Strangler Fig (Boğucu İncir) Deseni

Onlarca yıldır çalışan büyük bir kurumsal ERP, e-ticaret veya bankacılık uygulamasını bir gecede tamamen silip baştan sona Serverless fonksiyonlarla yeniden yazmak (Big Bang Rewrite), yazılım mühendisliğinde en yüksek başarısızlık oranına sahip yaklaşımdır. Bunun yerine başarılı teknoloji organizasyonları Strangler Fig (Boğucu İncir) mimari geçiş desenini uygular:

• Adım 1 - API Gateway / Edge Yönlendirme Katmanı: Mevcut monolitik uygulamanın önüne modern bir API Ağ Geçidi (AWS API Gateway, Cloudflare Workers veya Kong) yerleştirilir. Başlangıçta tüm trafik olduğu gibi eski sisteme aktarılır.
• Adım 2 - Asenkron ve Yan Görevlerin Ayrıştırılması: İlk olarak ana veritabanını yoran PDF rapor üretimi, görsel boyutlandırma, toplu e-posta/SMS gönderimi ve webhook dinleme gibi asenkron iş yükleri monolitten koparılarak bağımsız Serverless fonksiyonlara taşınır.
• Adım 3 - Yüksek Trafikli ve Kampanya Uç Noktalarının Taşınması: Black Friday gibi kampanya dönemlerinde darboğaz yaratan ürün arama, stok sorgulama veya kupon doğrulama uç noktaları (örneğin /api/v2/kupon-dogrula) API Gateway üzerinden doğrudan yeni Serverless fonksiyonlara yönlendirilir.
• Adım 4 - Veritabanı Modernizasyonu: Zaman içinde monolitin sorumlulukları küçülürken, yeni geliştirilen tüm modüller doğrudan bulut-yerli (cloud-native) sunucusuz altyapı üzerinde doğar ve kurumsal dönüşüm sıfır kesintiyle (Zero Downtime) tamamlanır.

Sıkça Sorulan Sorular (SSS)

1. Serverless mimari mikroservis mimarisi ile aynı şey midir?

Hayır. Mikroservis, büyük bir uygulamayı iş alanlarına (sipariş, ödeme, kargo) göre bağımsız servislere bölme yazılım tasarım desenidir; bu servisleri sanal makinelerde, Kubernetes konteynerlerinde veya Serverless fonksiyonlarda çalıştırabilirsiniz. Serverless ise kodun nasıl dağıtıldığı, ölçeklendiği ve faturalandırıldığıyla ilgili bir bulut çalışma ve altyapı modelidir. Bir mikroservis, bir veya birden fazla Serverless fonksiyondan oluşabilir.

2. Serverless fonksiyonlarda WebSocket ve gerçek zamanlı (Real-Time) bağlantılar nasıl yönetilir?

Fonksiyonlar kısa ömürlü olduğu için bir istemciyle saatlerce açık kalan kalıcı TCP/WebSocket bağlantısını doğrudan fonksiyon üzerinde tutmak maliyetli ve verimsizdir. Bunun yerine bağlantı durumunu yönetilen bir ağ geçidi katmanına (AWS API Gateway WebSocket API, Pusher, Ably veya Cloudflare Durable Objects) devredip, yalnızca istemciden mesaj geldiğinde Serverless fonksiyonun tetiklenmesini sağlayan mimari desen kullanılır.

3. Vendor Lock-in (Sağlayıcı Bağımlılığı) riskinden nasıl korunulur?

İş mantığınızı (domain logic) doğrudan bulut sağlayıcısına özgü olay nesnelerine (event.Records[0].s3...) sıkı sıkıya bağlamak yerine Hexagonal Architecture (Ports and Adapters) desenini kullanın. Giriş noktasındaki ince bir adaptör katmanı Lambda veya Cloudflare olayını standart bir iç veri modeline dönüştürsün; böylece çekirdek kodunuzu hiçbir değişiklik yapmadan Hono, Fastify veya standart bir Docker konteynerine dakikalar içinde taşıyabilirsiniz.

4. Uzun süren (15 dakikayı aşan) video işleme veya toplu veri aktarım işleri Serverless'ta nasıl yapılır?

Klasik FaaS fonksiyonlarının çalışma süresi sınırları (örneğin 15 dakika) vardır. Uzun süren işler için ya iş yükü AWS Step Functions / Temporal / Inngest gibi durum makineleriyle (Workflow Orchestration) küçük adımlara bölünerek zincirleme çalıştırılır ya da bu spesifik görevler AWS Fargate / Google Cloud Run Jobs gibi sunucusuz konteyner (Serverless Containers) servislerine devredilir.

5. Yerel bilgisayarda (Localhost) Serverless uygulama geliştirme ve test süreci nasıl yürütülür?

Buluta her kod değişikliğinde dağıtım (deploy) yapmak geliştirme hızını düşürür. SST (Serverless Stack), Wrangler (Cloudflare), AWS SAM CLI veya LocalStack gibi modern araçlar, yerel bilgisayarınızdaki kodu gerçek bulut kaynaklarıyla veya yerel emülatörlerle köprüleyerek milisaniyeler içinde canlı hata ayıklama (Live Lambda Debugging) ve birim testi yapmanıza olanak tanır.