☕Monolith'den Mikroservis'e

Mevcut Monolith Uygulamanın Mikroservis Mimari'ye Dönüşüm Serüveni

Bir önceki bölümde yeni bir projeye başlarken Monolith Mimari ile başlamanın daha doğru bir karar olacağını belirtmiş olsak da, Mikroservis Mimari ile başlangıç yapmak her koşulda yanlış olur gibi kesin bir ifade kullanmaktan da kaçınmalıyız. Dolayısıyla Mikroservis Mimari'ye geçiş için iki ana senaryomuz var diyebiliriz;

İlki, mevcut Monolith Mimarinin dönüşümü ve diğeri doğrudan Mikroservis Mimari ile başlama.

İlerleyen bölümlerde detaylıca inceleyeceğimiz; Transaction Yönetimi, Servisler Arası İletişim, Veri Tabanı Tasarımı gibi konular her iki senaryo için de geçerli olmakla beraber, mevcut monolith mimarinin dönüştürülmesi senaryosu ekstra bazı zorluklar ihtiva etmekte. Bu bölümde biraz bunlardan bahsedeceğiz. DDD ve Mikroservis Mimari konu başlığında da bu dönüşüm konusuna atıfta bulunduğumuzu ayrıca belirtmek isterim.

Dönüştürme İşlemine Nereden Başlamalıyız?

Dönüşüm işleminin toplam süresi, dolayısıyla harcanacak toplam efor, uygulamanın bağımlılık ve karmaşıklık seviyesiyle doğrudan ilişkilidir. Birbirine sıkı sıkıya bağlı katmanlar ve modüllerden oluşmuş, ağırlıklı olarak iyi pratiklere uyulmadan geliştirilmiş bir uygulamanın dönüşüm sürecinin daha sancılı geçeceğini tahmin etmek zor değil. Bunun yanında modüler tasarlanmış ve gevşek bağlı, değişime kapalı ancak gelişime açık yapıdaki bir uygulamada ise işimiz daha kolay olacaktır. Buradan, modüler ve gevşek bağlı tasarımın ileride Mikroservis Mimari dönüşüm yapılması planlanan projeler için çok daha önemli hale geldiği sonucunu çıkarabiliriz.

Dönüşümü yapılacak olan uygulama hali hazırda kullanılmakta olan bir ürün ve mevcut monolith yapı üzerine aktif olarak geliştirmeler ve hata ayıklama işlemleri devam ediyor. Haliyle tüm bu geliştirme sürecini durdurup, Mikroservis Mimari dönüşümünü yapma gibi bir lüksümüz olmayacaktır. Nefes alan, üzerinde aktif olarak geliştirme yapılan bir uygulamayı dönüşme gibi zorlu bir işimiz var.

Bu dönüşüm işini 'kodları birbirinden ayırma' gibi basit bir seviyeye indirgemek yapacağımız ilk yanlış olacaktır. Öyle ki, kodları servisler halinde ayrışma işi bu dönüşüm sürecinin belki de en kolay işi olacaktır.

Öncelikle kısa ve uzun vadelik eylem planları hazırlamamız gerekmekte. Mevcut monolith uygulamadan kaç adet servis doğacak, ve bu servislerin sınırlanır neler olacak soruları cevap bekleyen en zor sorular olarak karşımıza çıkacaktır. Bu sorularak nasıl cevap vermeliyiz, servislerin sınırlarını nasıl çizmeliyiz gibi konulara DDD ve Mikroservis Mimari konu başlığında örnek bir senaryo üzerinden ele alacağımızdan, burada detayına girmiyoruz.

Uzun ve hararetli toplantılar sonunda servislerimiz ve bu servislerin sınırlarını belirledik. Domain-Driven Design ile ilerleyeceksek, Bounded-Context'lerimiz ve bunların sınırlarını doğru bir şekilde belirlemiş olmalıyız. Ne demiştik, mevcut monolith uygulama hayatına devam ediyor, öyleyse servislerimizi monolith yapıdan birer birer kopararak kontrollü bir şekilde devreye almamız gerekmekte.Dönüşümü tamamlayana dek, monolith bir uygulamamız ve belirli sayıda Mikroservis ile hayatımıza devam edeceğimiz anlamına geliyor bu.

Burada kişisel bir tavsiye olarak şunu söyleyebilirim; İlk servisi mümkün olduğunca basit ve ayırması kolay olan bir servis olarak seçmenizdir. Gerek servisi geliştirme süreci gerekse DevOps anlamında bu sizin acemilik döneminiz olacağından servisin basit olması hızlı çıktı almanızı sağlayacaktır. Genelde benim aklıma ilk gelen notifikasyon servisi oluyor. Hemen her uygulamada, e-posta ve sms gibi bildirimleri göndermekle yükümlü bir modülümüz oluyor ve bu modülün pek bir bağımlılığı da olmuyor diğer modüllerle. Dolayısıyla notifikasyon işini yapmakla sorumlu modülü monolith yapıdan koparıp istediğiniz bir teknolojiyle servis haline getirerek başlangıç yapabilirsiniz. Eğer bu servis bir veri tabanına ihtiyaç duyuyorsa, mevcut veri tabanınızdaki ilgili tabloları ayrı bir ilişkisel veya NoSQL veri tabanına taşıyarak tam izolasyonu sağlayabilirsiniz. Her servisin mutlaka kendine ait bir izole veri tabanı olması gerektiğini unutmamalısınız. Veri tabanını servisler özelinde parçalama konusuna Veri Tabanı Tasarımı konu başlığında yine örnek bir senaryo üzerinden daha detaylı değineceğiz.

Bir diğer önemli nokta ise, dönüşüm sürecindeyken gelecek yeni bir talebin konumlandırılması konusudur. Konumlandırmadan kastımız geliştirmenin nerede yapılacağı. Burada 3 farklı ihtimal söz konusu;

a) Mevcut Monolith b) Mevcut Mikroservis'lerden birisi c) Yeni bir Mikroservis

Eğer gelen bu yeni istek uygulamamız için tamamen yeni bir özellik anlamına geliyorsa yeni bir Mikroservis olarak geliştirmek önceliğiniz olmalı. Eğer mevcut modüllerden birisiyle bağlantılıysa doğru konumlandırmak o kadarda kolay olmayabilir. Eğer servis sınırlarımızı (Bounded Contex'lerimizi de diyebiliriz) doğru bir şekilde çizdiysek, bu 3 seçenek arasında en doğru olanı çok zorlanmadan bulabiliriz. Aksi halde her yeni gelen istek için bu 3 seçenek arasında kalma ve yanlış kararlar verme ihtimalimiz olacaktır. Bu yüzden servis sınırlarının doğru olarak çizilmesi konusu büyük öneme sahip.