Serverless Mimari Nedir?

Serverless mimari, sunucu altyapısı yönetimini bulut sağlayıcısına devrederek geliştiricilerin yalnızca koda odaklanmasını sağlayan bulut bilişim modelidir.

Serverless mimari nedir sorusu, geleneksel sunucu provizyonlama, işletim sistemi bakımı, yama yönetimi ve kapasite planlama zorunluluklarını ortadan kaldıran modern bir yazılım geliştirme paradigmasını ifade eder. Fiziksel veya sanal sunucuların tamamen yok olduğu anlamına gelmeyen bu yaklaşım, sunucu yönetiminin getirdiği tüm operasyonel yükü Amazon Web Services (AWS), Microsoft Azure veya Google Cloud Platform (GCP) gibi bulut sağlayıcılarına aktarır. Yazılım ekipleri yalnızca iş mantığını barındıran fonksiyonları yazar; altyapı ise gelen talebe göre milisaniyeler içinde sıfırdan binlerce eşzamanlı örneğe otomatik olarak ölçeklenir. Bu rehberde; sunucusuz mimarinin çalışma prensiplerini, FaaS ve BaaS bileşenlerini, maliyet dinamiklerini, soğuk başlangıç (cold start) gibi teknik kısıtları ve kurumsal geçiş stratejilerini derinlemesine inceleyebilirsiniz.

Serverless (Sunucusuz) Mimari Kavramı ve Temel İşleyişi

Serverless mimari, yazılım geliştirme dünyasında altyapı soyutlamasının ulaştığı en uç noktayı temsil eder. Geleneksel sanal sunucu (IaaS) veya platform (PaaS) modellerinde geliştiriciler, uygulamanın çalışacağı ortamın CPU, RAM, disk alanı ve işletim sistemi konfigürasyonlarını manuel olarak tanımlamak ve optimize etmek zorundadır. Sunucusuz modelde ise bulut sağlayıcısı, kodun çalıştırılması için gerekli ortamı dinamik olarak tahsis eder, talebi karşılar ve işlem tamamlandığında kullanılan kaynakları anında serbest bırakır.

Sistemin temel çalışma dinamiği "durumsuzluk" (statelessness) ilkesine dayanır. Çalıştırılan her fonksiyon örneği, bellekte kalıcı bir durum (state) tutmaz; gereken tüm veriyi harici veritabanlarından, nesne depolama alanlarından veya önbellek mekanizmalarından çeker. Fonksiyonun yaşam döngüsü; tetikleyicinin (trigger) gelmesiyle başlar, kodun yürütülmesiyle devam eder ve yanıt döndürüldükten sonra konteynerin dondurulması veya imha edilmesiyle son bulur.

FaaS (Function as a Service) ve BaaS (Backend as a Service) Farkı

Serverless ekosistemi iki ana yapı taşı üzerinde yükselir: FaaS (Function as a Service) ve BaaS (Backend as a Service). Kurumsal mimarilerde bu iki bileşen birbirini tamamlayacak şekilde kurgulanır.

• FaaS (Function as a Service): Geliştiricinin yazdığı münferit kod parçacıklarının (fonksiyonların) olay bazlı olarak bağımsız sanallaştırılmış mikro ortamlarda çalıştırılmasıdır. AWS Lambda, Azure Functions ve Google Cloud Functions bu modelin önde gelen örnekleridir. Geliştirici sadece handler fonksiyonunu ve gerekli bağımlılıkları yükler; orkestrasyon, donanım tahsisi ve paralelleştirme tamamen sağlayıcı tarafından yürütülür.

• BaaS (Backend as a Service): Bir uygulamanın ihtiyaç duyduğu veritabanı, kullanıcı kimlik doğrulama, dosya depolama ve push bildirimleri gibi arka ofis servislerinin tamamen yönetilen API'ler üzerinden sunulmasıdır. AWS Cognito, Firebase Auth, DynamoDB, FaunaDB ve Supabase gibi platformlar BaaS kategorisine girer. Yazılım ekibi arka uçta bir kimlik doğrulama sunucusu kurmak veya bakımını yapmak yerine bu servislere doğrudan istemci (frontend) veya FaaS fonksiyonları üzerinden erişir.

Olay Güdümlü (Event-Driven) İşleyiş Modeli ve Tetikleyici Mekanizmaları

Serverless mimarinin omurgasını olay güdümlü mimari (event-driven architecture) oluşturur. Geleneksel sistemlerde sunucular, gelebilecek istekleri karşılamak amacıyla sürekli dinleme (listening) modunda kaynak tüketirken; serverless mimaride fonksiyonlar sadece belirli bir olay gerçekleştiğinde uyanır.

1. HTTP/REST İstekleri: Bir kullanıcı API uç noktasına istek attığında, API Gateway bu isteği bir olaya dönüştürür ve ilgili FaaS fonksiyonunu parametrelerle birlikte tetikler.

2. Veritabanı Değişiklikleri: Bir NoSQL veritabanına yeni bir kayıt eklendiğinde (Change Data Capture) tetiklenen fonksiyon, veriyi doğrulayabilir veya farklı tablolara senkronize edebilir.

3. Depolama Olayları: Kullanıcının nesne depolama alanına (örneğin AWS S3) bir görsel yüklemesi, görselin boyutlandırılması veya filigran eklenmesi için bir fonksiyonu anında tetikler.

4. Kuyruk ve Mesaj Akışları: RabbitMQ, AWS SQS veya Apache Kafka/AWS Kinesis üzerindeki mesaj akışları, fonksiyonları toplu (batch) veya tekil olarak devreye sokar.

5. Zamanlanmış Görevler: Cron işleri yerine geçen bulut zamanlayıcıları, fonksiyonları belirli periyotlarla otomatik olarak çalıştırır.

+------------------+       +-------------------+       +--------------------+
|  Olay Kaynağı    | ----> |    API Gateway    | ----> |    FaaS Fonksiyonu |
| (S3, HTTP, SQS)  |       |   veya Router     |       |    (AWS Lambda)    |
+------------------+       +-------------------+       +--------------------+
                                                                 |
                                                                 v
                                                       +--------------------+
                                                       | Yönetilen Servis   |
                                                       | (DynamoDB / BaaS)  |
                                                       +--------------------+

Geleneksel Altyapı ve Serverless Yaklaşımının Karşılaştırması

Kurumsal karar vericilerin doğru altyapı tercihi yapabilmesi için monolitik sunucular, konteynerleştirilmiş ortamlar (Docker/Kubernetes) ve sunucusuz yapıların sunduğu imkanların teknik ve finansal parametrelerle değerlendirilmesi gerekir. Geleneksel sanal sunucu mimarilerinde kapasite planlaması, sistemin karşılaşabileceği en tepe trafik (peak load) senaryosuna göre yapılır. Bu durum, trafiğin düşük olduğu zaman dilimlerinde ciddi bir atıl kaynak israfına (over-provisioning) yol açar.

Konteyner orkestrasyon sistemleri (özellikle Kubernetes), kaynak kullanım verimliliğini artırsa da küme (cluster) yönetimi, düğüm (node) ölçekleme, ingress kontrolcüleri ve güvenlik yamaları gibi operasyonel süreçler yüksek uzmanlık ve mühendislik eforu gerektirir. Serverless yaklaşımında ise operasyonel soyutlama en üst düzeye çıkarılarak altyapı yönetimi tamamen bulut platformuna delege edilir.

Monolitik Mimari, Konteynerler (K8s) ve Sunucusuz Yapılar

Monolitik mimarilerde tüm uygulama katmanları (kullanıcı arayüzü, iş mantığı, veri erişimi) tek bir çalıştırılabilir paket halinde aynı sunucu üzerinde barındırılır. Bu yaklaşım başlangıç aşamasında geliştirme kolaylığı sağlasa da, sistem büyüdükçe yatay ölçekleme zorlaşır ve tek bir modüldeki hata tüm uygulamanın çökmesine yol açabilir.

Konteyner tabanlı mikroservis mimarileri, iş mantığını birbirinden bağımsız servislere bölerek ölçekleme esnekliği kazandırır. Ancak Kubernetes gibi platformların operasyonel karmaşıklığı, adanmış bir Site Reliability Engineering (SRE) ve DevOps ekibi gerektirir. Serverless mimari ise mikroservis yaklaşımını fonksiyon düzeyine indirger (nano-services) ve küme yönetimi katmanını tamamen ortadan kaldırır.

Maliyet ve Kaynak Tahsisi Açısından Temel Farklar

Geleneksel sunucu modellerinde faturalandırma, tahsis edilen kaynağın (vCPU, RAM, bant genişliği) zamana bağlı olarak kiralanması esasına dayanır. Sunucu üzerinde çalışan kod olmasa dahi kira bedeli kesintisiz ödenir. Serverless modelinde ise faturalandırma iki temel metriğe göre milisaniye hassasiyetinde hesaplanır:

1. Çağrı Sayısı (Request Count): Fonksiyonun kaç kez tetiklendiği.

2. Yürütme Süresi ve Bellek Tüketimi (Duration & Allocated Memory): Fonksiyonun çalışma süresi (milisaniye cinsinden) ile fonksiyona tahsis edilen bellek miktarının (MB/GB) çarpımı (GB-saniye).

Kurumlar İçin Serverless Mimarisinin Stratejik Avantajları

Dijital dönüşüm süreçlerinde kurumsal organizasyonların karşılaştığı en büyük darboğazlardan biri, yazılım mühendislerinin zamanının önemli bir kısmını altyapı sorunlarına, dağıtım boru hatlarına ve sunucu optimizasyonuna harcamasıdır. Serverless mimari, bu operasyonel sürtünmeyi ortadan kaldırarak işletmelere stratejik düzeyde çeviklik kazandırır.

Sıfır Altyapı Yönetimi ile Operasyonel Odaklanma

Serverless mimari benimseyen bir kurumda mühendislik ekipleri işletim sistemi çekirdek güncellemeleri, güvenlik yamaları, web sunucusu konfigürasyonları (Nginx, Apache ayarları) veya yük dengeleyici (Load Balancer) kurulumları ile vakit kaybetmez. Altyapının donanımsal arızaları, ağ yedekliliği ve veri merkezi düzeyindeki felaket kurtarma senaryoları bulut sağlayıcısının sorumluluğundadır. Bu durum, DevOps eforunun doğrudan iş değeri üreten özellik geliştirmeye (feature development) aktarılmasını sağlar.

Kullandıkça Öde (Pay-as-you-go) Modeliyle Maliyet Optimizasyonu

Toplam Sahip Olma Maliyeti (TCO - Total Cost of Ownership) analizlerinde, geleneksel sunucuların görünmeyen maliyetleri genellikle göz ardı edilir. 7/24 çalışan bir sanal sunucunun ortalama CPU kullanım oranı kurumsal uygulamalarda çoğunlukla %10 ile %25 arasında kalır; bu da ödenen bütçenin büyük kısmının atıl kapasiteye gittiğini gösterir.

Serverless modelde kodun çalışmadığı hiçbir milisaniye için ücret ödenmez. Örneğin, mesai saatleri dışında veya hafta sonlarında işlem hacmi düşen bir B2B platformunun arka uç maliyetleri bu zaman dilimlerinde sıfıra yaklaşır. Ayrıca AWS Lambda gibi sağlayıcıların her ay sunduğu ücretsiz kullanım limitleri (Free Tier: 1 milyon çağrı ve 400.000 GB-saniye işlem süresi), başlangıç aşamasındaki veya orta ölçekli projelerde altyapı maliyetini minimum seviyede tutar.

Talep Dalgalanmalarında Otomatik Ölçeklenebilirlik

E-ticaret kampanya dönemleri, bilet satış lansmanları veya anlık bildirim gönderimleri gibi trafiğin saniyeler içinde yüzlerce katına çıktığı senaryolarda geleneksel sunucu kümeleri "ölçekleme gecikmesi" yaşar. Bir sanal sunucunun metrikleri algılayıp yeni bir sunucu örneği başlatması genellikle 3 ila 7 dakika sürer. Bu süre zarfında gelen istekler kuyrukta bekler veya zaman aşımına (timeout) uğrayarak 504 hatalarına yol açar.

Serverless altyapılar ise her gelen isteği bağımsız bir yürütme ortamında (execution environment) karşılar. Saniyede 1 istekten saniyede 10.000 isteğe geçiş, herhangi bir insan müdahalesi veya önceden kapasite artırımı gerekmeksizin bulut platformunun orkestrasyon katmanı tarafından milisaniyeler düzeyinde otomatik olarak yönetilir.

Yüksek Erişilebilirlik (High Availability) ve Doğal Hata Toleransı

Geleneksel mimarilerde yüksek erişilebilirlik sağlamak için uygulamanın en az iki farklı Kullanılabilirlik Alanında (Availability Zone - AZ) konuşlandırılması, aralarına yük dengeleyici konulması ve sağlık kontrollerinin (health checks) yapılandırılması gerekir. Serverless servisler (AWS Lambda, Azure Functions vb.) mimari yapıları gereği varsayılan olarak çoklu AZ desteğine sahiptir. Bir veri merkezinde meydana gelen donanımsal arıza veya kesinti, kodun diğer merkezlerde anında ve kesintisiz çalıştırılmasıyla kullanıcıya hissettirilmeden absorbe edilir.

Kritik Riskler ve Dezavantajlar: Geçiş Öncesi Dikkate Alınması Gerekenler

Serverless mimari önemli operasyonel avantajlar sunsa da, her kurumsal senaryo için en uygun çözüm değildir. Doğru bir teknoloji değerlendirmesi yapabilmek adına sistemin getirdiği teknik kısıtların, mimari sınırların ve potansiyel risklerin şeffaflıkla analiz edilmesi gerekir.

Performans Gecikmeleri: Cold Start (Soğuk Başlangıç) Problemi

Serverless mimarinin en sık tartışılan teknik kısıtı "soğuk başlangıç" (cold start) olgusudur. Bir fonksiyon belirli bir süre çağrılmadığında, bulut sağlayıcısı kaynak tasarrufu sağlamak amacıyla o fonksiyonun çalıştığı konteyner ortamını bellekten temizler (idle shutdown). Fonksiyona yeni bir istek geldiğinde sağlayıcı şu adımları izlemek zorundadır:

1. Yeni bir mikro sanal makine (örneğin AWS Firecracker) tahsis etmek.

2. Çalışma zamanı (Runtime: Node.js, Python, Java vb.) ortamını başlatmak.

3. Fonksiyon kodunu ve harici kütüphane bağımlılıklarını indirmek ve belleğe yüklemek.

4. Fonksiyonun başlatma (initialization) kodunu çalıştırmak.

5. Gelen asıl isteği işlemek.

Bu süreç; hafif çalışma zamanlarında (Node.js, Python, Go) 100-300 milisaniye sürerken, JVM tabanlı dillerde (Java, Scala) veya ağır bağımlılıkları olan C# (.NET) uygulamalarında 2-5 saniyeye kadar çıkabilir. Kullanıcı etkileşimli, düşük gecikme (ultra-low latency) gerektiren kritik finansal API'lerde bu gecikme kabul edilemez olabilir. Bu sorunu aşmak için bulut sağlayıcıları "Provisioned Concurrency" (Önceden Tahsis Edilmiş Eşzamanlılık) gibi çözümler sunsa da, bu özellikler maliyet avantajını kısmen azaltır.

Sağlayıcıya Bağımlılık (Vendor Lock-in) Riski ve Taşınabilirlik

Serverless uygulamalar, yalnızca FaaS fonksiyonlarından ibaret değildir. Sistem; olay yönlendiricileri (AWS EventBridge), kimlik doğrulama servisleri (Cognito), kuyruk sistemleri (SQS) ve NoSQL veritabanları (DynamoDB) ile sıkı sıkıya entegre çalışır. Bu servislerin API'leri, veri modelleri, yetkilendirme şemaları ve tetikleyici yapıları sağlayıcıya özeldir (proprietary).

Bir bulut sağlayıcısından diğerine (örneğin AWS'den GCP'ye) taşınmak istendiğinde, sadece fonksiyon kodlarının değil, tüm altyapı otomasyonunun, veritabanı sorgularının ve olay modellerinin sıfırdan yeniden yazılması gerekebilir. Bu bağımlılığı minimize etmek amacıyla Serverless Framework, AWS SAM veya Terraform gibi Altyapı Olarak Kod (IaC) araçları tercih edilmelidir.

Hata Ayıklama (Debugging) ve Sistem İzleme (Observability) Zorlukları

Geleneksel monolitik bir uygulamada bir hatanın izini sürmek, yerel ortamda (localhost) bir hata ayıklayıcı (debugger) bağlamak veya tek bir log dosyasını incelemek kadar basittir. Dağıtık bir serverless mimaride ise tek bir kullanıcı işlemi; API Gateway, 4 farklı Lambda fonksiyonu, 2 SQS kuyruğu ve bir veritabanı tetikleyicisi üzerinden akabilir.

• Dağıtık İzleme (Distributed Tracing): İsteklerin sistem boyunca izlenebilmesi için AWS X-Ray, Datadog, Dynatrace veya OpenTelemetry tabanlı izleme araçlarının kurulması zorunludur. Her isteğe benzersiz bir korelasyon kimliği (Correlation ID) atanmalı ve bu kimlik tüm servisler boyunca taşınmalıdır.

• Yerel Test Kısıtları: Bulut servislerinin (DynamoDB, S3, EventBridge) yerel simülasyonları (LocalStack vb.) her zaman gerçek bulut ortamındaki yetkilendirme (IAM) ve ağ davranışlarını birebir taklit edemez. Bu durum, test süreçlerinin uzamasına ve hataların prodüksiyon ortamında fark edilmesine zemin hazırlayabilir.

Çalışma Süresi Sınırları ve Uzun Süreli İşlemler

Bulut sağlayıcıları, serverless fonksiyonların kaynakları sonsuz süreyle işgal etmesini engellemek için katı zaman aşımı (execution timeout) sınırları uygular. Örneğin AWS Lambda üzerinde tek bir fonksiyon çağrısı en fazla 15 dakika (900 saniye) çalışabilir; Google Cloud Functions ve Azure Functions (Tüketim Planı) için de benzer kısıtlar mevcuttur. Büyük boyutlu video işleme, derin öğrenme model eğitimi veya saatler süren büyük veri ETL süreçleri gibi uzun soluklu işlemler, tekil serverless fonksiyonlar üzerinde yürütülemez.

Serverless Mimarinin İdeal Kullanım Senaryoları ve Anti-Pattern'ler

Mimari tercihler her zaman işletmenin iş modeline, veri hacmine ve performans gereksinimlerine göre şekillendirilmelidir. Serverless yaklaşımı bazı kullanım senaryolarında devrimsel verimlilik ve maliyet avantajı sağlarken, bazı senaryolarda maliyet patlamasına ve performans sorunlarına yol açabilir.

İdeal Kullanım Alanları (Best-Fit Senaryolar)

• Düzensiz ve Tahmin Edilemeyen Trafik Alan Web API'leri: Günün belirli saatlerinde yoğun istek alan, diğer saatlerde ise neredeyse hiç kullanılmayan müşteri portalları, e-ticaret mikroservisleri ve mobil uygulama arka uçları.

• Asenkron Dosya ve Medya İşleme: Kullanıcıların sisteme yüklediği belgelerin PDF'e dönüştürülmesi, fotoğrafların sıkıştırılması veya video metaverilerinin çıkarılması gibi işlem bittiğinde sonlanan görevler.

• Gerçek Zamanlı Veri Akışları ve IoT İşleme: IoT sensörlerinden veya tıklama akışı (clickstream) loglarından gelen milyonlarca verinin anlık olarak filtrelenmesi, dönüştürülmesi ve analitik veritabanlarına yazılması.

• Üçüncü Parti Entegrasyonları ve Webhook Karşılayıcıları: Stripe, Shopify, GitHub gibi platformlardan gelen webhook bildirimlerinin dinlenmesi, doğrulanması ve kuyruklara aktarılması.

• Zamanlanmış Otomasyon Görevleri: Gece yarısı çalışan veri yedekleme, rapor oluşturma, pasif kullanıcıları temizleme ve sistem sağlık kontrolleri.

Serverless İçin Uygun Olmayan Senaryolar (Anti-Pattern'ler)

• 7/24 Kesintisiz Yüksek CPU ve GPU Tüketen İşlemler: Sürekli olarak %80-100 kapasiteyle çalışan video render sunucuları veya makine öğrenimi çıkarım motorları (inference). Bu tür sabit iş yüklerinde adanmış sanal sunucular (EC2) veya rezerve bulut örnekleri maliyet açısından %60-80 daha avantajlıdır.

• Mikrosaniye Düzeyinde Düşük Gecikme Gerektiren Finansal Sistemler: Yüksek frekanslı alım-satım (HFT) platformları ve gerçek zamanlı oyun motorları gibi soğuk başlangıç veya ağ atlama (network hop) gecikmelerini tolere edemeyen mimariler.

• Devasa Monolitik Veritabanı İşlemleri: Fonksiyonların kısa ömürlü olması, geleneksel ilişkisel veritabanlarının (PostgreSQL, MySQL) bağlantı sınırlarını hızla tüketebilir. Bu senaryolarda RDS Proxy gibi bağlantı havuzu yönetim katmanları kurulmalı veya doğrudan sunucusuz mimarilere uygun NoSQL/Aurora Serverless çözümleri seçilmelidir.

+-----------------------------------------------------------------------------+
|                     SERVERLESS KARAR MATRİSİ                                 |
+------------------------------------+----------------------------------------+
| UYGUN SENARYOLAR (DOĞRU TERCİH)    | UYGUN OLMAYAN SENARYOLAR (RİSKLİ)       |
+------------------------------------+----------------------------------------+
| * Değişken / pik yapan trafik      | * Sabit, 7/24 kesintisiz yüksek yük    |
| * Asenkron kuyruk & olay işleme    | * 15 dakikayı aşan uzun işlemler       |
| * Webhook dinleyicileri            | * Mikrosaniye düzeyinde HFT sistemleri |
| * Hızlı MVP ve pazara çıkış        | * Aşırı yoğun bağlantı açan RDBMS      |
+------------------------------------+----------------------------------------+

Serverless Mimarisine Geçiş ve Kurulum Yol Haritası

Kurumsal bir sistemin doğrudan monolitik yapıdan tamamen sunucusuz bir ekosisteme dönüştürülmesi (Big Bang yaklaşımı) yüksek operasyonel riskler barındırır. Başarılı bir dönüşüm için endüstri standardı haline gelen "Strangler Fig" (Boğucu İncir) deseni uygulanmalıdır. Bu yaklaşımda monolitik yapının kenarındaki küçük, bağımsız modüller sırayla ayrıştırılarak serverless mikroservislere dönüştürülür.

1. Hazırlık ve Ayrıştırma Analizi

İlk aşamada uygulamanın bağımlılık haritası çıkarılır. Durumsuz (stateless) çalışmaya en uygun olan ve monolitik veritabanına sıkı sıkıya bağlı olmayan bileşenler belirlenir. E-posta gönderimi, bildirim dağıtımı, görsel işleme veya rapor oluşturma gibi asenkron modüller geçiş için ilk pilot adaylardır.

2. Altyapı Otomasyonu (IaC) ve CI/CD Boru Hatlarının Kurulması

Serverless mimaride onlarca hatta yüzlerce fonksiyon bulunabileceğinden, altyapının konsol üzerinden manuel yönetilmesi mümkün değildir. Sistem baştan sona kod olarak tanımlanmalıdır (Infrastructure as Code):

• IaC Çerçevesi: AWS CDK, Serverless Framework, SAM veya Terraform kullanılarak fonksiyonlar, tetikleyiciler, bellek limitleri ve IAM yetki politikaları kod dosyalarına dökülür.

• Sürekli Entegrasyon ve Dağıtım (CI/CD): GitHub Actions veya GitLab CI üzerinde kurulan boru hatları; her pull request için birim testleri (unit tests) çalıştırır, kod paketlerini oluşturur ve fonksiyonları otomatik olarak bulut ortamına dağıtır.

3. Güvenlik, IAM ve En Düşük Yetki Prensibi (Least Privilege)

Geleneksel mimarilerde sunucu seviyesinde uygulanan güvenlik duvarları (Firewall), serverless mimaride fonksiyon seviyesinde Kimlik ve Erişim Yönetimi (IAM) politikalarına dönüşür.

• Her fonksiyona sadece ihtiyaç duyduğu kaynaklara erişim izni veren özel bir IAM rolü tanımlanmalıdır. Örneğin, yalnızca belirli bir S3 kovasından dosya okuyan bir fonksiyonun veritabanına yazma yetkisi olmamalıdır.

• Hassas API anahtarları ve veritabanı şifreleri kod içinde veya açık ortam değişkenlerinde tutulmamalı; AWS Secrets Manager veya Azure Key Vault gibi güvenli kasalardan dinamik olarak çekilmelidir.