Monolith vs SOA vs MicroServis

Yazılar küçük kalmış ama neyse.

Uygulamalarımızı gerçekleştirirken onları bir mimari çerçeve içinde geliştiririz. Bu mimari bilinç içerisinde geliştirmek de önemlidir zira.

Tek kişi illa mikroservis geliştireceğim diye yola çıkmak hevesinizin kursağınızda düğümlenmesiyle sonuçlanıyor. Tecrübeyle sabit. Bu yüzden mümkünse takım halinde geliştirmek, mimariyi baştan düzgün oturtturmak önemli. Hızlı ilerlemek istiyorsan yola yalnız çık daha ileriye gitmek istiyorsan birlikte çıkmalısın.

Basit düşünmek lazım.

🥱 Monolith uygulama = MVC, basit bloglar veya içerik yönetim sistemleri genellikle monolitik bir mimariye sahiptir. Java Tymeleaf, Django, Dotnet MVC (Microsoft kendi ürünüymüş gibi sunuyor oysaki mimari yapı). Bu uygulamalarda Network’ü incelediğinizde Fetch/XHR kısmı boş olur Doc kısmında istekleri gözlemlersiniz çünkü atılan istekler HTTP request gelen responselar da HTTP responselardır. İlk Django uygulamamda noluoz abi olmuştum bu yüzden bir süre(70 saat). Deploy etmek kolaydır. Codebase tek kodlama dilinden oluşur.

🤑 SOA uygulama = MessageQueue, EventBus barındıran uygulamalar. Genellikle hemhal olunan mimari budur. Hem kişisel projelerinizde kullanabilirsiniz rahatça hem de iş hayatında sıklıkla karşılaşılır. Aşağıda görüleceği üzere servisler birbirlerine bağlıdır ve birbirleriyle iletişim kurarlar. Bu kodun tekrarlanmasını önler kodun daha güvenli ve dayanıklı olmasını sağlar. Yatay ölçeklemeye müsaittir. Ne demek istiyorum gerekirse search servisinin önüne konuşlandırılan bir load balancer ile search servis sayısı arttırılabilir. Bir search servisi çökerse başka bir servis ayakta olacağı için sistem ayakta kalır. Ancak resource kullanımı mikro servis mimarisine nazaran daha fazladır. Çünkü bir servis kuvvetle muhtemel birden fazla api içerir. Auth servisi SignIn, SignUp, RefreshToken, GenerateToken apilerini içerebilir bu servislerin ölçeği mikroservislerde olduğu gibi ayrılmadığı için topyekün ayağa kalkar.

Youtube Örneği (Referans)

😈 Mikroservis = Servisler API seviyesine kadar küçülmüştür. Çok fazla istek alan apileri daha hızlı dillerden Go veya Rust ile yazarsınız. Hatta apilerin ayrılmasıyla önyüzde farklı apilerde farklı teknolojilerin kullanıldığını da görürüz. Eğer tek database varsa ve o database çöktüğünde bütün uygulama çöküyorsa mikroservis mimarisi doğru uygulanmış diyemeyiz. Çünkü tüm servisler database’in ayakta kalmasına sıkı bir şekilde bağlı. SOA daha uygun bir tanım olabilirdi bu tarz bir mimari için. Network ve resource açısından SOA ile karşılaştırırsak SOA bandwith ve network’ü daha çok tüketir. Neden mikroservislerde kablodan geçen bilgiyi azaltmak adına REST yerine RPC kullanılır. Bunun haricinde bir neden varsa da ben bilmiyorum.

Boyut ve Kapsam:

• Monolit: Uygulama tek bir büyük kod tabanında bulunur. Tüm modüller ve bileşenler aynı uygulama içinde yer alır.
• Microservice: Uygulama, küçük, bağımsız servislere bölünmüştür. Her hizmet, tek bir işlevi gerçekleştirir ve kendi kod tabanına sahiptir.

Bağımsızlık:

• Monolit: Bir bileşenin güncellenmesi, tüm uygulamanın yeniden dağıtılmasını gerektirebilir.
• Microservice: Her servis bağımsız olarak dağıtılabilir, güncellenebilir ve ölçeklenebilir.

Teknoloji Çeşitliliği:

• Monolit: Teknoloji yelpazesi genellikle sınırlıdır, çünkü tüm uygulama aynı teknoloji yığınında geliştirilir.
• Microservice: Her servis kendi teknoloji yığınına sahip olabilir, bu da teknoloji çeşitliliğine olanak tanır.

Ölçeklenebilirlik:

• Monolit: Ölçeklenebilirlik genellikle uygulamanın tümünü kopyalayarak veya yükselterek gerçekleştirilir.
• Microservice: İhtiyaç duyulan servisleri yalnızca ölçeklendirerek kaynakların daha etkin kullanımını sağlar.

Bakım ve Sorun Giderme:

• Monolit: Sorun giderme ve bakım genellikle daha zordur, çünkü tüm uygulama tek bir kod tabanında yer alır.
• Microservice: Servislerin bağımsızlığı, sorun gidermeyi ve bakımı daha kolay hale getirir.

Bağlılık ve Bağımsızlık:

• Monolit: Tüm bileşenler birbirine sıkıca bağlıdır, bu da yeniden kullanımı ve değişiklikleri zorlaştırabilir. Örnek vermek gerekise bir MVC uygulamasında view, controller ve model birbirine sıkıca bağlıdır. View değiştiğinde model ve controller’ı da etkileyebilir.
• Microservice: Her servis bağımsızdır, bu da yeniden kullanımı, değişiklikleri ve hatta farklı projelerde kullanılabilirliği kolaylaştırır.

İlk Geliştirme Süreci:

• Monolit: Başlangıçta hızlı gelişme sağlayabilir, ancak zamanla karmaşıklık artabilir.
• Microservice: İlk aşamada zaman alır, ancak uzun vadede esneklik ve ölçeklenebilirlik sağlar. bir adet auth servisi oluşturup, bu servisi diğer bütün uygulamalarınızda kullanabilirsiniz. Benim tavsiyem SOA ile başlamak her zaman.

Tolerans ve Dayanıklılık:

• Monolit: Bir bileşen hatası genellikle tüm uygulamayı etkileyebilir.
• Microservice: Her servis bağımsız olduğu için bir hizmetin hatası diğerlerini etkilemez. Genellikle circuit breaker kullanılır bu sayede servislerin zincir halinde kubernetes tarafından restartlanmaları engellenmiş olur.