← Kursa Dön
📄 Text · 35 min

Monolith vs Microservice

Yazılım mimarisi seçimi, bir projenin başarısını doğrudan etkileyen en kritik kararlardan biridir. Bu derste monolitik ve mikroservis mimarilerini derinlemesine karşılaştıracak, her birinin avantaj ve dezavantajlarını analiz edecek, ne zaman hangisini seçmeniz gerektiğini ve monolitten mikroservise geçiş stratejilerini inceleyeceğiz.

Monolitik Mimari Nedir?

Monolitik (tek parça) mimari, uygulamanın tüm bileşenlerinin — kullanıcı arayüzü, iş mantığı, veri erişim katmanı — tek bir dağıtılabilir birim (deployable unit) olarak paketlendiği mimari stildir. Tek bir JAR/WAR dosyası, tek bir veritabanı, tek bir süreç:

┌─────────────────────────────────────────┐
│              Monolith Application        │
│  ┌──────────┬──────────┬──────────┐     │
│  │  User    │  Order   │ Product  │     │
│  │  Module  │  Module  │  Module  │     │
│  ├──────────┴──────────┴──────────┤     │
│  │       Shared Database Layer     │     │
│  └─────────────────────────────────┘     │
│              Single DB                   │
└─────────────────────────────────────────┘

Monolitin Avantajları:

  1. Basit geliştirme — Tek bir kod tabanı, tek bir IDE projesi. Yeni bir geliştirici hızla projeye adapte olabilir.

  2. Kolay debug — Tüm kod aynı process'te çalışır. Breakpoint koyarak uçtan uca debug yapabilirsiniz.

  3. Basit deployment — Tek bir artifact deploy edin. CI/CD pipeline'ı basittir.

  4. Kolay test — End-to-end testler bir process içinde çalışır. Service mock'lamaya gerek yoktur.

  5. Düşük operasyonel karmaşıklık — Tek bir sunucu, tek bir log dosyası, tek bir monitoring dashboard.

  6. Performans — Modüller arası iletişim in-process method call'dır. Ağ gecikmesi yoktur.

  7. ACID transaction — Tek veritabanı olduğu için tam transactional tutarlılık sağlanır.

Monolitin Dezavantajları:

  1. Ölçekleme zorluğu — Tüm uygulama birlikte ölçeklenir. Sadece sipariş modülü yoğunsa bile tüm uygulamayı ölçeklemeniz gerekir.

  2. Deployment riski — Küçük bir değişiklik bile tüm uygulamanın yeniden deploy edilmesini gerektirir. Bir modüldeki bug tüm sistemi çökertebilir.

  3. Teknoloji kilidi — Tüm modüller aynı dili, framework'ü ve veritabanını kullanmak zorundadır.

  4. Takım ölçekleme zorluğu — 50+ geliştiricinin aynı kod tabanında çalışması merge conflict cehennemidir.

  5. Büyüdükçe karmaşıklaşma — Zamanla modüller arasındaki bağımlılıklar "spagetti" haline gelir. Bir değişikliğin yan etkilerini anlamak zorlaşır.

  6. Uzun build süreleri — Kod tabanı büyüdükçe derleme ve test süreleri dakikalara, hatta saatlere çıkabilir.

Mikroservis Mimarisi Nedir?

Mikroservis mimarisi, uygulamayı küçük, bağımsız, kendi veritabanına sahip, bağımsız deploy edilebilen servisler topluluğu olarak tasarlar. Her servis tek bir iş alanına (bounded context) odaklanır:

┌──────────┐  ┌──────────┐  ┌──────────┐
│  User    │  │  Order   │  │ Product  │
│  Service │  │  Service │  │  Service │
│  ┌────┐  │  │  ┌────┐  │  │  ┌────┐  │
│  │ DB │  │  │  │ DB │  │  │  │ DB │  │
│  └────┘  │  │  └────┘  │  │  └────┘  │
└──────────┘  └──────────┘  └──────────┘
      ▲              ▲              ▲
      └──────────────┼──────────────┘
               API Gateway

Mikroservisin Avantajları:

  1. Bağımsız ölçekleme — Her servis ihtiyacına göre ayrı ayrı ölçeklenebilir. Sipariş servisi 10 instance, ürün servisi 2 instance.

  2. Bağımsız deployment — Her servis bağımsız deploy edilir. Sipariş servisini güncellerken ürün servisi çalışmaya devam eder.

  3. Teknoloji çeşitliliği — Her servis farklı dil, framework, veritabanı kullanabilir. Kullanıcı servisi PostgreSQL, arama servisi Elasticsearch.

  4. Takım özerkliği — Her servis küçük bir takım tarafından sahiplenilir (2-pizza team). Takımlar bağımsız karar alır ve hızlı ilerler.

  5. Hata izolasyonu — Bir servisin çökmesi diğerlerini etkilemez (circuit breaker ile).

  6. Kolay modernizasyon — Eski bir modülü sıfırdan yeniden yazmak yerine, sadece o servisi değiştirebilirsiniz.

Mikroservisin Dezavantajları:

  1. Dağıtık sistem karmaşıklığı — Ağ hataları, gecikme, tutarsızlık sorunlarıyla başa çıkmanız gerekir.

  2. Operasyonel karmaşıklık — Düzinelerce servis, düzinelerce veritabanı, düzinelerce log. Monitoring, logging, tracing altyapısı şarttır.

  3. Data consistency — ACID transaction'lar servisleri aşamaz. Eventual consistency ve Saga pattern gibi çözümler gerekir.

  4. Ağ gecikmesi — Servisler arası iletişim ağ üzerinden gerçekleşir. In-process call'a göre çok daha yavaştır.

  5. Test zorluğu — End-to-end testler birden fazla servisin ayakta olmasını gerektirir. Contract testing gibi yaklaşımlar gerekir.

  6. Yüksek başlangıç maliyeti — Service discovery, API gateway, config server, monitoring, CI/CD pipeline gibi altyapılar kurulmalıdır.

Bounded Context (Sınırlı Bağlam)

Domain-Driven Design'dan (DDD) gelen bu kavram, mikroservis sınırlarını belirlemek için kullanılır. Her bounded context, kendi dili (ubiquitous language), kendi modeli ve kendi veritabanı olan bağımsız bir alan tanımlar:

E-Ticaret Domain'i:

┌─ User Context ──┐  ┌─ Order Context ─┐  ┌─ Payment Context ┐
│ User             │  │ Order           │  │ Payment          │
│ Address          │  │ OrderItem       │  │ Transaction      │
│ Authentication   │  │ Shipping        │  │ Refund           │
│                  │  │ (User → userId) │  │ (Order → orderId)│
└──────────────────┘  └─────────────────┘  └──────────────────┘

Dikkat edin: Order Context, User nesnesinin tüm detaylarını bilmez — sadece userId referansını tutar. Bu, gevşek bağımlılık (loose coupling) sağlar.

Ne Zaman Hangisini Seçmeli?

Monolit tercih edin:

  • Küçük ekip (< 10 geliştirici)

  • Yeni proje / MVP / startup

  • Domain henüz netleşmemiş

  • Hızlı prototipleme gerekiyor

  • Operasyon ekibi/altyapısı sınırlı

Mikroservis tercih edin:

  • Büyük ekip (> 20 geliştirici)

  • İyi tanımlanmış domain sınırları

  • Farklı ölçekleme gereksinimleri

  • Bağımsız deployment zorunluluğu

  • Olgun DevOps kültürü ve altyapısı

Monolith → Microservice Geçiş Stratejileri

1. Strangler Fig Pattern: Yeni özellikler mikroservis olarak yazılır, eski modüller kademeli olarak taşınır. Monolith ile mikroservisler bir süre birlikte çalışır:

Aşama 1: [Monolith] ──── tüm trafik
Aşama 2: [Monolith] ──── /users, /products
         [User µs]  ──── /users (yeni)  ← Gateway yönlendirir
Aşama 3: [Monolith] ──── /products
         [User µs]  ──── /users
         [Order µs] ──── /orders
Aşama N: Monolith tamamen boşalır

2. Branch by Abstraction: Monolith içinde bir arayüz (abstraction) katmanı oluşturulur. Önce mevcut implementasyon bu arayüzün arkasına alınır, sonra yeni mikroservis implementasyonu yazılır, son olarak trafik yeni implementasyona kaydırılır.

3. Database First: Önce veritabanını bölün (schema veya tablo bazında), sonra uygulama kodunu ayırın. Bu yaklaşım veri bağımlılıklarını erken çözer.

Doğru mimari seçimi, projenin boyutuna, ekibin olgunluğuna ve iş gereksinimlerine bağlıdır. "Microservices first" yaklaşımı yerine "monolith first" ile başlayıp gerektiğinde parçalamak genellikle daha güvenlidir.