Monolitik Mimari Nasıl Mikro Servis Mimarisine Dönüştürülür: Strangler Deseni
Monolitik mimaride kurgulanmış ve uzun süredir yaşayan bir sisteminiz / uygulamanız var ve artık bu mimarinin ihtiyaçlarınızı karşılamadığını düşünüyorsunuz. Bunun için modern bir mimariye geçmek istediniz ve iyi bir araştırma sonrası mikro servis mimarisine geçmeye karar verdiniz (Bu cümle ile alakalı bu ve şu makalemi okumanızı tavsiye ederim). Önünüzde iki seçenek var: Ya uygulamanızı yeni mimari ile sıfırdan yazıp, Big Bang yaklaşımı ile tek seferde güncelleyeceksiniz ya da Strangler Deseni (Strangler Pattern) ile parçalı bir geçiş yaparak eski sistemi yavaşça küçültüp yeni sistemi yavaşça devreye alacaksınız. Bu makalede kısaca Big Bang konusuna bakıp, sonrasında Strangler Desenini detaylıca ele alacağız.
Big Bang Dönüşüm
Bir monolitik uygulamayı mikroservis mimaride yeniden yazmak ve big bang yaklaşımı ile tek seferde devreye almak ciddi bir maliyet çıkaracaktır. Maliyet konusunda sorununuz yok diyelim. Ancak bu yaklaşım sonucunda maliyet dışında birçok sorunla karşılaşacaksınız. Sitemi tek seferde tekrar yazıp yine tek seferde devreye alacaksınız. Bu nedenle çok iyi bir entegre test süreci yürütmeli ve tüm sistem parçalarının ciddi sürprizler çıkarmadan, senkron bir şekilde çalıştığından emin olmalısınız. Yıllardır çalışan, belki de sonsuza kadar değişiklik yapmaya bile ihtiyaç duymayacak, artık kimsenin arka taraftaki çalışan kurgusunu bilmediği onlarca alanı yeni yapıya taşıyıp, birbiri ile tek seferde düzgün bir şekilde haberleşmelerini ummak büyük bir risktir. Eski sistemi yenilerken tüm sistemi bilen uzmanlara sahipseniz bunu deneyebilirsiniz ama tüm sistemi bilen uzmanlara sahip olmak da oldukça zordur. Sistemin big bang geçişi sürecinde kesilmesi veya tamamen durması risklerini de düşünmelisiniz.
İşin teknoloji ve yeni talepler boyutuna bakarsak, big bang yapana kadar geçen süre bazen o kadar uzun olabilir ki seçtiğiniz teknoloji bile eskiyebilir. Bu durumda teknik borcunuz da artacaktır ve bunu kapatmak da çok zor olacaktır. Ayrıca yeni talepleri eski sistemde yapmak istemeyeceksiniz, istekler yeni sistemin canlıya çıkışına kadar bekleyecek. Böylelikle yeni taleplerde ciddi gecikme yaşanacak.
Strangler Deseni (Türkçe’ye Strangler=Boğucu şeklinde çevrilmiş ama ben makalede uluslararası terminolojiyi kullanacağım) ile yukarıdaki risklerin birçoğunu eleyebilirsiniz. Şimdi Strangler Deseni nedir ve nasıl uygulanır onu görelim.
Strangler Deseni Nedir
Monolitik mimariden her seferinde seçilen bir fonksiyonaliteyi kademeli bir şekilde mikroservis mimarisine dönüştürerek, zaman içinde tüm fonksiyonaliteleri monolitik mimariden mikroservis mimarisine taşımak anlamına gelen tasarım desenidir. Monolitik servisler ile mikro servisler bir süre boyunca eş yaşamlı (co-existance) bir şekilde yaşarlar ve mikro servisler zaman içerisinde stabil bir şekilde çalışmaya başlayınca monolitik uygulamadaki servisler boğulur (Strangler edilir) ve kaldırılır. Bu dönüşüm sürecinde iş ihtiyaçlarından doğan yeni talepler de mikroservis mimarisinin üzerinde ele alınmaya çalışılır.
Bu tasarım deseni adını, ağaçlara dallarından yapışan ve ağacın kaynaklarını kullanarak zaman içerisinde yukarıdan başlayıp köke kadar inen ve ağacı kurutan Strangler Fig (https://en.wikipedia.org/wiki/Strangler_fig) bitkisinden esinlenerek verilmiş. Strangler ifadesini ilk Martin Fowler kullanmıştır, dileyenler bu konudaki şu makaleyi okuyabilirler.
Strangler deseni ile yeni kurduğunuz mikroservis mimarisinin avantajlarından hemen faydalanmaya başlarsınız. Özellikle takımların bağımsız bir şekilde kendi pipeline’larını yönetmeleri ve sürekli yaygınlaştırma yapabilmeleri kazanacağınız güzel özellikler olacaktır.
Strangler Deseni Aşamaları
Strangler Deseni temel olarak 4 aşamadan oluşur:
1- Tanımlama (Identify)
• Monolitik uygulamanın analiz edilmesi.
• Uygulamanın tamamının veya dönüşüm için gözünüze kestirdiğiniz bir kısmının Boundex Context’lerinin belirlenmesi (Bounded Context Domain Driven Design başlığı altındaki bir konudur, ama kısaca birbiri ile sıkı bir şekilde alakalı Domain Modellerin bir anlam bütünlüğü oluşturduğu yapılardır diyebiliriz).
• Dönüşüm için en uygun, en küçük ve en kolay Bounded Context’in seçilmesi. Bu Bounded Context çok değişiklik almayan, genellikle stabil olan bir alan olmalıdır. Stabil bir yapıyı neden ilk olarak güncelleyelim diye akıllara gelebilir, ancak mikro servis mimarisi doğasınca karmaşık olduğu için stabil bir yapıyı dönüştürmek dönüşüm sürecinde bu yapının çok talep almayacağını ve çok değişmeyeceğini garantileyecek ve bu da yeni mimarinize daha çok odaklanmanızı sağlayacaktır.
2- Dönüşüm (Transform)
• Belirlenen Context’in mikroservis olarak oluşturulması ve yayınlanması.
3- Eş yaşam (Co-exist)
• Uygulamalarınız hala eski servisleri de kullandığı için ve tüm trafiği yeni yaptığınız mikro servise yönlendiremeyeceğinizden, bu çoklu yönlendirmeyi yapan bir ara sınıf (Facade) oluşturup trafiği bu sınıf üzerinden aktarmanız gerekecektir. Eski servis ve yeni servis aynı anda trafik aldığı için bir süre boyunca eş yaşam (co-existance) süreceklerdir. Bu tarz mimarilerde facade sınıflar genellikle API Gateway olarak kurgulanırlar. Dikkat edilmesi gereken bir nokta, ilgili API Gateway’in performans sorunları yaşamayacak ve tek hata (yıkım) noktası (single point of failure) olmayacak şekilde tasarlanması gerekliliğidir.
4- Eleme (Eliminate)
• Eş yaşamlı sisteminizde artık ihtiyaç duyulmayan eski sitemi / servisi kaldırılarak uygulamaların yeni mikro servise bakmalarını sağlamak.
Dönüşüm için yeni bir mikroservis seçilerek yukarıdaki döngü tekrarlanır.
Strangler deseninin bir diğer ismi de Transform, Co-existance, Eliminate desenidir. Tabi gerçekte yukarıdakilerden çok daha detay konular var. Özellikle yeni oluşturulan mikro servislerin pipeline yapısı nasıl olacak, eş yaşam süresince verinin çoklanması mı yoksa sadece bir tarafta tutulması mı tercih edilecek gibi birçok sorunun cevaplanması gerekecektir.
Sonuç
Güncel monolitik uygulamanızı modern bir mikro servis uygulamaya dönüştürmek kulağa güzel gelse de bu yolculuk oldukça meşakkatlidir ve iyi bir şekilde tasarlanmalıdır. Strangler Deseni size bu yolculukta oldukça yardımcı olacaktır. Kurgulayacağınız Strangler yapısında ilk çıktıyı görmek uzun süre alabilir ama mekanizmanızı oturttuktan sonra, yeni bir mikro servis yapıp eski sitemi devre dışı bırakmak daha kolay hale gelecektir. Strangler ile riskiniz azalacak, hatta hatalı dönüştürdüğünüzü düşündüğünüz bir mikroservisinizi belki de çöpe atıp yeniden yapabileceksiniz. Big Bang dönüşüm yapmış olsaydınız bu konudaki şansınız çok düşük olacaktı. Bütün bu bilgiye rağmen hala “Big Bang’ten şaşmam” diyorsanız “iyi şanslar, kolay gelsin” diyerek makaleyi sonlandırıyorum :)
Kaynaklar
https://dzone.com/articles/monolith-to-microservices-using-the-strangler-patt
https://martinfowler.com/bliki/StranglerFigApplication.html
https://cvsudheer.medium.com/stranger-pattern-6d2144ccc9c2
https://ichi.pro/tr/mikro-hizmet-mimarisi-ve-en-onemli-10-tasarim-modeli-143251434109505
https://dianadarie.medium.com/the-strangler-fig-migration-pattern-2e20a7350511
