Günümüzde microservice mimariye doğru hızlı bir geçiş var. Microservice mimarinin getiridiği avantajlar yatsınamaz. Fakat Chris Richardson "Microservices Patterns" kitabında küçük uygulamalarda monolotich mimarinin avantajları olduğunu söylüyor.
Bunlar:
1-) Kolay geliştirme : IDE'ler ve diğer geliştirici araçları sadece bir uygulamayı geliştirmek için focus oluyorlar.
2-) Uygulama üzerinde radikal değişiklikler yapabilmek : Radikal bir şekilde kodu, database şemasını kolayca değiştirip build ve deploy yapmanız microservice'e göre çok daha kolay.
3-)Test edilmesi kolay : Geliştiriciler, uygulamayı başlatan, REST API'sini çağıran ve Selenium ile kullanıcı arayüzünü test eden uçtan uca testleri rahatlıkla yazabilirler.
4-) Dağıtımı kolay : Bir geliştiricinin tek yapması gereken, WAR dosyasını Tomcat'in yüklü olduğu bir sunucuya kopyalamaktır.
5-) Ölçeklendirmesi kolay : Uygulamanın birden fazla örneğini bir yük dengeleyicinin arkasında çalıştırabilirsiniz.
Ancak zamanla geliştirme, test, dağıtım ve ölçeklendirme çok daha zor hale gelir. Eğer uygulamanın karmaşıklığı önceden ileride artacağı tahmin edilebiliyorsa microservice mimari ile başlanmadılır. Küçük ve karmaşık olmayan uygulamalar monolotich mimariye daha uygundur.
Monolotich mimari ile yazılan bir uygulama düşünelim. Herbir sprint'de uygulamaya yeni özellikler eklenir ve uygulama code base'i giderek büyür. Buna bağlı olarak yazılım ekibi de giderek kalabalıklaşır. Uygulamayı yönetmek giderek zorlaşmaya başlar. Fonksiyonel olarak ayrılmış Agile takımlar ortaya çıkar. Agile yöntemler kullanmak giderek zor hale gelir.
Uyguluma giderek karmaşıklaştıkca ve büyüdükçe monolotich mimaride yaşanan zorluklar :
1-) Karmaşıklık geliştiricileri korkutur hale gelir : Uygulama çok karmaşık hale geldiğinden hataları düzeltmek ve yeni özellikleri doğru şekilde uygulamak zor ve zaman alıcı hale gelir. Son teslim tarihleri genellikle kaçırılır.
2-) Geliştirme yavaşlar : Büyük uygulama, geliştiricinin IDE'sini aşırı yükler ve yavaşlatır. Uygulamayı build etmek uzun zaman alır. Dahası, çok büyük olduğu için, uygulamanın başlatılması uzun zaman alır. Sonuç olarak, edit-build-run-test döngüsü uzun zaman alır ve bu da üretkenliği kötü etkiler.
3-) Commit'den deployment'a giden uzun ve yorucu yol : Uygulamayla ilgili bir diğer sorun da değişikliklerin üretime aktarılmasının uzun ve acı verici bir süreç olmasıdır. Ekip genellikle ayda bir kez, genellikle Cuma veya Cumartesi gecesi geç saatlerde üretim güncellemelerini dağıtır. Ve continuous deployment benimsemek imkansız gibi görünür. Feature branch'lerinin merge işlemi saatler alabilir ve production'a geçmenin bu kadar uzun sürmesinin bir başka nedeni de testin uzun sürmesidir. Kod tabanı çok karmaşık olduğundan ve bir değişikliğin etkisi iyi anlaşılmadığından, geliştiriciler ve Sürekli Entegrasyon (CI) sunucusu tüm test paketini çalıştırmalıdır.
4-) Ölçeklendirme zor : Bunun nedeni, farklı uygulama modüllerinin çakışan kaynak gereksinimleri olmasıdır. Örneğin uygulamada bazı modüller , çok fazla belleğe sahip sunucularda ideal olarak deploy edilen büyük bellek veritabanında saklanırken, görüntü işleme modülü CPU yoğun bir işlemdir ve en iyi CPU'lara sahip sunucularda en iyi şekilde çalışır. Bu modüller aynı uygulamanın bir parçası olduğundan, sunucu yapılandırmasında bu aşamada ödünler verilmesi gerekir.
5-) Reliable bir monolitich sunmak zor : Reliable olmamasının bir nedeni, büyük boyutu nedeniyle uygulamayı kapsamlı bir şekilde test etmenin zor olmasıdır. Bu test edilebilirlik eksikliği, hataların productiona geçmesi anlamına gelir. Daha da kötüsü, tüm modüller aynı işlem içinde çalıştığından uygulamada hata izolasyonu yoktur. Çoğu zaman, bir modüldeki bir hata - örneğin bir bellek sızıntısı - uygulamanın tüm modullerini tek tek çökertir.
6-) Giderek kullanılmayan teknolojiye mahkum kalmak : Mimarinin giderek modası geçmiş bir teknoloji yığını kullanmaya zorlamasıdır. Monolitik mimari, yeni frameworklerin ve dillerin benimsenmesini zorlaştırmaktadır. Tüm monolitik uygulamayı yeniden yazmak son derece pahalı ve riskli olacaktır, böylece yeni ve muhtemelen daha iyi bir teknoloji kullanamayacaktır. Sonuç olarak, geliştiriciler projenin başlangıcında yaptıkları teknoloji seçimlerine bağlı kalırlar.
Bunlar:
1-) Kolay geliştirme : IDE'ler ve diğer geliştirici araçları sadece bir uygulamayı geliştirmek için focus oluyorlar.
2-) Uygulama üzerinde radikal değişiklikler yapabilmek : Radikal bir şekilde kodu, database şemasını kolayca değiştirip build ve deploy yapmanız microservice'e göre çok daha kolay.
3-)Test edilmesi kolay : Geliştiriciler, uygulamayı başlatan, REST API'sini çağıran ve Selenium ile kullanıcı arayüzünü test eden uçtan uca testleri rahatlıkla yazabilirler.
4-) Dağıtımı kolay : Bir geliştiricinin tek yapması gereken, WAR dosyasını Tomcat'in yüklü olduğu bir sunucuya kopyalamaktır.
5-) Ölçeklendirmesi kolay : Uygulamanın birden fazla örneğini bir yük dengeleyicinin arkasında çalıştırabilirsiniz.
Ancak zamanla geliştirme, test, dağıtım ve ölçeklendirme çok daha zor hale gelir. Eğer uygulamanın karmaşıklığı önceden ileride artacağı tahmin edilebiliyorsa microservice mimari ile başlanmadılır. Küçük ve karmaşık olmayan uygulamalar monolotich mimariye daha uygundur.
Monolotich mimari ile yazılan bir uygulama düşünelim. Herbir sprint'de uygulamaya yeni özellikler eklenir ve uygulama code base'i giderek büyür. Buna bağlı olarak yazılım ekibi de giderek kalabalıklaşır. Uygulamayı yönetmek giderek zorlaşmaya başlar. Fonksiyonel olarak ayrılmış Agile takımlar ortaya çıkar. Agile yöntemler kullanmak giderek zor hale gelir.
Uyguluma giderek karmaşıklaştıkca ve büyüdükçe monolotich mimaride yaşanan zorluklar :
1-) Karmaşıklık geliştiricileri korkutur hale gelir : Uygulama çok karmaşık hale geldiğinden hataları düzeltmek ve yeni özellikleri doğru şekilde uygulamak zor ve zaman alıcı hale gelir. Son teslim tarihleri genellikle kaçırılır.
2-) Geliştirme yavaşlar : Büyük uygulama, geliştiricinin IDE'sini aşırı yükler ve yavaşlatır. Uygulamayı build etmek uzun zaman alır. Dahası, çok büyük olduğu için, uygulamanın başlatılması uzun zaman alır. Sonuç olarak, edit-build-run-test döngüsü uzun zaman alır ve bu da üretkenliği kötü etkiler.
3-) Commit'den deployment'a giden uzun ve yorucu yol : Uygulamayla ilgili bir diğer sorun da değişikliklerin üretime aktarılmasının uzun ve acı verici bir süreç olmasıdır. Ekip genellikle ayda bir kez, genellikle Cuma veya Cumartesi gecesi geç saatlerde üretim güncellemelerini dağıtır. Ve continuous deployment benimsemek imkansız gibi görünür. Feature branch'lerinin merge işlemi saatler alabilir ve production'a geçmenin bu kadar uzun sürmesinin bir başka nedeni de testin uzun sürmesidir. Kod tabanı çok karmaşık olduğundan ve bir değişikliğin etkisi iyi anlaşılmadığından, geliştiriciler ve Sürekli Entegrasyon (CI) sunucusu tüm test paketini çalıştırmalıdır.
4-) Ölçeklendirme zor : Bunun nedeni, farklı uygulama modüllerinin çakışan kaynak gereksinimleri olmasıdır. Örneğin uygulamada bazı modüller , çok fazla belleğe sahip sunucularda ideal olarak deploy edilen büyük bellek veritabanında saklanırken, görüntü işleme modülü CPU yoğun bir işlemdir ve en iyi CPU'lara sahip sunucularda en iyi şekilde çalışır. Bu modüller aynı uygulamanın bir parçası olduğundan, sunucu yapılandırmasında bu aşamada ödünler verilmesi gerekir.
5-) Reliable bir monolitich sunmak zor : Reliable olmamasının bir nedeni, büyük boyutu nedeniyle uygulamayı kapsamlı bir şekilde test etmenin zor olmasıdır. Bu test edilebilirlik eksikliği, hataların productiona geçmesi anlamına gelir. Daha da kötüsü, tüm modüller aynı işlem içinde çalıştığından uygulamada hata izolasyonu yoktur. Çoğu zaman, bir modüldeki bir hata - örneğin bir bellek sızıntısı - uygulamanın tüm modullerini tek tek çökertir.
6-) Giderek kullanılmayan teknolojiye mahkum kalmak : Mimarinin giderek modası geçmiş bir teknoloji yığını kullanmaya zorlamasıdır. Monolitik mimari, yeni frameworklerin ve dillerin benimsenmesini zorlaştırmaktadır. Tüm monolitik uygulamayı yeniden yazmak son derece pahalı ve riskli olacaktır, böylece yeni ve muhtemelen daha iyi bir teknoloji kullanamayacaktır. Sonuç olarak, geliştiriciler projenin başlangıcında yaptıkları teknoloji seçimlerine bağlı kalırlar.
Türk Ninja IT Dünyası'ndan haberler, röportajlar, makaleler, eğitimler ve video içerikleri sunar.
