Monolit mi, Mikroservis mi? Her Projenin Mikroservise İhtiyacı Var mı?
Monolit mi mikroservis mi? .NET ve SaaS projelerinde mimari seçimi, modüler monolit yaklaşımı, operasyonel maliyetler ve gerçek örnekler.
· 7 dk okuma
Yazılım dünyasında bazı teknolojiler ve mimari yaklaşımlar zamanla o kadar popüler hale geliyor ki, gerçekten ihtiyaç duyup duymadığımızı sorgulamadan kullanmaya başlayabiliyoruz.
Mikroservis mimarisi de bunlardan biri.
Özellikle yeni bir projeye başlarken sıkça karşılaştığımız sorulardan biri şu: Monolitik bir uygulama mı geliştirmeliyiz, yoksa doğrudan mikroservis mimarisiyle mi başlamalıyız?
Bence burada asıl sorulması gereken, hangi mimarinin daha modern olduğu değil, hangi mimarinin projenin ihtiyaçlarına daha uygun olduğudur.
Çünkü her uygulamanın mikroservise ihtiyacı olmadığı gibi, her monolitik uygulama da kötü tasarlanmış değildir.
Monolitik Mimari Nedir?
Monolitik mimari (Monolithic Architecture), uygulamanın farklı işlevlerinin tek bir uygulama ve dağıtım birimi içerisinde çalıştığı mimari yaklaşımdır.
Örneğin bir işletme yönetim yazılımı geliştirdiğimizi düşünelim.
Uygulamada müşteri yönetimi, stok takibi, sipariş, muhasebe ve raporlama gibi modüller bulunuyor.
Monolitik mimaride bu işlevler aynı uygulama içerisinde geliştirilebilir ve birlikte yayınlanabilir.
Bu yaklaşımın önemli avantajları var. Geliştirme ortamını hazırlamak, uygulamayı test etmek, hata ayıklamak ve sunucuya dağıtmak genellikle daha az operasyonel karmaşıklık gerektirir.
Ancak uygulama büyüdükçe modüller arasındaki bağımlılıklar artabilir. Bir noktadan sonra küçük bir değişiklik, hiç beklenmeyen başka bir modülü etkileyebilir.
Burada önemli bir ayrıntı var: Bu sorun monolitik mimarinin kaçınılmaz sonucu değil, çoğu zaman uygulamanın nasıl tasarlandığıyla ilgilidir.
İyi tasarlanmış bir monolitik uygulama, uzun yıllar boyunca güvenle geliştirilebilir.
Mikroservis Mimarisi Nedir?
Mikroservis mimarisi (Microservices Architecture), uygulamanın belirli iş yeteneklerine göre ayrılmış, bağımsız geliştirilebilen ve dağıtılabilen servislerden oluşmasıdır.
Aynı işletme yönetim yazılımını mikroservis yaklaşımıyla tasarladığımızı düşünelim.
Müşteri, stok, sipariş ve ödeme süreçleri ayrı servisler olarak çalışabilir. Her servis kendi iş kurallarını ve verisini yönetir. Diğer servislerle API veya mesajlaşma altyapıları üzerinden iletişim kurar.
Bu yaklaşım özellikle büyük ve karmaşık sistemlerde önemli avantajlar sağlayabilir.
Örneğin sipariş servisinde yoğunluk oluşuyorsa yalnızca o servisin kaynakları artırılabilir. Bir ekip ödeme sistemini geliştirirken başka bir ekip stok yönetiminde değişiklik yapabilir.
Ancak bu bağımsızlık beraberinde yeni sorumluluklar getirir.
Artık yalnızca uygulama kodunu değil; servisler arası iletişimi, ağ hatalarını, veri tutarlılığını, servis sürümlerini ve dağıtık sistemlerin izlenebilirliğini de yönetmek zorundayız.
Microsoft'un mikroservis mimarisi rehberinde de bu operasyonel karmaşıklık, mimarinin en önemli zorlukları arasında gösteriliyor.
Monolit mi, Mikroservis mi? Temel Farklar
Kriter | Monolitik Mimari | Mikroservis Mimarisi |
|---|---|---|
Geliştirme | Başlangıçta genellikle daha basit | Servis sınırları ve entegrasyonlar gerektirir |
Dağıtım | Uygulama birlikte yayınlanır | Servisler bağımsız yayınlanabilir |
Ölçeklendirme | Genellikle uygulama bütün olarak ölçeklenir | Servisler ayrı ayrı ölçeklenebilir |
Veritabanı | Ortak veritabanı kullanımı yaygın | Servis bazlı veri sahipliği esastır |
Hata ayıklama | Tek süreçte takip daha kolaydır | Dağıtık izleme gerekebilir |
Operasyon | Genellikle daha az bileşen | Daha fazla altyapı ve koordinasyon |
Takım yapısı | Küçük ekipler için yönetilebilir | Bağımsız ekipler için avantaj sağlayabilir |
Bu karşılaştırmada dikkat edilmesi gereken nokta, mikroservisin otomatik olarak daha hızlı veya daha güvenilir olmadığıdır.
Her iki yaklaşımda da performans, güvenlik ve sürdürülebilirlik; mimari tasarımın yanında kod kalitesine, altyapıya ve operasyonel süreçlere bağlıdır.
Modüler Monolit: Çoğu Projenin Gözden Kaçırdığı Alternatif
Bana göre monolit ve mikroservis arasında değerlendirilmesi gereken önemli bir seçenek daha var: Modüler Monolit (Modular Monolith).
Modüler monolit, tek bir uygulama olarak çalışan ancak içerisinde iş alanlarına göre net sınırlarla ayrılmış modüller barındıran mimari yaklaşımdır.
Örneğin stok yönetiminin kendi servis katmanı, iş kuralları ve veri erişim sınırları olabilir. Sipariş modülü, stok tablolarına doğrudan erişmek yerine tanımlanmış arayüzleri kullanır.
Böylece uygulama tek bir bütün olarak çalışırken modüller arasındaki bağımlılıkları kontrol altında tutabiliriz.
Üstelik ilerleyen dönemde belirli bir modülü bağımsız servise dönüştürmek istersek, iyi tanımlanmış sınırlar bu süreci kolaylaştırabilir. Tabii bu dönüşümün tamamen zahmetsiz olacağını söylemek doğru olmaz.
Bence özellikle küçük ekiplerle geliştirilen SaaS ürünleri için bu yaklaşım oldukça değerlidir.
Başlangıçta mikroservisin bütün operasyonel yükünü üstlenmeden, modüler ve gelişime açık bir sistem oluşturmak mümkündür.
Gerçek Bir Örnek: Prime Video Neden Monolite Döndü?
Mimari tercihlerle ilgili dikkat çekici örneklerden biri Amazon Prime Video ekibinin 2023 yılında paylaştığı teknik çalışma.
Prime Video, görüntü ve ses kalitesini analiz eden sisteminde başlangıçta dağıtık ve sunucusuz bileşenlerden oluşan bir mimari kullanıyordu.
Ancak sistem büyüdükçe servisler arasındaki veri aktarımı ve iş akışı yönetimi ciddi bir maliyet ve ölçeklendirme problemi oluşturdu.
Ekip, bu belirli iş yükündeki bileşenleri tek bir süreç içerisinde birleştirerek mimariyi sadeleştirdi.
Sonuç: İlgili sistemin altyapı maliyetlerinde yaklaşık %90 azalma sağlandı.
Bu sonuç, mikroservislerin kötü veya monolitin her zaman daha ekonomik olduğu anlamına gelmiyor.
Örnekteki kazanım, özellikle o iş yükünün veri aktarımı ve orkestrasyon maliyetlerinin azaltılmasından kaynaklanıyordu. Ayrıca Prime Video'nun tamamı monolitik mimariye taşınmadı.
Bu örneği önemli buluyorum çünkü bize çok temel bir şeyi hatırlatıyor:
Bazen sistemi daha fazla parçaya bölmek değil, gereksiz dağıtık yapıyı ortadan kaldırmak daha doğru mühendislik kararı olabilir.
Kaynak: InfoQ – Prime Video Switched from Serverless to EC2 and ECS to Save Costs, 3 Mayıs 2023.
Kendi SaaS Deneyimimden: PiaFix
Geliştirdiğim PiaFix üzerinden de bu konuyu değerlendirme fırsatım oldu.
PiaFix'in ilk versiyonunu ASP.NET MVC, C#, SQL Server ve Azure teknolojileriyle monolitik bir yaklaşımla geliştirdim.
Uygulama içerisinde servis kayıtları, müşteri yönetimi, stok takibi, gelir-gider işlemleri ve farklı operasyonel süreçler bulunuyor.
İlk aşamada önceliğim, sistemi mümkün olduğunca hızlı geliştirerek gerçek işletmelerin kullanımına sunmaktı.
Zamanla işletme sayısı, servis kayıtları ve kullanıcı ihtiyaçları arttıkça yalnızca yeni özellik geliştirmek yeterli olmamaya başladı. Modüller arasındaki ilişkileri, yetkilendirmeleri, veri yönetimini ve bakım süreçlerini de daha fazla düşünmek gerekti.
Burada öğrendiğim önemli bir şey var:
Bir uygulamanın büyümesi, mutlaka mikroservis mimarisine geçmesi gerektiği anlamına gelmiyor.
Bazen ihtiyacımız olan şey daha iyi bir veritabanı tasarımı, doğru indeksler, önbellekleme, arka plan işlemleri veya modüller arasında daha net sınırlar olabiliyor.
PiaFix'i geliştirme sürecindeki diğer deneyimlerimi Bir SaaS Ürününü Fikirden Gerçek Kullanıma Taşımak başlıklı yazımda da paylaşmıştım.
Peki Ne Zaman Mikroservis Kullanmalıyız?
Her projeye aynı mimariyi uygulamak yerine ihtiyacı değerlendirmek gerektiğini düşünüyorum.
Özellikle aşağıdaki durumlarda mikroservis yaklaşımı anlamlı olabilir:
Farklı iş alanlarını yöneten birden fazla bağımsız geliştirme ekibi varsa,
Sistemin bazı bileşenleri diğerlerinden çok farklı ölçeklendirme ihtiyaçlarına sahipse,
Servislerin bağımsız yayınlanması gerçek bir operasyonel avantaj sağlayacaksa,
İş alanları ve servis sınırları yeterince anlaşılmışsa,
CI/CD, merkezi loglama, izleme ve hata yönetimi gibi süreçler yeterince olgunsa.
Buna karşılık küçük bir ekiple MVP geliştirdiğimiz, iş ihtiyaçlarının sürekli değiştiği ve henüz ürün-pazar uyumunu aradığımız projelerde mikroservisle başlamak gereksiz karmaşıklık yaratabilir.
Örneğin yalnızca birkaç geliştiricinin çalıştığı bir uygulamada, bir müşteri kaydı oluşturmak için birden fazla servisin iletişim kurması gerekiyorsa sistemin gerçekten ne kazandığını sorgulamak gerekir.
Servisleri birbirinden ayırmak tek başına iyi mimari oluşturmaz. Bağımsız geliştirilebilir ve yönetilebilir olmaları gerekir.
Mimari Kararları Varsayımlarla Değil, Ölçümlerle Vermek
Bu konudaki bir başka önemli nokta da performans ve maliyet konusunda yeterli ölçüm yapmadan karar vermemek.
Örneğin bir uygulama yavaş çalışıyorsa doğrudan mikroservise geçmeyi düşünmek yerine önce yavaşlığın kaynağını araştırmak gerekir.
Sorun veritabanı sorgularında mı, uygulama kodunda mı, dış servislerde mi, yoksa altyapı kaynaklarında mı?
Benzer şekilde mikroservis mimarisinin maliyetini değerlendirirken yalnızca sunucu ücretlerini karşılaştırmak da yeterli değil.
Dağıtım süreçleri, izleme altyapısı, hata çözme süresi ve geliştirme eforu da toplam maliyetin parçası.
Bu nedenle mimari kararlarında yanıt süresi, kaynak tüketimi, yayın sıklığı, hata oranı ve operasyonel maliyet gibi ölçümleri birlikte değerlendirmeyi daha doğru buluyorum.
Sonuç: En İyi Mimari Hangisi?
Yazılım geliştirme dünyasında her probleme uygulanabilecek tek bir doğru mimari olduğuna inanmıyorum.
Monolitik mimari, doğru tasarlandığında son derece başarılı ve sürdürülebilir olabilir. Mikroservisler ise belirli ölçek ve organizasyonel ihtiyaçlarda ciddi avantajlar sağlayabilir.
Modüler monolit yaklaşımı da iki dünyanın bazı avantajlarını bir araya getiren önemli bir alternatif.
Bugün yeni bir projeye başlayacak olsam önce iş ihtiyaçlarını, ekibin büyüklüğünü, mevcut altyapıyı ve beklenen büyümeyi değerlendirirdim.
Büyük ihtimalle küçük başlayıp ihtiyaç oldukça geliştirebileceğim bir mimari tercih ederdim.
Çünkü benim için iyi yazılım mimarisi, kullanılan teknolojilerin sayısıyla değil, problemi ne kadar doğru çözdüğü ve zaman içerisinde ne kadar sürdürülebilir kaldığıyla ilgilidir.
Bir sistemi mikroservislere bölmek kolay olabilir. Asıl mesele, neden böldüğümüzü açıklayabilmektir.