Yazılımda Üretim Bandı Modeli
Yazılım dünyası microservice bakış açısı ile kendini yenileme sürecine son sürat devam ediyor. Monolithic dünyada hazır bir altyapı üzerinde bir kod parçası olarak hizmet verecek iş parçacığı, microservice dünyasında kendi alt yapısına sahip bir uygulamaya dönüşmekte.
Belli bir altyapıya sahip uygulama parçacığını, her bir microservice için tek tek hazırlama maliyeti süreçleri uzatacak, fayda maliyet analizinde infranın sunduğu dinamikliğe yazılım parçacığının erişmesine engel teşkil edecektir. Bir süre sonra yeni bir microservice hazırlamak yerine var olana eklemeye bizi yönlendirecek domain bazlı yaklaşımı bozacaktır. Bu süreci hızlandırıcı önlemler almak ‘microservice’leşmenin temellerindendir.
‘Microservice’leşme kavramını oluşturan bileşenler dinamizmi temsil etmekte. Infra, iş birimi talepleri, ortak kullanılan dil, analiz-tasarım-geliştirme süreçleri, operasyonel süreçler hepsi bütün halinde microserviceleşme zihinsel dönüşümü bakış açısı ile şekillenmesi gerekmekte. Conway’s Law günün sonunda devreye girip yazılımınızın yönüne karar veriyor. Tek yönlü düşünmeden yazılım üretme sürecinizde ve sonrasındaki her bir yapı bileşeninizi bu çerçevede değerlendirmek zorundasınız.
Microserviceleşme ile yazılım üretim sürecinizi bir üretim bandı gibi düşünmek, montaj hattında gerekli bileşenleri birleştirip yeni bir uygulama parçacığı ortaya çıkaracak hazırlıkları yapmak, sizi doğru yönde kalmak konusunda motive edecektir. Paycell’de biz de bu bakış açısı ile microserviceleşirken bir üretim bandı kurmaya çalıştık.
Bu kapsamda;
- parent pom
- archetype
- shared pipeline
- config store
- ortak kütüphane
kavramlarını geliştirdik.
Parent Pom ile, kendini kanıtlamış bütün halinde çalışan kütüphane listesine erişmekteyiz. Ortak versiyon yönetimi, ortak altyapı yönetimi konusunda hizmet vermekte, değişikliğin microserviceler arasında yaygınlaşması konusunda fayda sağlamakta. İçindeki ana bileşenlerimiz;
- java temel configurasyonları
- spring, spring-cloud bileşenleri
- test bileşen configurasyonları
- monitoring bileşenleri
- kod format eklentileri
- kod kalite eklentileri
- image build eklentileri
şeklinde ifade edebiliriz. Artık bu parent a sahip bütün microservicelerimiz bu yetkinliklere sahip olarak doğmakta. Versiyon yenileme süreçlerimizi bu bileşen üzerinden hızlıca yapabilmekteyiz.
Archetype, bir microservice için ilk kodumuzu bize vermekte. İçinde;
- parent pomu barındıran,
- hexagonal mimariye sahip,
- CI/CD için gerekli hazırlıkları içeren,
- monitoring süreçlerimize hazırlanmış,
ilk kodumuzu bu bileşenimiz ile üretmekteyiz. Bu ortaya çıkan ilk kod build aracımızda tanımlandığı gibi ilgili branchler üzerinden ilgili ortamlara kadar çıkmakta. Çalışan bir microservice koduna tek komut ile ulaşıp, içine gerekli iş parçacıklarını ekleyebilir hale geliyoruz. Bu bize, infranın sunduğu dinamikliğe yeni bir microservice eklerken, çekincemiz olan altyapı bileşenlerini hazır etme sürecindeki geri durmayı engellemektedir.
Shared Pipeline, bizim infra ile kod parçacığımızı buluşturan ana bileşenimiz. Çalıştığı kanıtlanmış, belirli kod kalitesine sahip olduğu teyit edilmiş, güvenlik zaafiyeti bulunmadığını gösteren, ilgili microservice imizi veya ortak kütüphanemizi, ilgili ortamlara “Jenkins Shared Library” olarak “Multi Branch Pipeline” yardımı ile çıkmakta. Helm chart yardımı ile GitOps kavramına yakınlaşmaya çalıştık. Kalitesi onaylanmış microservice parçasını içeren imaj ve konfigurasyonları içeren helm chart yardımı ile, canlı ortama kadar geliştirmelerimizi çıkmamıza hizmet etmekte. Ortaya çıkan iş birimi onayı alınmış son paketi promote edip, canlı ortama almaktayız. Test otomasyon bu süreçlerin her bir adımında gerekli şekilde yer almakta.
Config Store, bizim açımızdan GitOps kavramını Helm Chart lar yardımı ile şekillendirdiğimiz bileşenimiz. Temel anlamda her bir microservice için gerekli ortam ayarları, yüke dinamik şekilde cevap verebilmesini sağlayan ayarları, network ayarlarını içermekte. Çalışan parçacığın manifestlerini ortaya çıkan bileşenleri (values.yaml, helm charts) burada tutmaktayız. Olası bir ortamdaki değişikliği git üzerinden saklayıp, sonraki bir durum için(ortam taşıma gibi) yedeklenmesini sağlamaktayız. Helm Chart yardımı ile template mantığı sayesinde dinamik bir şekilde kazanımlarımızı ilgili microservicelere yayabilmekteyiz.
Şirket içi Ortak Kütüphanelerimizi açık kaynak kod yaklaşımı ile yönetmekteyiz. Kendini bir çok projede kanıtlamış, versiyonlanmış bileşenlerimizi microservicelerimizde kullanırken, her ne kadar anti-pattern olsa da, daha rahat hissetmekteyiz. Değişiklik yönetimini belirli bir sayıda onay sonrası kabul etmekteyiz. Kütüphanelerimizi herhangi bir projede kullanılacak seviyede, şirket içi veya projeye özel bir içeriği olmayacak şekilde, geliştirmekteyiz.
Bütün bunlar bir araya geldiğinde kod geliştirme sürecimizi oluşturmakta, dinamizm ile kod geliştirme süreçlerimizi bu şekilde buluşturmaktayız.
Voltran! Voltran! Voltran! :)
