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.
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.
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:
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.
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 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.
Dilerseniz bazı avantajlarına bir bakalım:
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:
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.
{:en}In today’s technological age, we typically build our application solutions on event-driven architecture in order…
{:tr} Makalenin ilk bölümünde, Software Supply Chain güvenliğinin öneminden ve containerized uygulamaların güvenlik risklerini azaltabilmek…
{:tr}Bildiğimiz gibi modern yazılım geliştirme ortamında containerization'ın benimsenmesi, uygulamaların oluşturulma ve dağıtılma şekillerini oldukça değiştirdi.…
{:tr}Bildiğimiz gibi bir ürün geliştirirken olabildiğince farklı cloud çözümlerinden faydalanmak, harcanacak zaman ve karmaşıklığın yanı…
{:tr}Bazen bazı senaryolar vardır karmaşıklığını veya eksi yanlarını bildiğimiz halde implemente etmekten kaçamadığımız veya implemente…
{:tr}Bildiğimiz gibi microservice architecture'ına adapte olmanın bir çok artı noktası olduğu gibi, maalesef getirdiği bazı…
View Comments
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.