Dapr: Distributed Application Runtime ve Microservice Building Block 2026

Dapr nedir sorusunun teknik cevabı net: Dapr (Distributed Application Runtime), mikroservis uygulamalarının ortak ihtiyaçlarını (state yönetimi, pub/sub, service invocation, secrets, observability, workflow) sidecar mimarisi üzerinden dil bağımsız HTTP/gRPC API’leriyle sağlayan, CNCF Graduated statüsündeki açık kaynak bir runtime’dır. 2024 sonunda CNCF Graduation alan Dapr v1.14, 2026 itibarıyla v1.15 hattında ilerliyor ve GitHub’da yaklaşık 24.5K star, 500’ün üzerinde contributor ile aktif geliştiriliyor. Uygulama kodu Dapr API’sine konuşur; altyapı değişimi (Redis → Cosmos DB, Kafka → RabbitMQ) component YAML’ında değişir, kod değişmez. Bu yazıda Dapr’ın building block mimarisini, sidecar deployment modellerini, performans karakteristiklerini, alternatiflere karşı pozisyonunu ve 2026 üretim ortamı için karar çerçevesini gerçek rakamlarla ele alıyoruz.

Dapr’ın Mimari Temeli: Sidecar ve Building Block Yaklaşımı

Dapr, “application-level distributed primitives” felsefesini benimser: her uygulama instance’ı yanına bir sidecar süreç (daprd) yerleşir, uygulama ile sidecar arasında localhost üzerinden HTTP (varsayılan 3500) veya gRPC (varsayılan 50001) iletişim kurulur. Sidecar, altyapı bileşenleriyle (Redis, Kafka, Postgres, Cosmos DB, AWS SQS, Azure Service Bus) konuşmaktan sorumludur. Uygulama kodu, altyapının ne olduğunu bilmek zorunda kalmaz.

Bu yaklaşım mikroservis mimarisi bağlamında değerlendirilmelidir: mikroservis sayısı arttıkça her servisin kendi state, messaging ve resilience kodunu yazması teknik borç üretir. Dapr bu cross-cutting concern’leri runtime katmanına taşır. Microsoft Open Source ekibi tarafından 2019 sonunda başlatılan proje, Kasım 2024’te CNCF Graduated projesi statüsüne yükseldi — bu, Kubernetes, Prometheus, Envoy gibi olgun projelerle aynı kategori.

Dapr’ın 10 temel “building block”u şu şekilde yapılandırılır:

Building Block	API Endpoint	Temel Use Case	Component Örnek
Service Invocation	/v1.0/invoke	Servisler arası mTLS çağrı	Built-in (HTTP/gRPC)
State Management	/v1.0/state	Key-value persistence	Redis, Cosmos, Postgres
Pub/Sub	/v1.0/publish, /subscribe	Async messaging	Kafka, RabbitMQ, NATS
Bindings	/v1.0/bindings	Input/output external systems	S3, Twilio, MQTT
Actors	/v1.0/actors	Stateful single-threaded objects	Redis, SQL Server
Secrets	/v1.0/secrets	Vault entegrasyonu	Azure KV, HashiCorp Vault
Configuration	/v1.0/configuration	Dinamik config + watch	Redis, Postgres
Workflow	/v1.0-alpha1/workflows	Long-running orkestrasyon	Built-in (durable)
Distributed Lock	/v1.0-alpha1/lock	Mutex across replicas	Redis
Cryptography	/v1.0-alpha1/crypto	Encrypt/decrypt/sign	Azure KV, JWKS

Bu tablodaki API’lerin tümü dil-bağımsızdır. Python, Go, Java, .NET, Rust, JavaScript SDK’ları aynı HTTP/gRPC çağrılarının ince sarmalayıcılarıdır. CNCF 2024 Annual Survey’e göre kuruluşların %29’u sidecar tabanlı runtime’ları üretimde değerlendiriyor; Dapr bu segmentin en olgun temsilcisi konumunda.

Sidecar Modeli, Performans ve Latency Bütçesi

Sidecar yaklaşımının en sık sorgulanan boyutu performans overhead’idir. Dapr’ın resmi benchmark sayfası ve community ölçümleri 2024-2025 itibarıyla şu profilleri yayınlıyor:

Operasyon	p50 Latency	p99 Latency	Throughput (tek pod)	CPU Overhead
Service Invocation HTTP	~1.2 ms	~4.5 ms	~6.500 RPS	0.1-0.3 vCPU
Service Invocation gRPC	~0.8 ms	~3.2 ms	~9.000 RPS	0.1-0.3 vCPU
State Get (Redis)	~1.5 ms	~6.0 ms	~7.000 RPS	0.15 vCPU
Pub/Sub Publish (Kafka)	~2.5 ms	~12 ms	~4.500 RPS	0.2 vCPU
Actor Invocation	~2.0 ms	~8.0 ms	~3.500 RPS	0.2 vCPU

Bu rakamlar Dapr’ın resmi performans dokümantasyonundan ve CNCF TAG-App-Delivery 2024 raporundan derlenmiştir. Kritik nokta: Dapr sidecar, doğrudan altyapı çağrısına göre yaklaşık 0.5-1.5 ms p99 ekstra latency ekler. P99 SLA bütçesi 50 ms olan tipik B2B API’de bu overhead %3’ün altındadır; ama p99’u 10 ms hedefleyen high-frequency trading ya da gerçek-zamanlı bidding sistemleri için tartışmalıdır.

Latency bütçesi planlanırken şu kalemleri ayrı ayrı düşünmek gerekir:

• Uygulama → sidecar (localhost): ~0.2-0.5 ms (Unix socket veya loopback TCP)
• Sidecar serialization/deserialization: ~0.1-0.3 ms (JSON için protobuf’a göre yüksek)
• Sidecar → component (network): bileşene bağlı (Redis aynı AZ ~0.5 ms, cross-region ~30 ms)
• mTLS handshake (ilk istek): ~10-20 ms (sonrası connection reuse ile <0.1 ms)
• Resilience policy değerlendirme: ~0.05 ms (timeout, retry, circuit breaker)

Üretim ortamında HTTP yerine gRPC seçmek ortalama %30 throughput kazandırır; özellikle API entegrasyon stratejilerinde sidecar-to-sidecar iletişimde gRPC tercih edilmelidir.

Building Block’lar: Pratik Senaryolarla

Dapr’ın gücü tek tek bileşenlerden çok bileşenlerin kombinasyonundan gelir. Saga Pattern ya da CQRS Event Sourcing gibi distributed transaction desenlerini Dapr Workflow + Pub/Sub + State kombinasyonu ile uygulanabilir hale getirir.

State Management — multi-backend strateji: Dapr state API’si key-value semantiği sunar ama 20+ component arasında geçiş YAML değişikliğiyle yapılır. Etag-based optimistic concurrency, TTL, multi-key transaction (component destekliyorsa) ve query API (alpha) sunulur. Üretimde sık tercih edilen sıralama:

1. Redis — düşük latency, küçük payload, cache-benzeri kullanım (varsayılan başlangıç)
2. Azure Cosmos DB / DynamoDB — global dağıtım, yüksek throughput, multi-region
3. PostgreSQL — ACID transactional state, mevcut RDS yatırımı varsa
4. Cassandra — write-heavy, time-series benzeri state

Pub/Sub — broker bağımsız mesajlaşma: CloudEvents 1.0 spesifikasyonuna uyumlu envelope ile publisher sadece topic adı bilir; broker (Kafka, RabbitMQ, NATS JetStream, Azure Service Bus, AWS SNS+SQS, GCP Pub/Sub, Redis Streams) component değişimiyle değişir. Dead-letter queue, retry policy, message TTL, bulk publish, programmatic subscription (v1.11+) gibi advanced özellikler component-agnostic API’lerden kullanılır.

Actor Model: Dapr Actors, Microsoft Orleans’tan ilham alan virtual actor implementasyonudur. Her actor benzersiz ID’ye sahip, tek thread’de çalışan, durumlu nesnedir. IoT cihaz state’i, oyuncu profili, sipariş aggregate’i, kullanıcı session’ı tipik kullanım örnekleri:

• Avantaj: Single-threaded model concurrency bug’larını ortadan kaldırır, location transparency ile partitioning otomatiktir.
• Dezavantaj: Yüksek actor sayısında reminder/timer yükü Redis state store’u zorlar; cross-actor transaction yoktur.
• Ne zaman seç: Milyonlarca bağımsız varlığın bağımsız state’i (IoT, gaming, telephony) varken — REST + RDBMS bu yükü karşılayamadığında.
• Ne zaman kaçın: Az sayıda ağır aggregate + yoğun cross-entity transaction senaryolarında klasik CQRS daha temizdir.

Workflow: v1.10’da alpha, v1.14’te beta seviyesine taşınan Workflow API, Microsoft Durable Task Framework üzerine inşa edilmiştir. Code-first orkestrasyon: long-running süreçler (e-ticaret sipariş akışı, KYC süreci, batch ETL) kod olarak yazılır, runtime checkpoint alır, sidecar yeniden başlasa bile state korunur. Temporal.io ve AWS Step Functions’a alternatif konumdadır.

Dapr vs Service Mesh: Tamamlayıcı mı, Rakip mi?

En sık karıştırılan konu Dapr’ın Service Mesh (Istio, Linkerd, Consul) ile ilişkisidir. İkisi de sidecar pattern kullanır ama farklı katmanlarda çalışır:

Boyut	Service Mesh (Istio/Linkerd)	Dapr
Katman	L4/L7 network proxy	Application-level API
Görünürlük	Uygulamaya transparent	Uygulama Dapr API’sini explicit çağırır
mTLS	Var (transparent)	Var (sidecar arası)
State Management	Yok	Var (10+ backend)
Pub/Sub abstraction	Yok	Var (10+ broker)
Traffic shifting (canary)	Güçlü	Sınırlı
Actor model	Yok	Var
Workflow	Yok	Var
Sidecar tipi	Envoy proxy	daprd (Go)
Bellek footprint	~40-80 MB	~30-60 MB

Pratik kararda iki yaklaşım bir arada kullanılabilir: Istio L4/L7 traffic management ve advanced canary, Dapr application-level building block’lar. Dapr 1.10+ ile Linkerd ve Istio entegrasyonu için resmi rehber mevcuttur. Buildpiper, Diagrid, Bilgin Ibryam’ın “Multi-Runtime Microservices” makalesi (2020, IEEE Software) bu ayrımı netleştirir: Service mesh “out-of-process networking”, Dapr “out-of-process application primitives” sağlar.

Component Modeli ve Pluggability

Dapr’ın taşınabilirlik vaadi component YAML’larında somutlaşır. Her component üç bilgi içerir: type (state.redis, pubsub.kafka), version, metadata (connection string, credentials). Aşağıda tipik bir state store component örneği:

Alan	Değer	Açıklama
apiVersion	dapr.io/v1alpha1	K8s CRD
kind	Component	Sabit
metadata.name	orderstore	Uygulama kodunda referans
spec.type	state.redis	Backend belirleyici
spec.version	v1	API kontrat versiyonu
spec.metadata.redisHost	redis:6379	Bağlantı
spec.metadata.actorStateStore	true	Actor backend olarak kullan
scopes	[order-svc, billing-svc]	Hangi uygulamalar erişebilir

Component pluggability, Hexagonal Architecture prensiplerinin runtime karşılığıdır: uygulama port’a (Dapr API), runtime adapter’a (component) konuşur. v1.9+ ile “pluggable components” özelliği geldi: artık community Go kodlu component yazmadan, ayrı bir Unix socket process’i ile özel component implementasyonu yapılabiliyor.

Deployment Modelleri: Kubernetes, Self-Hosted, Serverless

Dapr üç ana deployment modunu destekler:

1. Kubernetes mode (üretim önerisi): dapr-operator, dapr-sentry (mTLS CA), dapr-placement (actor partitioning), dapr-sidecar-injector control plane. Annotation ile pod’a sidecar otomatik enjekte edilir (dapr.io/enabled: "true").
2. Self-hosted (geliştirme ve VM): dapr init ile lokal Docker container’lar (Redis, Zipkin, placement) ayağa kalkar; dapr run ile uygulama ve sidecar lokal başlatılır.
3. Serverless / managed: Diagrid Catalyst (Dapr core ekibinden çıkmış SaaS), Azure Container Apps native Dapr desteği (ücretsiz katmanda dahi), AWS EKS + Helm chart yaygın senaryolar.

Azure Container Apps platformu Dapr’ı first-class entegrasyonla sunar: Microsoft Learn dokümantasyonuna göre platform sidecar yaşam döngüsünü, mTLS sertifika rotasyonunu ve component scope’larını yönetir; ek lisans ücreti yoktur. AWS tarafında EKS üzerinde Helm ile kurulum standartken, GCP GKE’de aynı pattern geçerlidir. Dapr resmi GitHub repository üzerinden production-ready Helm chart’lar yayınlanır.

Observability: OpenTelemetry, Tracing ve Metrik

Dapr 1.14 itibarıyla OpenTelemetry’yi varsayılan trace exporter olarak destekler; W3C Trace Context header propagation otomatiktir. Sidecar her invocation, state, pub/sub işlemini span olarak yayımlar. Prometheus metric endpoint’i (varsayılan 9090) RED metriklerini (Rate, Errors, Duration) ve component-specific metrikleri (Kafka lag, Redis latency) sunar.

Observability Boyutu	Dapr Native Desteği	Önerilen Tool	Konfig Yükü
Distributed Tracing	OTEL, Zipkin, Jaeger	Tempo, Datadog APM	Düşük (config CRD)
Metrics	Prometheus pull	Prometheus + Grafana	Düşük
Logs	JSON structured stdout	Loki, ELK	Orta
Health checks	/v1.0/healthz	K8s liveness/readiness	Düşük
Dashboard	dapr dashboard CLI	Geliştirme için	Düşük

OpenTelemetry Collector kullanıldığında, uygulama kodunun ayrıca instrumentation yapması gerekmez: sidecar üzerinden geçen tüm trafik otomatik trace üretir. Bu, Domain-Driven Design bağlamında bounded context’ler arası çağrı zincirlerini görünür kılar.

Güvenlik: mTLS, Token Authentication, Secrets

Dapr güvenlik mimarisi üç katmanlıdır:

• mTLS sidecar-to-sidecar: Dapr Sentry servisi self-signed root CA üretir, sidecar’lara X.509 sertifikası dağıtır; varsayılan 24 saat rotasyon. SPIFFE-uyumlu identity format (spiffe:///ns//).
• API token authentication: Uygulama ↔ sidecar trafiği dapr-api-token header ile korunur; sidecar açık internete açılmaz, sadece localhost.
• Secret management: Component metadata’sında secret referansı (secretKeyRef) ile çalışma zamanında Vault/Azure KV/AWS Secrets Manager’dan çekilir; YAML’a credential gömme yok.

NIST SP 800-204 “Security Strategies for Microservices” rehberinde tanımlanan zero-trust prensipleri (her servis-servis çağrısında authentication + authorization + encryption) Dapr varsayılan konfigürasyonuyla karşılanır. Access control policy CRD’leri ile servis bazlı izin verme (verb + path bazlı) yapılır.

Dapr vs Alternatifler: Karar Matrisi

Dapr’ın doğrudan rakipleri değil, kısmen örtüşen üç ekosistem vardır: Spring Cloud (Java-only), framework-specific çözümler (Akka, Orleans, Temporal), ve raw cloud SDK kullanımı. Modular Monolith aşamasındaki ekipler için Dapr erken yatırım olabilir; tasarım desenleri ve SOLID prensipleri ile yeterli soyutlama sağlanabilir.

Çözüm	Dil Bağımsız	State Abstraction	Pub/Sub Abstraction	Actor Model	Workflow	Olgunluk
Dapr 1.15	Evet	20+ backend	10+ broker	Var	Var (beta)	CNCF Graduated
Spring Cloud	Java only	Sınırlı	Stream	Yok	Yok	Olgun (Java)
Akka (Lightbend)	JVM + .NET	Persistence plugin	Yok (Alpakka)	Var (yerel)	Yok	Olgun
Orleans (.NET)	.NET only	Grain storage	Streams	Var (yerel)	Var	Olgun (.NET)
Temporal.io	Multi-language SDK	Yok (workflow state)	Yok	Yok	Var (core)	Olgun
Raw cloud SDK	Evet	Yok (manuel)	Yok	Yok	Step Functions vb.	Vendor-locked

Karar çerçevesi:

• Çok-dilli ekip + multi-cloud taşınabilirlik istiyorsanız: Dapr açık ara öndedir.
• Saf .NET ekip + Azure ağırlıklı: Orleans + Azure native servisler daha az soyutlama maliyetiyle yeter olabilir.
• Saf Java + Spring ekosistemi: Spring Cloud yeterli; Dapr getirisi ekipte küçük kalır.
• Workflow ağırlıklı uzun süreçler: Temporal.io daha derin workflow özelliği sunar; Dapr Workflow hızlı ilerliyor ama paritede değil.

Bu kararı kendi ekibiniz için netleştirmek istiyorsanız, Ömer Önal olarak mikroservis runtime danışmanlığı kapsamında ekibinizin mevcut stack’ini ve servis sayısını birlikte değerlendiriyoruz.

Üretim Olgunluğu: Adoption, Topluluk, Risk

Dapr’ın üretim olgunluğunu somut metriklerle değerlendirmek gerekir:

Metrik	2024 Q4 Değer	Kaynak	Yorum
GitHub Stars	~24.5K	github.com/dapr/dapr	Sürekli artış
Contributor sayısı	500+	GitHub	Bireysel + 30+ şirket
CNCF statüsü	Graduated (Kasım 2024)	cncf.io	En üst olgunluk seviyesi
Stable building block sayısı	7 / 10	docs.dapr.io	Workflow/Lock/Crypto alpha-beta
Production adopter (bilinen)	100+ kuruluş	Dapr End-User Showcase	Roche, Zeiss, FICO, Bosch, Alibaba
SDK desteği	.NET, Java, Go, Python, JS, Rust, PHP, C++	resmi	Birinci sınıf 6 dil
Release kadansı	~4 ay / minor	release notes	Predictable

Riskler ve dikkat noktaları: (1) Workflow API hâlâ beta — kritik long-running süreç için Temporal değerlendirilmeli. (2) Pluggable components ekosistemi henüz dar — niş backend’ler için Go kodlu PR gerekebilir. (3) Sidecar başlatma süresi (cold start ~1-3 sn) serverless cold path’lerinde latency’e eklenir. (4) Multi-cluster federation ve cross-cluster service invocation hâlâ resmi roadmap’te.

CNCF 2024 yıllık raporuna göre Graduated projeler arasındaki adoption hız sıralamasında Dapr, Argo ve Cilium ile birlikte en hızlı büyüyen üçlü içinde yer alıyor. CNCF Graduation duyurusunda 25’ten fazla referans müşteri listelenmiştir.

İmplementasyon Patikası: 90 Günlük Yol Haritası

Ekibe Dapr’ı tanıtmanın güvenli yolu aşamalı pilot yaklaşımıdır. Repository Pattern ve BFF Pattern gibi mevcut soyutlamalarla nasıl örtüştüğünü erken görmek önemlidir.

1. Hafta 1-2 — Discovery: Mevcut servislerden 2 düşük riskli adayı seç (örn. notification-svc, audit-log-svc). Dapr CLI ile lokal POC, state + pub/sub building block’ları dene.
2. Hafta 3-4 — Component standardı: Component YAML naming convention, scope politikası, secret kaynağı (Vault?), trust domain belirle. Helm chart hazırla.
3. Hafta 5-8 — Staging deployment: Pilot servisleri staging K8s’e taşı. mTLS, observability, alerting devreye al. SLO ölç (p99, error rate). Resilience policy (timeout 5s, retry exponential 3 attempt, circuit breaker 50% threshold) tanımla.
4. Hafta 9-10 — Üretim canary: Pilot servisi üretimde %5 trafik ile başlat, 1 hafta gözlem, sonra %100.
5. Hafta 11-12 — Genişleme planı: Sonraki 5-10 servis için göç sırası, eğitim materyali, runbook (sidecar crash, sentry CA rotation, component failover) hazırla.

Bu patikayı 1.13+ versiyonla başlatın; 1.10 öncesi API’ler bazı building block’larda kırılgan. Production’da daima minor sürüm n-1 veya stable LTS kullanın.

Sıkça Sorulan Sorular (SSS)

Sonuç

Dapr, mikroservis ekosisteminin “cross-cutting concern” yorgunluğuna açık bir cevap sunuyor: uygulama kodu altyapı detaylarını bilmeden state, messaging, actor, workflow ve secrets API’lerini standart bir arayüzden tüketiyor. CNCF Graduated statüsü, 24.5K GitHub star, 100+ üretim adopter ve 7/10 stable building block 2026 itibarıyla Dapr’ı “olgun ama hâlâ hızlı gelişen” kategorisine yerleştirir. Sidecar overhead’i tipik B2B yüklerinde p99 bütçesinin %3-5’idir; çok dilli ekip ve multi-cloud taşınabilirlik hedeflerinde bu maliyet hızla amorti olur.

Karar çerçevesi şudur: (1) Eğer ekibiniz tek dil + tek bulut + az servis sayısındaysa Dapr erken yatırımdır; klasik framework + raw SDK ile başlayın. (2) 8+ servis, 2+ dil, multi-cloud hedef varsa Dapr’ın soyutlama getirisini operasyonel maliyetinin önüne geçer. (3) Workflow ağırlıklı, milyon-aktör senaryolarında Dapr’ı Temporal veya Orleans ile karşılaştırın. Pilot servis seçimi, component standardizasyonu ve 90 günlük patikayla risk minimal kalır.

Dapr mimarisini kendi servislerinize uyarlamak, hangi building block’ların ROI’sinin en yüksek olduğunu belirlemek veya pilot servis seçimini birlikte planlamak için iletişim sayfasından ulaşabilirsiniz; mevcut stack’inizi inceleyip 90 günlük somut yol haritası çıkarıyoruz.