Mikroservis Mimari Notlar

https://dev.to/alex_barashkov/microservices-vs-monolith-architecture-4l1m

Yazılım geliştirirken belirli bir mimaride uygulama çatısı oluşturulur. Bu en başta alınacak kararın uygulamanın ilerleyen zamanlarındaki bütün adımlarına etkisi vardır. Örneğin deployment, teknoloji seçimi .. gibi başta etkisini çok öngörmesek de seçtiğimiz mimari bu sorulara yön verir. Günümüzde en sık rastladığımız monolitik ve giderek yaygınlaşan mikroservis mimari hakkında incelemeler yapacağız. Keyifli okumalar 🤚

🎆 Monolitik Mimari

Uygulama içerisinde yer alan bütün modüllerin tek bir birimde toplanmasını ifade eder. Single Unit olarak da adlandırılıyor. Aşağıdaki resimde görüleceği gibi uygulamanın arayüz kodları, iş gereksinimlerin gerçekleştirildiği sınıflar, veri katmanı hepsi tek bir pakette toplanmıştır. Uygulama çıktısı olarak web uygulamasını düşünürsek tek bir war yada ear üretiliyor ve buda bir sunucu üzerinde deploy ediliyor. Özetle elimizde tek bir tane kod deposu bunun sonucunda bir tane war ve deploy yapılacak tek bir sunucu bulunuyor.

eazybytes

Bu mimarinin bize sağladığı bazı avantaj ve dezavantajlar bulunuyor. Mimari kararlarda yapacağımız işe göre tercihlerde bulunmak gerek o yüzden seçeceğiniz çatının güçlü ve negatif yanlarını iyi anlamak gerektiğini düşünüyorum.

Avantaj;

• Küçük takımlar ve küçük uygulamalar için basit geliştirme ortamı sunuyor. Uygulamanın bütün modülleri tek bir çatı altında o yüzden mimari olarak anlaşılması çok daha basit. Tek bir war dosyası oluştuğu için bunun deployment süreci de yine aynı şekilde basitleşmiş oluyor. Kullanacağınız uygulama server örneğin Tomcat kullanıyorsanız bu dosyayı arayüzden seçip deploy etmek oldukça basit ve anlaşılabilir bir süreç.
• Daha az cross-cutting concerns (log,security,izleme..); tek bir çatıda olmasından dolayı servislerin birbiri ile iletişimi için bir kuyruk yada rest servis kullanmasına gerek yoktur buda güvenlik izleme gibi süreçlerde daha az dikkat edilecek nokta olmasını sağlıyor.
• İyi performans; servisler aynı sunucu içerisinde olduğundan birbiri ile iletişimlerinde network performansından etkilenmezler.
• Test edilebilirlik; tek bir çatı altında olduğundan bir sorunu tespit etmesi yada test süreçleri mikroservis mimarisine göre çok daha basittir.

Dezavantaj;

• Yeni teknolojilere adapte olma zorluğu; Uygulamalar genelde iş kurallarına göre modüllere ayrılır. Örneğin katalog, sepet, ödeme.. gibi farklı modülleri olan bir uygulama düşünelim bunlardan biri için yeni bir teknolojiyi kullanmak istiyorsunuz fakat bütün modülleri etkileyeceğinden herkesin onay vermesi durumunda aksiyon alabilirsiniz. Buda yeniliklere uyumda süreci oldukça uzatabilecek bir durumdur.
• Sınırlı çeviklik; Bu mimarideki uygulamalarda genelde şirketlerde belirli aralıklarında çalışan standart deployment zamanları bulunuyor, uygulama içerisindeki bütün modüller derlenerek paketlenme süreci oluyor. Bu durumda örnek verecek olursak; uygulama içerindeki tek bir modülde geliştirmeniz var diyelim bunu devreye almak için bütün modülleri içeren o zamana uymanız gerekmektedir.
• Tek bir kod deposu ve bunun bakım zorluğu; bir sürü sınıf milyonlarca kod parçası tek bir repository de saklanıyor. Buda projede değişiklik yapmak istediğimizde hem anlama hem de yapılacak değişikliğin etkisini öngörmede zorluk oluşturuyor. Yaptığınız bir değişikliğin etkilediği modüllere göre ilgili arkadaşlara haber verilmesi gerekiyor. Küçük ekiplerde sorun gibi gözükmese de kalabalık ekiplerde kod deposunun versiyonunu yönetmekte zor bir süreçtir.

🎆 Mikroservis Mimari

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

James Lewis and Martin Fowler (2014)

Yukarıda ki açıklama çok güzel ve özet bir tanım olmuş. Bende kendimce yorumlayıp çevirmeye çalıştım; Mikroservis aslında mimarı olarak bir yaklaşımdır; en uygun biçimde bölünmüş her biri kendi başına çalışabilen servislerin birbiri ile iletişiminden oluşur. Bu servisler kendi iş kullarına göre ayrılır ve birbirinden bağımsız / izole bir şekilde deployment süreçleri bulunur. Buda minimum düzeyde merkezi yönetim sağlar örneğin servislerden birini javada spring framework ile oluştururken diğerini go ile yazabilirsiniz. Yada bir servis için postgresql gibi relational veritabanı kullanırken diğeri için nosql bir veritabanı tercih edebilirsiniz.

Aşağıdaki resimde görüleceği gibi arayüz kodları ile backend kodları birbirinden ayrılmıştır. Buda farklı arayüz teknolojileri için beslenebilecekleri ortak servisleri sağlamış oluyor.

eazybytes

Avantaj;

• Her servis için ayrı git reposu bulunuyor; bu yüzden her modül kendi ayrı deployment süreçlerini yürütebiliyor. Buda daha çevik bir yapı sağlıyor.
• Merkezi veri tabanı yerine servislerin ayrı veri tabanları bulunabiliyor, buda veri tabanı bağımlılığını azaltmış oluyor. Örneğin çok fazla arama işleminin olduğu bir modülde elasticsearch gibi arama yönü kuvvetli bir veri tabanı seçilebilir. Yine örnek olarak kullanıcı bilgilerinin tutulduğu diğer bir modülde postgresql veri tabanı tercih edilebilir.
• Hızlı ve basit geliştirme, test süreci; Monolitikde olduğu gibi büyük bir kod deposunu(repository) inceleyip onun içinde kod geliştirmeye çalışılmıyor çok daha özelleşmiş kod deposunda işlem yapılıyor. Buda anlamayı ve adapte olma süresini kısaltıyor.
• Paralel development; ayrı kod deposu olduğu için birbirinden bağımsız şekilde geliştirme süreçleri tasarlanabiliyor. Buda hata durumunda sadece ilgili servisin etkilemesine neden oluyor.

Dezavantaj;

• Daha karmaşık bir sistem; monolitik uygulamada izlenecek tek bir sistem var fakat mikro servislerde onlarca farklı server ve sistem var bu yüzden izlenmesi daha karmaşık bir yapı oluşturuyor.
• Uygulama güvenliğini sağlamak daha zor; monolitik uygulamalarda kullanıcı login ve ardından token kontrolü ile bunu çözmek daha basitken onlarca microservis in birbiri ile haberleşirken güvenli bir iletişim kurmasını sağlamak daha zor bir yapı.
• Performans; daha önce belirttiğimiz gibi servisler farklı sunucularda, containerlar da bulunabiliyor buda network performansının uygulama performansına direk etkide bulunmasına sebep oluyor.

Aslında microservice lerin dezavantajları olarak tanımladıklarımız monolitik uygulamalarda karşımıza çıkmayan zorluklar. Bu maddeleri aşmak için yöntemler / kütüphaneler bulunuyor. Spring Framework için Spring Cloud modülü içerisinde bu bahsettiğimiz konular için oldukça faydalı bağımlılıklar (dependency) vardır.

İki mimarinin de güçlü ve zayıf yönlerine değindik, kişisel kanaatim küçük ölçekli bir uygulama yapıyorsak microservice mimarinin bize sunduğu avantajların yanında çok daha fazla zorluk getireceğinden monolitik ile ilerlemek daha mantıklı geliyor. Fakat çok fazla etkileşimin olduğu büyük ölçekli bir uygulamada microservis mimarinin avantajlarını çok fazla hissedebileceğimizden bu zorluklarına da katlanılabilir gibi duruyor :)

Referanslar;

Udemy üzerinden izlediğim Eazy Bytes ın verdiği Master Microservices with Java, Spring, Docker, Kubernetes eğitim içeriği gerçekten oldukça faydalı (fazlasıyla mantık anlattığı bölümler var eğer sadece kodsal olarak bir eğitim almak istiyorsanız belki uygun olmayabilir), vakti olanların izlemesini tavsiye ederim.