Monolitik Mimariler Dinazor Değildir!
Birçok şirket, büyük kurumsal yazılım sistemlerini (monolitler) daha küçük, daha esnek mikro hizmet mimarilerine dönüştürme eğilimindedir. Ancak bu yaklaşım, monolitleri dinozorlar olarak nitelendirir ve onları modern yazılım geliştirme dünyasında kullanılamaz hale getirir. Bu yaklaşım, monolitlerin sürdürülemez olduğunu ima ederken, bu yazılım sistemlerinin hala kullanışlı olabileceğini unutturur.
Yazılım mimarileri, köprü ve ev mimarileri gibi değildir. Bir köprü inşa edildikten sonra, inşa ediliş şeklini değiştirmek mümkündür ancak zordur. Yazılım ise oldukça farklıdır. Yazılımı bir kez çalıştırdığımızda, iş yüklerimiz hakkında tasarlandığımızdan daha fazla içgörü elde edebiliriz. Eğer başlangıçta bunu fark etseydik ve geliştirilebilir bir mimari seçseydik, müşteri deneyimini etkilemeden bileşenleri değiştirebilirdik. Benim temel kuralım, her büyümede mimarinizi yeniden gözden geçirmeniz ve bir sonraki büyüme seviyesini hala destekleyip destekleyemeyeceğinizi belirlemeniz gerektiğidir.
Prime Video’nun mühendislik ekipleri tarafından yazılan iki bilgilendirici blog yazısında harika bir örnek bulunabilir. İlkinde Perşembe Gecesi Futbolu canlı yayınının nasıl dağıtık bir iş akışı mimarisi üzerine inşa edildiği anlatılıyor. İkincisi ise akış izleme araçlarının mimarisini ve deneyimlerinin analizlerini kullanarak bu aracı monolitik bir mimari olarak uygulamaya nasıl yönlendirdiklerini anlatan yeni bir yazı var.
“Prime Video ses/video izleme hizmetini ölçeklendirmek ve maliyetleri %90 oranında azaltmak” başlıklı blog yazısında Prime Video mühendislik ekibi, dağıtık bir mikro hizmet mimarisinden monolitik bir uygulamaya geçerek nasıl daha yüksek ölçek, esneklik ve maliyet azaltma elde ettiklerini anlatıyor.
Ekip, başlangıçta izleme hizmetini bir mikro hizmet mimarisi kullanarak oluşturduklarını açıklıyor. Ancak kısa süre sonra Prime Video platformunun artan taleplerini karşılamak için hizmeti ölçeklendirirken zorluklarla karşılaştılar. Çok sayıda mikro hizmeti yönetmenin ve izlemenin giderek daha karmaşık ve maliyetli hale geldiğini fark ettiler.
Bu zorlukların üstesinden gelmek için ekip, tüm hizmet bileşenlerinin tek bir uygulamada birleştirildiği monolitik bir mimariye geçmeye karar verdi. Bu sayede altyapı basitleştirildi, operasyonel ek yükler azaltıldı ve izleme hizmetinin genel performansı iyileştirildi.
Ekip ayrıca monolit uygulamanın dağıtımını ve ölçeklendirmesini yönetmek için Amazon Elastic Container Service’ten (ECS) yararlandı. ECS kullanmanın, hizmeti gerektiği gibi kolayca yukarı veya aşağı ölçeklendirmelerine olanak sağladığını ve önceki mikro hizmet mimarilerine kıyasla maliyetlerini %90 oranında azaltabildiklerini gördüler.
Geliştiricileri her zaman sistemlerinin zaman içindeki gelişimini göz önünde bulundurmaya ve temelin minimum sayıda bağımlılıkla değiştirebileceğiniz ve genişletebileceğiniz şekilde olduğundan emin olmaya teşvik ediyorum. Event Driven Architecture(EDA)(Olaya Dayalı Mimari) ve mikro hizmetler bunun için iyi bir eşleşmedir. Bununla birlikte, her zaman yanıta katkıda bulunan, tam olarak aynı ölçeklendirme ve performans gereksinimlerine, aynı güvenlik vektörlerine sahip ve en önemlisi tek bir ekip tarafından yönetilen bir dizi hizmet varsa, bunları birleştirmenin mimarinizi basitleştirip basitleştirmediğini görmek değerli bir çabadır.
Bir grup kıdemli mühendisin Amazon’u monolit bir yapıdan hizmet odaklı bir mimariye taşımak üzere harekete geçiren Dağıtık Bilgi İşlem Manifestosu’nu kaleme aldığı 1998 yılına kadar geri gidebilirsiniz. O zamandan bu yana geçen on yıllar içinde, mikro hizmetlere, ardından paylaşılan altyapı üzerindeki mikro hizmetlere ve bahsettiğim gibi EDA’ya geçtikçe işler gelişmeye devam etti.
Ayrıştırılmış bağımsız sistemlere geçiş doğal bir evrimdi. Mikro hizmetler daha küçük ve yönetimi daha kolay, iş gereksinimlerini karşılayan teknoloji yığınlarını kullanabiliyorlar, dağıtım süreleri daha kısa, geliştiriciler daha hızlı geliştirebiliyor, yeni bileşenler tüm sistemi etkilemeden dağıtılabiliyor ve en önemlisi, bir dağıtım bir mikro hizmeti devre dışı bırakırsa, sistemin geri kalanı çalışmaya devam ediyor. Hizmet tekrar çevrimiçi olduğunda kaçırdığı olayları tekrarlar ve yürütür. Biz buna evrilebilir mimari diyoruz. Zaman içinde kolayca değiştirilebilir. Küçük bir şeyle başlarsınız ve vizyonunuza uygun karmaşıklıkta büyümesine izin verirsiniz.
Amazon S3, 2006'daki lansmanından bu yana birkaç mikro hizmetten, eklenen depolama metodolojileri, politika mekanizmaları ve depolama sınıfları ile 300'den fazla mikro hizmete genişleyen bir hizmetin harika bir örneğidir. Bu ancak sistem tasarlarken kritik bir husus olan mimarinin evrimleşebilirliği sayesinde mümkün olmuştur.
Bununla birlikte, hepsine hükmedecek tek bir mimari model olmadığını yinelemek istiyorum. Hizmetleri nasıl geliştirmeyi, dağıtmayı ve yönetmeyi seçeceğiniz her zaman tasarladığınız ürüne, onu oluşturan ekibin becerilerine ve müşterilere sunmak istediğiniz deneyime (ve elbette maliyet, hız ve esneklik gibi unsurlara) bağlı olacaktır. Örneğin, beş mühendisi olan bir startup, dağıtımı daha kolay olduğu ve küçük ekibinin birden fazla programlama dili öğrenmesini gerektirmediği için monolitik bir mimari seçebilir. Onların ihtiyaçları, her biri ayrı bir alt hizmeti yöneten düzinelerce mühendislik ekibine sahip bir kuruluştan temelde farklıdır. Ve bu sorun değil. Önemli olan iş için doğru araçları seçmektir.
Çok az tek yönlü kapı vardır. Sistemlerinizi düzenli olarak değerlendirmek, onları ilk etapta inşa etmek kadar, hatta daha da önemlidir. Çünkü sistemleriniz, onları tasarlamak için geçen süreden çok daha uzun süre çalışacaktır. Yani, monolitler ölmedi (tam tersine), ancak evrilebilir mimariler değişen teknoloji ortamında giderek daha önemli bir rol oynuyor ve bu bulut teknolojileri sayesinde mümkün.
Sonuç olarak, monolitler, büyük kurumsal yazılım sistemlerinin hala kullanışlı olabileceğini unutturan bir dinozor olarak görülmemelidir. Bu yazılım sistemleri, geliştirme ekiplerinin doğru yaklaşımı benimsemeleriyle devam edilebilirliği sağlayabilir.
- Werner Vogels, “Monoliths are not Dinosaurs”, All Things Distributed, Mayıs 2023
- Martin Fowler, “Microservices”, Martin Fowler, 2014
- Sam Newman, “Building Microservices: Designing Fine-Grained Systems”, O’Reilly Media, 2015.
- Benjamin Wootton, “Microservices vs Monolithic Architecture”, Contino, 2021
- Adrian Cockcroft, “Monolithic to Microservices: Evolutionary Patterns”, IEEE Software, 2015
- Randy Shoup, “From the Monolith to Microservices: Lessons Learned on the Journey”, O’Reilly Media, 2018.
Bu kaynaklar, monolitler ve mikro hizmet mimarileri hakkında daha fazla bilgi edinmenize ve daha kapsamlı bir tartışma sağlamanıza yardımcı olabilir. Eğer herhangi bir sorunuz veya geri bildiriminiz varsa, benimle iletişime geçmekten çekinmeyin. Teşekkürler.
