Microservices mi Monolith mi? Mimari Kararın Gerçek Maliyeti

"Biz microservices kullanıyoruz" cümlesi bir noktada statü sembolüne dönüştü. LinkedIn profillerinde, iş ilanlarında, startup sunumlarında. Sanki microservices kullanmak başlı başına bir başarıymış gibi.

Bu yazı o yanılgıyı düzeltiyor. Microservices güçlü bir araç — ama her araç gibi yanlış ellerde yanlış zamanda kullanıldığında hasara yol açar.

Monolith Nedir? Neden Kötü Üne Kavuştu?

Monolith, tüm uygulama bileşenlerinin tek bir deployable birim olarak paketlendiği mimaridir. Kullanıcı arayüzü, iş mantığı, veri erişim katmanı — hepsi aynı kod tabanında, aynı süreçte çalışır.

Monolith:
┌─────────────────────────────────┐
│           Uygulama              │
│  ┌────────┐  ┌────────────┐    │
│  │  Auth  │  │  Sipariş   │    │
│  └────────┘  └────────────┘    │
│  ┌────────┐  ┌────────────┐    │
│  │ Ürünler│  │  Ödeme     │    │
│  └────────┘  └────────────┘    │
└────────────────┬────────────────┘
                 │
           PostgreSQL

Monolith neden kötü üne kavuştu? Çünkü büyüdükçe sorunlar birikir. Küçük bir değişiklik tüm sistemi etkileyebilir. Tek bir modül bellek sızdırıyorsa tüm uygulama çöker. Farklı ekipler aynı kod tabanında çalışırken birbirlerinin değişikliklerini bozar. Ölçeklendirme kaba taneli olur — sadece ödeme modülüne yük gelirken tüm uygulamayı scale etmek zorunda kalırsınız.

Ama bunlar monolithin kaçınılmaz özellikleri değil. Kötü organize edilmiş monolithin özellikleri.

Microservices Nedir?

Microservices, uygulamayı küçük, bağımsız olarak deploy edilebilen servislere böler. Her servis tek bir iş kapasitesine odaklanır, kendi veritabanını yönetir ve diğer servislerle API üzerinden iletişim kurar.

Microservices:
┌──────────┐  ┌──────────┐  ┌──────────┐
│  Auth    │  │ Ürünler  │  │ Sipariş  │
│ Servisi  │  │ Servisi  │  │ Servisi  │
└────┬─────┘  └────┬─────┘  └────┬─────┘
     │              │              │
  Users DB      Products DB    Orders DB

┌──────────┐  ┌──────────┐
│  Ödeme   │  │Bildirim  │
│ Servisi  │  │ Servisi  │
└────┬─────┘  └──────────┘
  Payment DB

Her servis bağımsız deploy edilir. Auth servisi güncelleneceğinde ürünler servisi etkilenmez. Sipariş servisi aşırı yükleniyorsa sadece onu scale edersiniz. Farklı ekipler farklı servislerde özerk çalışır.

Kulağa mükemmel geliyor. Peki neden herkes microservices kullanmıyor?

Microservices'in Gerçek Maliyeti

Microservices ücretsiz değil. Ödediğiniz bedeli net görmek gerekiyor.

Dağıtık sistem karmaşıklığı. Monolith'te bir fonksiyon çağrısı olan şey, microservices'te bir network isteğine dönüşür. Network gecikebilir, başarısız olabilir, timeout verebilir. Partial failure senaryoları ortaya çıkar — sipariş servisi çalışırken ödeme servisi cevap vermiyorsa ne olur?

Servisler arası iletişim. Senkron (REST, gRPC) mu yoksa asenkron (Kafka, RabbitMQ) mu iletişim? Her seçimin trade-off'ları var. Asenkron iletişim dayanıklılık sağlar ama eventual consistency getiriyor — ödeme onaylandı ama sipariş durumu güncellenmedi henüz.

Veri tutarlılığı. Monolith'te database transaction'ları veri tutarlılığını garanti eder. Microservices'te her servisin kendi veritabanı var. Birden fazla servisi kapsayan işlemlerde ACID garantisi yok. Bu problemi çözmek için Saga pattern gibi karmaşık yaklaşımlar gerekiyor.

Operasyonel yük. 10 servis, 10 ayrı deployment pipeline, 10 ayrı log kaynağı, 10 ayrı monitoring konfigürasyonu demek. Kubernetes bilmek gerekiyor. Distributed tracing kurmak gerekiyor. Service mesh değerlendirmek gerekiyor.

Geliştirici deneyimi. Lokal geliştirme zorlaşır. 10 servisi aynı anda çalıştırmak için Docker Compose konfigürasyonu şişer. Bir özellik birden fazla servisi kapsıyorsa koordinasyon maliyeti artar.

Ne Zaman Hangisi?

Doğru soru "microservices mi monolith mi?" değil, "şu an ne kadar karmaşıklık taşıyabilirim?"

Monolith tercih edin:

Ürününüzün ne olacağını hâlâ keşfediyorsanız. İlk kullanıcılara ulaşmadan önce mimari kararlarla vakit kaybetmek, asıl problemi ertelemektir. Ekibiniz küçükse (5-10 kişi altı). Küçük ekiplerde servis sınırlarını yönetme maliyeti, kazanımı geçer. Domain'inizi henüz tam bilmiyorsanız — yanlış çizilmiş servis sınırları, monolithteki kötü modülerden çok daha pahalıya patlar.

Microservices değerlendirin:

Farklı bileşenler dramatik biçimde farklı ölçeklenme ihtiyacı gösteriyorsa. Ekip büyüdü ve aynı kod tabanında birden fazla ekip sürtüşme yaşıyorsa. Domain'inizi iyi tanıyorsunuz ve servis sınırlarını güvenle çizebiliyorsanız. Operasyonel olgunluğunuz var — CI/CD, monitoring, distributed tracing kurabilecek altyapı.

Modüler Monolith: Çoğunlukla En İyi Başlangıç

İki uç arasında çoğu zaman göz ardı edilen bir seçenek var: modüler monolith.

Tek bir deployable birim, ama içi net modül sınırlarıyla bölünmüş. Her modül kendi sorumluluk alanına sahip, diğer modüllere doğrudan erişimi kısıtlı. Gerektiğinde servis sınırları zaten çizili olduğu için microservices'e geçiş çok daha az acı verir.

Modüler Monolith:
┌─────────────────────────────────────┐
│              Uygulama               │
│  ┌──────────────────────────────┐   │
│  │  Auth Modülü                 │   │
│  │  (kendi repository'leri var) │   │
│  └──────────────────────────────┘   │
│  ┌──────────────────────────────┐   │
│  │  Sipariş Modülü              │   │
│  │  (sadece public API'ye erişir│   │
│  └──────────────────────────────┘   │
└─────────────────────────────────────┘

Shopify yıllarca modüler monolith ile büyüdü. Stack Overflow hâlâ monolith ile milyonlarca isteği karşılıyor. Bu şirketler yetersiz değil — bilinçli seçim yapıyorlar.

Amazon ve Netflix Hikayesi

Microservices'in popülerleşmesinde Amazon ve Netflix'in büyük rolü var. İkisi de monolith'ten microservices'e geçişin başarı hikayelerini anlattı.

Ama şunu unutmayın: Amazon 2000'lerin başında, yüzlerce mühendisle monolith'in gerçekten acı verdiği ölçeğe ulaştıktan sonra geçiş yaptı. Netflix 2008'de streaming'e geçerken, yüksek availabiliy ihtiyacı net olduğunda dönüştürdü.

İkisi de önce problemi yaşadı, sonra çözümü benimsedi. Siz henüz problemi yaşamadan çözümü benimsiyorsanız, aslında yeni bir problem ediniyorsunuz.

Mimari kararlar geri alınamaz değil — ama her dönüşümün maliyeti var. En iyi mimari, şu anki probleminizi çözen, büyümenize engel olmayan ve ekibinizin taşıyabileceği karmaşıklık seviyesindeki mimaridir.