Monolitik ve Mikroservis Mimarilere Genel Bir Bakış

Bugün kurumsal bir proje geliştiriyorsanız mobil, web, masaüstü uygulamalar da dahil olmak üzere birçok farklı ortamdaki istemcileri desteklenmesi beklenebilir. Bu talepler yanında üçüncü tarafların kullanacağı APIler ve web servisler veya mesaj brokerlar aracılığıyla diğer uygulamalar ile entegre çalışması istenebilir.

İş mantığı çerçevesinde yukarıda bahsettiğimiz durumları göz önünde bulundurarak Monolitik ve Mikroservis yaklaşımlarını inceleyeceğiz.

Monolitik Mimari ve Mikroservis Mimarilerini önce ayrı ayrı ele alıp güçlü ve zayıf yönlerini ardından da yorumlar yaparak bu iki yaklaşım hakkında bilgi sahibi olacağız.

İlk adım olarak Monolitik Mimari’yi inceleyelim.

Geleneksel yaklaşımımız olan Monolitik yaklaşım sergilenerek geliştirilen projeler genellikle bir istemci, bir sunucu ve bir veri tabanı içerirler.

• Monolitik yaklaşım için birden çok görevi yerine getirmek için tasarlanmışlardır.
• Tüm görevleri aynı proje üzerinde barındırır.
• İlk iki cümlemiz üzerinden yorumladığımız zaman monolitik yaklaşım ile geliştirilen projeler çok büyük code baselere sahip olma eğilimi gösterirler.
• Projemiz üzerinde gerçekleştireceğimiz çok basit bir geliştirme dahi tüm platformlarda derleme ve test ihtiyacı doğurabilir.

Monolitik Yaklaşımın Güçlü Yönleri:

• Belirli bir işlevsellik yalnızca projemizi ilgilendirdiği için idare etmek daha kolaydır.
• Hata ayıklamak ve test etmek daha kolaydır. Tek bir parça olarak ele aldığımız için uçtan uca test çok daha kolay gerçekleşir.
• Yine son cümlemizi destekler nitelikte tek bir parça olması dolayısıyla dağıtımı çok daha kolaydır.

Monolitik Yaklaşımın Zayıf Yönleri:

• Projemiz büyüdükçe karmaşıklaşacak hatta anlamak oldukça güçleşecektir. Yine bu sebepten ötürü yönetmesi daha zor olacaktır.
• Projemiz üzerinde bir değişiklik yapacağımız durumda projemiz çok büyük ve sıkı sıkıya birbirine bağlı olduğu için aynı güçlük burada da karşımıza çıkacaktır.
• Her bir bileşeni ayrı ayrı ele alamayacağımız için ölçeklenebilirlik projenin bütünü için söz konusudur.
• Yine yukarıda bahsettiğimiz sebeplerden dolayı yeni bir teknoloji geçişi tüm uygulama üzerinde konuşacağımız için kuvvetle muhtemel ilgili süreç projenin yeniden yazılmasıyla sonuçlanır. (Ki biz de şirket olarak tam da böyle bir teknoloji dönüşümünün ortasındayız.)

Şimdi de Microservislere bir göz atalım.

Her bir parça kendi mantığına ve gerekirse kendi veri tabanına sahip olabilir ve her bir parça kendi iş süreçleri bağımsız olarak yürütür.

• Monolitik yaklaşımın aksine bir mikroservis birbirlerine (gevşek) bağlı fakat bağımsız olarak dağıtılan daha küçük uygulamalardan oluşur.
• Geliştirme açısından ele aldığımızda mikroservis geliştirmek görece daha basit süreçler söz konusu olabilir. (Hemen celallenmeyelim.) Çünkü her bir alt görevi yerine getiren uygulamalar üzerinden kapsamları göz önüne alındığında daha küçük boyutlar ve maliyetler söz konusudur.
• Söz konusu her bir küçük parça özelinde herhangi bir programlama dili ve yaklaşımıyla geliştirilebilirler. (Bağımsızlık).
• APIler aracılığıyla birbirleriyle haberleşirler. — APIler uygulamalar arasındaki kimlik bilgilerini ve veri aktarımını kolay bir yolunu sunarak entegre uygulamalar geliştirmeyi kolaylaştırır.

Mikroservislerin Güçlü Yönleri

• Tüm hizmetler bağımsız olarak geliştirilebilir, yeni özellikler ekleyip çıkarabilir ve dağıtılabilir. Bu durum da beraberinde bize esnekliği ve ölçeklenebilirliği getirir.
• Oluşacak olumsuz bir durum sadece ilgili servisi etkileyeceğinden dolayı bakımı ve hata ayıklaması daha kolay olacaktır.
• Ekibimize yeni katılan arkadaşlar daha küçük parçalar ve dolayısıyla daha basit iş mantıklarıyla karşılacağı için anlaşılması ve yönetilmesi aynı ölçüde daha kolay olacaktır.
• Teknoloji ve dil seçimindeki esneklik daha yüksek çeviklik ve düşük riski beraberinde getirir.

Mikroservislerin Zayıf Yönleri

• Sistem dağıtık bir yapıda olduğu dolayısıyla tüm modüller ve veri tabanları arasındaki bağlantıları belirlememiz ve kurmamız bizim için ekstra karmaşıklığın içerisine çekecektir.
• Yine tüm bileşenlerin bağımsızlığı bizim için tümünün bağımsız olarak dağıtılması gerekliliğini getirecektir.
• Bağımsız olarak dağıtılan çok sayıda bileşen mikroservis tabanlı bir çözümü uçtan uca test etmeyi ve hata ayıklamayı çok daha zor ve maliyetli hale getirecektir.

Şimdi bir sürü cümle kurduk. Bu cümleler üzerinden yorumlayarak sona doğru gelelim.

Peki Microservis Yaklaşımı mı? Yoksa Monolitik Yaklaşım mı?

Bu noktada cevabımız için şöyle genel bir cümle kurabiliriz diye düşünüyorum.

Söz konusu proje ve kurumun ihtiyaçları yanında geliştirici ekibin yetkinlik ve bilgi birikimi gibi birçok farklı kıstas üzerinden bir değerlendirme yapmak gerekir.

Popülerlik derdine girişeceğimiz bu yolculukta kaos ve sonrasında fail olmak işten bile değil.

— Küçük bir takımı ile mikroservis karmaşıklığında boğmak gereksiz olabilir.

— İçerisinde çok fazla iş mantığı olmayan, yüksek ölçeklenebilirlik ve esneklik gerektirmeyen basit projeler için Monolitik yaklaşım iyi bir seçimdir.

Önceki cümlemiz ile bağımlı olarak hızlı aksiyon almamızı gerektiren, uygulamanın en kısa sürede sonlandırılması beklenilen bir ortamda Monolitik yaklaşım iyi bir seçimdir.

Başlangıçta daha az maliyet ile iş fikrini doğrulamak adına Monolitik yaklaşım işe yarar sonuçlar getirir.

— Microservis en temelde uzmanlık gerektiren bir konudur. Yeterli uzmanlığa sahip olmayan bir ekip için beklentileri boşa çıkarabilir.

Ki sadece mimari bilgisi kendi başına başına yeterli değildir. Burada birbirine sıkı sıkıya bağlı kavramlar olan DevOps ve Container uzmanlıklarına da ihtiyaç duyulur. Dolayısıyla güçlü kaynaklara sahip olmak gerekir.

— Mikroservislerle çalışmak sistemi ayrı işlevlere ve sorumluluklara bölmek anlamı taşır.

— Ölçeklenebilirlik ve esneklik gibi konuları göz önünde bulundurarak çok büyük ve birden fazla modül barındıran ve kullanıcı yoğunluğunun söz konusu olduğu projeler için mikroservis yaklaşımı iyi bir seçimdir.

Araştırmamızın ve makalemizin sonuna geldik. Umarım fayda sağlayabilmişimdir. Kendinize çok iyi bakın. :)