Monolith vs Modular Monolith vs Microservices: Hangi Mimari Seçilmeli?

Bir yazılım projesinde yanlış mimari seçim, ilk aylarda değil sistem büyüdüğünde kendini gösterir. Küçük bir ekip mikroservislerle başladığında geliştirme yerine servis keşfi, deployment, log takibi ve ağ hatalarıyla uğraşabilir. Hızlı kurulan klasik monolith ise sınırlar korunmadığında birkaç yıl sonra küçük değişikliklerin bile bütün sistemi etkilediği bir yapıya dönüşebilir.

Bu nedenle karar “mikroservis modern, monolith eski” gibi basit bir karşıtlıkla verilmemelidir. Ekip sayısı, domain’in ne kadar anlaşıldığı, modüllerin farklı ölçek ihtiyacı, bağımsız yayın gereksinimi, veri tutarlılığı ve operasyon kapasitesi birlikte değerlendirilmelidir. Modular monolith ise çoğu projede iki uç arasında geçici bir basamak değil, tek deploy içinde güçlü iş sınırları sunan bağımsız bir mimari seçenektir.

Bu rehber mikroservislerin genel tanımını veya modular monolith’in uygulama ayrıntılarını tekrar etmez. Odak, üç yaklaşım arasında karar vermeyi sağlayacak somut bir seçim matrisidir.

Üç mimari arasındaki temel fark nedir?

Monolith, uygulamanın temel davranışının aynı süreç içinde çalıştığı ve çoğunlukla tek birim olarak dağıtıldığı yapıdır. Microsoft’un modern web uygulamaları rehberi, monolitik uygulamanın temel davranışının tek süreçte çalıştığını ve yatay ölçeklemede bütün uygulamanın çoğaltıldığını açıklar Microsoft Common Web Application Architectures.

Modular monolith de tek deployment birimidir; fakat kod tabanı iş yeteneklerine göre sınırlandırılmış modüllerden oluşur. Modüller yalnızca izin verilen public sözleşmeler üzerinden iletişim kurar. Spring Modulith, uygulamanın mantıksal parçalarını işlevsel modüller halinde yapılandırmayı, bağımlılıklarını doğrulamayı ve modülleri ayrı test etmeyi destekler Spring Modulith Reference.

Microservices mimarisinde ise uygulama, bağımsız geliştirilebilen, dağıtılabilen ve ölçeklenebilen servislerden oluşur. Azure Architecture Center her servisin belirli bir iş yeteneğini ve bounded context’i sahiplenmesini temel özellik olarak tanımlar Azure Microservices Architecture Style.

Kısa karşılaştırma tablosu

Monolith ne zaman doğru seçimdir?

Yeni ürünün iş modeli henüz doğrulanmamışsa, ekip küçükse ve domain sınırları sürekli değişiyorsa monolith hızlı öğrenme için güçlü bir seçenektir. Tek repository, tek deployment hattı ve tek yerel çalışma ortamı geliştirme maliyetini azaltır. İşlem akışları aynı veritabanı transaction’ı içinde güvenli biçimde yürütülebilir.

• Ekip birkaç geliştiriciden oluşuyorsa.
• Ürün-market uyumu henüz doğrulanmamışsa.
• İş kuralları ve modül sınırları sık değişiyorsa.
• Trafik ve ölçek ihtiyacı bütün uygulamada benzerse.
• Bağımsız deployment için somut bir gerekçe yoksa.
• Operasyon ve DevOps kapasitesi sınırlıysa.

Monolith seçimi kodun kontrolsüz yazılması anlamına gelmemelidir. Katman ayrımı, otomatik test, açık domain paketleri ve bağımlılık kuralları uygulanırsa sistem daha sonra modular hale getirilebilir.

Klasik monolith ne zaman sorun oluşturmaya başlar?

Sorun uygulamanın tek deploy edilmesi değil, iç yapının bağımlılık ağına dönüşmesidir. Bir modül başka modülün tablolarına, repository sınıflarına ve iç servislerine doğrudan eriştiğinde değişiklik etkisi büyür. Küçük bir özellik çok sayıda dosya ve takımın koordinasyonunu gerektirir.

• Modül sahipliği belli değilse.
• Her bölüm ortak veritabanı tablolarını değiştirebiliyorsa.
• Bağımlılık döngüleri oluşuyorsa.
• Testlerin yalnızca bütün uygulamayla çalışması gerekiyorsa.
• Tek deployment çok sayıda ekibi sürekli birbirine bağlıyorsa.
• Bir modülün kaynak ihtiyacı bütün sistemi ölçeklemeye zorluyorsa.

Bu belirtiler doğrudan “hemen mikroservise geçin” sonucu üretmez. İlk çözüm çoğu zaman uygulama içinde modül sınırlarını netleştirmek ve veri sahipliğini düzenlemektir.

Modular monolith ne zaman daha güçlü bir ara değil, son durumdur?

Modular monolith, tek deployment sadeliğini korurken iş yetenekleri arasında güçlü sınırlar kurulmasını sağlar. Küçük ve orta ekipler için bu yapı uzun süre yeterli olabilir. Sipariş, stok, müşteri ve faturalama modülleri kendi domain modeline ve veri erişimine sahip olur; diğer modüller yalnızca public API üzerinden iletişim kurar.

Spring Modulith’in doğrulama mekanizması, modül iç paketlerine dış erişimi engelleme ve izin verilen bağımlılıkları tanımlama gibi kontroller sunar Spring Modulith Module Verification. Aynı prensipler başka teknoloji yığınlarında mimari testlerle uygulanabilir.

Yazılım geliştirme projesinde modül sınırları anlaşılmış fakat bağımsız servis operasyonu için gerçek ihtiyaç oluşmamışsa modular monolith genellikle dengeli seçimdir.

Microservices ne zaman gerçek değer sağlar?

Microservices, servislerin gerçekten bağımsız yaşam döngülerine ihtiyaç duyduğu durumda değer üretir. Belirli iş yetenekleri farklı ekipler tarafından yönetiliyor, farklı hızlarda yayınlanıyor veya birbirinden çok farklı ölçekleniyorsa servis ayrımı anlamlı olabilir.

• Çok sayıda ekip bağımsız release takvimiyle çalışıyorsa.
• Belirli modüllerin yük profili diğerlerinden ciddi biçimde farklıysa.
• Hata ve güvenlik izolasyonu iş açısından zorunluysa.
• Farklı teknoloji veya çalışma zamanı somut avantaj sağlıyorsa.
• Servis bazlı veri sahipliği kurulabiliyorsa.
• Dağıtık tracing, mesajlaşma ve olay müdahalesi kapasitesi varsa.
• Tek deployment organizasyonun hızını ölçülebilir biçimde düşürüyorsa.

Azure’un mikroservis rehberi servislerin bağımsız deployment, ölçekleme ve iş yeteneği sahipliğini temel özellikler arasında gösterir Azure Microservices Architecture Style. Bu avantajların hiçbirine ihtiyaç yoksa servis ayrımı yalnızca maliyet üretir.

Ekip büyüklüğü mimariyi nasıl etkiler?

Beş kişilik ekipte her geliştiricinin ayrı servis, deployment hattı ve on-call sorumluluğu taşıması verimsiz olabilir. Aynı ekip tek veya modular monolith içinde daha hızlı iletişim kurar. Ekip büyüdükçe ortak repository ve tek release takvimi koordinasyon darboğazı oluşturabilir.

Mikroservis sınırları organizasyon sınırlarıyla uyumlu olmalıdır. Bir servisin birden fazla ekip tarafından sürekli ortak değiştirilmesi veya tek ekibin onlarca kritik servisten sorumlu olması bağımsızlık avantajını azaltır. Mimari, organizasyon kapasitesinden daha parçalı olmamalıdır.

Domain karmaşıklığı ve sınırların olgunluğu neden önemlidir?

Servis sınırlarını erken belirlemek zordur. Ürün geliştikçe “müşteri”, “abonelik”, “faturalama” veya “sipariş” kavramlarının gerçek sorumlulukları değişebilir. Yanlış servis sınırı, sürekli ağ üzerinden konuşan ve birlikte deploy edilmek zorunda kalan dağıtık monolith üretir.

AWS Well-Architected, iş yeteneklerinin bounded context’lerle belirlenmesini ve servislerin belirli business domain’lere odaklanmasını önerir AWS Business Domain Segmentation. Domain henüz anlaşılmadıysa modular monolith, sınırları daha düşük maliyetle deneyip düzeltme imkânı sağlar.

Deployment bağımsızlığı gerçekten gerekli mi?

Microservices’in en güçlü vaatlerinden biri bir servisin diğerlerini beklemeden yayınlanabilmesidir. Fakat servisler aynı anda değişmek zorunda kalıyor, API sözleşmeleri geriye uyumlu değil veya her release bütün sistemi etkiliyorsa bağımsız deployment yalnızca teoride kalır.

Karar verirken şu sorular ölçülmelidir:

• Tek deployment nedeniyle kaç release erteleniyor?
• Bir modül değişikliği gerçekten diğer modüllerden bağımsız mı?
• Servis API’leri geriye uyumlu geliştirilebiliyor mu?
• Her servis için test ve rollback hattı kurulabilir mi?
• Bağımsız release’in ticari değeri operasyon maliyetini karşılıyor mu?

Ölçekleme ihtiyacı üç mimaride nasıl farklılaşır?

Monolith ve modular monolith genellikle bütün uygulamanın yatay çoğaltılmasıyla ölçeklenir. Trafiğin çoğu aynı modüllere dağılıyorsa bu yaklaşım uzun süre yeterli olabilir. Stateless uygulama örnekleri, cache ve veritabanı optimizasyonu birçok sistemi servis ayrımı olmadan taşıyabilir.

Microservices belirli servisin bağımsız çoğaltılmasına izin verir. Görsel işleme çok yoğunken müşteri yönetimi düşük trafikteyse yalnızca işleme servisi büyütülebilir. Ancak ayrı ölçeklemenin değeri, servisler arası ağ trafiği ve veri bağımlılıklarıyla birlikte hesaplanmalıdır.

Microsoft’un monolitik uygulama rehberi, monolith’in yatay ölçeklemede bütün uygulama olarak çoğaltıldığını belirtir Microsoft Common Web Application Architectures. Bu her zaman verimsiz değildir; uygulama yükü dengeliyse daha basit ve ekonomik olabilir.

Veri sahipliği seçimde neden kritik rol oynar?

Klasik monolith içinde bütün modüllerin aynı tablolara erişmesi kolaydır. Modular monolith tek veritabanı kullanabilir; fakat her tablo veya şemanın sahibi olan modül belirlenir. Microservices yaklaşımında servislerin kendi verisini sahiplenmesi hedeflenir ve başka servisler bu veriye API veya event üzerinden ulaşır.

Ortak veritabanı üzerinde bağımsız servis görünümü oluşturmak, deployment ayrılığına rağmen güçlü veri bağımlılığı bırakır. Şema değişikliği birden fazla servisi kırabilir ve servisler gerçek anlamda bağımsız ölçeklenemez. Mikroservise geçişin en zor bölümü çoğu zaman kodu değil veriyi ayırmaktır.

Transaction ve tutarlılık maliyeti nasıl değişir?

Monolith ve modular monolith içinde aynı veritabanı transaction’ı birden fazla iş adımını atomik yürütebilir. Microservices’te her servis kendi verisine sahipse dağıtık transaction yerine event, saga, idempotency ve telafi işlemleri gerekir. Kullanıcı kısa süre farklı ekranlarda farklı state görebilir.

Bu karmaşıklık iş tarafından gerçekten gerekli bağımsızlık sağlıyorsa kabul edilebilir. Fakat basit sipariş ve stok akışını yalnızca mimari trend nedeniyle dağıtmak, daha önce bulunmayan eventual consistency sorunları üretir.

Hata izolasyonu gerçekten microservices avantajı mıdır?

Servis sınırı, bir bileşenin çökmesinin bütün uygulamayı durdurmasını engelleyebilir. Ancak bu yalnızca timeout, circuit breaker, kaynak izolasyonu, kuyruk ve fallback davranışları doğru kurulursa geçerlidir. Bir servis çağrısı bütün kullanıcı yolunda zorunluysa ilgili servisin arızası yine sistemi etkiler.

Monolith içinde de process isolation olmasa bile modül bazlı hata yönetimi, background worker ayrımı ve kaynak sınırlama yapılabilir. Microservices hata izolasyonu potansiyeli sunar; otomatik dayanıklılık sağlamaz.

Gözlemlenebilirlik ve hata ayıklama maliyeti nasıl değişir?

Tek süreçte request stack trace ve uygulama logu çoğu problemi izlemek için yeterli olabilir. Dağıtık mimaride tek kullanıcı işlemi gateway, kimlik servisi, sipariş servisi, ödeme servisi ve mesaj broker üzerinden geçebilir. Trace ID, merkezi log, metric ve distributed tracing zorunlu hale gelir.

Microservices seçilmeden önce ekip yalnızca container çalıştırmayı değil, servisler arası hatayı üretimde bulma ve düzeltme kapasitesini de değerlendirmelidir. Aksi halde geliştirme bağımsızlaşırken olay müdahalesi yavaşlar.

Operasyon maliyeti karşılaştırması

Yeni bir proje için varsayılan seçim ne olmalıdır?

Ürün ve domain belirsizse en düşük operasyon maliyetli, geri dönüşü kolay yapı seçilmelidir. Çoğu küçük ve orta ekip için iyi yapılandırılmış monolith veya modular monolith güvenli başlangıçtır. Sınırlar yeterince açıksa doğrudan modular monolith tercih edilebilir.

Microservices varsayılan seçim değil, doğrulanmış bağımsızlık ihtiyaçlarına verilen cevaptır. Tek bir yüksek hacimli modül, bağımsız ekip veya güvenlik sınırı şimdiden belliyse hibrit başlangıç yapılabilir; geri kalan sistem tek deploy içinde kalabilir.

Mevcut monolith nasıl modernize edilmelidir?

İlk adım uygulamayı rastgele servislere bölmek değil, iş yeteneklerini ve bağımlılıkları çıkarmaktır. Modül sınırları kod içinde kurulmalı, ortak veritabanı erişimleri azaltılmalı ve her veri kümesinin sahibi belirlenmelidir. Daha sonra yalnızca somut bağımsızlık ihtiyacı bulunan modül ayrılabilir.

Microsoft’un monolith modernizasyon rehberi, domain-driven design ile uygulamanın daha modüler hale getirilmesini ve servis ayrımının sistematik yürütülmesini önerir Microsoft Monolith Modernization Guidance. Bu kademeli yaklaşım, “big bang rewrite” riskini azaltır.

Strangler yaklaşımı ne zaman kullanılabilir?

Eski sistemin tamamını tek seferde yeniden yazmak yerine belirli iş yeteneği yeni bir modül veya servis olarak çıkarılabilir. Trafik gateway veya routing katmanında eski ve yeni uygulama arasında yönlendirilir. Yeni bölüm doğrulandıktan sonra eski işlev kapatılır.

İlk aday; bağımlılığı düşük, veri sahibi belirli, bağımsız ölçek veya release faydası yüksek bir modül olmalıdır. Sistemin merkezindeki en karmaşık modülle başlamak geçiş riskini büyütür.

Üç mimari için hızlı karar matrisi

• Küçük ekip + belirsiz domain + hızlı ürün doğrulama: Monolith.
• Küçük/orta ekip + bilinen iş modülleri + tek deployment yeterli: Modular monolith.
• Çok ekip + bağımsız release + farklı ölçek profilleri: Microservices.
• Karmaşık domain fakat operasyon kapasitesi düşük: Modular monolith.
• Tek sıcak modül bütün sistemi pahalı ölçekletiyor: İlgili modülü servis olarak ayıran hibrit yapı.
• Ortak veritabanı ve sürekli birlikte değişen servisler: Önce sınırları düzelt; mevcut yapı dağıtık monolith olabilir.
• Sadece teknoloji modası nedeniyle servis talebi: Monolith veya modular monolith ile başla.

En sık yapılan mimari seçim hataları

1. Mikroservisi yalnızca gelecekte büyüme ihtimaliyle seçmek.
2. Monolith’i modülsüz ve bağımlılık kuralsız geliştirmek.
3. Modular monolith’i yalnızca klasör yapısı sanmak.
4. Servisleri teknik katmanlara göre bölmek.
5. Bağımsız deployment olmadan servis ayrımının fayda sağlayacağını varsaymak.
6. Ortak veritabanını koruyup servislerin bağımsız olduğunu düşünmek.
7. Dağıtık izleme ve on-call maliyetini hesaba katmamak.
8. Domain anlaşılmadan erken ve kalıcı servis sınırları çizmek.
9. Ölçek problemini ölçmeden bütün sistemi parçalamak.
10. Hibrit mimari seçeneğini göz ardı etmek.

Mimari karar öncesi kontrol listesi

1. Ekip kaç kişi ve kaç bağımsız ürün takımı bulunuyor?
2. Domain sınırları gerçekten anlaşıldı mı?
3. Tek deployment ölçülebilir bir release darboğazı oluşturuyor mu?
4. Modüllerin yük profilleri ne kadar farklı?
5. Bağımsız veri sahipliği kurulabilir mi?
6. Eventual consistency hangi iş akışlarında kabul edilebilir?
7. Distributed tracing, mesajlaşma ve servis güvenliği işletilebilir mi?
8. Bir servisin arızasında sistem nasıl degrade olacak?
9. Modular monolith gerçek ihtiyacı daha düşük maliyetle karşılıyor mu?
10. Mimari karar iki yıl sonra geri çevrilebilir veya kademeli geliştirilebilir mi?

Sonuç: En iyi mimari, gereksiz bağımsızlık üretmeyen mimaridir

Monolith küçük ekip ve belirsiz ürün için hız sağlar. Modular monolith, tek deployment sadeliğini korurken güçlü domain ve bağımlılık sınırları sunar. Microservices ise bağımsız ekip, deployment, ölçek ve hata izolasyonu ihtiyacı gerçekten oluştuğunda değer üretir.

Karar teknoloji prestijine göre değil, bugün var olan organizasyon ve iş gereksinimine göre verilmelidir. Çoğu proje için iyi yapılandırılmış modular monolith, dağıtık sistem maliyetine girmeden uzun vadeli sürdürülebilirlik sağlayabilir. Microservices’e geçiş ise bütün sistemi aynı anda parçalamak yerine, ölçülen darboğazı sahiplenen modüllerle kademeli yürütülmelidir.