İçeriğe geç →

Monolithic ve MicroService Architecture’a Genel Bir Bakış

Merhaba arkadaşlar.

Bu blog yazımdaki konum, her ne kadar yeni bir şey olmasada, son dönemlerde Martin Fowler ile gündeme gelen ve git gide önemini arttıran MicroService mimarisi üzerine genel bir bakış olacak. Ayrıca bu doğrultuda doğru bilinen yanlışlar, MicroService mimarisinin artıları ve eksileri gibi yönlerine de değiniyor olacağız.

Dilerseniz öncelikle Monolithic kavramından bir bahsedelim.

micro-services

Monolithic Architecture Nedir?

Monolithic architecture yazılımın self-contained(kendi kendine yeten) olarak tasarlanması anlamına gelmektedir. Bir standart doğrultusunda “tek bir parça” olarak oluşması da diyebiliriz. Bu mimarideki component’ler loosely coupled olmasından ziyade, interdependent olarak tasarlanmaktadır.

Günümüze baktığımızda kurumsal projeler, Service Oriented Architecture(SOA) ile geliştirilmeye başlanmış ve büyük ölçüde yerini zaten almış durumdadır. Geleneksel SOA mimarisinde geliştirilen tüm component’lerin de, tek bir çatı altında olduğunu da görmekteyiz. Çünkü yakın geçmişten bu yana SOA ile birlikte manageability(yönetilebilirlik), maintenance(bakım) ve interoperability(birlikte çalışabilirlik) gibi kavramlar göz önüne alınmıştır. Günümüzdeki şirketlerin IT yaklaşımlarına baktığımızda ise genelde IT for Business kapsamında olduğundan dolayı, her zaman pazarlama odaklı gitmektedirler. Bu doğrultuda sürekli artan bir entegrasyon ihtiyaçları doğmaktadır. Bu bitmeyen ihtiyaçlar doğrultusunda ise Monolithic architecture ile tasarlanmış olan SOA’lar, gitgide istemsizce büyümektedirler.

Bu noktaya kadar her şey “büyüme” haricinde normal görünebilir fakat problem nerede/ne zaman başlıyor? İşte bu soruya geçmeden önce Monolithic architecture’ın dezavantajlarını bir ele alalım.

Monolithic Architecture’ın Getirdiği Bazı Dezavantajlar

monolithic

Yukarıdaki resme baktığımızda bölünmez, self-contained olarak tasarlanmış monolithic bir yapı görüyoruz. Scaling için bir load balancer arkasına koyulmuş fakat bu durumda da scale edilmek istenin component’in aksine, tüm monolith yapının kopyasını farklı ortamlarda saklamak durumunda kalınıyor.

Diğer dezavantajlarını maddelemek gerekirse:

  • Tüm component’lerin aynı framework, aynı programlama dili ile geliştirilmesinin gerekmesi
  • Bir component üzerinde olan değişiklik için, tüm monolith yapının tekrar deploy edilmesi ve restart edilmesi durumunda kalınması
  • Versiyon yönetiminin gitgide zorlaşması
  • Birbirlerine olan bağımlılıklarından dolayı, bir component için yapılan değişimden diğer component’in etkilenebilmesi
  • Continuous Delivery’nin uygulanmasının zorlaşması

Bu dezavantajların bazıları monolithic mimarinin büyümesi ile gelmese de en major problemlerden birtanesi,  monolithic mimari üzerindeki component’lerden herhangi birinde olan değişikliğin deployment’ı yapıldığında, bu durumdan diğerlerinin de etkilenebiliyor/etkilenebilecek olmasıdır.

Düşünelim. Belediye otobüslerine hangi durakta olduklarını ve her durak içinde ilgili otobüsün gelmesine tahmini kalan sürenin gösterimini yapan ekranların servisini geliştiriyoruz. Bizden otobüs içerisindeki ekranda gösterilmesi gereken bazı yeni özellikler istendi. İlgili geliştirmeyi ilgili ekip yaptı ve deployment’ı gerçekleştirdi. Peki ya diğer servis olan duraklardaki otobüs sürelerini gösteren fonksiyonun geliştirilmesinde yarım kalan bir şey varsa? Veya otobüs içerisindeki ekranlar için geliştirilen serviste bir hata oluşursa ve diğer servise olan bağımlılığından dolayı, her iki serviste kullanılamaz hale gelirse? Bu ve bunun gibi farklı varyasyon ve senaryolar göz önüne alındığında, monolithic mimaride geliştirilen servislerde yazılım ekiplerinin birbirleri ile iletişim becerilerinin yüksek olması gerektiği, farklı özellikler geldikçe code base’in daha da karmaşıklaşacağı ve micro deployment’lar yapılamayacağı görülüyor. Yani buradaki tek problemimiz scale etmek ve micro deployment’ları sağlayabilmek değil.

Peki bu durum birbirlerinden bağımsız(independently) olarak gerçekleşse idi fena olmaz mıydı? İşte bu noktada geleneksel SOA mimarisi yaklaşımı yerine yenilikçi SOA ile MicroService yaklaşımı ortaya atılmaktadır. MicroService yaklaşımı için ise geleneksel SOA’nın getirdiği karmaşıklığı ve yönetimini kolaylaştıran bir kavramdır da diyebiliriz.

MicroService’lere Genel Bakış

monolith-vs-microservices

Resme ilk baktığımızda Monolith yapı gibi tüm sistemin self-contained olarak geliştirilmesi yerine, her bir parçanın/component’in kendi bünyesinde self-contained olarak modüler bir şekilde geliştirildiğini görebilmekteyiz. Bu sektörde uzun zaman geçirmiş bir çoğumuz belkide bundan bir kaç dönem öncesinde servislerin farklı parçalara bölünmesi fikirleri söylenildiğinde, bu sistemin maintenance’ını nasıl gerçekleştireceksin? sistemi nasıl yöneteceksin? gibi soruları hatırlayabilirler. Fakat ilerleyen ve sürekli gelişen teknoloji karşısında üretilen tüm çözümlerin, gün geldiğinde eskidiğini ve kalıcı olmadığını görüyoruz sürekli. Su sebep ile bu yaklaşımda artık yerini yavaş yavaş MicroService mimarisine bırakmaya başlıyor. Çünkü artık firmalar farklı concern’lere sahipler. Bu doğrultuda scaling ve deployment’lar en büyük problem olmaya başlamıştır.

MicroService Mimarisinin Getirdiği Bazı Faydalar

MicroService yapısı sürekli ve plansız bir şekilde büyüyen monolithic yapıdaki servislerin, beraberinde getirdiği karmaşıklığı ve yönetim zorluklarını çözmeye odaklanmaktadır. SOA’ya alternatif bir model değildir kesinlikle. Geleneksel SOA yaklaşımı yerine yenilikçi SOA yaklaşımı ile beraber, biraz önce de bahsettiğimiz gibi karmaşıklığı ve yönetimi pratikleştirmeye çalışan bir kavramdır diyebiliriz.

monolith-vs-microservices-2

Dilerseniz bazı avantajlarına bir bakalım:

  • Servisler farklı dillerde ve farklı framework’lerde geliştirilebilir
  • Birbirlerinden bağımsız olarak her bir servis değişebilir, kolay test ve build yapılabilir
  • Continuous delivery’e olanak sağlar ve hızlı deployment’lar gerçekleştirilebilinir
  • Her bir servisi birbirinden bağımsız olarak scale edebilme olanağı sağlar
  • Her bir servis birbirinden bağımsız olacağı için, code base’i sade ve maintenance’ı kolay olacaktır
  • Versiyonlama kolay bir şekilde yapılabilecektir

Bu saydığımız maddelerin zaten gayet net ve yeterli olacağına inanıyorum. Bunlara ek olarak da geliştirilecek olan yeni özellikler ise kolay bir şekilde implemente edilebilir olacaktır. Peki bu avantajlardan kimler yararlanıyor ve neden? diyecek olursak:

Uber, Netflix, Amazon, Ebay ve dahası… Çünkü bunlar gibi büyük firmaların tek dertleri, yükü kolay bir şekilde scale edebilmek ve deployment süreçlerini continuous delivery ile kolay bir şekilde ele alabilmek. Gerektiğinde saniyeler arasında, dakikalar arasında deployment işlemlerini gerçekleştiriyorlar. Düşünsenize en basitinden monolithic bir yapıda devam etselerdi servis yaklaşımlarına, bu deployment süreçlerini nasıl ele alabileceklerdi? Uber’in SOA ve MicroService ile ilgili deneyimlerini yazdıkları bu blog post’una baktığınızda aşağıdaki bu cümle yeterli olacaktır sanırım:

Adding new features, fixing bugs, and resolving technical debt all in a single repo became extremely difficult. Tribal knowledge was required before attempting to make a single change.

Peki her şey kulağa güzel ve hoş geliyor. Hani olur ya her oyunun bir de bölüm sonu canavarı vardır. Peki MicroService yaklaşımının getireceği bölüm sonu canavarı yani dezavantajları nelerdir de derseniz:

  • Birbirlerinden bağımsızlaşan farklı servisler aynı business objelerini kullanacaklarından dolayı kaçınılmaz bir kod tekrarı meydana gelecektir
  • Servisler farklı platform ve ortamlarda çalışabileceklerinden dolayı yönetim ve monitoring maliyeti ortaya çıkacaktır
  • Birden çok database ve transaction’ların yönetimi zor olabilir

gibi maddeleri sıralayabiliriz. Fakat bu maddelerin zaten bir çoğu adreslenmiş durumda ve otomasyon araçları ile yönetilebilmektedir. Bunlara ek olarak da zaten ihtiyaçlar doğrultusunda MicroService yaklaşımının getirileri göz önüne alındığında ise bu dezavantajlar görmezden de gelinebilir. Yönetim kısmında ise DevOps kavramı ile kolay bir şekilde ele alınabilmekte. Transaction yönetimi işlemlerinede DTC(Distrubuted Transantion Manager) ile çözüm bulunabilmekte.

Gördüğümüz gibi faydasının çok olmasıyla beraber getireceği bir kısım maliyetler de olacaktır. Bu kapsamda benim sizlere aktarabileceklerim şimdilik bu kadar.

Bir sonraki seride görüşmek dileğiyle.

Bu makale toplam (3500) kez okunmuştur.

27
0



Kategori: Architectural SOA

2 Yorum

  1. Çağlar Çağlar

    Gökhan Bey merhabalar,

    Tercih yaparken nerelerde ESB üzerinden servis geliştirimi nerelerde microservisler kullanılmalı nasıl karar verebiliriz sizce ?

    sıraladığınız eksiler/dezavantajlar da tamaen haklısınız ve bir çok anlamda sıkıntılar yaratabilir kurumsal ölçekli firmalarda

    Teşekkürler

    • Bu konu tamamen business case ile alakalı açıkçası. Sen ne kadarını bölebilirsin? Ne kadar küçük, o kadar iyi. 🙂 Kararını maintenance + deployment süreçleri olarak düşünebilirsiniz.

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

*