Cloud Run ve Container as a Service (CaaS)

Cloud Run ve Container as a Service (CaaS)

Konteynerler, uygulamaları bağımlılıklarıyla birlikte paketleyerek taşınabilirlik sağlar. Ancak konteynerleri çalıştırmak için gereken altyapıyı yönetmek (Kubernetes cluster'ı, node'lar, ölçekleme) ciddi bir operasyonel yüktür. İşte CaaS (Container as a Service) ve onun en olgun örneklerinden biri olan Google Cloud Run, bu yükü ortadan kaldırarak geliştiricilerin yalnızca konteyner imajına odaklanmasını sağlar.

1. CaaS (Container as a Service) Nedir?

CaaS, konteyner tabanlı uygulamaların dağıtılması, yönetilmesi ve ölçeklendirilmesi için bulut sağlayıcısı tarafından sunulan yönetilen bir platformdur . IaaS ile PaaS arasında konumlanır: IaaS'ın kontrolünü, PaaS'ın basitliğini birleştirir .

CaaS'ın Temel Özellikleri:

Konteyner Orkestrasyonu: Dağıtım, yük dengeleme, zamanlama ve ölçeklendirme otomatik yapılır .
Altyapı Soyutlaması: Sunucu sağlama, yama yönetimi ve bakım sağlayıcıya aittir.
Taşınabilirlik: Standart OCI konteyner imajları sayesinde platformlar arası geçiş kolaydır .
Entegrasyon: CI/CD, yönetilen veritabanları ve mesaj kuyrukları ile doğal entegrasyon .

CaaS Örnekleri: AWS ECS Fargate, Google Cloud Run, Azure Container Apps, Google Kubernetes Engine (GKE) .

2. Google Cloud Run Nedir?

Cloud Run, Google'ın ölçeklenebilir altyapısı üzerinde kod, fonksiyon veya konteyner çalıştıran tam yönetilen bir uygulama platformudur . Konteyner imajı zorunlu değildir; Go, Node.js, Python, Java, .NET gibi dillerde kaynak koddan doğrudan dağıtım da yapılabilir .

Üç Çalıştırma Modeli:

Model	Amaç	Özellik
Service	HTTP isteklerine yanıt veren stateless uygulamalar	Otomatik ölçekleme, HTTPS endpoint, WebSocket/gRPC desteği
Job	Çalışıp biten görevler (script, batch iş)	Manuel veya zamanlanmış; array job ile paralel işleme
Worker Pool	HTTP tabanlı olmayan, pull-based arka plan işleri (Kafka consumer, Pub/Sub)	Manuel ölçekleme; CREMA ile harici metrik tabanlı otomatik ölçekleme

Cloud Run Service'in Öne Çıkan Özellikleri:

Scale-to-Zero: Trafik yoksa instance sayısı sıfıra iner; boşta ücret ödenmez .
Hızlı Cold Start: CPU tabanlı cold start'lar bu karşılaştırmadaki en hızlısıdır .
Cömert Ücretsiz Katman: Kalıcı bir ücretsiz kullanım kotası sunar .
Eşzamanlılık (Concurrency): Bir instance, aynı anda 1.000'e kadar isteği karşılayabilir .
Trafik Yönetimi: Revision'lar arasında kademeli trafik bölme (canary) ve geri alma desteği .

3. Cloud Run vs. Diğer CaaS Platformları (2026)

Kriter	Google Cloud Run	AWS Fargate	Azure Container Apps
Scale-to-Zero	✅ Evet (gerçek sıfır)	❌ Hayır (boşta ücret)	✅ Evet
Cold Start	En hızlı (CPU için)	En yavaş	Değişken
Maksimum Konteyner	8 vCPU / 32 GiB	32 vCPU / 244 GiB	2 vCPU / 4 GiB (Consumption)
Ücretsiz Katman	✅ Cömert	❌ Yok	✅ Var
Ölçekleme Tetikleyicileri	Eşzamanlılık tabanlı	Manuel yapılandırma	KEDA (kuyruk, cron, custom)
En Uygun Senaryo	HTTP API, web, AI inference	Sürekli, ağır iş yükleri	KEDA tabanlı event-driven

Cloud Run'un Sınırları:

GPU'lu cold start'lar yavaştır (35-40 saniye) .
Konteyner boyutu Fargate'e göre daha küçüktür .
Fiyatlandırma sayfaları arasında tutarsızlıklar bütçe riski yaratabilir .

4. Cloud Run'da Yürütme Ortamı Seçimi

Cloud Run, iki yürütme ortamı sunar ve seçim cold start ile performansı doğrudan etkiler :

Ortam	Temel	Cold Start	Kullanım
1. Nesil	gVisor	Kısa	Ani trafik, sık scale-to-zero, <512 MiB bellek
2. Nesil	microVM	Daha uzun	CPU-yoğun, NFS gerektiren, kararlı trafik

Pratik Kural: Cold start sizin için kritikse ve trafiğiniz düzensizse 1. Nesil'i seçin. CPU-yoğun ve kararlı bir iş yükünüz varsa 2. Nesil daha iyi performans verir .

5. Cloud Run'da .NET Desteği

Cloud Run, .NET uygulamalarını doğal olarak destekler. .NET 8+ ile minimal API veya ASP.NET Core uygulamanızı standart bir Dockerfile ile paketleyip dağıtabilirsiniz.

Kritik Nokta: Cloud Run, konteynerin PORT environment variable'ında belirtilen portu dinlemesini bekler . .NET uygulamanızda bu portu okumalısınız:

csharp

var port = Environment.GetEnvironmentVariable("PORT") ?? "8080";
builder.WebHost.UseUrls($"http://0.0.0.0:{port}");

Dağıtım:

bash

gcloud run deploy my-dotnet-service \
  --image gcr.io/my-project/my-dotnet-app:latest \
  --cpu 1 --memory 512Mi \
  --min-instances 0 --max-instances 10 \
  --allow-unauthenticated

6. Ne Zaman Cloud Run, Ne Zaman CaaS'ın Diğer Türleri?

Senaryo	Öneri
HTTP API, web uygulaması, mikroservis	Cloud Run Service
Batch iş, veritabanı migrasyonu, raporlama	Cloud Run Job
Kafka/Pub/Sub consumer, sürekli arka plan işi	Cloud Run Worker Pool
Sürekli çalışan, ağır CPU/bellek iş yükü	AWS Fargate (scale-to-zero yok, ama sürekli iş için ucuz)
KEDA tabanlı event-driven ölçekleme	Azure Container Apps
GPU'lu AI inference (cold start toleransı varsa)	Cloud Run (GPU destekli)

7. En İyi Pratikler

Pratik	Açıklama
PORT'u Dinleyin	Konteyner, Cloud Run'ın beklediği portu dinlemelidir .
Graceful Shutdown	`SIGTERM` sinyalini yakalayın; 10 saniye içinde kapanmaya hazır olun .
Min Instance Kullanın	Cold start kritikse `--min-instances 1` ile en az bir instance'ı sıcak tutun.
Cold Start'ı Test Edin	Gerçek trafik deseniyle (idle-then-burst) test yapın; sadece sürekli yük ile değil .
Yerel Dosya Sistemi Kalıcı Değildir	Kalıcı veri için Cloud Storage veya NFS kullanın .
Kaynak Limitlerini Ayarlayın	`--max-instances` ile downstream sistemleri koruyun.

Sonuç

Cloud Run, CaaS kategorisinin serverless ve HTTP odaklı en olgun örneklerinden biridir. Scale-to-zero, hızlı cold start, cömert ücretsiz katman ve basit eşzamanlılık modeli ile özellikle API'ler, web uygulamaları ve event-driven iş yükleri için idealdir. Ancak sürekli çalışan ağır iş yükleri için Fargate'in daha büyük konteyner limitleri ve öngörülebilir maliyeti daha uygun olabilir. .NET geliştiricileri için Cloud Run, standart Dockerfile ile sorunsuz çalışır; tek kritik nokta PORT environment variable'ını dinlemektir. Unutmayın: CaaS seçimi, iş yükünüzün trafik desenine (ani mi, sürekli mi) ve cold start toleransınıza bağlıdır.