Microservices: Tek Büyük Uygulamadan Yüzlerce Küçük Servise Geçiş
Netflix, Amazon, Spotify gibi şirketler monolit yapıdan microservice mimarisine geçti. Modern bulut çağının en popüler mimari deseni.

Klasik problem: monolit
Bir e-ticaret uygulaması düşünün:
- Ürün katalog.
- Sepet.
- Ödeme.
- Kargo.
- Yorumlar.
- Bildirim.
Klasik yaklaşım (monolit): hepsi tek bir kod tabanında, tek bir veritabanı, tek bir sunucu.
Avantaj: basit. Dezavantaj: büyüdükçe kaos.
- 1000 geliştirici aynı kod tabanında.
- Bir özellik değişikliği tüm uygulamayı etkiler.
- Tek bir hata her şeyi düşürür.
- Ölçeklemek zor: tüm sistem ölçeklenir.
Microservices çözümü
Uygulamayı küçük, bağımsız servislere ayır:
- Ürün Servisi: ayrı kod, ayrı DB, ayrı takım.
- Sepet Servisi.
- Ödeme Servisi.
- ...
Her servis kendi içinde tam, bağımsız deploy edilir.
Tanım (Fowler, 2014)
Martin Fowler & James Lewis: microservices = ...
- Küçük, tek bir iş alanına odaklı servisler.
- Akıllı endpoint, aptal pipe: iletişim basit (HTTP/REST, gRPC).
- Bağımsız deploy.
- Decentralized: her takım kendi teknoloji seçimi.
- Otomatik test/deployment.
- Hata toleransı: bir servis düşse de sistem çalışır.
Pros
- Ölçeklenebilirlik: yalnız yüksek yük yaşayan servisleri ölçekle.
- Takım özerkliği: her takım kendi servisini yönetir.
- Teknoloji çeşitliliği: Python, Java, Go beraber.
- Hata izolasyonu: bir servis çökse de diğerleri çalışır.
- Hızlı deploy: küçük servis = hızlı CI/CD.
Cons
- Karmaşıklık: dağıtık sistem zorlukları.
- Network latency: artık her şey API çağrısı.
- Tutarlılık zor: distributed transactions.
- Operasyonel yük: 100 servis = 100 monitoring.
- DevOps olgunluğu şart.
Mimari bileşenler
API Gateway
Tek giriş noktası. Yönlendirme, kimlik doğrulama, rate limiting.
Araçlar: Kong, NGINX, AWS API Gateway.
Service Discovery
Servisler birbirini dinamik bulur (sabit IP yok).
Araçlar: Consul, etcd, Eureka.
Service Mesh
Servis-servis trafiği yönetimi: retry, circuit breaker, observability.
Araçlar: Istio, Linkerd.
Container Orchestration
Kubernetes baskın.
Message Broker
Asenkron iletişim. Kafka, RabbitMQ.
Distributed Tracing
Bir isteğin onlarca servisten geçişini izle.
Araçlar: Jaeger, Zipkin, OpenTelemetry.
Centralized Logging
Tüm servislerin log'u tek yerde.
Araçlar: ELK (Elasticsearch + Logstash + Kibana), Splunk, Loki.
Patterns
Saga
Distributed transactions yerine kademeli adımlar + telafi.
Circuit Breaker
Bir servis sürekli hata veriyorsa isteği kesilir, kullanıcıya hızlı hata.
Bulkhead
Servisler arasında kaynak izolasyonu.
CQRS + Event Sourcing
Yazma ve okuma ayrı, durum olaylardan türetilir.
Domain-Driven Design (DDD)
Microservice sınırını çizmek zor. Eric Evans 2003 DDD kitabı:
- Bounded context: bir iş alanı.
- Ubiquitous language: ortak terimler.
- Aggregate: işlem birimi.
Microservice bir bounded context = doğru sınır.
Netflix vakası
Netflix 2008'de monolitten microservice'e geçti. Sebepleri:
- Veri merkezi yangını.
- Bulut'a geçiş.
- Ekip ölçeklendirme.
Sonuç: 1000+ microservice. Chaos Monkey ile dayanıklılık testi.
Netflix mimarisi modern microservice dürüstü.
Modern eleştiriler
Monolith ilk
Birçok şirket: "Mikroservis çok erken". Önce monolit yap, gerçekten sınırlar belirginleşince ayır.
Distributed monolith
Microservices yapıyorum sandığın ama servisler çok bağımlı — distributed monolith.
Microservices fatigue
Çok karmaşık geldiğinde monolit'e geri dönen şirketler (Segment, Amazon Prime Video).
Modern alternatifler
Modular monolith
Tek deploy ama iç modüler yapı.
Macroservices
Microservices arası, daha az ama daha büyük.
Function-as-a-Service (FaaS)
AWS Lambda gibi: sadece fonksiyon.
Türk endüstri örnekleri
- Trendyol: 2000+ microservice.
- Garanti BBVA: kurumsal microservice.
- Yemeksepeti: tam microservice.
- Hepsiburada: hybrid (microservice + bazı monolit).
Kim için iyi?
- Büyük ekip (50+ geliştirici).
- Sık deploy ihtiyacı.
- Yüksek trafik.
- DevOps olgunluğu.
Kim için kötü?:
- Küçük ekip.
- Henüz domain belirsiz.
- DevOps zayıf.
Felsefe
Microservices temel mesajı: "Conway's Law'a uy: yazılım mimarisi organizasyon yapısını yansıtır".
Organizasyon küçük takımlardan oluşuyorsa, mimari de küçük bağımsız servislerden oluşmalı.
Kapanış
Microservices modern bulut çağının en popüler mimari deseni ama gümüş kurşun değil. Doğru durumda muhteşem, yanlış durumda felaket.
Bir yazılım mimarının olgunluk işareti: "Microservices uygulayalım mı?" sorusundan önce "Buna ihtiyacımız var mı?" sormak.
Etiketler
Kendinizi Test Edin
Cevaplarınız profilinizde istatistik olarak saklanır.
1. Microservices ile monolit farkı?
2. Service Mesh ne yapar?
3. Conway's Law?
4. Distributed monolith?
5. Ne zaman uygulanmalı?
İlgili Yazılar
İki Çocuk Paradoksu: "Biri Kız" Demek Olasılığı Neden Değiştirir?
Bir ailenin iki çocuğu var ve en az biri kız. İkisinin de kız olma olasılığı kaçtır? Çoğu insan "yarı yarıya" der ve yanılır. Bu küçük bulmaca, koşullu olasılığın ne kadar kaygan olduğunu gösterir.
MatematikKıyamet Argümanı: Olasılıkla İnsanlığın Ömrü Tahmin Edilebilir mi?
Sadece "sıradan bir insan" olduğunuz varsayımından yola çıkarak, insan türünün daha ne kadar süreceğini tahmin etmeye çalışan tuhaf bir akıl yürütme var. İkna edici mi, yoksa istatistiğin bir tuzağı mı?
MatematikManifold Nedir? Eğri Uzayları "Düzleştirerek" Anlamanın Matematiği
Dünya yuvarlaktır, ama elinizdeki harita düzdür ve gayet işe yarar. İşte manifold fikri tam olarak budur: küçük parçaları düz görünen, ama bütünüyle eğri olabilen uzaylar. Modern geometrinin ve fiziğin dili.