Mikroservisler ve getirdiği çözümler
Son birkaç senedir çok meşhur olan bir tasarım şablonundan bahsetmek istiyorum. Benimde son zamanlarda çok ilgi duyduğum ve araştırdıkça neden bir çok firmanın benimsediğini ve uyguladığını gördüğüm mikro servislerden biraz bahsedeceğim. Örneklerimi .NET üzerinden vereceğim.
Örnek projemizin C# dilinde .NET ile yapıldığını, hafızada tutulması gereken veriler için Redis ve persistent veri için de Microsoft SQL kullanıldığın varsayalım.
Mikro servis mimarisi daha yaygınlaşmadan önce uygulamaları genelde monolitik denilen bir yapıyla yapıyorduk. Öyle ki uygulamanın geliştirme süreci bittiğinde uygulamayı çalıştırmak için elimizde bir dosya ve bu dosyaya bağlı başka dosyalar oluyordu. Ve bu dosyayı çalıştırabilmek için sunucumuzda ilgili .NET sürümlerinin yüklü olması ve bunun gibi daha bir çok bağımlılığın yüklü olması gerekiyordu (Microsoft SQL sunucusu ve Redis yüklenmesi gibi).
Uygulamamız gerektiği gibi problemsiz çalışmakta olsa bile ilerleyen safhalarda uygulamamıza yeni özellikler katmak istediğimizde ilgili solution içerisinde ki katmanlarımızda değişiklikler yapıyoruz ve bu değişiklikleri production sunucumuza uygulayıp (her ne kadar eksiksiz test yapılmış olsa da) herhangi bir sürprizle karşılaşmadan uygulamamızı güncellemeyi umuyoruz. Bu esnada uygulama geliştirilen ortamdan tutunda geliştirme esnasında kullanılan .NET, mssql ve redis sürümleri dahil bir çok şey farklı olabilir ve bu farklılıklar production sunucusunda hata vermeye ve çalışmayı durdurmayla sonuçlanabilir.
Burada single point of failure denen bir durum ortaya çıkarmış oluyoruz. Çünkü tek bir veri tabanımız mevcut ve uygulamamızın sadece tek bir çalışma noktası var. Yani herhangi bir potansiyel hata durumunda bütün uygulamamızı riske atmış oluyoruz. Düşünün ki bir şekilde SQL sunucusu kapanırsa uygulama çalışmaz hale gelir veya redisten bir veri okunması gerekiyorsa ve redis bir şekilde kapanmışsa tekrardan uygulama çalışmaz hale gelir. Ve bunların hepsinin sadece tek bir sunucuya bağlı olmasından bahsetmiyorum bile. (Sunucu giderse her şey gider).
Bu arada monolitik yaklaşımın yanlış olduğunu düşünmüyorum sadece büyük ve çok büyük ölçekli projelerde projeyi maintain etmenin neredeyse imkânsız olduğunu söylüyorum. Düşük ve orta ölçekli uygulamalarda kullanılabileceğini düşünüyorum.
Tüm bu problemlerden sıkılan yazılımcı arkadaşlarımız tek bir noktadan çalışan bu gibi monolitik uygumaları parçalara böldüler ve bu mimarinin adına da SOA adını verdiler (Service oriented architecture). Mikro servis mimarisi de SOA mimarisinden yola çıkarak türemiştir.
Bir örnekle şu şekilde açıklayabilirim: Bir e-ticaret uygulamasının sepet, sipariş, ürünler, kategoriler, kampanyalar, ödeme sistemi, kargo takibi gibi özelliklerinin her birinin apayrı birer sunucularda kendilerine ait bir veri tabanı ile çalıştığını ve bu farklı uygulamaların aralarındaki iletişim sağlamak için de bir mesajlaşma sistemi olduğunu düşünün. (Örneğin, sepet uygulamasında sepete bir ürün eklemek için ürünler uygulamasından veri alması gerekir.). İşte mikro servis mimarisi tam olarak bundan ibaret. (artık bu uygulamalar için servis ibaresini kullanacağım)
Bu mimari öncelikle fazla kaynak gerektiren, test ve hata ayıklama işlemlerini zorlaştıran, zor bir deployment süreci bulunan ve yönetmenin zor olduğu bir mimari. Peki tüm bunlara rağmen neden bu mimariyi kullanıyor koca koca firmalar?
Düşünün ki sipariş servisimiz bir hata verdi ve kapandı, bu durumda artık uygulamanız halen daha çalışmaya devam edecektir. Bir süre sipariş alamayacaksınız ama bu süre zarfında sipariş vermek isteyen ziyaretçilerin istekleri bir mesajlaşma servisi tarafından toplanıp sipariş servisi tekrardan aktif hale geldiğinde işlenecektir. Hem uygulamanız hata verip kapanmadığı için hemde sipariş servisi kapalı olduğu halde ziyaretçiler sipariş verebildiği için (bunu ziyaretçinin bilmesine gerek yok elbette) ziyaretçileriniz ile aranızda ki güven köprüsü sarsılmayacak (ekranda bir hata görmeyecek ve sitenizin her daim aktif olduğunu bilmek ona güven verecek).
Örneğin uygulamanızda yapay zeka veya makine öğrenmesini kullanan bir servis gerekiyor artık .NET teknolojilerine bağımlı olmadığınız için Python bilen bir personel istihdam edebilirsiniz. Farklı farklı teknolojilerden çok yetenekli kişilere ulaşıp onlarla çalışmanız mümkün.
Ziyaretçileriniz arttı ve artık eliniz de ki kaynaklar yetmiyorsa yeni sunucular ekleyebilir ve uygulamanız hiç kapanmadan dahi kapasitesini arttırabilirsiniz.
Ve bunun gibi daha bir çok faydası ile birlikte mikroservis mimarisinin yazılım sektörünün seyrini değiştirdiğini düşünüyorum. Devasa boyutta ki uygulamaların önü yine mikroservis mimarisi ile açılmış oldu.
Okuduğunuz için teşekkür ederim.
