Uzun yıllardır proje geliştiriyoruz ve bu gelişimle birlikte aslında biz de gelişiyoruz. Bu gelişmelerin bir kısmına teknolojinin bizden önce gelişmeye devam etmesi eşlik ediyor. Yeni diller, yeni veritabanı yönetim sistemleri, yeni veri yapıları gibi konular hayatımıza girdikçe aslında bizim de projeleri dizayn stillerimiz de değişiyor.
Teknolojik gelişmelerin yanı sıra, projeler büyüdükçe yaşadığımız zorluklar da bizim proje dizayn stillerimizi en başından tekrardan düşünmemizi gerektiriyor. Bunlardan bir tanesi de projenin monolithic mimaride mi yoksa microservice mimarisinde mi olacağı tabiki.
Daha küçük projeler geliştirirken, daha küçük ekiplerde projelerle ilgili ölçeklendirme ihtiyacı hissetmediğimiz için aslında monolithic yapıda gayet mutlu bir şekilde kodlarımızı yazıyor, testlerimizi yapıyor ve yayına alarak hayatımıza devam ediyorduk. Ta ki uygulamalar artık devasa boyutlara ulaşana, modül bazlı revizyonları yaptığımızda o büyük projenin başka noklarının patlaması endişesini yaşayana kadar.
Monolithic Mimari
Monolithic yapı kelime anlamı olarak teklik ifade etmektedir. Monolithic mimari ise, bir projenin/sistemin tek bir bütünden oluşmasını nitelemektedir. Geliştirdiğimiz uygulama, tüm modülleri, fonksiyonları, bağlantıları kendi içinde ayrı katmanlara ait olsa da nihai olarak tek bir isim alanı veya tek bir çatı altında buluşmaktadır. Tabi bunun bazı olumlu yönleri de vardır.
Eğer geliştirdiğiniz proje küçük veya orta ölçekli bir proje ise, geliştirme ekibiniz birbiriyle çok yakın olan 1-2 kişi veya tek kişi ise monolithic yapıda uygulama geliştirmek mantıklıdır. Daha küçük ölçekli yapılarda, parçaları yönetmek zorlaşacağı için tek bir yapıyı yönetmek de izlemek de daha kolay olacaktır. Bu da monolithic mimaride yazılım geliştirmeyi zorunluluk haline getirebilir. Peki ya olumsuz yönleri?
- 4 farklı işlem gerçekleştiren bir uygulama inşaa ettiğimizi varsayarsak, ortak kullanılan fonksiyonları da muhtemelen tekrar yazmamak için ortak bir noktada toplamışızdır. Peki ya o ortak kullanılan fonksiyonların bir tanesinde hata alırsak? Veya diğer alanlardan bir tanesinde? Uygulama tamamen çalışamaz hale gelebilmektedir.
- Versiyon yönetimi zorlaşmaktadır. Bir fonksiyonla ilgili işlem geçmişini aradığımızda, farklı fonksiyonlar için defalarca alınmış güncellemeler arasından, o fonksiyon özelinde yapılan güncelleme geçmişine erişmemiz oldukça zorlaşacaktır.
- Bir fonksiyonda yapılacak değişiklik, farklı method ya da fonksiyonları etkileyecek, bir alanda yapılan düzenlemeler başka bir alanda hata almamıza sebep olacaktır.
- Birden fazla kişilik ekiplerde geliştirilen kodlarda, bağımlılık kontrolleri giderek zorlaşacaktır.
- Ekipte çalışan kişi sayısının artması sebebiyle, tek platform halinde geliştirilen monolithic mimarinin dil bağımlılığı da artacaktır. Kişi sayısı artmasına, teknolojinin gelişmesine rağmen, projenin geliştirildiği dil ve teknolojiler kullanılmaya devam edilmek zorunda kalacaktır.
- Uygulamanın en küçük ve belki de çok fazla kullanılmayacak bir parçasında yapılan geliştirmelerin yayına alınması için tüm projenin durdurulması, projenin tekrar derlenmesi ve yeniden yayına alınması gerekmektedir.
Yaşanan bu tarz zorluklar bizi monolithic mimariden, daha parça bazlı mimarilerde çalışmaya götürmektedir. Bu tarz bir uygulama, tek bir ajandada herkesin farklı sayfalarda not tutmasına benzer bir yapı haline gelmekte, belirli aşamalardan sonra takibi de çok fazla zorlaşmaktadır. Peki, tüm çalışanlar tek bir ajanda kullanmasa da, her konuya özel defterler alsak, o konu ile ilgili daha küçük defterlerde daha küçük notlar alınarak, birleştiğinde daha anlaşılabilir bir hal alsa?
Microservice Mimarisi
Yazılım geliştirirken unutmamamız gereken temel prensiplerden bir tanesi sürdürülebilirliktir. Sürdürülebilirlik, sıfırdan doğan, kullanılmaya başlanan bir uygulamanın/yazılımın/projenin ona ihtiyaç duyulduğu süre boyunca yaşam hayatına devam edebilmesi ve bu yaşam süreci boyunca da gelen istek ve talepler doğrultusunda evrilebilmesidir. Monolithic mimaride bu kurala uyulmamakta, projeler büyüdükçe kontrolleri ve sürdürülebilirliği de azalmaktadır.
Microservice mimarisinde temel özellik, her işi yapan parçanın kendi başına, sistemin bütününü etkilemeden çalışabilmesidir. Bir modül, kendisine gelen veriyi işleyip, geriye belirli kriterlerde değer döndürmeye odaklanmış olarak çalışıyorsa, sistemin diğer bölümlerinde herhangi bir hata da olsa, çalışmasa da tek başına kendisine gelen değerleri işleyip, veri döndürebilmektedir. Dolayısıyla, microservice mimaride geliştirilen uygulamalar, parça parça geliştirilip toplamında tek bir bütünü oluşturmaktadır. Son kullanıcı her ne kadar sistemin hangi mimari ile geliştirildiğini anlamasa da, sistem kendi içinde bir bütün olarak çalışmaya devam etmektedir. Tabiki bu mimarinin de kendine has olumsuzlukları vardır. Çok fazla parçaya bölünmüş projelerin takip edilmesi ve yönetilmesi de zorlaşabilmektedir. Tek bir bütün halinde çalışan bir yapıya nazaran, 14 tane modülün birleşerek oluşturduğu bir projenin modüllerinin yaşam süreçlerini takip etmek de zorlaşabilir. Her bir modülün testleri, izlenebilirliği zor bir hal alabilir. Ama o modülden sorumlu kişiler atanabilirse bu zorluğun da üstesinden gelinebilir.
“Microservice mimarisi, uygulamayı bir bütün olarak geliştirmek yerine, küçük parçalar halinde geliştirilmesini amaçlayan bir felsefedir.”
- Geliştirilen projenin tümünü ilgilendirmeyen sadece bir alanı ilgilendiren bir güncelleme yapılmak istendiğinde, sadece o servis parçacığında güncelleme yapılarak atılacağı için, sistemin tamamını durdurmaya gerek yoktur.
- Okulabilir ve anlaşılabilirdir. Herhangi birisi projenin tamamına hakim olmasına gerek kalmadan, sadece o modülü anlayarak o modüle ilişkin geliştirme yapabilir.
- Versiyonlama ve yönetim oldukça kolaydır. Bir modül veya parçacıkla ilgili versiyon, geçmiş kayıtların okunması ve anlaşılması kolaydır. Modüle özel versiyonlama yapılabilir.
- Kalabalık ekiplerde herkesin aynı teknolojiye hakim olmasını beklemek yerine, o modül için hangi dil, iletişim teknolojisi veya veritabanı daha sağlıklı çalışacaksa o dilde geliştirme işlemi yapılabilir. Yapılan geliştirmeler modüller halinde birbiri ile standart süreçlerle haberleştiği için sorunsuz çalışmaya devam edilecektir. Örneğin satış yapan bir sisteminiz var ve kurları sürekli olarak takip etmek istiyorsunuz. Bunu ayrı bir servis parçası olarak geliştirip, C#, .Net Core ile API Entegrasyonunda zorlanıyorsanız Go dilinde daha basit bir şekilde yapıp, ihtiyacınız duyduğunda size anlık veriyi çekip getirecek bir servisi farklı bir dilde geliştirip mimarinin içerisine dahil edebilirsiniz.
Nihai olarak değerlendirecek olursak, microservice mimarisi daha iyidir ve tüm projelerde bu mimari tercih edilmelidir gibi bir yaklaşım kesinlikle doğru değildir. Proje bazlı değerlendirme yapılmalı, monolithic yapıda geliştirmenin avantajları ve dezavantajları ne olur, microservice mimarisinde geliştirmenin artıları eksileri nelerdir değerlendirerek karar verilmelidir. Karar verilirken, projenin süresi, büyüklüğü, çalışacak personel sayısı, personellerin turn-over oranları, kullanılan teknolojiler, hakim olunan teknolojiler gibi parametreler de göz ardı edilmemelidir.
