Monolith’ten mikroservise yolculuk -2
Önceki yazımızda Monolith ve mikroservis yaklaşımlarının artıları ve eksileri üzerine düşünmüştük. Servislerimizin bulunduğu konumu ve gitmek istediğimiz yerde bizi nelerin beklediği hakkında bilgilerimizi topladık. Yolculuğun sonunda varmak istediğimiz yeri biliyoruz artık.
Gideceğimiz yeri biliyoruz. Oraya nasıl gideceğimizi hangi yolları kullanmamız gerektiğini nasıl anlayacağız? Belki de taşınmaya gerek kalmadan daha güzel bir hayata bulunduğumuz yerde başlayabiliriz. Bu soruları kısaca şöyle çevirebiliriz.
- Servisimi ayırmaya nereden başlamalıyım?
- Yapmam gereken değişiklikleri nasıl yöneteceğim?
- Takımımı aldığımız kararlara nasıl dahil edebilirim?
- Gerçekten bu geçişe ihtiyacım var mı?
Bu 4 soru mikroservise geçiş için her zaman aklımızda bulunması gereken sorulardır. Hedefimiz hiç bir zaman hadi mikroservise geçelim herkes böyle yapıyor olmamalıdır. Unutmayın ki mikroservisi olanlar her zaman kazanmazlar =) O yüzden bu 4 soru üzerinden kendimizi kandırmamalıyız. Mevcut sistemde neyi yapamıyoruz yeni sistem bize hangi artıları getirecek gibi kararlar bize nereden başlayacağımızı ve öncelik sıramızı gösterecek.
Eğer bu yapacağımız değişiklikler bize herhangi bir fayda sağlamıyorsa veyahut sağladığı faydayı servisimi ayırmadan da extra alternatif bir yol ile sağlayabiliyorsam; Eski bir tarzda da olsa daha iyi uygulayabildiğimiz ve daha hakim olduğumuz yapıda kalmayı tercih etmeliyiz.
Monolitik bir uygulamdan hangi servisi çıkarmaya nasıl karar vereceğim sorusu bizim için çok kritik. Burada yapmamız gereken mantıksal olarak servislerimizi ayırmamız. Bir birine sınırlı şekilde bağlanmış yapıları gözden geçirmeli ve ana domain’imize ulaşmalıyız.
Şekilde de ifade edildiği üzere bildirim servisi diğer bütün domainlerden çağrılıyor gibi. Fatura domaini diğerlerine göre daha sade bir yapıya sahip. Bu durumda fatura domainini kalan uygulamamızdan ayırmamız kodsal olarak daha kolay olacaktır.
Bir diğer karar verme şekli ise kolay ama bir o kadar da faydalı olanı bulmamızda yardımcı olacak bir yöntem. Domainlerimizi ayırma kolaylığına ve sağlayacağı faydaya göre sıralıyoruz.
Grafikte görüleceği üzere bildirimler servisi bizim için en faydalı ama ayırması en zor olanı gibi gözüküyor. Fatura servisi ise; en kolay ayrılabilecek ama ayırmak bizim sistemimiz için çok fayda sağlayamayacak gibi duruyor. Genel olarak en uygulanabilir ve sistemi rahatlatacak servisin beğeni servisi olduğunu görüyoruz.
Domainimize karar verdik diyelim. Yapacağımız değişiklikleri belirlememiz gerekli. Bu değişikliklerini planlarken yapılması gereken ön önemli şey her zaman hata yapma olasılığımızın olduğudur. Kendimize küçük hedefler ve kontrol noktaları belirlemeliyiz. Hedefimize doğru giderken atacağımız her bir adımı planlamalıyız. Ortaya çıkan her bir sonucu attığım bu adım gerçekten işe yarıyor mu? hata yaptım mı? tarzı sorularla desteklenmeliyiz.
Örneklemek gerekirse; ayıracağım servis için bir veritabanına ihtiyacım olacak ama hangisini kullanmam gerektiğini belirlerken yapacağım çalışmalarda ortaya çıkan sonuç benim için bir kontrol noktasıdır. Şuanki var olan monolith’e göre bana bir avantaj sağlamıyorsa belki de servis olarak değilde modül olarak bölmeliyim.
Bir uygulama için önemli bir karar verdiğimizi göz önüne alırsak takım olarak aynı hedefe doğru koşmanın önemini daha iyi anlarız. Bütün planımız belli ama takım olarak bu ayrıma hazır mıyız? Çok fazla çalışanın olduğu şirketlerde küçük takımlar halinde bölünerek daha hızlı, daha verimli işlerin çıktığını biliyoruz. Peki ama bizim takımımız nelere odaklanmalı ? Gerçekten mikroservise geçmek için geçerli sebeplerimiz olabilir. Bu sebepleri yeri gelince (genelde sistemler zorlanmaya başlayınca) dile getirmek ve çözdüğümüz sıkıntılara odaklanmak takımın da ilgisini çekecektir. Yanınızda sizin ile aynı düşüncede olan bir takım ile product ekibini ikna etmek daha kolay olacaktır. Ürüne olan katkısını hep birlikte artırabilirsiniz. Belirlediğimiz amaç doğrultusunda takım olarak ilerlerken küçük ve kolay hedeflere doğru ilerlemek önemli olabilir. Tamamen %100 kullanışlı, mükemmel bir servis düşünmemektense yola çıkmak daha iyi olacaktır. Buradaki esas nokta bir şeyleri başarma ve ekip olabilme hissini yakalamak olarak düşünebiliriz. Dikkat edilmesi gereken şey ise; bir süre sonra işler tek düze hale gelmeye başladığında yaratıcılığımızı kaybetmememiz ve yeni çözümlere her zaman açık olmamız gerektiğidir.
Tüm bu düşüncelerin ışığında gerçekten bu maceraya çıkmaya hazır mıyız? Yapacağımız her değişiklik, atacağımız her adım gerçekten sistem ihtiyacı doğrultusunda olmalıdır. Yaptığımız sistem gerçekten canlıya çıkamadan tamamlanmış olmaz. Bir sonraki yazımızda geçiş için yola çıkmış olacağız. İlk servisimizin ayrılmasında çok fazla hata yapıp, daha fazlasını öğreneceğiz. Bu yüzden de ufak ama sağlam adımlar atmanın önemini tekrar vurgulamak istiyorum.
