1. GİRİŞ

Yazılım mimarisinde "Monolith vs Mikroservisler" tartışması son on yılda teknoloji dünyasının en merkezi konularından biri oldu. Bulutun yükselişi, konteyner teknolojileri (Docker), orkestrasyon platformları (Kubernetes) ve CI/CD kültürünün yaygınlaşması mikroservis yaklaşımlarını cazip kıldı. Ancak bu, monolitik uygulamaların tamamen geri plana atılması anlamına gelmiyor. Doğru seçim bağlam bağımlıdır ve her iki yaklaşımın da güçlü ve zayıf yönleri vardır.

Bu teknoloji neden konuşuluyor?

• Küresel dijital hizmetlerin ölçeği ve hız gereksinimleri mimari tercihleri doğrudan etkiliyor.
• Büyük ekipler, farklı iş domain'leri ve hızlı sürüm döngüleri için uygun organizasyonel yapı arayışları artıyor.
• Maliyet optimizasyonu, güvenlik, veri tutarlılığı ve operasyonel karmaşıklık sorunları mimari kararları önemli kılıyor.

Kimler için önemli?

• Kurumsal yazılım mimarları ve teknik liderler
• Platform mühendisleri, DevOps ve SRE ekipleri
• Proje yöneticileri ve CTO'lar — maliyet/karmaşıklık trade‑off'larını anlamak isteyenler
• Geliştiriciler — domain modelleme ve dağıtık sistem tasarımına geçiş yapanlar

Hangi problemleri çözüyor?

• Hızlı teslimat ve bağımsız dağıtım gereksinimleri
• Farklı bölümlerin bağımsız ölçeklenmesi
• Organizasyonel autonomiyi ve takım sınırlarını netleştirme
• Büyük sistemlerde hata yalıtımı ve daha iyi fault domain tasarımı

2. KAVRAMSAL TEMELLER

2.1 Tanımlar

Monolitik Mimari

Uygulamanın tüm bileşenlerinin tek bir dağıtılabilir birim (single deployable artifact) içinde yer aldığı yapı. Tipik olarak tek bir kod tabanı, tek bir deployment ve tek bir runtime süreci.

Mikroservis Mimarisi

Sistemin birbirinden bağımsız dağıtılabilen, küçük, iş odaklı servisler olarak tasarlandığı yaklaşım. Her servis kendi veri saklama stratejisine sahip olabilir ve bir veya birkaç bounded context'i kapsar.

Bounded Context

Domain‑driven design (DDD) terminolojisinde, bir kavramın tutarlı bir şekilde tanımlandığı ve uygulandığı sınır. Mikroservislerin sorumlulukları genelde bounded context'e karşılık gelir.

Service Mesh

Servisler arası iletişimi, gözlemlenebilirliği ve güvenliği uygulama kodundan bağımsız olarak sağlayan altyapı katmanı (örn. Istio, Linkerd).

2.2 Mimari bileşenler

• API Gateway: Dış istemciler için tek giriş noktası, yönlendirme, kimlik doğrulama, rate limiting gibi görevleri üstlenir.
• Orchestration & Container Platform: Konteyner yönetimi (Kubernetes) ve dağıtım otomasyonu için gereklidir.
• Data Stores: Her servis için ayrı veri deposu (database per service) prensibi; transactional boundary'leri belirler.
• Event Bus / Message Broker: Asenkron iletişim, eventual consistency ve decoupling için kullanılır (Kafka, RabbitMQ, Pulsar).
• Monitoring & Tracing: Prometheus, Grafana, Jaeger gibi araçlarla operasyona görünürlük sağlanır.

2.3 Terminoloji

• Coupling (bağımlılık): Servisler arası sıkı bağlam (tight coupling) veya gevşek bağlam (loose coupling).
• Coherence / Consistency: Veri tutarlılığı modelleri (ACID vs eventual consistency).
• Deployment Unit: Dağıtılan paket — monolit için tek artifact, mikroservislerde her servis için ayrı artifact.

3. NASIL ÇALIŞIR? — Teknik Mimari ve Veri Akışı

3.1 Sistem mimarisi

Monolitik uygulamada tüm modüller aynı process içinde çalışır; paylaşılan memori, aynı database, aynı deployment pipeline kullanılır. Mikroservislerde her servis bağımsızdır: farklı diller, farklı veri depoları, farklı release cadences mümkün. Servisler synchronous (REST/gRPC) veya asynchronous (event-driven) yollarla iletişim kurar.

3.2 Bileşenler ve sınırlar

Mikroservis tasarımında en kritik adım bounded context'leri ve servis sınırlarını doğru belirlemektir. Yanlış sınırlandırma, servisler arasında excessive chatty communication (çok fazla konuşma) ve distributed transaction sorunlarına yol açar. Bir servis mümkün olduğunca tek bir işlevi (single responsibility) üstlenmelidir.

3.3 Veri akışı ve tutarlılık

Monolitlerde veri tutarlılığı genelde ACID transactional boundary'leri ile sağlanır. Mikroservislerde ise "database per service" prensibi uygulandığında distributed transaction'lar (global transaction) kullanmak pahalı ve karmaşık olur; bunun yerine eventual consistency, sagas ve event sourcing gibi desenler tercih edilir. Örnek akış:

• Kullanıcı bir sipariş oluşturur — Order servisinde bir event publish edilir.
• Payment servisinde ödeme alındığında PaymentConfirmed event'i publish edilir.
• Inventory servisleri PaymentConfirmed event'ini dinleyip stoğu günceller; gerekirse compensating action tetiklenir.

3.4 İletişim protokolleri ve performans

REST, gRPC, GraphQL gibi synchronous protokoller düşük gecikme ve basit hata modellemeleri için uygundur; ancak servisler arası gereksiz synchronous çağrılar sistem performansını ve gecikmeyi artırır. Asenkron mesajlaşma (Kafka, RabbitMQ) ile loose coupling sağlanırken, gecikme ve eventual consistency kabul edilmeli.

3.5 Deployment ve CI/CD

Monolitik uygulamalarda tek bir pipeline yeterlidir; mikroservislerde ise her servis için bağımsız pipeline'lar gerekir. Bu, hızlı teslimatı ve küçük scope'ta geri dönüşü (rollback) kolaylaştırır ama pipeline yönetimi, test izolasyonu ve release koordinasyonu zorlukları getirir.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix — Monolitikten Mikroservise Geçiş

Netflix klasik olarak monolitik bir uygulamadan başlayıp, artan ölçek ihtiyaçları ve dağıtık geliştirme gereksinimleri nedeniyle mikroservislere geçiş yapan örneklerden biridir. Bu süreç sırasında servis keşfi (Eureka), fault tolerance (Hystrix) ve streaming tabanlı veri hatları kritik rol oynadı. Netflix örneği, organizasyonel yeniden yapılandırmanın teknik geçiş kadar önemli olduğunu gösterir.

Amazon — Heterojen Servis Lansmanı

Amazon, servis bazlı mimariye erken geçmiş kurumlardan biridir. Her ekip kendi servisini sahiplenir ve bağımsız deploy eder. Bu model, güçlü ownership kültürü ve otomasyon gerektirir. Veri tutarlılığı ihtiyaçları için event-driven pattern'leri ve asenkron işlemler geniş kullanılır.

Uber — Gerçek Zamanlı Veri ve Event Sourcing

Uber gibi gerçek zamanlı veri ve yüksek trafikli sistemlerde mikroservisler ile event-driven yaklaşımlar bir arada kullanıldı. Veri akışları, stream işleme ve eventual consistency modelleri kritik oldu. Ayrıca opentracing ve dağıtık izleme altyapısı (Jaeger) performans analitiği için zorunlu hale geldi.

Spotify, Etsy ve Diğerleri

Küçükten büyüğe pek çok firma hibrit yaklaşımlar kullanır: çekirdek domain monolitik bırakılırken, yeni özellikler mikroservislerle ayrıştırılır. Bu pragmatic strateji teknik borcu yönetirken riskleri azaltır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Bağımsız ölçeklenebilirlik: Yük altında olan servisi izole ederek sadece o parçayı ölçekleyebilirsiniz.
• Hızlı dağıtım: Küçük ekipler, küçük servisler üzerinde bağımsız deploy yaparak daha hızlı iterasyon sağlar.
• Teknoloji heterojenliği: Her servis ihtiyaca göre farklı dil veya veri deposu seçebilir.
• Fault isolation: Bir servisin çökmesi tüm sistemi felç etmez, doğru tasarlanmışsa etkisi sınırlıdır.

Sınırlamalar ve Dezavantajlar

• Karmaşıklık: Dağıtık sistemler debugging, deployment, observability ve güvenlik açısından daha karmaşıktır.
• Operasyon maliyeti: Daha fazla servis → daha fazla pipeline, monitoring ve işletim yükü.
• Veri tutarlılığı: Transaction sınırlarının servislere bölünmesi eventual consistency gerektirir; compensating logic tasarımı zor olabilir.
• Network overhead: Servisler arası iletişim ağ gecikmesi ve hata oranlarını artırabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• İş ihtiyaçlarına göre seçim yapın: performans, ekip yapısı ve operasyonel olgunluk belirleyici olsun.
• Hibrit strateji düşünün: modüler monolit ile başlayıp, ihtiyaç duyulan alanları mikroservislere dönüştürün.
• Servis sınırlarını DDD perspektifiyle belirleyin; teknik değil iş odaklı bounded context'ler kullanın.

Performans optimizasyonu

• Servisler arası synchronous çağrıları minimize edin — önbellekleme, bulk endpoints veya async eventlerle değiş tokuş yapın.
• gRPC gibi binary protokoller ile düşük gecikmeli iletişim sağlayın; ancak izleme ve hata yönetimini unutmayın.

Güvenlik

• Servisler arası iletişimde mutual TLS (mTLS) kullanın; kimlik doğrulama ve yetkilendirmeyi merkezi olarak yönetin.
• API Gateway ile edge güvenliği uygulayın: authentication, authorization, rate limiting ve WAF kuralları.

Ölçeklenebilirlik ve operasyon

• Otomatik ölçekleme (HPA, VPA) politikalarını servis karakteristiklerine göre ayarlayın.
• Observability odağı: distributed tracing, structured logging ve metrik toplama must have tir.
• Servis sözleşmelerini (API contracts) ve backward compatibility politikalarını belgeleyin.

8. SIK YAPILAN HATALAR

• Mikroservislere geçişi bir sihirli çözüm olarak görmek — organizasyonel ve operasyonel hazırlık ihmal edilir.
• Servis sınırlarını teknik katmanlara göre çizmek — iş odaklı bounded context ihmal edilir.
• Veri modeli ve transaction stratejisini sonradan düşünmek; distributed transaction sorunları ortaya çıkar.
• Yetersiz gözlemlenebilirlik: tracing ve loglama olmadan dağıtık sorunları izlemek imkansız olur.
• Test stratejisini atlamak: end‑to‑end testler, contract testleri ve integration test'ler önemlidir.

9. GELECEK TRENDLER

1. Serverless & FaaS entegrasyonu: Mikroservislerin bazı parçaları fonksiyonel olarak serverless platformlara taşınacak; operasyonel yük azalırken tasarım karmaşıklığı yeni sorular getirir.
2. Service Mesh evrimi: Daha hafif, kolay yönetilebilir service mesh çözümleri yaygınlaşacak; uygulama seviyesindeki cross‑cutting concerns daha çok altyapı ile çözülecek.
3. AI destekli operability: Olay korelasyonu, otomatik root cause analysis ve anomaly detection çözümleri gelişecek.
4. Platform engineering'in yükselişi: İç platform takımları (internal developer platforms) ekipler arasında standarizasyonu ve self‑service deneyimini sağlayacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Mikroservis mimarisine ne zaman geçmeliyim?

   Öncelikle ekip büyüklüğü, bağımsız teslimat gereksinimi, performans ihtiyaçları ve organizasyonel olgunluk değerlendirilmelidir. Küçük proje veya erken aşama startup için modüler monolit daha sağlıklıdır. Mikroservislere geçiş, spesifik darboğazlar tespit edildiğinde ve operasyonel olgunluk sağlandığında mantıklıdır.

2. 2. Modüler monolit ile mikroservis arasındaki fark nedir?

   Modüler monolit, tek deployment içinde modüler, katı sınırları olan bir tasarımı ifade eder. Mikroservis ise bu modülleri bağımsız deploy edilebilir servislere ayırır. Modüler monolit geçiş maliyetini düşürür ve erken aşamada hızlı iterasyon sağlar.

3. 3. Veri tutarlılığını mikroservislerde nasıl sağlamalıyım?

   Distributed transaction'lar genelde kaçınılmalıdır. Bunun yerine sagas, event sourcing, ve idempotent operation desenleri kullanarak eventual consistency sağlanır. Kritik finansal işlemler gibi durumlarda compensating transactions dikkatle tasarlanmalıdır.

4. 4. Mikroservislerin yönetim maliyetini nasıl azaltırım?

   Platform engineering yaklaşımıyla self‑service platform, standart araç setleri, şablonlar ve otomasyon ile pipeline yönetimini basitleştirin. Ayrıca servis sayısını makul seviyede tutun ve gereksiz parçalanmadan kaçının.

5. 5. API Gateway gerekli mi?

   Genelde evet — API Gateway dış dünyaya tek giriş noktası sağlayarak güvenlik, rate limiting, authentication ve monitoring işlevlerini merkezileştirir.

6. 6. Service mesh ne zaman kullanılmalı?

   İzleme, mTLS, trafik yönetimi ve dağıtık tracing ihtiyaçları arttığında service mesh fayda sağlar. Ancak ek operasyonel maliyet ve karmaşıklık getirdiği için küçük ölçeklerde gereksiz olabilir.

7. 7. Hangi test stratejileri önemlidir?

   Unit testler, contract testleri (Pact gibi), integration testler ve end‑to‑end testlerin kombinasyonu gereklidir. Canary deploy ve blue‑green deploy stratejileri riskleri azaltır.

8. 8. Geçiş sırasında rollback nasıl yönetilir?

   Feature flags, canary deploy ve backward compatible API tasarımı rollback stratejileri için kritik öneme sahiptir. Veritabanı şeması değişiklikleri için versioning ve migration stratejisi net olmalıdır.

Anahtar Kavramlar

Bounded Context

Domain modelinin tutarlı olduğu sınır; servis sınırları bu bağlama karşılık gelir.

Event‑driven Architecture

Servislerin olay (event) publish/subscribe mekanizmaları üzerinden iletişim kurduğu model.

Saga Pattern

Distributed transaction yerine kullanılan, adım adım uygulanan ve gerekirse compensating action'larla geri dönülebilen işlem dizisi.

Service Mesh

Servisler arası iletişimi yöneten, güvenlik ve gözlemlenebilirliği artıran altyapı katmanı.

Contract Testing

Servisler arası API sözleşmelerinin test edildiği yaklaşım; tüketici ve sağlayıcı arasında güven oluşturur.

Öğrenme Yol Haritası

1. 0–1 ay: Temel kavramlar (monolit, mikroservis, bounded context), küçük bir monolit uygulama inşa edin ve tek bir deployment deneyimi yaşayın.
2. 1–3 ay: Domain‑driven design (DDD) öğrenin; bounded context'leri tanımlama pratiği yapın. Basit bir mikroservis seti kurun (REST/gRPC), Docker ile konteynerleştirme ve temel CI/CD deneyimi edinin.
3. 3–6 ay: Asenkron iletişim (Kafka/RabbitMQ), event sourcing ve saga pattern uygulamaları yapın. Observability: Prometheus, Grafana, Jaeger ile izleme ve tracing entegrasyonları kurun.
4. 6–12 ay: Service mesh, güvenlik (mTLS), advanced deployment stratejileri (canary, blue/green) ve platform engineering konularında deneyim kazanın. Gerçek dünya ölçekli problemler için performans, güvenlik ve maliyet optimizasyonu yapın.